По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 27.08.03 04:23
Оценка: 4 (2) +1 -9
Сразу некоторые ответы на вопросы, возникшие в этом
Автор: DOOM
Дата: 26.08.03
топике.

Дельфи действительно швыряет EAbstractError при попытке создания экземпляра абстрактного класса, и это правильно, что в именно в run-time, поскольку пусть у меня следующая иерархия классов:
TAbstractClass = class ....
TClass1 = class(TAbstractClass)...
TClass2 = class(TAbstractClass)...
Я хочу создать массив, в котором будут и TClass1 и TClass2 — понятно, что надо создать массив TAbstractClass. В С это можно решить только используя указатели на класс, а в Дельфи есть только указатели на класс, просто это все неявно. И при их организации ООП это единственный способ. Поэтому-то мне и интересно как это сделано в С. К сожалению сейчас у меня нет времени покопаться в VS-ке и погладет как на asm'е все это выглядит.

По поводу того, что у Дельфи меньше возможностей... Приведите хоть один пример, который нельзя реализовать на Дельфи, но можно на C++. Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов, но это все очень, на мой взгляд, сомнительные вещи без которых вполне можно обойтись(макрос меняется inline функцией и результат одинаковый, шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).


По поводу IDE — тут по-моему вопросов нет. В дельфи оно факт удобнее.

По поводу библиотек — MFC vs VCL. VCL — действительно объектная библиотека, в которой обработка событий инкапсулированна в объект, а не реализуется посредством вставляемых куда-то макросов и т.п.

Теперь ваща очередь...

15.12.03 10:55: Перенесено из 'Философия программирования'
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 03:46
Оценка: 30 (5) +1
Здравствуйте, WolfHound, Вы писали:

WH>А оно РЕАЛЬНО надо? Почему бы просто не сотворить абстрактную фабрику?


Можно. Но зачем? Она уже сделана!
Поясняю:
Фактически, объявление каждого класса в Delphi автоматически вводит 2 типа и 1 объект.
Первый тип — собственно сам класс (например TMyClass). Второй тип — метакласс, class of TMyClass, он невидим до объявления, тем не менее можно считать, что он есть. Существует синглтон-объект этого типа, собственно TMyClass.
В случае наличия виртуального конструктора, этот метакласс автоматически становится фабрикой. Весь прикол в том, что иерархия фабрик в точности повторяет иерархию классов! Я навскидку не скажу, как это воспроизвести в плюсах. Дело в том, что тот самый метод фабрики, который и производит полезные объекты, (виртуальный конструктор) возвращает разные типы.
Если у меня есть class TA с constructor Create(I: Integer); virtual и class TB(TA), и объявлены метаклассы TAClass и TBClass, то:
TAClass.Create имеет тип результата TA;
TBClass.Create имеет тип результата TB;
при этом в люое место, где ожидается TAClass можно передать TBClass, как будто он является его наследником (что и делает его абстрактной фабрикой).
Собственно, вся VCL построена ровно на constructor TComponent.Create(AOwner: TComponent); virtual;
Другие фабрики используются реже (есть в коллекциях). Именно она позволяет читать DFM файлы: по имени класса находится указатель на его метаобъект, и на нем вызывается Create. При этом
1. сам Create не теряет типизации. Он возвращает объект нужного класса. Поэтому, без введения нового метода я могу потребовать где-то TControlClass вместо TComponentClass, и компилятор будет знать, что вызов на нем Create(AOwner) вернет TControl.
2. Мне не нужно писать код этих методов — я пишу только ту часть, которая относится к инициализации объекта. Поэтому я застрахован от ошибок. Грубо говоря, в плюсах я рискую написать в TA* TBClass::Create(int I) {return new TC(I);}
3. Любые изменения в иерархии классов автоматически отражаются в иерархии метаклассов.

Кроме всего этого, я имею бонус в виде возможности вставить в метакласс методы, как статические, так и виртуальные. Их можно вызывать и на объектах, и на классах.

Таким образом, за мелкими деталями реализации следит компилятор. И это приятно. Всякий паттерн хорош; а тот, который поддержан языком — хорош вдвойне. Ибо эффективен.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка: -4 :)
DOO>>Кстати, а много ли люди видали драйверов написанных на С++, а не на С?
DOO>>MS сами рекомендуют невыеживаться и писать не на асмах и С++ дрова, а на обычном С. Да и хороший пример ОС разработанной на языке высокого уровня это *nix — между прочим тоже С, а не C++.

VDZ>Э... типа... опаньки...

VDZ>Если Вы не видели критичного ко времени софта, написанного на С++, не надо говорить, что его нет :]
VDZ>почитайте Страуструпта — Дизай и эволюция С++ — если найдёте, и тогда поймёте многое, а вот такие высказывания — это полная чушь.

Короче, хотите программировать под Windows — читайте Страуструпа. Там всё написано. MSDN — для лохов. А если ваша программа заглючила, это всё бредни и чушь. Всё равно Страуструп круче в сто раз!
... << RSDN@Home 1.1 beta 1 >>
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка: 15 (1) +1 -2
WH> Разговорные языки по функциональности практически равноценны. Но С++ и делфи... ой не смешите мои тапочки.

Мне кажется, твоя обувь слишком много на себя берёт.

По функциональности C++ опережает Дельфи только в возможности компилировать драйвера.

WH>>>С++ это язык для создания других языков. Причем при наличии определенных знаний и воображения это делается очень легко.


Для создания других языков? Вот придурки, а они на нём операционки пишут! Дикий народ, наверное. Скорее всего, дети гор.

A>>Я тоже могу написать библиотеку для создания других языков по тому или иному принципу.

WH>А ну-ну. Напиши boost::spirit на дельфе. Можешь даже не пытаться. Не выдет.

Какой-то дыбильный boost::spirit. На Дельфи он попросту не нужен никому. Ты бы ещё попросил на C# Hashtable написать.

А ты вот напиши на C++ доступ к COM-объектам по позднему связыванию. Хоть поприкалываемся над небывалой простотой C++
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: Vladimir Khatzkevich Россия  
Дата: 18.09.03 13:30
Оценка: +4
Здравствуйте, WolfHound, Вы писали:

[skip]

WH>>>Какие проблемы с надежностью С++ шаблонов мне ктонибудь обьяснит наконец?

S>> Да втом, что шаблон он и в африке "Шаблон".
WH>ГДЕ ПРОБЛЕМЫ С НАДЕЖНОСТЬЮ?
Нет никаких проблем у шаблонов с надёжностью. Да Вы это лучше меня знаете Похоже некоторые Ваши оппоненты не до конца представляют себе, что такое шаблон...
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[45]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 15:11
Оценка: +1 -1 :))
WF>>> И все. В C++ бывают ситуации с гораздо более тяжелым синтаксисом.

M>>Вот он, булыжник в огород сишников!


WH>Ага ты посмотри посты Serginio1 где он пытается реализовать элементарные вещи.


Ну, ты не путай. Одно дело — коренная убогость капиталистов, а другое дело социалистические перегибы на местах.
... << RSDN@Home 1.1 beta 1 >>
Re: Свойства... Как много в этом слове для сердца ...
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.09.03 19:20
Оценка: 28 (2) +1
Здравствуйте, akasoft, Вы писали:

Вопрос про свойства несколько сложнее, чем просто "удобные псевдонимы для get... и set...".
При таком отношении теряется семантика. Свойства вообще противоречат концепции поведенческой объектной модели. В этой модели объект обладает некоторым поведением, при этом его повадки определяются его интерфейсом. Все "внутреннее наполнение" объекта служит только для того, чтобы поведение, задаваемое интерфейсом, имело контекст. (В таком подходе публикация полей является членовредительством, т.к. мы даем тем самым возможность управлять состоянием объекта, минуя его интерфейс.) Судить о состоянии объекта можно только косвенным образом, сравнивая его реакцию на одно и то же сообщение в разные моменты времени.

Однако в некоторых случаях хочется все же иметь некий доступ к состоянию объекта, пусть даже и контролируемый. Как раз эту задачу и решают свойства. С точки зрения внешнего наблюдателя, свойство — это некоторый атрибут состояния. Он отличается от поля тем, что его можно безопасно менять (здесь безопасность подразумевает гарантию того, что результатом воздействия станет целостное состояние). Таким образом, свойство можно рассматривать как некую специфическую "надстройку" над поведением объекта — мы придаем специальную семантику некоторым сообщениям из его интерфейса.
Это накладывает определенные обязанности на реализацию свойства. В частности, как правило ожидается сохранность значения свойства: если мы записали что-то в некоторое свойство, и сразу же (т.е. до посылки еще каких-либо сообщений этому объекту (или вообще любым объектам в системе)) читаем из него, то мы должны получить записанное значение (или близкое к нему).
С этой точки зрения, плохой идеей является обьъявление свойств вот таким образом:
type TPerversiveObject = class
private
  FA, FB: integer;
public
  property A: integer write FA read FB;
    property B: integer write FB read FA;
end;

А вот такой пример является "хорошим":
type TPoint = class
private
  FX, FY: extended;
public
  property X: extended read FX write FX;
    property Y: extended read FY write FY;
    property R: extended read GetR write SetR; // имеется в виду R = sqrt(x*x+y*y)
    property Alpha: extended read GetAlpha write SetAlpha // полярный угол

Дальнейшее развитие этой идеи приводит к введению базиса — набора свойств, значения которых однозначно определяют состояние объекта. (очевидно, что не для всех объектов это возможно).
На этом построена VCL: базисом считаются те свойства, которые расположены в секции published.

Если быть более точным, то Delphi предоставляет возможность динамически определять базис при помощи ключевого слова stored. Кроме того, поверх базовых возможностей языка реализован механизм "псевдосвойств", но они определяются исключительно процедурным способом, в отличие от декларативных published/stored.

Это совершенно другой подход к управлению состоянием объекта, нежели принятая в чисто-поведенческих системах концепция сохраняемости. Там объект наделяется при необходимости специальным поведением "сохранить/восстановить свое состояние", что позволяет ему самостоятельно заначивать и доставать свое состояние, не давая посторонним доступа к нему.

Такая реализация кажется, с теоретической (да иногда и с практической) точки зрения, несколько громоздкой. В конце концов борланд пришлось написать свой собственный уникальный компилятор, иначе программисты убились бы следовать этому тернистому пути. (желающие убедиться могут сравнить TurboVision с VCL).
Зато она дает более гранулярный доступ к состоянию объекта. Вместо конверсии состояния в монолитный битовый поток, мы получаем поименный самодокументированный набор примитивных значений. Это позволяет нам отделить логику конструирования состояния объекта от его "собственного" поведения, и иметь ту самую RADость, которой так не хватало все эти годы программистам на MS VC.

Однако нужно отдавать себе отчет в том, что целостность системы иногда важнее полировки отдельных фич. И бездумное внесение синтаксических возможностей в некоторую среду может привести к плохо управляемым последствиям. Не стоит валить все вкусности из холодильника в одну кастрюлю — вряд ли мороженое с картофельным пюре, вареньем и горчицей порадует ваших гостей. С++Builder в свое время меня просто потряс неожиданностью трактовок выражения X.y[i]=X.y[i]+someconst. Учитывая то, что y — индексированное свойство, для типа которого нетривиальным образом перегружены операторы присваивания и сложения .
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: По просьбам трудящихся: Кто сильнее: кит или слон ?
От: bt  
Дата: 02.09.03 15:40
Оценка: 11 (2) :)
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 29.08.03 04:47
Оценка: 2 (2) +1
Здравствуйте, mihailik, Вы писали:

WH>>Во всех остальных областях дельфи проигрывает С++ с треском.

M>Кгм. В удобстве C++ проигрывает всем, кому только можно. Разве что ассемблеру не проигрывает.

Типа я никогда на дельфе не писал...
В дельфе надо следить за ресурсами ручками, а это так задалбывает...
А если писать с использованием исключений то код превращается в кучу try/finally что не добавляет ни читабельности ни скорости, а как оно задалбывает... В С++ все куда проще захватил ресурс в конструкторе, освободил в деструкторе и плевать хотел на исключения и ветвистую логику. И обрабатывать исключения буду там где удобно, а не там где ресурс захватил.
Еще очень часто есть куча рутинной работы которую в 99% случаев можно свалить на шаблоны.
STL контейнеры это вобще штука не заменимая. Если знаешь что тебе надо и свойства контейнеров то самопальные контейнеры не нужны в 99.999% случаев.
И многое другое...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: ArtDenis Россия  
Дата: 08.09.03 15:00
Оценка: 1 (1) +2
Здравствуйте, FWP, Вы писали:

FWP>Здравствуйте, ArtDenis, Вы писали:



AD>>Мне например, платят не за размер кода, а за результат работы, который выражается в том, что доволен или недоволен AD>заказчик программным продуктом.

FWP>Вот именно! Главное программный продукт. И вот тут-то получается, что на Delphi быстрее и надежнее.Несмотря на все template, smartpointer и т.д.

Каким же это боком? Откуда берётся скорость в написаннии кода? Если это база данных с парой строчек кода, то оно понятно, потыкал мышкой, и всё работает. Но тоже самое можно сделать на C++Builder. Скорость будет такая же. Если же речь идёт о реализации алгоритмов, работающих с большим набором различных данных, то C++ c его шаблонами нет равных. Кстати говоря, smartpointer избавляют от программмиста от гемора с удалением объектов и валидности указателей. Что тоже повышает скорость написания программы.

Если даже рассматривать шаблоны в контексте контейнеров и алгоритмов, то они — уже большой шаг вперёд, по сравнению с возможностями паскаля. А если добавить сюда Александреску и обобщённое программирование, то получается что C++ и Pascal — небо и земля.

Кроме того, Delphi предоставляет программисту такие вольности в приведении типов указателей, что даже программисту на C и не снились. А подобная вольность — источник повышенного количества ошибок.

Так что, FWP, твоё утверждение — скорее самовнушение, и не соответствует истине.

Денис.
... << RSDN@Home 1.1 beta 1 >>
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 27.08.03 06:10
Оценка: -3
Здравствуйте, Jenyay, Вы писали:

J>Да потому что макросы заменяются до компиляции и можно долго смотреть на одну строчку с ошибками компиляции, а она окажется в макросе. Где-то был хороший пример с max, сейчас уже некогда — если до вечера не напишут — попытаюсь найти.


Дак это плюсы макросов что ли? По-моему Вы не ту точку зрения стали отстаивать
И вообще — макром наворот текстового редактора, а не языка.

DOO>>>>шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).

WH>>>Ты спутал с макросами. Шаболы в С++ дают тАкие преймущества что по сравнению с ними некоторое разбухание ехешника это ничто.

DOO>>В одной книжке я встретил правильную фразу, дословно не помню, что-то вроде, что существует объектно ориентированное пргораммирование и шаблонное программирование.

DOO>>Очень разные вещи, поскольку в STL нет никакого наследования, например.

J>Насчет STL не знаю — как то не приходилось от них ничего наследовать (хотя, вроде бы можно), но никто не мешает сувать шаблоны в свои классы и наследовать от них.


Получается очень странный малопонятный гибрид. Пример:

template <class T>
class CTemplateClass
{
  T member;
}
class CSon1 : public CTemplateClass<class1>
{
}
class CSon2 : public CTemplateClass<class2>

И что в итоге получается? CSon1 и CSon2 сложно называть детьми CTemplateClass.




J>Так со смартпоинтерами можно не бояться, что забудешь освободить память.


Волков бояться в лес не ходить
В JScript и выделять-тоо память не обязательно, но это не плюс по-моему.

Я предпочитаю и сам конструктор вызвать и деструктор. И как-то использование owner у TComponent прозрачнее и понятнее.


J>А зачем нам MS


Мне на работе сказали WTL — хорошо, но MS не поддерживает. Поэтому пиши на MFC.
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 06:07
Оценка: :)))
Здравствуйте, bkat, Вы писали:

B>Ты думаешь это случайно?


Конечно нет! Просто VS дешевле(намного, VS7 по-моему вообще была бесплатной, у нас ее из нета качали), чем Дельфи(если брать все легально).

А, между прочим, один препод у нас заявил, что в "Европе и лучших домах Филадельфии "(за бугром, одним словом) ОТКАЗАЛИСЬ от С в промышленной разработке ПО, поскольку, цитирую, "этот язык похабен".
P.S. По его словам все прогрессивное человечество использует Аду.
P.P.S. Это цитаты, поэтому на их тему никаких дебатов.
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 01.09.03 07:37
Оценка: +3
Здравствуйте, DOOM, Вы писали:
DOO>Ну конечно. А в VS я ее жду секунд 6-8. За это время успеваешь расслабиться
ЧАВО???? Она мнгновенно выскакивает.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 05.09.03 04:49
Оценка: +1 :))
Здравствуйте, mihailik, Вы писали:


M>Конечно, есть люди, которым по долгу службы приходится на ассемблере писать. Слава богу, я к таким не принадлежу.


Повреь мне зря... Самый красивый и понятный язык(когда макросами не перегружен по самое нехочу).
Re[24]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 10.09.03 11:08
Оценка: +1 -2
C> Что мне делать, если я хочу отсортировать встроенный массив или вообще какой-то свой контейнер? Придумал! Копировать его в этот TList, а потом забирать назад! Прекрасное решение!

Встроенных типов не так много, легче простого написать небольшую библиотечку с функциями типа SortIntegerArray и т.п.

Или крутизна шаблонов как раз и заключается в работе со встроенными типами? Игрушечки какие-то

Вот тебе тоже вопрос на тему как применить микроскоп для забивания гвоздей. Как в C++ отсортировать виндовый SafeArray, причём в режиме thread-safe?
... << RSDN@Home 1.1 beta 1 >>
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 15.09.03 04:28
Оценка: +1 -2
Здравствуйте, WolfHound, Вы писали:

WH>ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?

Это для С++ программеров такое слово в новинку, а для пишущих на OP это само собой разумеется. Строгая типизация была в языке с самого начала.
Re: Некоторые итоги:
От: DOOM Россия  
Дата: 15.09.03 09:48
Оценка: +1 -2
Что-то вы граждане поклонники С очень непоследовательны в своих заявлениях. Единственное исключение пожалуй Wolfhound, который усиленно гнет свою тему, но, если честно, я с ним в корне не согласен. Так нравится типобезопасность и обобщенность, так может какой-нибудь скриптик подходящий поискать?

Остальные же "защитники" С++ начинают кидаться лозунгами типа "С для инженеров, Pascal для обучения". Причем сильно напирая на низкоуровневость С по сравнению с паскалем, причем именно С, а не С++. Т.е. мы получаем прямой доступ к памяти без всяких там смартпойнтеров и т.д. т.е. это точкка зрения полностью противоположная точке зрения Wolfhound'а.

И еще. Очень часто в потверждение превосходства С++(а именно VC++), над Дельфи люди начинают сравнивать его(С++) с BCB. Я этим BCB в жизни не пользовался и насколько понял не зря, поскольку, видимо, это хуже даже Visual Studio.
Re[2]: Некоторые итоги:
От: Sergey Россия  
Дата: 15.09.03 10:11
Оценка: +3
Hello, DOOM!
You wrote on Mon, 15 Sep 2003 09:48:56 GMT:

D> Что-то вы граждане поклонники С очень непоследовательны в своих

D> заявлениях.

Что-то вы гражданин DOOM не менее непоследавательны в своих заявлениях То у вас C и C++ — одно и то же, то — разное

D> Единственное исключение пожалуй Wolfhound, который усиленно

D> гнет свою тему, но, если честно, я с ним в корне не согласен. Так
D> нравится типобезопасность и обобщенность, так может какой-нибудь
D> скриптик подходящий поискать?

А что, ты можешь предложить хоть один широко распространенный скриптовый язык со строгой статической типизацией? Если нет, то ты нифига не понял из того, что тебе говорил Wolfhound.

D> Остальные же "защитники" С++ начинают кидаться лозунгами типа "С для

D> инженеров, Pascal для обучения".

Так защитники C или C++? Потому что "C vs. C++" — тоже вполне неслабая тема для holy war.

D> Причем сильно напирая на

D> низкоуровневость С по сравнению с паскалем, причем именно С, а не С++.

C++ позволяет обходиться с памятью столь же непосредственно, как и С. Но именно позволяет, а не принуждает. Кстати, и VB вплоть до 6'й версии включительно тоже позволял напрямую работать с памятью — но это не означало, что надо всегда так делать.

D> Т.е. мы получаем прямой доступ к памяти без всяких там смартпойнтеров и


Чем, с твоей точки зрения, доступ к памяти с помощью смартпойнтеров отличается от прямого доступа к памяти?

D> И еще. Очень часто в потверждение превосходства С++(а именно VC++), над

D> Дельфи люди начинают сравнивать его(С++) с BCB. Я этим BCB в жизни не
D> пользовался и насколько понял не зря, поскольку, видимо, это хуже даже
D> Visual Studio.

Вот только не надо валить в одну куча язык и средства разработки.

Best regards,
Sergey.
Posted via RSDN NNTP Server 1.7 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 15.09.03 18:43
Оценка: -1 :))
Здравствуйте, WolfHound, Вы писали:

WH>>>ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?

A>>Знаем. В основе — массив указателей.
WH>Как гибко А если критична произвольная вставка/удаление? А если поиск? А если вставка/удаление с конца/начала?

А мы будем выбирать тогда, как реализовать. К услугам [коллекции, списки] (это для объектов), [динамические массивы, тип записи, вариантные массивы] для чего другого. Нужно очень быстро — возмём массивы и record.

A>>Для хранения списка чего угодно.

WH>Вот тут и начинаются проблемы.

Да нет. Опыт сказывается.

A>>Потому что поддержка вариантов пришла позже.

WH>А вот это совсем изврат

Даже соглашусь. Зачем их так в COM любят? Или зачем Дельфи позволяет передавать/получать от COM-объектов эти OleVariant и Variant? Нет бы динмассивы...

WH>И как можно добится автоматического уничтожкния при удалении из списка? А если объект надо хранить в нескольких списках?


Разумным проектированием. Перекрытием (перегрузкой, override) методов, написанием своих классов-оболочек.

WH> А если мне нужен не список, а КЧ дерево?


Написанием класса-оболочки, инкапсулирующего это дело. Возможно, он и есть, мне не было нужды в таком.

WH>Это у вас в паскакале надо долго и нудно извращаться, а потом долго и нудно отлаживать. В С++ все просто.

WH>...

Код опустил.

Нет, вы (к другим слушателям ) мне скажите! Нас обвиняют в смертном грехе — кликерстве, настройке свойств и поведения классов визуально. Более того, мы уши опускаем, согдашаясь, что да, виновны, уровень знаний падает, т.к. для кликанья много знать не надо.

И кто нас обвиняют? Эти Си и Си плюплюснутые (абсолютно беззлобно ), которые всё пишут ручками? Да где ручками, я вас (других) спрашиваю? У них теперь шаблоны и помощники. Так вот, это теперь у них уровень знаний падает, это они теперь сбанзали шаблон и вуалля. Я понимаю, шаблоны серьёзно облегчают и упрощают дело — ну и пришли они к тому же корыту, у которого мы стоИм уже сколько?... Они что, не видят как и сколько мы стоИм...

А теперь о стратегии: Борланд ушёл в RAD — и далеко зашёл, надо признать, что их продукты очень привлекательны и функциональны. А MS (просто представитель отдельный мира Cx) ответил на это шаблонами (или кто там ответил на самом деле...) — облегчением ручного труда, возможностью придавать функциональность шаблона произвольным (почти) данным. По терминологии OP хорошую библиотеку и её поддержку в языке и компиляторе предложил.

Ну, не так?

WH>Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.


Вот, вот, вот! Та же лень. Думаешь, я не знаю про эти манипуляции с временем жизни и областью видимости. Знаю. Я даже знаю, какую цену я плачу за необходимость объявлять типы и переменные заранее. Я проникся этой идеей настолько, что она для меня также естественна, как дышать. Я не ошибусь с декларированием переменных и буду всегда знать, где их найти. Для проверки мне достаточно распечатать блок var, а на C# надо лазить по телу метода да собирать переменные по сусекам...


И мы ещё не затронули любимый мозоль — case sensetive.

WH>... и если мне не изменяет сколероз try finaly не ловит exit.


Правда? Надо будет покопаться что-ли...
... << RSDN@Home 1.1 beta 2 >>
Re[44]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 19.09.03 13:10
Оценка: -2 :)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>>>Ну и нафига во все интерфейсы подсчет ссылок запихивать? В С++ это делается на раз, а для привидения типов служит dynamic_cast.

S>> В классы а не в интерфейсы. И работа с приведением через интерфейсы как в Net очень удобна.
WH>А чем чисто абстрактный класс без данных отличается от интерфейса?
Чем ??? Посмотри на реализацию придуманную M$. Дла каждого объекта (не класса) генерятся в памяти функции заглушки, которые генерят вызов методов класса с передачей данных объекта (Self) в методы класса.
Вот и поймешь в чем причина. Не прав.
WH>>>Вот уж нафиг не упало все классы от одного наследовать. И dynamic_cast никто не отменял.
S>>Аналог dynamic_cast Is плиз ???
WH>typeid
Гхы-Гхы. WolfHound хоть ты и RSDN но рассыждаешь как зеленоротый птенец. По сути объекты 1С++ схожи со структурами. Но виртуальность накладывает на обязательное поле ссылки на VMT, в Delphi с отрицательным смещение хранится куча информации о типе , интерфейсах итд. Кроме всего прочего вариантный подход, тоже требует определенных методов по преобразованию. Я лично ну ни как не пойму какие проблемы у С++ с БД.
А как насчет InheritedForm,,,,
S>> Единая информация об объекте. Не прав.
S>> А вот структуры объекты действительно нужны, но с возможность боксинга в объект как в Net
WH>НАФИГА? Создал в стеке пусть лежит в стеке, создал в хипе пусть будет в хипе. Нафига это разделение?
Создал структуру как в Net и пусть себе лежит. Какие проблемы. Неотвечаешь на предыдущие вопросы. Единственный аргумент Шаблоны. И все???
Честно говоря, как оппонент Вы WolfHound, очень не интересны. Абсолютно нет никакого конструктивизма и анализа. Уперся рогом и все. Извини за столь резкие высказывания, но это Правда. Не важно на чем программируешь. Мне лично по барабану. Но в Net Я нашел, то что искал и ищу.
С++ умрет, а Виртовский Паскаль останется. И уже доказал свою состоятельнось, не взирая на свой возраст. Главное фундамент.
Если Ты в Москве готов в личном поединке обсудить общеязыковые проблемы за кружечкой Водки.
и солнце б утром не вставало, когда бы не было меня
Re[22]: Еще итогов
От: Glоbus Украина  
Дата: 10.12.03 11:21
Оценка: 48 (2)
Товарищи
Ваще ветка клевая получилась — реально почитал, получил удовольствие, много узнал.
Но все таки хотелось бы вставить свои пять копеек. Вот спорят тут типа "Делфи!" "С++!" "Шаблоны!" "быстрее!" "медленнее!" "свойства!". Я предлагаю взглянуть на этот вопрос в несколько иной плоскости. А че ваще нужнее. То есть мы тут не для чистого кайфа программим, и не для удовлетворения комплекса создателя и творца в нас. Педалинг должен приносить пользу народному хозяйству. Вот давайте посмотрим, что нужно щас больше народному хозяйству — пользователь голосует рублем.
А сделаем так. Заходим на сайтилу по работе (скажем job.ru), и набираем следующие запросы

1) Раздел — информационные технологии
Город — Москва
Образование — Высшее
З/п — от 1000 уе
График работы — полный день
Занятость — полная
Ключевое слово — С++
Исключить слова — Delphi (шоб не было объяв с коктейлями а как можно более чисто сишные)

2) Раздел — информационные технологии
Город — Москва
Образование — Высшее
З/п — от 1000 уе
График работы — полный день
Занятость — полная
Ключевое слово — Delphi
Исключить слова — C++ (шоб не было объяв с коктейлями а как можно более чисто дельфовые)

И что же мы видем, сладкие мои
Запрос 1)
Кол-во вакансий — 148
З/п — 2500, 3000 уе и выше

Запрос 2)
Кол-во вакансий — 33
З/п — 1500б 1300 уе и ниже

Так что, как говорил товарищ Сталин: "Факты — вещь упрямая". То есть оказывается не нужны людям свойства, не нужны им быстрые кнопочки на формах, не нужны им самопальные реализации контейнеров через наследование и код через Копи/Паст. А нужны им шаблоны, нужен им монстроидальный синтаксис, нужна им, гадам, перегрузка операторов. И готовы они потерпеть лишнее время, так как как ни крути, а на сях прожект сложнее разработать и реализовать (может потому что задачи сложнее). И готовы эти гады (работодатели всмысле) в 2 раза больше денег платить за все эти сишные неудобства, и хотят они их почти в 5 раза больше и сильнее чем все TContainer"ы и ТПрограммер компоненты вместе взятые. Так что королевство дельфей может сушить сухари. Где то я там видел фразу типа "С++ и дельфи — умирающие направления". Ага, жестко они умирают. А лохи эти, из котор программерских — они ж лапти, у них денег куры не клюют — вот и платят специалистам по тупиковым направлениеям по 3000 уе.
Вот такие дела
Удачи тебе, браток!
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 11:08
Оценка: 4 (1) +1
Здравствуйте, Mamut, Вы писали:

M>В МС в 8-ой строчке показывает member-list из CMyClass, а в 9-ой орет "ci is not a structure or a class". Причем такие глюки повсеместно.

Говорят VisualAssist помогает.

M>В 6-ой версии как минимум Builderа всплывающая подсказка показывает только те функции, методы и т.п., которые имеют смысл в данной конкретной ситуации, а не содержание всех заголовочных файлов SDK.

Ну это очень сомнительное достоинство.
А вот то что подсказака вываливается 2-3 секунды это очень напрягает.

M>В Борландовских продуктов гораздо умнее расставлена клавиатура. Одно только то, что Add Watch в студии не снабжен коьбинацией клавиш, меня полностью убило.

Вот только вижут позволяет перенастроить каждое сочетаеи клавишь на практически любое действие доступное в IDE. Короче это решается в несколько кликов и пару нажатий.

M>Самый главный минус Дельфей, и их внебрачного урода Builderа, — это именно завязка всего под VCL. В Дельфях все обьекты автоматически наследуются от TObject, что в результирующий экзешник добавляет такое количество кода, что потом листинг функций в файле смотреть страшно.

+1
M>Про TStringList и вообще любые списки, TListView и прочие Борландовские извращения говорить не буду. Например, почему TListItem::Data имеет тип данных TObject*? Я в эту самую дату загоняю свои типы дынных, и пользоваться огромадным кол-вом reinterpret_cast меня уже плющит.
+1
M>Что еще нельзя делать в Delphi/Builder? Нельзя эффективно перехватывать оконные сообщения для создания кустомизированных контролов "на лету". Необходимо создавать свои собственные компоненты.
+1
M>Код Дельфи не кроссплатформенный, как здесь кто-то утверждал, если не пользоваться CLX. Если пользовать, придется таскать n-мегабайтовые библиотеки. Правда, в случае Buildera, это и так приходится делать...
+1
M>Ну спорю, Borland'овские продукты красивы и в общем удобны,
Это дело привычки
M>но... Писать не-GUI и серьезные вещи IMHO надо на С++.
+1
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 08:59
Оценка: 3 (1) -1
Здравствуйте, FWP, Вы писали:

WH>>Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.

FWP>C# и Delphi — это близнецы братья (или сестры?)
Общего у них только то что редактор форм немного похож.

WH>>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.

WH>>А сейчас все очень убого. Почти на уровне дельфи.
FWP>Какое самомнение! Ну почти господь бог.
А что не похож?
FWP>Истина в последней инстанции.
Аргумента против.
FWP>А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов.
Ибо реализовать их нАмного сложнее чем кажется.
FWP>Разговоры идут, планы ввода есть. А реализаций нет. И в C# тож самое. Видно не все так просто с надежностью.
С надежностью то как раз все хорошо, а вот реализовать это...
FWP>А ведь для разработки именно НАДЕЖНЫХ приложений создавались эти среды.
А это тут причем?
FWP>А вот интересно! После ввода шаблонов в С# куда они будут отнесены: к безопасному программированию или нет?
К безопасному. К томуже в шарпе шаблоны не будут обладать такойже мощью как в С++.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 26.09.03 04:46
Оценка: 2 (2)
Здравствуйте, Sinclair, Вы писали:

WH>>Допустим у нас есть некий объект который держит ресурс. Этот объект использовало куча других и через некоторое время он перестал быть нужен. Вопрос как узнать когда именно нужно освободить ресурс, а если легика была довольно сложной? В конце концов после долгих мучений выяснится что оптимальным решением будет именно подсчет ссылок.

S>Почему ты так думаешь? Проблема GC ровно в одном — простой ресурсов. хъ
Вот только однажды ктото долго матерился когда на слабой машине софтина на любых стресстестах работала как часы, а на серваке падала в месте с системой.
S>Подсчет ссылок в этом случае вообще встрянет, так как есть цикл, который ему неподвластен. Итого, мы имеем некоторую задержку возврата супротив невосполнимой утечки. Кто победит?
Чесно говоря не могу себе представить случай когда могут возникнуть циклические ссылки. Особенно в объектах которые используют внешние ресурсы. Проблема GC в том что ему не надо циклов для того чтобы держать ресурсы. К томуже он не риагирует на нехватку внешних ресурсов, а только на нехватку памяти.
S>Да, можно программировать так, чтобы такие объекты никогда не вступали в циклы. Но почти с тем же успехом можно прораммировать так, чтобы ресурсы освобождались детерминистически, при помощи IDisposable.
Проблема какраз в том чтобы узнать когда именно вызвать Dispose особенно если однозначно не возможно определить хозяина, а вот если использовать подсчет ссылок и GC одновременно(для того чтобы рано или позно но убить цикл)то это может дать очень не плохие результаты.
S>Причем, стоит отметить, что GC наплевать на то, насколько сложна логика. Он собирает любые циклы. В то время как при подсчете ссылок в сложной логике можно нечаянно замутить-таки цикл. И дооолго думать, откуда он взялся.
Ну не знаю как тако можно замутить особенно в той части программы которая работает с внешними ресурсами.
WH>>Хотя некоторые объекты (строки,...) лучше на GC.
S>Ты не мог бы пояснить, в чем принципиальная разница между строками и... другими ресурсами? Дело в том, что я знаком с различиями технологий управления памятью в реальных системах в основном теоретически (ни разу не видел, чтобы одна и та же система была реализована сразу в обоих вариантах ), так что может не знаю каких-нибудь удручающих фактов из жизни мусоросборщиков.
Да просто строки и компания используют ТОЛЬКО память, а именно не ее нехватку реагирует GC а вот колличество открытых файлов в системе ограничено и GC на это не риагирует. Тоже самое касается других ресурсов.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: elmm_ Украина http://herocraft.com
Дата: 28.08.03 08:08
Оценка: 1 (1) +1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:


DOO>>Что значит забей? .NET языковонезависимая, т.е. начнется что лучше C#,C++,Delphi.NET и еще бог знает что.

WH>А то и значит. Если надо ГУИ и клиентов к БД то прямая дорога на .НЕТ
WH>Во всех остальных областях дельфи проигрывает С++ с треском.

Вот именно... А вы попробуйте написать что нибудь на делфях или НЕТе не офисно-ДБшной направлености, да еще если оно должно не только под виндой работать... Топик правда про C++ в VS, но сделав свой проект в комфортной IDEшке в визуале и погоняв там же, без проблем переношу пот линукс... Да в делфе есть кайликс, но во первых дальше линукса не сунешся, а во вторых — если мне надо кросплатформенное гуи — я выбираю то что мне нравится из тонны библиотек (мне лично wxWindows понравился почему-то) и получаю подобную функциональность удобными для МЕНЯ средствами + еще большие возможности по портированию... Да и к томуже кода на C/C++ на сегодняшний день гараздо больше чем на Delphi — как ни как существует он дольше и пишут на нём больше людей... Вобщем единственное что мне понравилось при знакомстве с Delphi это более быстрая возможность рисовать окошки — в свое время такое же радостное впечатление было при виде VB, но со временем VB был за ненадобностью забыт... А поигравшись с делфей и получив состояние, близкое к экстазу, при виде красивых кнопочек намалеваных за 5 минут, забил на это дело за не надобностью...

Вобщем если мне предется писать какую-нибудь прогу для работы с БД и красивым интерфейсом — буду учить делфи — там это быстро и легко — это его явное преимущество, как по мне.

Пока что такой необходимости нет, так что моя верность к C++ (VS) не поколебима

Но это все не преимущества и недостатки самого языка, а скорее совокупность — язык, средства разработки, имеющиеся библиотеки, возмодность переноса и распостранненость...

Вобщем делфи штука не плохая, но у C++ (VS) охватываемое поле деятельности куда шире, где-то они пересикаются где-то нет. Все что можно сделать на делфе можно повторить на C++, наоборот вряд ли...
C.E.O. HeroCraft Ukraine — fun on the run.
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: Аноним  
Дата: 27.08.03 08:51
Оценка: +2
Про технические вещи спорить даже как-то не охота.
Сравнивать шаблоны с копи-пейстом — это просто не понимать, что такое шаблоны.

Мне лично вообще все равно, на чем писать.
Если задача интересная, то и на Бейсике буду,
и на Делфи и вообще на чем угодно.

Еще один факт. Число инсталляций VS значительно больше,
чем продукта от Борланда.
Это означает, что работы для того, кто владеет VS больше,
чем работы для дельфистов.
Причем не просто работы, а интересной работы.
Для меня это гораздо больше значит, чем маниакальная любовь
одной группы программеров к одному продукту и такая же нелюбовь к другому.
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 28.08.03 12:53
Оценка: -2
WH>>Во всех остальных областях дельфи проигрывает С++ с треском.

SYN>Правильно! Если нужно компактное и шустрое приложение. То на Дельфях его писать смысла нет.


Компактное и шустрое приложение сейчас мало кому нужно. Notepad'ы, WordPad'ы и MSPaint'ы разные давно никому не нужны.
... << RSDN@Home 1.1 beta 1 >>
Re[19]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 04.09.03 08:44
Оценка: +2
Здравствуйте, FWP, Вы писали:

FWP>Ну зачем считать других глупее себя. Читай еще раз Берем библиотеку, в которой реализована сортировка для нужного типа и все.


Да-да. Пишем свой тип данных, а потом ищем в интернете, не написал ли уже кто-нибудь для него сортировку.
Re[19]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 04.09.03 09:21
Оценка: +2
Здравствуйте, FWP, Вы писали:

FWP>Ну зачем считать других глупее себя. Читай еще раз Берем библиотеку, в которой реализована сортировка для нужного типа и все.

В STL реализована сортировка не для нужного мне типа, а для ВСЕХ типов в том числе и еще не созданых.
Почувствуй разницу для ВСЕХ и для КОНКРЕТНОГО.
Другими словами один раз для всех или много раз для каждого.
И тоже для всех STL алгоритмов и контейнеров.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 08.09.03 06:26
Оценка: -1 :)
Здравствуйте, WolfHound, Вы писали:

WH>Вот только приходится использовать какойнибудь изварат типа TList либо писать ручками...


А почему TList это изврат, а std::vector нет? По мне дак TList поудобнее...
Re[25]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 08.09.03 06:42
Оценка: +2
Здравствуйте, DOOM, Вы писали:

DOO>А почему TList это изврат, а std::vector нет? По мне дак TList поудобнее...

Если уж сравнивать то с std::list. А вчем это он удобней? Кроме того что типо не безопасен? Не может прибивать обхекты которые в нем хранятся при удалении их из себя....
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: ArtDenis Россия  
Дата: 10.09.03 06:21
Оценка: +2
Здравствуйте, DOOM, Вы писали:

AD>>Кроме того, Delphi предоставляет программисту такие вольности в приведении типов указателей, что даже программисту на C и не снились. А подобная вольность — источник повышенного количества ошибок.

DOO>А по-моему я не маленький и мне можно разрешать смотреть на память как я хочу. Это не источник ошибок, а повышение возможностей. Это лучше всяких там шаблонов, поскольку здесь я до конца представляю, что происходит при подобных действиях, а следовательно в случае ошибки я буду грешить не на "Майкрософт", а на свою прогу!

Почитай-ка вот это: Re[30]: Ты записался в .NET?
Автор: VladD2
Дата: 03.09.03


Влад в своих рассуждениях в чём-то прав. Но тут есть один момент: на C++ можно (и нужно) программировать, не используя небезопасных приведений типов. А в паскале такие приведения типов приходится использовать вне зависимости от желания программиста.

Денис.
... << RSDN@Home 1.1 beta 1 >>
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 10.09.03 08:30
Оценка: +1 :)
Здравствуйте, DOOM, Вы писали:

DOO>Приехали граждане... Оказывается в С нет понятия указатель на метод произвольного класса(аналог of object в Дельфи). Что на это скажете?

Нафига?
Ну уж если приспичило то boost::function. А если надо вызывать несколоко функций залпом? Как на дельфях делать будешь? На С++ это boost::signal.
Запомни это не в С++ нет чегото что есть в дельфе это в дельфе нет много чего что есть в С++.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 14.09.03 09:14
Оценка: +1 -1
Здравствуйте, WolfHound, Вы писали:

WH>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...


То есть вопрос класса "goto или без goto"?

WH>ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?


Знаем. В основе — массив указателей. Для хранения списка чего угодно. Потому что поддержка вариантов пришла позже. Да и в связи сс динамическими массивами поддерживать вариантный TList (а он-то будет типизированным/автопреобразующимся) неактуально. А вот для списка объектов Борланд быстро допёр сделать TObjectList. Я такую штуку в D3 или D4 сам писал, т.к. не было её.

В TOjectList храним потомков TObject, список может выступать Owner для этих потомков с вытекающими. При необходимости хранить одинаковых потомков можно заместить свойство Items[].

WH>...куча методов должны возвращать массивы созданные при помощи CoTaskMemAlloc. На С++ я за пять минут сотворил шаблон помошник который проверял былали выделена память, следил за выделеной памятью, инициализировал память и в случае чего вызывал деструкторы, а самое главное прикидывался массивом и уже когда все закончино и гарантировано не будет исключений я забирал заполненый массив и возвращал из функции.


Понимаю как полиморфизм и инкапсуляцию.

WH>...Такие помошники позволяют не задумоватся о исключениях, их использование прозрачно и не навязчиво, пишутся раз и навсегда.


См. ответ выше. ООП тоже понимает не задумываться о других кирпичиках. Но тут ключевой момент, что чтобы не задумываться, надо сначала отладить.

WH>Слабо на дельфях написить такого помошника?


Может и нет, если постановку задачи сделать словами, или хотя бы на C#. А то слова вроде знакомые, а вместе — чехарда в голове. Только надо ли?

WH>Ой не надо на дельфе начинается try finaly hell.


Ну, ну. Я вот тоже не понимал, зачем не просматривается иерархии в блоках try и catch в C#. В обоих случаях эти блоки просты, и их понимание и правильное использование приходит с опытом.
... << RSDN@Home 1.1 beta 2 >>
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 15.09.03 04:37
Оценка: -2
Здравствуйте, WolfHound, Вы писали:

S>> Время рассудит, но Delphi найдет свою нишу в Net да и у Delphi с C# намного больше общего чем у C# с С++, да и M$ помоему не особо горит желанием развивать Native компиляторы.

WH>Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.
C# и Delphi — это близнецы братья (или сестры?)

WH>>>Вот только пока далеко не все лучшие идеи используются в шарпе.

S>> Например???? Шаблоны будут, что еще???
WH>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
WH>А сейчас все очень убого. Почти на уровне дельфи.
Какое самомнение! Ну почти господь бог. Истина в последней инстанции. А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов. Разговоры идут, планы ввода есть. А реализаций нет. И в C# тож самое. Видно не все так просто с надежностью. А ведь для разработки именно НАДЕЖНЫХ приложений создавались эти среды.
А вот интересно! После ввода шаблонов в С# куда они будут отнесены: к безопасному программированию или нет?
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 16.09.03 04:53
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

WH>Нет не так. ГУЙ это в большинстве задачь ничтожно малая часть работы.

Это в Delphi ничтожно малая часть. Потому ручная работа сведена к минимуму. А в C++ все ручками, да ручками

WH>>>Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.

И он в некотрых случаях может принять неправильное решение. И следить за этим надо и обходить такие ситуации вручную. Да и надежности это не добавляет.
Спор бесполезен!
От: Miem Россия  
Дата: 16.09.03 20:41
Оценка: :))
Этот Человек одержим! Это положительно его характеризует!
Давно слежу за топиком. Все ответы четкие, все в тему, но с уклоном в одно.. Однобокий взгляд...
Попробуйте поспорить с истинным православным. У вас ничего не получится... Когда человек ВЕРИТ в то, что говорит его не переубедить, он живет этим. Поставить под сомнение веру такого человека — значит посягнуть на самое дорогое, обречь на гибель. Коперника сожгли такие люди! Опомнитесь!

PS Не в обиду WolfHound'у
... << RSDN@Home 1.1 beta 2 >>
ICQ: 446240
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 17.09.03 09:35
Оценка: -2
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>> using в Net нужен только для освобождения системных ресурсов для их немедленного освобождения, во всех других объектах нет деструкторов в в обычном понимании, т.к. за освобождение памяти занятой объектом следит GC. Но через GC а так же через выделение памяти неподвласное GC итд можно многое, к сожалению еще не во все дебри Net залез.

WH>Все что GC попало уже не детерминировано. И using не всегда спасти может.
Есть области памяти неподвласные GC. Например когда using может не спасти если главная цель деструктора освобождение хэндлов системных ресурсов ????

S>>>>>> Например???? Шаблоны будут, что еще???

WH>>>>>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
S>>Насчет шаблонов в Net посмотри http://www.dotsite.ru/Publications/PublicationDetails.aspx?ID=115
S>> Почитай очень интересно, плю что предлагают SUN. Так что ты со своими шаблонами уже отстал от жизни.
WH> Ну прочитал. После С++ шаблонов каменный век. Конечно не на столько плохо как сейчас но всеравно близко нет той мощи.
WH>И ни слова о подключении реализации. Такое впечатление что ни кому не надо. Неполные типы это ИМХО штука безполезная особенно если сделать нормальное подключение реализации.

S>> Шаблоны,макросы по сути являются Copy-Paste-Replace и ни о каком ООП не идет и речи и легко реализуются без компиляторов путем генерации соответсвующих модулей на основании "Шаблона".

WH>Да ни фига подобного. Слова дилетанта. Это .НЕТ шаблоны можно генерить генератором, а С++ требуют информации о типах на много больше.

То есть ты утвержаешь что невозможно создать программу, которая генерит исходники из определенным образом написанных заготовок с конролем типов и выбора наилучшего алгоритма????

S>> А вот шаблоны в Net это действительно ООП.

WH>Обьясни мне пожалуйста кого волнует ФИЗИЧЕСКОЕ ООП. А что касается логической состовляющей то шаблоны в С++ очень объектно ориентированые.
Меня лично очень волнует.
WH>При помощи С++ шаблонов можно не только создавать обобщенные контейнеры но и выберать алгоритм наиболие подходящий типу.
WH>Например так Кто хотел определения наличия функции-члена?
Автор: MaximE
Дата: 13.09.03

WH>И много чего еще.

S>> Кроме всего прочего на данном этапе надежность кода встает на первый план (хотя мне это и не импонирует)

WH>Какие проблемы с надежностью С++ шаблонов мне ктонибудь обьяснит наконец?
Да втом, что шаблон он и в африке "Шаблон".
и солнце б утром не вставало, когда бы не было меня
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.09.03 10:24
Оценка: +2
Здравствуйте, mihailik, Вы писали:

M>Есть COM-объект. Необходимо вызывать какие-то его методы, использовать свойства при помощи позднего связывания, т.е. методов IDispatch. В скриптовых языках, в VB, в Дельфи это очень просто.


M>
M>var Excel : Variant;

M>begin
M>  Excel := CreateOleObject('Excel.Application');
M>  Excel.OpenFile('sdfsdfsdfsd.xls');
M>  Excel.Range("A1").Value=294;
M>end.
M>


Ну вот же ж блин. Ну нельзя на C++ наезжать по таким направлениям — не для того он предназначен.

Конечно, если накатать набор врапперов, то можно сделать и "по позднему связыванию". В результате код пользователя будет примерно таким:


ExcelWrapper excel(CREATE_BY_NAME); // Предположим, что CREATE_BY_NAME - константа,
                                    //определяющая способ создания объекта Excel.Application,
                                    // альтеннативой может быть передача конструктору GUID-а объекта.
excel.OpenFile("tra-la-la.xls");
excel.Range("A1") = 294; // Вот здесь избавимся от '.Value' за счёт перекрытия оператора присвоения значения


Лучше всего, конечно, сделать свою приблуду для импорта описаний .tlb а-ля директива #import.

Только это всё равно не решит глобальной проблемы COM, связанной с тем, что в реальности у тебя диспетчерский вызов может улететь в никуда, а QueryInterface на самом деле вернёт E_NOINTERFACE. Это — общая беда парадигмы позднего связывания. Кстати, Excel тоже тот ещё подарочек...

Ну и наконец, если в твоей программе логики помимо подключения COM-объектов мало, то кой чёрт тогда тебе C++ использовать? Бери тот же VB и полный вперёд!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 12:19
Оценка: :))
Здравствуйте, AlexK, Вы писали:

AK>скоро это будет выглядить приблизительно так: надо тормоза — пиши на НЕТ... увольте... не хочу так жить...

Ну да Native компиляторы доживают свой век или уйдут в Linux, т.к. там уже на конкретной машине под камень и операционку компилируют, а не толко программы.
Живи по старому....
AK>они своей надежностью воспитают еще одно поколение псведо-программеров, который будет считать что умение кинуть на формочку кнопку — делает его прогарммером...
Хехе уже давно воспитаны на Васиках и 1С.
AK>на счет непонятных ошибок так ты ее и в НЕТ получиш... не смотрел как дебугер показывает часть кода от макрософта?

AK>с++ — путь к силе духа! и ясности ума!

Программирование это не профессия, а Смысл Жизни!!!!
и солнце б утром не вставало, когда бы не было меня
Свойства... Как много в этом слове для сердца ...
От: akasoft Россия  
Дата: 22.09.03 18:39
Оценка: +2
Здравствуйте, FWP, Вы писали:

FWP>... Свойства — это атрибут компонентно-ориетированного языка. Компоненты в Delphi, а теперь и в C#?, позволяют затачивать IDE под себя...


Свойства — это более близкий человеческому способ настраивать поведение и работу объектов (классов). При этом возможна именно логическая (абстракционная) настройка, меняющаяя сразу несколько переменных-членов класса и даже других свойств (опосредованно этих переменных-членов и функций-членов). За модификацией свойства может следовать как модификация переменных-членов, так и функций-членов (методов) класса.

По сути, это даже можно сравнить с шаблонами C++ — задача та же упростить программисту жизнь, скрыть от него подробности реализации, сократить текст программы, оставив только функциональный смысл.

И при этом (при пользовании свойствами) можно использовать прелести наследования, инкапсуляции и полиморфизма.

По моему, по меньшей мере глупо говорить, что С++ свойства ни к чему. К удобному быстро привыкаешь...
... << RSDN@Home 1.1 beta 2 >>
Re[10]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.09.03 09:22
Оценка: +1 :)
Здравствуйте, WolfHound, Вы писали:

WH>BCB это глюкалово страшное. Если все это перенести в дельфи то точно хана дельфе.

S>>При всей твоей рекламе шаблонов, лично я совершенно безболзненно обхожусь без них,
WH>Ну некоторые и на С безболезненно пишут, а некоторые и на асме.
S>>но от возможности их применения не отказался бы. Еще раз давай совсем немного подождем,а на данном этапе Delphi уже исчерпал себя.
WH>Вот я и говоряю что .НЕТ2 ждать надо.

Применение Маккросов и Шаблонов наложили отпечаток и на сам язык, так перегрузки операций и функций прекрасно вписываются в Шаблонную систему и неявное приведение типов, но их переизбыток иногда ведет к непониманию кода, особенно когда перегруженная функция имеет совсем другой смысл, но написание ее будет темже. Перегрузка операторов для элементарных типов тоже может вести к неправильному восприятию (например сложение указателей и неявное приведение к LongWord).
Отсутствие шаблонов в Delphi, заставляет мыслить Виртуально, а не Шаблонно.
Вернемся к сортировке. Для элементарных типов шаблоны впереди планеты всей, но со сложными структурами, когда нужно сортировать по любому сочетанию полей и во время выполнения программы шаблоны бессмыслены, если вспомнить комбинаторику и посчитать все сочетания.
Решение выглядит приблизительно так.


unit FLDUnit;
  {$R-,T-,X+,H+,B-}
interface
 Uses SysUtils;
 Type
   TFld = Class(TObject)
   Len,Offset:Cardinal;
   protected
   Procedure SetCompValue(Const p:Pointer); virtual; abstract;
   Function GetAsString(Const p:Pointer):string; virtual; abstract;
   Procedure SetAsString(Const p:Pointer; Const Value:String); virtual; abstract;

   Public
   Procedure Swap(Const p1,p2:Pointer); virtual; abstract; // для любителей оптимизации на Asm
   Function CompareFlds(Const p1,p2:Pointer):Integer; virtual; abstract;
   Function CompareFldWithCompValue(Const p:Pointer):Integer; virtual; abstract;

   Procedure SetValue(Const p,buffer:Pointer); virtual; abstract;
   Procedure GetValue(Const p,buffer:Pointer); virtual; abstract;

   Property  CompValue:Pointer write SetCompValue;
   Property AsString[Const P:Pointer]:String Read GetAsString write SetAsString;

    Constructor Create; Virtual;
   end;

   TFldClass = class of TFld;

   TFldArray =  Array of TFld;

   TMultiFlds = Class(TFld)
      PointerOfCompValue:Pointer;
      Fields  : TFldArray;
      CompFlds: TFldArray;
      HiCompIndex:Cardinal;
     Public
   Function CompareFlds(Const p1,p2:Pointer):Integer; Override;
   Function CompareFldWithCompValue(Const p:Pointer):Integer; override;
   Procedure SetCompValue(Const p:Pointer);Override;
   Procedure SetFldValue(Const i:Cardinal; Const p,buffer:Pointer);
   Procedure GetFldValue(Const i:Cardinal; Const p,buffer:Pointer);
   Procedure SetCompareFields(CmpFld:array of TFLD);
   Constructor Create; override;
   Constructor CreateFromFldClass(Flds: array of TFldClass); Virtual;
   Constructor CreateFromFlds(Flds: array of TFld);Virtual;
   destructor Destroy; override;
   end;

   implementation

{ TMultiFlds }

function TMultiFlds.CompareFlds(const p1, p2: Pointer): Integer;
 Var I:Integer;
 Fld:Tfld;
begin
    For i:=0 To HiCompIndex Do
      Begin
       Fld:=CompFlds[i];
       result:=Fld.CompareFlds(Pointer(Cardinal(p1)+Fld.Offset),Pointer(Cardinal(p2)+Fld.Offset));
        If Result<>0 Then
         Break
       end;

end;

function TMultiFlds.CompareFldWithCompValue(const p: Pointer): Integer;
 Var I:Integer;
     Fld:Tfld;
begin

    For i:=0 To HiCompIndex Do
      Begin
       Fld:=CompFlds[i];
       result:=Fld.CompareFldWithCompValue(Pointer(Cardinal(p)+Fld.Offset));
        If Result<>0 Then
         Break
        end;

end;


constructor TMultiFlds.Create;
begin

 Inherited Create;
end;

constructor TMultiFlds.CreateFromFldClass(Flds: array of TFldClass);
 Var i:Integer;
begin
    inherited Create;
    SetLength(self.Fields,Length(Flds));

        len:=0;
      For i:=0 to  Length(Flds)-1 do
        Begin
        Fields[i]:=Flds[i].Create;
        Fields[i].Offset:=len;
        Inc(len,Fields[i].Len);
        end;



end;

constructor TMultiFlds.CreateFromFlds(Flds: array of TFld);
 Var i:Integer;
begin
    inherited Create;
    SetLength(self.Fields,Length(Flds));
        len:=0;
      For i:=0 to  Length(Flds)-1 do
        Begin
        Fields[i]:=Flds[i];
        Fields[i].Offset:=len;
        Inc(len,Flds[i].Len);
        end;

end;

destructor TMultiFlds.Destroy;
 Var i:Integer;
begin
    For i:=0 To Length(Fields)-1 Do
        Fields[i].Free;
  inherited;
end;



procedure TMultiFlds.GetFldValue(const i: Cardinal; const p,
  buffer: Pointer);
begin
   Fields[i].GetValue(p,buffer);
end;




procedure TMultiFlds.SetCompareFields(CmpFld: array of TFLD);
 Var i:integer;
begin
  HiCompIndex:=Length(CmpFld);
  SetLength(CompFlds,HiCompIndex);
  Dec(HiCompIndex);
 For i:=0 to HiCompIndex Do
    CompFlds[i]:=CmpFld[i];


end;

procedure TMultiFlds.SetCompValue(const p: Pointer);
 Var i:Integer;
     Fld:Tfld;
begin
   For i:=0 To Self.HiCompIndex Do
    Begin
       Fld:=CompFlds[i];
       Fld.CompValue:=Pointer(Cardinal(p)+Fld.Offset);
    end;
end;

procedure TMultiFlds.SetFldValue(const i: Cardinal; const p,
  buffer: Pointer);
begin
 Fields[i].SetValue(p,buffer);
end;
end;



Теперь переопределив TFld всех элементарных типов Мы имем два класса которые могу применять в любых функциях сравнения, динамического отображения и редактирования, отображать и редактировать таблицы БД на основании их заголовков полей итд.

Вот пример сортировки


    Procedure SortArrayFld(Var a;Fld:TFld);
     Var
         BeginArray,len:Cardinal;
 procedure QuickSort(L, R: Integer);
var
  I, J: Integer;
begin


    I :=L;
    J :=R;
     Fld.CompValue:=Pointer( L+(( ((r-l) div len) shr 1)*len));

    repeat
      while Fld.CompareFldWithCompValue(Pointer(I)) < 0 do
        Inc(I,Len);
      while Fld.CompareFldWithCompValue(Pointer(J)) > 0 do
        Dec(J,len);
      if I <= J then
      begin

      //Fld.Swap(Pointer(I),Pointer(J));
      Q_SwapMem(Pointer(i),Pointer(j), Len);

        Inc(I,Len);
        Dec(J,Len);
      end;
    until I > J;

    if L < J then
      QuickSort(L,J);
     if R>I then
     QuickSort(I,R);

end;

     Begin
      Len:=fld.Len;
      BeginArray:=PCardinal(@a)^;
            QuickSort(BeginArray,BeginArray+(PCardinal(BeginArray-4)^-1)*len);
     End;


И в отличие от шаблонов, скорость падает, но я имею универсальность, а при выборе оптимальных алгоритмов в прктических диапозонах вычислений ловит тысячные секунды не имеет смысла. Все зависит от задачи.
и солнце б утром не вставало, когда бы не было меня
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 23.09.03 11:05
Оценка: +1 -1
WH>>>Ну и нахрена это надо?
M>>Для однообразности и простоты. Все объекты ведут себя с памятью одинаково. Мозги не парятся.
WH> Супер аргумент.

Именно. Всё должно быть как можно проще.

WH>А слабо integer by ref сделать? Я не знаю зачем но в С++ это делается на раз boost::shared_ptr<int>


Именно, что слабо. Никому не нужная экзотика.

WH>>>В том то и засада что не всегда объект можно просто скопировать.

M>>А все объекты byref, то есть ничего и не копируется. Чтобы сделать копию, нужно как и в .NET вызвать какой-нибудь Clone.
WH>Да ради бога. В С++ можно тоже пользоваться только by ref и что? Просто я предпочитаю иметь выбор.

В некоторых случаях ограничения выбора — благо. К примеру, на мосту через Днепр перильца есть.

WH>>>При написании ГУИ к БД согласен, а вот на счет всего остального.

M>>Ты что, предлагаешь и в браузерах скрипты на C++ писать? Или ты какое-то конкретное "остальное" имеешь ввиду?
WH>Ты дурочку не валяй. Прекрасно понял о чем речь.

Прекрасно понял. Когда ты говоришь "всё остальное", это означает "узкий круг задач, которыми я сейчас занимаюсь"
... << RSDN@Home 1.1 beta 1 >>
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 23.09.03 14:38
Оценка: :))
M>>Языки, в которых поддерживаются свойства являются компонент-ориентированными. Ну вот не могу сказать почему так выходит, а реальность такова.

WH>Это ни как не связано. В С++ я могу эмулировать свойства, а некоторые компиляторы поддерживают их в качестве расширения.


Ну, в Дельфи тоже можно много чего эмулировать. Те же шаблоны можно эмулировать.


M>>А я не вижу ничего хорошего в том, что C++ не понимают люди без образования.

WH>А я не вижу ни чего хорошего в том что людей без образования допускать к работе ибо всеравно глаз да глаз за ними нужен.
WH>Ну не дело это домохозяйкам программы писать.

Ага. А в начале прошлого века говорили: не дело это, домохозяек за руль пускать. Но когда машины стали удобны, надёжны и просты в управлении, домохозяйки сели за руль.

С языками/компьютерами/программированием будет точно то же самое.

M>>Если тебе непонятны эти преимущества, возможно они тебе и не нужны.

WH>Преймущества .НЕТ это Reflection и Reflection.Emit это сильно, а все остальное фигня.

Именно! Правда, как ты говоришь, разработчики COM'а тебя не поймут

M>>Мало ли у кого какая отрасль работы. А мне вот нужно, чтобы мой код был понятен [censured]'ам, и свойство-ориентированность тоже удобна.

WH> Вот это действительно круто.

Всё дело в том, что иногда я сам являюсь [censured]'ом, и забочусь о том, чтобы самому в своём коде разобраться.
... << RSDN@Home 1.1 beta 1 >>
Re[15]: Некоторые итоги:
От: WolfHound  
Дата: 30.09.03 11:52
Оценка: +2
Здравствуйте, Serginio1, Вы писали:

S> Обрати внимание на мой код

А что твой код? Изврат редкостный. Не типизировано. Те если будет 100 записае и у одной изменился тип мне придеться лиш перекомпилировать, а тебе бегать по всей программе и выискивать что не так. К томуже использовать индексы полей это тоже плохо ибо опятьже структура может измениться.
А мой код можно на раз переделать в
    dynamic_cmp_t<test> cmp;
    cmp.reset()
        (&test::f1)
        (&test::i2)
        (&test::i1)
    ;
    std::sort(test_arr, test_arr+100, cmp.less());
    cmp.reset()
        (&test::i1)
        (&test::i2)
        (&test::f1)
    ;
    std::sort(test_arr, test_arr+100, cmp.greater());
    cmp.reset();
    if(some1)cmp(&test::i1);
    if(some2)cmp(&test::i2);
    if(some3)cmp(&test::f1);
    std::sort(test_arr, test_arr+100, cmp.less());

К томуже std::sort работает с любым рандомакцесс итератором которыми также являются и указатели
S> Но нет китайских иероглифоф. А по писанине то же.
Ну и где ты нашол иероглифы?
К томуже мне не надо следить за порядком полей в структуре, за типами полей, не надо писать TIntegerFld итп и для того чтобы поддерживалась сортировка по полю определенного типа надо чтобы для этого типа был определен оперетор < и все. А он определен для всех базовых типов, для std::string и в общем то для всех типов для которых имеет смысл сравнение.
S> А если структура как в БД насчитывает 100 полей и нужно делать динамическую сортировку по 1, сразу по нескольким полям и нужно как в Ёкселе вывести массив динамически его отсортировать, произвести поиск итд.
Какие проблемы?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Некоторые итоги:
От: WolfHound  
Дата: 01.10.03 04:44
Оценка: +2
Здравствуйте, Serginio1, Вы писали:

S> Давай вспомним комбинаторику, сколько сочетаний возможно уже из 3. А из 4.

Давай вспомним программирование и подумаем причем тут комбинаторика?
S>И для всех них писать свои функции????
Зачем? Я компатор полностью динамичеки собрать могу.
S>А если мне структура записи известна только на этапе выполнения,
И что? Поставь конкретную задачу получишь конкретный ответ. Но ни каких проблем я не вижу.
S>как с таблицами БД и зачем мне типизация в данном случае.
А кудаж без нее? Внутри программы она лишней не будет.
S> Честно говоря единственно, что мне в Delphi не хватает Это Inline.
Практически безполезная штука единственное он иногда бывает нужет когда не шаблонную функцию описываешь прямо в заголовке.
S>Все остальное так же как ит ты пишу заготовки и Copy-Paste-Replase или собственную генерилку объектов на худой конец.
Да как ты не понимаешь что шаблоны и долбаный CPR не имеют ни чего общего. CPR раздувает код, разносит одну ошибку в десятки мест, создает новые... С шаблонами таких проблем НЕТ И БЫТЬ НЕ МОЖЕТ. К томуже шаблоны могут адаптироваться к типам с которыми они работаю, а код полученый при помощи CPR надо каждый раз править ручками.
А что касается ФИЗИЧЕСКОГО уровня то каму какое дело? Там все лишнее оптимизатор выкинет. Главное что ПРОГРАММИСТ не видит эту гору совершенно безполезного, мусорного кода.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: Oxy  
Дата: 12.02.04 16:58
Оценка: -1 :)
Здравствуйте, Аноним, Вы писали:

А>Стековые объекты испоьзуются в области видимости и уничтожаются при выходе из нее. Память выделяется гораздо быстрее чем при (.Create или new в С++). Тем более память может вообще не выделяться если это не нужно напрмер в условиях. Это конечно детали но мне в Delphi этот момент не нравится


Просто в Delphi понятие области видимости намного уже чем в С++, так как все определения даются в начале модуля или процедуры/ф-ции. Кстати мне такая структуированнсть кода больше нравится чем возможность определять переменные и т.п. в любом месте кода. Хотя все зависит от привычки.

А>Еще по поводу библиотеки типов в Delphi. Вроде визуально удобно но много глюков. Если знаешь IDL гораздо легче работать в текстовов редакторе. Это мое мнение. не зняю может я ошибаюсь


Что ты подразумеваешь под "библиотекой типов"?
Если ты имеешь в виду VCL, то она даже очень удобна. И глюков в ней не так уж и много. А уж свою основную ф-ию она выполняет на все 100%. Такого удобства проэктирования интерфейса как с помощью VCL я вообще нигде не встречал. Причем для нее написано великое множество расширений на все случаи жизни. Причем подавляющее большинство их полностью бесплатно и в исходных кодах.
Фактически что бы создать дружественный и красивый интерфейс требуется раз в 10 меньше времени чем в VC++, хотя он гордо называется Visual
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: pidolas  
Дата: 29.09.04 20:03
Оценка: -2
Здравствуйте, DOOM, Вы писали:

DOO>Сразу некоторые ответы на вопросы, возникшие в этом
Автор: DOOM
Дата: 26.08.03
топике.


DOO>Дельфи действительно швыряет EAbstractError при попытке создания экземпляра абстрактного класса, и это правильно, что в именно в run-time, поскольку пусть у меня следующая иерархия классов:

DOO>TAbstractClass = class ....
DOO>TClass1 = class(TAbstractClass)...
DOO>TClass2 = class(TAbstractClass)...
DOO>Я хочу создать массив, в котором будут и TClass1 и TClass2 — понятно, что надо создать массив TAbstractClass. В С это можно решить только используя указатели на класс, а в Дельфи есть только указатели на класс, просто это все неявно. И при их организации ООП это единственный способ. Поэтому-то мне и интересно как это сделано в С. К сожалению сейчас у меня нет времени покопаться в VS-ке и погладет как на asm'е все это выглядит.

DOO>По поводу того, что у Дельфи меньше возможностей... Приведите хоть один пример, который нельзя реализовать на Дельфи, но можно на C++. Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов, но это все очень, на мой взгляд, сомнительные вещи без которых вполне можно обойтись(макрос меняется inline функцией и результат одинаковый, шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).



DOO>По поводу IDE — тут по-моему вопросов нет. В дельфи оно факт удобнее.


DOO>По поводу библиотек — MFC vs VCL. VCL — действительно объектная библиотека, в которой обработка событий инкапсулированна в объект, а не реализуется посредством вставляемых куда-то макросов и т.п.


DOO>Теперь ваща очередь...


Уж сколько раз твердили миру...
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: Dimonka Верблюд  
Дата: 16.09.03 08:20
Оценка: 18 (1)
Здравствуйте, WolfHound, Вы писали:

WH>Я хоть слово сказал что рисовать ГУЙ это плохо?

WH>хъ
A>>Ну, не так?
WH>Нет не так. ГУЙ это в большинстве задачь ничтожно малая часть работы.

В моей работе 90% времени клиенты рассматривают именно ГУИ. Им наплевать на функциональность, функциональность проверят тестеры.
Так что на рынке самое главное это получить деньги на создание продукта, которых завтра тебе их уже не дадут или поменяются интересы или ... или ...
Клиенту надо увидеть как это будет примерно работать, где будет находится какая кнопочка. Тогда начинает работать фантазия: "а сюда ещё это добавить, а сюда то"..
Мне не надо писать ни сервисов, ни драйверов, ни операционных систем. А работы, поверь мне, хватит и Delphi в этом плане идеальная система для быстрой реализации задуманного. Недостатки известны, достоинства тоже. А весь этот топик видится мне на 90% бессмысленным. Одни эмоции. Ведь главное цель, а средства надо выбирать отталкиваясь уже от бюджета.
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 15.09.03 07:47
Оценка: 12 (1)
Здравствуйте, FWP, Вы писали:

FWP>Здравствуйте, WolfHound, Вы писали:


FWP>Какое самомнение! Ну почти господь бог. Истина в последней инстанции. А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов. Разговоры идут, планы ввода есть. А реализаций нет. И в C# тож самое. Видно не все так просто с надежностью.



Как раз с надежностью-то проблем нет (шаблоны есть, скажем, в Ada и SDL, которые, вообще говоря, надежны), есть проблема со сложностью реализации поддержки шаблонов. Откройте стандарт С++ и посмотрите описания name resolution-а. В этом, кстати, и была проблема с тем, что очень долго не существовало компилятора поддерживающего С++ в полном объеме.
Name resolution в Java-е прост и ясен, внедрение шаблонов повлечет черезмерное его усложнение.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re: Спор бесполезен!
От: centurn Россия  
Дата: 17.09.03 05:39
Оценка: 12 (1)
Здравствуйте, Miem, Вы писали:

M> Этот Человек одержим! Это положительно его характеризует!

M>Давно слежу за топиком. Все ответы четкие, все в тему, но с уклоном в одно.. Однобокий взгляд...
M>Попробуйте поспорить с истинным православным. У вас ничего не получится... Когда человек ВЕРИТ в то, что говорит его не переубедить, он живет этим. Поставить под сомнение веру такого человека — значит посягнуть на самое дорогое, обречь на гибель. Коперника сожгли такие люди! Опомнитесь!

M>PS Не в обиду WolfHound'у


Ага. Осторожно, WolfHound, а то эти Delphi-поклонники и сжечь могут.
Re: Идём дальше
От: WolfHound  
Дата: 12.09.03 07:33
Оценка: 6 (1)
Здравствуйте, akasoft, Вы писали:

A>Скажи, практика использования инструмента "Дельфи" у тебя большая?

Больше года
A>А оная, связанная с "C++"?
Гда четыре
A>С чем из этих двух ты познакомился раньше?
С дельфей, а еще раньше с турбо паскакалем

A>Для меня это естественно (Естественно, что естественно не "...Через задницу", а использовать TCollection и TCollectionItem). Более того, наглядно понятно. ООП. А запись шаблона смотрится, как на китайском языке. Но это потому, что я с ними не знаком, не пользовал ещё в практике...

В программах на С++ классы делятся на
1)Помошники(как правило шаблоны)
Делают всю грязную работу типа захват/освобождение ресурса причем полностью автоматически
В подовляющем большинстве на дельфе не реализуемы
2)Синглетоны
3)Логика(самые многочисленые)
Их специфика такова что их объекта путешествуют из функции в функцию, хранятся в коллекциях а то и в нескольких.
И что их всех теперь наследовать от TCollectionItem? И как реализовать хранение в нескольких коллекциях одного объекта?
Я делаю посто встроеный рефкаунтинг и дальше смартпоинтеры ведут объект пока он нужен. Причем все строго типизировано.
delete в программе на С++ это дурной тон.

WH>>Ага. Это каждай объект который я хочу хранить в коллекции должен быть наследником TCollectionItem ...

A>Ну да. Ты, похоже иерархию не прочувствовал. Всё наследуется от одной базы. Не нравится что? То, что это именно Коллекция, заточенная под ИДЕ? Так нет проблем, по аналогии клепаем свой базовый класс итемов и коллекций, и работаем. Это же 2 мин копи-пастом, где 1,5 мин. марафет наводить и комментарии писать. Чем это хуже? Копи-паст сакс — не аргумент никакой.
Да все я прочувствовал. И что КАЖДЫЙ объект должен тащить кучу ЛИШНЕЙ функциональности и то что хоть ты тресни но коллекция одна(в С++ есть std::map, std::set, set::list. std::vector, std::deque,... и все строго типизированые) причем полиморфная...

A>Не нравится, значит, как я код изложил. Так моей целью была не оптимизация, а демонстрация. Давай так.

О что я про эту дурь в хелпе прочитал... Там могут хранится только объекты одного типа нахрена нужна такая коллекция вобще не понятно.

A>Я уже не говорю о разработке собственной пары классов, заточенной под мои нужды. Один раз разрабатываю, много раз юзаю. Шаблоны кто-то тоже разрабатывал. Не 10 сек.

Вот только шаблоны приходиться писать много реже и пользовать много дольше.

WH>>Дельфевые коллекции это пародии на коллекции...

A>Опять же, почему? Это инструмент для работы в Инспекторе. Я, объявив published свойство (или поле) в классе, без никаких доп. затрат получаю возможность редактировать его в дизайн-тайме. Цель, которая ставилась перед инструментом, достигнута.
Возвращают TCollectionItem который надо приводить к типу коллекции, не могут хранить объекта разных типов, не могут просто добавить в себя рание созданный объект(только копированием)....

WH>>... Тормозные не типизированые...

A>И в чём тормоза, см. код на асме выше. Не типизированность отметаем, мы объявляли
A>типы указаны.

A>var
A>    C: TCollection;
A>    Item: TMyItem;
A>begin
A>    C := TCollection.Create(TMyItem);

А если в выделеных строчьках не совпадут типы тогда что? И мы не использовали as, is то мы получим не понятные глюки в рантайме
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.09.03 11:44
Оценка: 6 (1)
Здравствуйте, WolfHound, Вы писали:

S>> Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше.

WH>И в какой БД ты не типизированую пимять нашол?
S>>Да и API написан на Asme и С где типизацией если и пахнет то ...
WH>И очень на прасно. Хотя в те времена когда это все писалось выбора небыло. К томуже это язаки низкого и среднего уровня, а мы про ЯВУ разговариваем.
S>> Зачем огульно бросаться словами??? Не прав.
WH>Нда? Смотри выделеное и скажи что из этого не нужно в ЯВУ? Разве что смартпоинтеры там где есть GC и то иногда хочется детерминированого управления жизнью объекта.

В Net есть возможность детерминированого управления жизнью объекта.
Inline не нужен т.к. JIT компилятор следит за возможностью вставки кода и при этом оптимизируя под конкретный процессор.
Про шаблоны уже прошелся.

S>> Время рассудит, но Delphi найдет свою нишу в Net да и у Delphi с C# намного больше общего чем у C# с С++, да и M$ помоему не особо горит желанием развивать Native компиляторы.

WH>Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.

WH>>>Вот только пока далеко не все лучшие идеи используются в шарпе.

S>> Например???? Шаблоны будут, что еще???
WH>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
WH>А сейчас все очень убого. Почти на уровне дельфи.

А вот на шаблонах ты зря зациклился. Шаблоны по сравнению со ссылками на определенные структуры (с применением виртуальных функций ли интерфесов) имеют премущество в скорости и полную типизацию, но при этом значительно выигрывают только при вызове быстрых функций. Кроме всего прочего полно вариантов, где должны хранится ссылки на различные объекты и здесь премущество шаблонов как корова языком слизала.
И при всей твоей нелюбви к Copy-Paste-Replace названные тобой аргументы (ошибки в базовом классе, неудобство) не выдерживают критики.
и солнце б утром не вставало, когда бы не было меня
Re[24]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.09.03 20:21
Оценка: 6 (1)
Здравствуйте, WolfHound, Вы писали:

WH>У мнея такое ощущение что кто-то чего-то сильно не понимает.

WH>Допустим у нас есть некий объект который держит ресурс. Этот объект использовало куча других и через некоторое время он перестал быть нужен. Вопрос как узнать когда именно нужно освободить ресурс, а если легика была довольно сложной? В конце концов после долгих мучений выяснится что оптимальным решением будет именно подсчет ссылок.
Почему ты так думаешь? Проблема GC ровно в одном — простой ресурсов. Т.е. дефицитный ресурс может некоторое время простоять из-за того, что его овнер еще не финализировался. Давай рассмотрим такой случай. Пусть у нас есть пул из, скажем, 10 ресурсов. И вот толпа народу их разбирает. Теперь у нас есть 10 хозяев, каждый из которых держит ссылки на эти ресурсы. Пусть восемь из них циклически ссылаются друг на друга, остальные двое присутствуют в графе достижимости. Итого, восемь простаивают зря. Еще толпа народу стоит и ждет, когда освободятся эти ресурсы. Что делает GC? Рано или поздно он проснется и пристрелит этих восьмерых козлят, вернув ресурсы в пул. Причем чем сильнее нужны эти ресурсы, тем больше потоков встанут в ожидание — это повышает шансы GC проснуться и заработать. На пальцах картина получается примерно такой.
Подсчет ссылок в этом случае вообще встрянет, так как есть цикл, который ему неподвластен. Итого, мы имеем некоторую задержку возврата супротив невосполнимой утечки. Кто победит?
Да, можно программировать так, чтобы такие объекты никогда не вступали в циклы. Но почти с тем же успехом можно прораммировать так, чтобы ресурсы освобождались детерминистически, при помощи IDisposable.
Причем, стоит отметить, что GC наплевать на то, насколько сложна логика. Он собирает любые циклы. В то время как при подсчете ссылок в сложной логике можно нечаянно замутить-таки цикл. И дооолго думать, откуда он взялся.
WH>Хотя некоторые объекты (строки,...) лучше на GC.
Ты не мог бы пояснить, в чем принципиальная разница между строками и... другими ресурсами? Дело в том, что я знаком с различиями технологий управления памятью в реальных системах в основном теоретически (ни разу не видел, чтобы одна и та же система была реализована сразу в обоих вариантах ), так что может не знаю каких-нибудь удручающих фактов из жизни мусоросборщиков.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 17.09.03 08:10
Оценка: 5 (1)
Здравствуйте, mihailik, Вы писали:


M>Что вообще стоит писать на C++, если не низкоуровневый код, с использованием WinAPI и т.п.? А во всех этих WinAPI union'ы кругом торчат.


Гм. У нас на нем (C++/C) написан CASE тул, который включает: GUI, внутренние представление для модели, парсеры, кодогенераторы, Debugger, run-time библиотеки, импорт из других языков, storage в XML и все остальное. И все это хозяйство работает и под Win и под Solaris и под Linux. Помимо всего прочего, мы имеем COM Api, просто Api и Tcl Api. Все немеряно расширяемо.


С Delphi-ями мы бы зависли на реализации эффективного и удобного внутреннего представления по причине отсутствия множественного наследования и шаблонов.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: alexkro  
Дата: 29.08.03 08:13
Оценка: 4 (1)
Здравствуйте, Jenyay, Вы писали:

J>Здравствуйте, WolfHound, Вы писали:


J>>>Так тут другое дело, что память и выделяется и освобождается, когда надо, но сама. Хотя такими указателями я сам редко пользуюсь, но это не из-за глючности, а просто редко бывает запутанный код, что можно забыть освободить. Просто я стараюсь сразу после выделения памяти писать, где она освобождается.

WH>>А вто это очень зря. Для того чтобы я не использовал смартпоинтер нужна ооочень веская причина. Я даже с ходу придумать не могу.

J>Ну что ж, попробую пользоваться ими везде.


Только знай, что существует много вариаций классов смартпоинтеров, и что в разных случаях нужно использовать разные классы. Смотри, например, здесь и документацию по std::auto_ptr.
Re[19]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 25.09.03 01:19
Оценка: 4 (1)
Здравствуйте, mihailik, Вы писали:

M>А без C++ можно определение дать? А то получается, детерминированное осовобождение — чисто внутренне понятие C++.


Детерминированное == определенное. Т.е когда точно известен момент (и им можно управлять), например, смерти объекта.

WF>>Я не понимаю, что все к этим циклическим ссылкам привязались . Не так уж часто они встречаются.


M>Если важный сервер в банке будет падать "не так уж часто", ребята будут очень недовольны. Так что категории "часто/нечасто" тут не совсем правильны.


Почему нет? 100% надежных систем нет. Я всего лишь хотел сказать, что вероятность встречи с такой ситуацией, на мой взгляд, не очень высока. Хотя это архитектурная проблема.

Кстати, потенциальные циклические графы можно ведь и автоматически искать. Например есть модель в Розе ("умный" указатель — ассоциация с неким стереотипом, например, "shared ptr"). А потом просто все циклы таких ассоциаций искать. На бейсике наверняка довольно быстро ищется.

WF>>Гораздо чаще встречаются повисшие на событиях делегаты в .NET-е, и насколько мне известно, эта проблема красиво не решается.


По аналогии. Если важный сервер в банке будет падать "не так уж часто" (от нехватки памяти), ребята будут очень недовольны. И решается эта проблема аналогично C++-ым утечкам — профайлером. Между прочим, довольно распространенная ошибка. Видимо программисты думают, что GC за них все освободит и забывают обнулять ссылки, отписывать делегаты — отсюда получаются утечки памяти. Конечно, на объекты есть ссылки, но от этого они не перестают быть утечками — память тратится впустую.

M>А в чём, собственно, проблема-то? Ну да, делегаты создают жёсткую ссылку на объект и не дают его выбросить. Ну оно так и задумывалось, под это и написано.


Да.

WF>>А все из-за отсутствия автоматического вызова деструкторов. Приходится два раза думать об одном и том же. И если подписывание — это часть логики, которую за тебя, разумеется, никто не сделает, то отписывание часто — всего лишь освобождение ресурсов. Которое, опять таки, довольно часто может быть автоматизировано.


M>Проблема автоматического вызова деструкторов — та же архитектурная проблема циклических ссылок.


Проблема в том, что когда я подписываю на событие (например, в конструкторе, да еще и на статическое событие) — это часть логики. Если я забуду подписаться, это, скорее всего, легко обнаружится. А вот отписывание — уже не часть логики, я могу с легкостью забыть отписаться и получу утечку. Вот почему "умные" указатели существенно облегчают работу — нужно лишь захватить ресурс, а освободится он сам, причем управляемо.
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: LaptevVV Россия  
Дата: 27.08.03 13:54
Оценка: 2 (1)
Здравствуйте, DOOM, Вы писали:

DOO>Теперь ваща очередь...

Давайте не путать язык, компилятор и IDE.
1. Язык. С++ ИМНО богаче будет. Как раз за счет перегрузки операций и шаблонов. В остальном ИМХО — совпадают.
Но!!! STL, как ни крути, стандарт С++! до чего Дельфям топать и топать.
2. IDE — ИМХО дело вкуса.
3. Компилер — тут, без сомнения, дельфи по скорости давит все с++компилеры.

Кто возразит?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[11]: Некоторые итоги:
От: WolfHound  
Дата: 18.09.03 12:11
Оценка: 2 (1)
Здравствуйте, Serginio1, Вы писали:

WH>>В .НЕТ это простой copy-paste-replace. Там даже шаблонных функций нет

S> Еще раз http://www.dotsite.ru/Publications/PublicationDetails.aspx?ID=115
Ну и что ты этим постоянно сказать пытаешься? Для валью типов все тоже дублирование кода, а для ссылочных один код на всех. И что с того?
Мне чесно говоря вобще наплевать на то как это реализовано.
Мне нужно на уровне языка иметь возможности для реализации:
1)Обобщенных строготипизированых контейнеров. Это все на что способны .НЕТ шаблоны в том виде как они описаны в статье. Причем опять же не дотягивают до С++. Что касается ограничений то это они либо по незнанию либо террористы. В С++ можно тАкие проверки на параметры шаблона задать что шарпу и не снилось.
2)Обобщенные, адаптивные алгоритмы.
3)Мощьный codereusing
Причем 2 и 3 они только выглядат скромно, а на самом деле каждый из них будет побольше чем 1.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 27.08.03 10:05
Оценка: 1 (1)
Здравствуйте, Аноним, Вы писали:

А>Еще один факт. Число инсталляций VS значительно больше,

А>чем продукта от Борланда.
А>Это означает, что работы для того, кто владеет VS больше,
А>чем работы для дельфистов.
А>Причем не просто работы, а интересной работы.
А>Для меня это гораздо больше значит, чем маниакальная любовь
А>одной группы программеров к одному продукту и такая же нелюбовь к другому.

Я ни разу не попадал на такую работу, чтоб мне сказали, вот тебе задача, пиши на чем хочешь. Всегда на работе говорят: пиши на том-то. К сожалению, мне нравиться(сложилось так) паскаль и все, что из него выросло, а везде заставляют писать на С. Причем видел я и такой идиолтизм как написание достаточного громоздского интерфейса средствами чистого API. Больно было смотреть как маятся люди, делая тривиальные вещи, стоит только начать использовать VCL.
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 07:24
Оценка: 1 (1)
Здравствуйте, LaptevVV, Вы писали:

LVV>Так что единственное, в чем дельфи явно превосходит ВСЕ (имно) сишные компиляторы — это скорость компиляции. Вот за это его можно любить.

Да ну фигня какая. Если PCH нормально настроены то С++ тоже летает. Если фаил компилится меньше полсекунды я этого не замечаю, а с нормальными настроеками так и происходит.
А пара минут на полный билд большого проекта это смешно.
Тут главное PCH ручками настроить, а это за несколько кликов можно сделать.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: AlexK Украина  
Дата: 12.09.03 11:41
Оценка: 1 (1)
Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, AlexK, Вы писали:


AK>>...что лишний раз доказывает что не в языке дело, а в ДНК... или руках (смотря кому что роднее)


A>Да нет, дело в рынке.


A>Ну зачем писать 2 либы, делающие одно и тоже, но на двух языках. Представляете, ядро Windows, написанное на C, и то же самое, но на Fortran-е...


A>Буржуины началали первыми, а деньги они на ветер не бросают. Не прибыльно это дело. Куда проще сделать одну, а потом к ней описалово дать, ну или там заголовочные файлы для нескольких языков дать...


A>Отладка одна сколько сил отнимет...


вот к чему я и виду — что язык програмирование есть тулкит для работы.

Грубая аналогия: гаечный ключ... гайку можно и руками закрутить, но при помощи ключа это делать намного удобнее. продлим аналогии — у паскаля ручка чуть короче чем у с++. а по функционалу они равны... ( имелось ввиду что при помощи с++ можно намного сильнее закрутить гайки (рычаг больше), чем при помощи паскаля... усилия разные прикладывать просто надо )

а кривизна рук тут уже будет определяться на сколько правильно они умеют ключ поворачивать/держать и крутить в нужном направлении. )))

по-этому спор какой из двух "ключей" круче надо прекращать. бред это!
кому как нравиться, тот так и живет. Мне вот очень с++ нравиться, но пишу я щас с#... а он мне не нравиться...

некоторые фичи как шаблоны из с++ нужны, но проблему сию можно решить копи-пасте-реплейс...
только вот места в три раза больше занимает... это плохо — трудоемко... особенно когда менять надо...

т.е. как на меня крутизна языка должна определяться трудоемкостью... если одну и тужу задачу можно сделать за одно и тоже время на разных языках, то смысла спорить что круче нету! утрачивает свою основную опору такой спор и начинаються частности связанные с реализациями, а не языками.

во осинило:
язык — это средство выражения. кому-то русский родной, кому-то английский. что тут спорить какой язык круче?
один являеться интернациональным из-за простоты, а второй являеться очень выразительным в плане имоциональных настроений...
во загнул... самому понравилось.

так что тут каждый выберет: убогость но доступную каждому или гамму чувст, но доступную для понимания только некой части от общего.
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 27.08.03 05:01
Оценка: +1
Здравствуйте, DOOM, Вы писали:

DOO>Дельфи действительно швыряет EAbstractError при попытке создания экземпляра абстрактного класса, и это правильно, что в именно в run-time, поскольку пусть у меня следующая иерархия классов:

Не в ту степь занесло...
procedure some
var
  ptr:SomeAbstractClass
begin
  ptr:=SomeAbstractClass.Create;
end

Вопрос: Почему во время КОМПИЛЯЦИИ не происходит ошибки? С++ компилятор при попытке СОЗДАТЬ абстрактный класс будет громко ругаться во время компиляции.

DOO>По поводу того, что у Дельфи меньше возможностей... Приведите хоть один пример, который нельзя реализовать на Дельфи, но можно на C++.

DOO>Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов,
Если без этого то язики почти эквивалентны
DOO>но это все очень, на мой взгляд, сомнительные вещи без которых вполне можно обойтись
А вот это ооочень напрасно
DOO>(макрос меняется inline функцией и результат одинаковый,
Макросы в место инлайн функций спользуют только [censured]...
DOO>шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).
Ты спутал с макросами. Шаболы в С++ дают тАкие преймущества что по сравнению с ними некоторое разбухание ехешника это ничто.
Одни смартпоинтеры чего стоят... я давно забыл что существует оператор delete.
А STL это вобще чудо света на дельфях низачно так просто не создашь строго типизированый список ассациотивных массивов
std::list<std::map<std::string, boost::shared_ptr<object> > >
Только не спрашиавй зачем это надо я не знаю но когда понадобится то...

DOO>По поводу IDE — тут по-моему вопросов нет. В дельфи оно факт удобнее.

Ну это дело привычки. По мне вижуловский IDE (когда дело не касается GUI) моного лучше. А если мне понадобится GUI то есть C#, а есть так приспичило анменеджет то можно и на VB6 нарисовать. Да и вконце концов использовать WTL не на много сложнее чем в делфе рисовать.

DOO>По поводу библиотек — MFC vs VCL. VCL — действительно объектная библиотека, в которой обработка событий инкапсулированна в объект, а не реализуется посредством вставляемых куда-то макросов и т.п.

Вот про MFC не надо. Этого динозавра давно пора пристрелить чтобы ни кто не мучался. Все прогрессивное человечество либо уже переползло на WTL либо собирается.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: Jenyay http://jenyay.net
Дата: 27.08.03 05:55
Оценка: +1
Здравствуйте, DOOM, Вы писали:

DOO>>>(макрос меняется inline функцией и результат одинаковый,

WH>>Макросы в место инлайн функций спользуют только [censured]...
DOO>Конкретнее. В чем разница?

Да потому что макросы заменяются до компиляции и можно долго смотреть на одну строчку с ошибками компиляции, а она окажется в макросе. Где-то был хороший пример с max, сейчас уже некогда — если до вечера не напишут — попытаюсь найти.

DOO>>>шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).

WH>>Ты спутал с макросами. Шаболы в С++ дают тАкие преймущества что по сравнению с ними некоторое разбухание ехешника это ничто.

DOO>В одной книжке я встретил правильную фразу, дословно не помню, что-то вроде, что существует объектно ориентированное пргораммирование и шаблонное программирование.

DOO>Очень разные вещи, поскольку в STL нет никакого наследования, например.

Насчет STL не знаю — как то не приходилось от них ничего наследовать (хотя, вроде бы можно), но никто не мешает сувать шаблоны в свои классы и наследовать от них.

WH>>Одни смартпоинтеры чего стоят... я давно забыл что существует оператор delete.

WH>>А STL это вобще чудо света на дельфях низачно так просто не создашь строго типизированый список ассациотивных массивов
WH>>std::list<std::map<std::string, boost::shared_ptr<object> > >
WH>>Только не спрашиавй зачем это надо я не знаю но когда понадобится то...

DOO>А указатели-то никто не отменял. Все можно творить используя их. И логика программы по-моему тогда на порядок понятнее.

DOO>Мне просто это больше нравится(ну просто псле программирования на asm'е появились такие привычки)

Так со смартпоинтерами можно не бояться, что забудешь освободить память.

WH>>Вот про MFC не надо. Этого динозавра давно пора пристрелить чтобы ни кто не мучался. Все прогрессивное человечество либо уже переползло на WTL либо собирается.


DOO>Видимо MS это не прогрессивное человечество . Все ведь говорят, что WTL больше не поддерживается и не документируется.


А зачем на м MS
... << RSDN@Home 1.1 beta 1 >>
Софт, исходники и фото
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 27.08.03 06:18
Оценка: -1
Здравствуйте, Jenyay, Вы писали:

J>Здравствуйте, DOOM, Вы писали:


DOO>>Кстати, совсем забыл!!! Библиотеки Дельфи кросс-платформенные!


J>Ну к Сям тоже можно найти кроссплатформенные.


J>>>С перегрузкой как-то красивее будет.


DOO>>Да перегрузка операторов это хорошо. Но, когда я увидел, что у _bstr_t перегружен char * — меня это возмутило, ведь это в корне не верно!


J>А что за _bstr_t? А вообще испахабить все можно.


_bstr_t это из той же серии, что _com_ptr(смарт пойнтер кстати), _variant_t — и т.д. Какие-то MSовские типы данных для поддержки COM, но не ATL.
Ну ладно, отвлечемся, а как еще удобно BSTR'ами работать?

DOO>>В дельфи не встречал такого. Может в Builder'e. Меня как раз возмутило, что, если в VS хочешь посмотреть объявление чего-то, то надо откомпилить поект в начале(на моем PIII 600 это долго(!)). А в дельфи навел мышью и уже пишут в каком файле, в какой строке. А если нажел Ctrl и щелкнул мышью, то моментально перейдешь туда.


J>А зачем компилить? Или я этим не пользовался. VA вверху вроде бы пишет объявление (я этим как-то редко пользуюсь).


Елси я хочу, например, посмотреть что такое AFX_INLINE я нажимаю правую кнопку и вызываю Go to definition.

J>>>2. В студии сами ставятся закрывающиеся } (Или это уже VA?)


DOO>>Это VA и эту вещь я вырубил. Больше мешает.


J>Впранципе, про IDE спорить вообще бесполезно — слишком субъективно, а при желании можно найти другой редактор.


В принципе да.
Но языка Дельфи нет. Есть слегка расширенный object pascal и IDE.
J>>>Что-то не нравилось еще, но это было давно, поэтому не помню. А если поставить VisualAssist, то после него не то что с Дельфей невозможно работать, со студией без этого Assist.

DOO>>Да VA сильно улучшает VS, но у моего коллеги после VA полностью заглючил ClassWizard...


J>У меня вроде бы нет.


У меня тоже вроде нет. Но VS вообще довольно глючная...
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 27.08.03 08:19
Оценка: +1
J>>Да потому что макросы заменяются до компиляции и можно долго смотреть на одну строчку с ошибками компиляции, а она окажется в макросе. Где-то был хороший пример с max, сейчас уже некогда — если до вечера не напишут — попытаюсь найти.

#define max(a,b)    (((a) > (b)) ? (a) : (b))

int a=5, b=5;
max(a++, b)

классика...

DOO>Дак это плюсы макросов что ли? По-моему Вы не ту точку зрения стали отстаивать

DOO>И вообще — макром наворот текстового редактора, а не языка.

Да ту все... Смысл в том, что макросы плохо, но все же лучше, чем copy-paste, и у них есть гораздо более важные применения, чем inline-функции, а вот шаблонные функции гораздо лучше макросов. И опять же, шаблонные функции — только самое очевидное и примитивное применение шаблонов.
А вот что такого есть в Делфях кроме copy-paste?


J>>Насчет STL не знаю — как то не приходилось от них ничего наследовать (хотя, вроде бы можно), но никто не мешает сувать шаблоны в свои классы и наследовать от них.

DOO>Получается очень странный малопонятный гибрид. Пример:
...

DOO>И что в итоге получается? CSon1 и CSon2 сложно называть детьми CTemplateClass.


Они дети специализированного CTemplateClass. А вообще-то может так подразумевалось?
template <class T>
class CTemplateClass
{
 T member;
}
template <class T>
class CSon : public CTemplateClass<T>
{
}

Так можно. Честно. Кстати, STL сама обычно использует наследование шаблонов налево и направо. Можно глянуть ее реализацию...

И вообще сила шаблонов в инстанциациях (то, что именно в этот момент увязываются зависимые вещи) — например, благодаря этому в вещи вроде for_each можно подать и функцию, и функтор. А главное — специализации. С их помощью можно делать действительно мощные и легко изменяемые вещи с проверкой на этапе компиляции и максимально эффективно по времени выполнения — все из-за возможности обойтись без всяких там RTTI...

DOO>Я предпочитаю и сам конструктор вызвать и деструктор. И как-то использование owner у TComponent прозрачнее и понятнее.


А забыть вызвать деструктор в случае "ветвистого" кода, например?
В C++ я могу создавать автоматические объекты, а могу, если надо, сам говорить, года ему создасться, а когда умереть. Всегда лучше, если есть выбор...

J>>А зачем нам MS


DOO>Мне на работе сказали WTL — хорошо, но MS не поддерживает. Поэтому пиши на MFC.
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.08.03 16:24
Оценка: +1
Здравствуйте, mihailik, Вы писали:

S>> А так это уже религиозный вопрос. В любом случае дельфистам предпочтительнее знать vs C++,


M>Да не нужны эти плюсы Дельфистам. На C# лучше смотреть, он и понятнее и перспективнее.


S>> а обратное по желанию. Но читабельность и скотрость разработки на .... выше.


M>По моим впечатлениям, C# в обоих категориях лучше Дельфи. Delphi.NET мог бы исправить положение, но слишком опаздывает. The time is almost up (Matrix 2).


Не соглашусь, что Все Дельфисты перебежали на C# (хотя самому Оооочень нравится), а вот Delphi.NET ускорит переход на Net. И влюбом случае надо знать C#. А выход Delphi.Net в конце года и интересно какая будет трудоемкость по переписыванию приложений на Net .
и солнце б утром не вставало, когда бы не было меня
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 05:59
Оценка: -1
Здравствуйте, WolfHound, Вы писали:


DOO>>В одной книжке я встретил правильную фразу, дословно не помню, что-то вроде, что существует объектно ориентированное пргораммирование и шаблонное программирование.

DOO>>Очень разные вещи, поскольку в STL нет никакого наследования, например.
WH>STL это набор базовых контейнеров и базовых алгоритмов.
WH>Внимание вопрос:Какое отношение ООП имеет к сортировке? А к двухсвязному списку?
WH>Ну скажи мне тебе часто приходит в голову наследоваться от массива? А потом подумай чем логически stl'ные контейнеры отличаются от простых массивов?

Спор пошел не в ту сторону. Я просто сказал, что шаблонное прграммирование — это совершенно иная техника программирования, которая, на мой взгляд не очень сочетается с ООП(не в том случае, если создаются только разного рода контейнеры).

DOO>>А указатели-то никто не отменял. Все можно творить используя их. И логика программы по-моему тогда на порядок понятнее.

WH>Слегка перефразируем. Вот такой контейнер очень даже может понадобиться
WH>std::map<std::string, std::list<boost::shared_ptr<object> > >
WH>Это ассациотивный массив списков смартпоинтеров на объекты. Нука покажи мне как ты это сделаешь на дельфях? Ы? Причем сложность поиска в std::map log(N).

TStringList у которого объекты это TList, в котором хранятся указатели на нужные объекты — не вижу проблемы.
P.S. Конкрентные примеры из языка мне давать тяжело, поскольку инет на работе, а тут под рукой только VS


DOO>>Мне просто это больше нравится(ну просто псле программирования на asm'е появились такие привычки)

WH>Что нравится? Писать тонну кода ручками каждый раз когда нужен ассациотивный массив на красно-черном дереве?

Почему тонну кода? Возьмем, к примеру, Array из JScript — умеет сортировать свои элементы qsort'ом, для счастья надо только функцию сравнения.
Тоже самое можно реализовать везде. Я просто имел ввиду, что пойнтер он и в Африке пойнтер, не важно на что указывает. И в роли type cast'а после asm'а я признаю логичные вещи типа Dword Ptr и т.п., соответственно, когда _bstr_t перегоняется в char * простым type cast'ом — это на мой взгляд не верно.
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: Дарней Россия  
Дата: 28.08.03 07:30
Оценка: +1
DOO>А, между прочим, один препод у нас заявил, что в "Европе и лучших домах Филадельфии "(за бугром, одним словом) ОТКАЗАЛИСЬ от С в промышленной разработке ПО, поскольку, цитирую, "этот язык похабен".
DOO>P.S. По его словам все прогрессивное человечество использует Аду.

всегда подозревал, что ни один толковый програмер не полезет в ВУЗ преподавателем. Если только от большой любви к преподаванию (но я ни разу таких не встречал )
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 09:32
Оценка: +1
Здравствуйте, desperado_gmbh, Вы писали:

_>А у нас полмиллиона строк ребилдятся час и линкер свопит даже на 512 мегах памяти. Настройки уже нормальные.

А на пару десятков длл разрезать не пробовали? Говорят помогает...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 09:33
Оценка: +1
Здравствуйте, DOOM, Вы писали:

DOO>Имелись ввиду Pre Compiled Headers — но разве это сильно ускорит компиляцию?

Ооочень сильно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 09:46
Оценка: +1
Здравствуйте, DOOM, Вы писали:

Д>>Какой другой смысл?

DOO>(char *)name — указатель на байт. Занимает 4-ре байта. Посмотри на первые четыре байта от метки name как на указатель на байт. Такой вроде всегда был смысл(если не ошибаюсь reinterpret_cast в С++)
C style cast ни когда не был аналогом reinterpret_cast
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: Дарней Россия  
Дата: 28.08.03 10:18
Оценка: +1
DOO>(char *)name — указатель на байт. Занимает 4-ре байта. Посмотри на первые четыре байта от метки name как на указатель на байт. Такой вроде всегда был смысл(если не ошибаюсь reinterpret_cast в С++)

1. char* — не то же самое, что BYTE*. Как правило, char* играет роль указателя на строку, здесь — в том числе
2. не нужно путать операторы преобразования и приведения типов, это абсолютно разные вещи, хотя и выглядят похоже. То, что здесь оператор преобразования выдает указатель — всего лишь частный случай
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 28.08.03 12:53
Оценка: -1
DOO>>Что значит забей? .NET языковонезависимая, т.е. начнется что лучше C#,C++,Delphi.NET и еще бог знает что.

WH>А то и значит. Если надо ГУИ и клиентов к БД то прямая дорога на .НЕТ


GUI на .NET как раз пока не очень удобно делать. Бесплатных компонент маловато

WH>Во всех остальных областях дельфи проигрывает С++ с треском.


Кгм. В удобстве C++ проигрывает всем, кому только можно. Разве что ассемблеру не проигрывает.
... << RSDN@Home 1.1 beta 1 >>
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 28.08.03 12:53
Оценка: -1
WH>Да ну фигня какая. Если PCH нормально настроены то С++ тоже летает. Если фаил компилится меньше полсекунды я этого не замечаю, а с нормальными настроеками так и происходит.
WH>А пара минут на полный билд большого проекта это смешно.
WH>Тут главное PCH ручками настроить, а это за несколько кликов можно сделать.

В Дельфи принято исправлять ошибки компиляции в таком режиме. Компилируем, IDE выбрасывает курсор на первую ошиюку. Исправляем — и опять компилируем. Курсор на следующей ошибке.

Это получается ровно столько же по времени, как и просто для перехода к следующей ошибке.

Такая вот скорость компиляции. Это тебе не полсекунды, это просто моментально.
... << RSDN@Home 1.1 beta 1 >>
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 29.08.03 09:49
Оценка: -1
WH>В дельфе надо следить за ресурсами ручками, а это так задалбывает...

Эт смотря за какими. Например, при использовании интерфейсов всё за счёт "скрытых" AddRef/Release отлично освобождается.

procedure abc;
var s: IMyInterface;
begin
  s:=TMyObject.Create;
    s.DoSome;
    ...
    // и никаких забот — само освободится
end;


C++ вызывает деструкторы только для объектов в стеке. Если объект используется через указатель — точно так же заботится приходится самому. Просто в Дельфи все объекты — указатели.

WH>А если писать с использованием исключений то код превращается в кучу try/finally что не добавляет ни читабельности ни скорости, а как оно задалбывает...


Ну уж не знаю, как можно писать безопасный код без try/finally. Даже на C++. Разве что на WinAPI да ручками проверять каждый возврат на 0 или INVALID_FILE_HANDLE или что там ещё.

WH>Еще очень часто есть куча рутинной работы которую в 99% случаев можно свалить на шаблоны.


Хе-хе. Это кто же виноват, что в C++ столько рутины?

В Дельфи и без шаблонов рутинной работы практически нет.

Возьми вон сделай простейшую Dll с одним экспортом. На C++ это будет куча мелкий хидеров, файликов и всяких деклараторов. А на Дельфи — один скромный исходник.

WH>STL контейнеры это вобще штука не заменимая. Если знаешь что тебе надо и свойства контейнеров то самопальные контейнеры не нужны в 99.999% случаев.


Что, и типизированные коллекции для COM можно на одних шаблонах сбацать?

WH>И многое другое...


Ну, насчёт многого другого может быть ты и прав.
... << RSDN@Home 1.1 beta 1 >>
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 01.09.03 05:40
Оценка: :)
Здравствуйте, Mamut, Вы писали:



M>Что еще нельзя делать в Delphi/Builder? Нельзя эффективно перехватывать оконные сообщения для создания кустомизированных контролов "на лету". Необходимо создавать свои собственные компоненты.


А чем тебя не устраивает
procedure Foo(var msg:TMessage);message WM_что_угодно;

M>Код Дельфи не кроссплатформенный, как здесь кто-то утверждал, если не пользоваться CLX. Если пользовать, придется таскать n-мегабайтовые библиотеки. Правда, в случае Buildera, это и так приходится делать...


M>Нe спорю, Borland'овские продукты красивы и в общем удобны, но... Писать не-GUI и серьезные вещи IMHO надо на С++.


А как же например, работа с сетью? Написать сервер на Дельфи раз плюнуть.
Написать многопотоковое приложение тоже очень просто.
Что еще подразумевается под *серьезными* вещами?
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 01.09.03 05:48
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Mamut, Вы писали:


M>>В МС в 8-ой строчке показывает member-list из CMyClass, а в 9-ой орет "ci is not a structure or a class". Причем такие глюки повсеместно.

WH>Говорят VisualAssist помогает.

Не полностью.

M>>В 6-ой версии как минимум Builderа всплывающая подсказка показывает только те функции, методы и т.п., которые имеют смысл в данной конкретной ситуации, а не содержание всех заголовочных файлов SDK.

WH>Ну это очень сомнительное достоинство.
WH>А вот то что подсказака вываливается 2-3 секунды это очень напрягает.

Ну конечно. А в VS я ее жду секунд 6-8. За это время успеваешь расслабиться
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 02.09.03 08:23
Оценка: +1
Здравствуйте, DOOM, Вы писали:

DOO>Разница-то в чем??? Я на Дельфи не только "окошки с клиентами БД" писал. Я, например, писал полноценный сканер портов(ничем не хуже nmap'а) и NetBios сканнер. И утверждаю, что это намного проще чем на сях!

А я утверждаю что эти аппликухи практически равноценны окошам к БД.

ЗЫ ты так и не ответил на этот
Автор: WolfHound
Дата: 28.08.03
пост.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 03.09.03 06:43
Оценка: -1
M>>

M>>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
M>>Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

M>>expor.c
M>>expor.c(3) : error C2059: syntax error : 'string'


WH>Ну и что ты этим сказать хотел?


Запускаю компилироваться — не работает.

Наверное, там ещё кучу всяких makefile и т.п. нужно? Вот так я о том и говорю.

library MyDll;

procedure MyExportFunction; stdcall;
begin
end;

exports MyExportFunction;

end.


И всё, ни тебе препроцессорных директив, ни тебе двойных подчёркиваний, ни даже поганенькой ссылки на подключаемые модули. Текст прозрачен и чист, просто хоть в рамочку бери. На C++ так безмятежно не покодируешь.
... << RSDN@Home 1.1 beta 1 >>
Re[12]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 03.09.03 09:03
Оценка: -1
Попробую ответить на основные претензии к Delphi.

-На Delphi нельзя писать компактные приложения.
Никто ведь не отменял WinAPI. Кроме того существует библиотека KOL позволяющая работать в Delphi как RAD и получать очень (ну очень) маленькие приложения.
-На Delphi нельзя писать быстрые приложения.
Тут пробегала ссылка на статью "Кто сейчас самый шустрый". Так ведь в там Delphi обошел VC++ в шести тестах из десяти.
-На Delphi нет STL
Сдается мне, что в абревиатуре STL буквочка L обозначает LIBRARY. Ну и кто вам сказал, что для Delphi нет соответствующих библиотек. Другое дело, что STL явлется стандартом для С++, а для Delphi библиотеки пишутся третьими фирмами и их еще нужно искать .
-На Delphi нельзя писать драйверы.
Это не недостаток языка или инструмента. Это политика MS. Сдается мне, что к примеру на GCC тоже не получится написать драйвер. А необходимой функциональностью Delphi обладает.
-Delphi устарела и нужно переходить на C#.
Поковырялся немного с C#. У меня создалось впечатление, что пишу на Delphi, но с другим синтаксисом. А вообще конечно замечательный язык
-На Delphi нет серьезных проектов.
М.б. мы их просто не знаем. Но к примеру значительная часть бортовой математики для космоса и военной авиации у нас была написана на Modula2. А это ведь ближе к Delphi, чем к С++.
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.09.03 21:10
Оценка: :)
Здравствуйте, mihailik, Вы писали:

M>Так я же и говорю — в Дельфи скорость компиляции примерно такая же, как пару раз нажать стрелочку вниз. Даже C# до этой скорости далеко. А уж C++ ни в жизнь не догонит.


Ну, ну. У нас был проектик который компилировался минуту. Отлаживаться было очень не комфортно.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 04.09.03 04:07
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Ну предоставь Кое о чем я уже говорил.

Если ты об этом:

int main()
{
    enum{N=100};
    int int_arr[N];
    float float_arr[N];
    double double_arr[N];
    std::string string_arr[N];
    //....
    std::sort(int_arr, int_arr+N);
    std::sort(float_arr, float_arr+N);
    std::sort(double_arr, double_arr+N);
    std::sort(string_arr, string_arr+N);
    return 0;
}

то все просто. Берем библиотеку, в которой реализована сортировка для этих типов и все.


FWP>>А шаблоны для Delphi есть. Не знаю уж насколько хороши.

WH>Если ты про ту шутку которая на королевстве описана то это даже до препроцессора недотягивает.
Скорее всего.

FWP>>Не люблю я их. Даже в C++.

WH>Просто не знаешь.
Имею представление. Но не нравятся они мне. М.б. потому, что приходится использовать BCB. А это такая глючность
Re[18]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 04.09.03 07:23
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, FWP, Вы писали:


WH>>>Ну предоставь Кое о чем я уже говорил.

FWP>>Если ты об этом:
WH>[]
FWP>>то все просто. Берем библиотеку, в которой реализована сортировка для этих типов и все.
WH>Я же говорю что не предстовляешь что такое STL. std::sort реализована для ЛЮБЫХ типов у которых определен оператор <, а если хочешь отсортировать типы для которых не определен < просто пишешь свой компатор и все.
Ну зачем считать других глупее себя. Читай еще раз Берем библиотеку, в которой реализована сортировка для нужного типа и все.
Re[16]: По просьбам трудящихся: Delphi vs C++(VS)
От: Dimonka Верблюд  
Дата: 04.09.03 07:26
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Dimonka, Вы писали:


FWP>>>>-На Delphi нет STL

D>>Что ж в этом STL такого, чего на Delphi не досягаемо?
WH>Нука изобрази аналог на дельфях.
WH>
WH>int main()
WH>{
WH>    enum{N=100};
WH>    int int_arr[N];
WH>    float float_arr[N];
WH>    double double_arr[N];
WH>    std::string string_arr[N];
WH>    //....
WH>    std::sort(int_arr, int_arr+N);
WH>    std::sort(float_arr, float_arr+N);
WH>    std::sort(double_arr, double_arr+N);
WH>    std::sort(string_arr, string_arr+N);
WH>    return 0;
WH>}
WH>

WH>Заметь объекты разного размера и природы. А тагже мы не получаем никакого оверхеда.
WH>Еще сюда
Автор: WolfHound
Дата: 28.08.03
глянь.

WH>И это только цветочки...

Сортировка, это конечно замечательно, но не так критично.

WH>Что? GC? Reflection? Runtime code generation? Или ты говоришь что окошки похожи?

WH>Ну окошки на дельфе рисовать это нормально но писать логику

А логика на Дельфи выглядит, имхо, гораздо более читаемо, чем на Си++, а это тоже немаловажно.
Re[16]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.09.03 16:19
Оценка: :)
Здравствуйте, WolfHound, Вы писали:


FWP>>>>-На Delphi нет STL

D>>Что ж в этом STL такого, чего на Delphi не досягаемо?
WH>Нука изобрази аналог на дельфях.
WH>
WH>int main()
WH>{
WH>    enum{N=100};
WH>    int int_arr[N];
WH>    float float_arr[N];
WH>    double double_arr[N];
WH>    std::string string_arr[N];
WH>    //....
WH>    std::sort(int_arr, int_arr+N);
WH>    std::sort(float_arr, float_arr+N);
WH>    std::sort(double_arr, double_arr+N);
WH>    std::sort(string_arr, string_arr+N);
WH>    return 0;
WH>}
WH>

WH>Заметь объекты разного размера и природы. А тагже мы не получаем никакого оверхеда.
WH>Еще сюда
Автор: WolfHound
Дата: 28.08.03
глянь.

WH>И это только цветочки...
Данный пример очень легко решается смотри _DynArrayXXX и typeInfo правда Функцию сравнения нужно присваивать.
Проблема шаблонов в Delphi легко решается через обыкновенную замену (суть в шаблонах та же, только выполняется компилятором) но шаблоны явно не помешали бы. Перегрузка операторов тоже нет. С другой стороны очень много вещей которые компилятор берет на себя в Delphi (Динамические массивы,строки интерфейсы, диспинтерфейсы итд).

Тот же вариант легко решается и через TList, но не совсем красиво.

Я лично считаю, что будущее за Net и спор этот абсолютно бессмысленен и неуместен ввиду их (Native Delphi и VS C++) скорой гибели . Очень интересно посмотреть на Delphi.Net. А вот перспективы (опять же в моем понимании) C++ весьма туманны и ....
И связано прежде всего с выходом огромного количества по архитектуре процессоров да и сама идеалогия Net (отражение, динамическое создание объектов, продуманная структура объектов, единая платформа и языковая независимость) намного прогрессивнее, чем улучшать уже морально устаревшие Native компиляторы и языки на них базирующихся.

В любом случае Сишники должны быть только благодарны Delphi за одно только, что есть конкурент, а значит есть стимул развития продуктов от M$. Кстати здесь тоже интересно посмотреть на подводные камни
Например
Теория: MS .Net — продукт Borland
http://sumdu.edu.ua/~chekalov/teach/net_is_borland03.htm
это третья статья
http://sumdu.edu.ua/~chekalov/teach/net_is_borland01.htm
http://sumdu.edu.ua/~chekalov/teach/net_is_borland02.htm

Это только мое скромное личное мнение.
и солнце б утром не вставало, когда бы не было меня
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 05.09.03 04:38
Оценка: -1
Здравствуйте, centurn, Вы писали:

C> Ты сам-то хоть представляещь себе шутер, написАнный на Делфях? Я говорю, что можно, но только можно ли всерьез воспринимать такую возможность? Кстати, я именно про шутер — какую-нить турновую стратегию довольно нормально можно сделать... А драйвера и операционки тоже на Делфях писАть будем...


Кстати, а много ли люди видали драйверов написанных на С++, а не на С?
MS сами рекомендуют невыеживаться и писать не на асмах и С++ дрова, а на обычном С. Да и хороший пример ОС разработанной на языке высокого уровня это *nix — между прочим тоже С, а не C++.
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: Lloyd Россия  
Дата: 05.09.03 07:28
Оценка: +1
Здравствуйте, DOOM, Вы писали:

DOO>Кстати, а много ли люди видали драйверов написанных на С++, а не на С?

DOO>MS сами рекомендуют невыеживаться и писать не на асмах и С++ дрова, а на обычном С. Да и хороший пример ОС разработанной на языке высокого уровня это *nix — между прочим тоже С, а не C++.

Было бы удивительно, если бы они ее написали в 70-ых на С++, которого тогда еще не было.
Re[20]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 05.09.03 08:17
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>>>Отсутствие автоматических объектов превращает жизнь в ад вернее в try finaly что тоже самое.

FWP>>Борьба с неопределенным поведением автоматических объектов ничем ни лучше. Читай вашего любимого классика Б.Страуструпа.
WH>Каким не определенным поведением? Нука обьясни.

Пожалуйста:

  class char_stack {
      int size;
      char* top;
      char* s;
  public:
      char_stack(int sz) { top=s=new char[size=sz]; }
      ~char_stack()      { delete s; }     // деструктор
      void push(char c)  { *top++ = c; }
      char pop()         { return *--top; }
  };

  void h()
  {
      char_stack s1(100);
      char_stack s2 = s1;  // неприятность
      char_stack s3(99);
      s3 = s2;             // неприятность
  }



Здесь конструктор char_stack::char_stack() вызывается дважды: для
s1 и для s3. Для s2 он не вызывается, поскольку эта переменная
инициализируется присваиванием. Однако деструктор
char_stack::~char_stack() вызывается трижды: для s1, s2 и s3! Кроме
того, по умолчанию действует интерпретация присваивания как
побитовое копирование, поэтому в конце h() каждый из s1, s2 и s3
будет содержать указатель на вектор символов, размещенный в
свободной памяти при создании s1. Не останется никакого указателя
на вектор символов, выделенный при создании s3. Таких отклонений
можно избежать: см. Главу 6.

И такими перлами эта книга прямо напичкана под завязку.
Re[12]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 05.09.03 08:36
Оценка: :)
Здравствуйте, DOOM, Вы писали:

DOO>И современные разработки продолжают вести на C. И вообще все unix'оиды не признают C++, нас препод долго обсмеивал за то, что на парах по Linux'у мы пытались писать программки с использованием new и т.п. И утверждал при этом, что лишь С достоин существования. Вот так.

Давай его сюда. Сначала я ему обьясню почему С++ круче чем С, а потом Влад и AVK почему надо все бросать и писать на C#.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 05.09.03 09:06
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, FWP, Вы писали:


WH>>>Каким не определенным поведением? Нука обьясни.

FWP>>Пожалуйста:
FWP>>И такими перлами эта книга прямо напичкана под завязку.
WH>Вот только не надо путать кривизну рук с неопределенным поведением.
WH>Тут все четко и понятно. Все определено все действия предсказуемы.
WH>Нужно всеголишь описать конструктор копирования и копиующие присваивание.
WH>Этот пример был дан как предостережение и не болие того.
WH>И вобще std::stack никто не отменял.

1-е Какого черта пости для каждого объекта я должен писать такую тучу конструкторов.
2-е Почему в объекте сыне я могу вызвать конструктор родителя только перед выполнением своего конструктора.
3-е (к другому вопросу) Универсальная сортировка это TList.Sort.
Re[22]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 05.09.03 10:27
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Дык конибудь покажите мне уневерсальную сортировку на паскакале. Пусть жаде придеться писать коматоры. Слабо?

Ну почему ты такой упертый! Ну хорошо я повторю:
В Delphi шаблонов нет. Поэтому это сделать нельзя приемлемым для практического использования способом. Но всегда можно найти соответствующую ПРАКТИЧЕСКИМ НУЖДАМ библиотеку!
Re[18]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 05.09.03 13:29
Оценка: +1
Здравствуйте, _Obelisk_, Вы писали:

_>>То есть для таких задач не надо использовать C, потому что в нем есть malloc? Никто же не заставляет использовать ненужную функциональность, а про RTTI и exceptions, добавляющие оверхед, я уже написал двумя строками выше.

_O_>Меньше функциональности — проще компилятор, зачем стрелять из пушки по воробъям ?

Да, средства разработки для контроллеров часто очень убоги. Но если под данную платформу есть плюсовый компилятор, какие могут быть причины им не пользоваться, кроме поддержки старого кода?
Re[25]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 05.09.03 16:44
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S> Вопрос тебе сортировку массивов элементарных типов или сложных структур.

И тех и других в одном флаконе.
S>Иногда легче применять ссылочные массивы с функцией сравнения или при динамической сортировке применять Б деревья.
Типа std::map и std::set это из другой оперы у меня есть массив хочу его отсортировать.
S>Все о чем ты говришь с применением шаблонов легко решается с помощью Replace или заменой типа соответсвенно скопировав модуль и переименовав его. Не очень сложная задача.
cope/paste это не решение это проблема.
S>Можно вспомнить про GetIdsOfNames и Invoke, MakeCreateInstace. Несовместимост Дельфийных и Сишных классов. Суть в совместимости. И почему сишники пишут на Delphi совмещаяя с С++????? А их огромное множество.
Ни чего не понял.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[27]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 08.09.03 06:51
Оценка: +1
Здравствуйте, DOOM, Вы писали:

DOO>Пожалуйста:

Ага проверяем параметры и если не правильные то создаем частично инициализированый объект. Очень крутая логика.
Если уж так надо проверить что-то перед инициализацией базы то

struct some{};
struct base
{
    base(some*){}
};
struct derived
    :base
{
    derived(some* ptr)
        :base(test_some(ptr))
    {}
    static some* test_some(some*)
    {
        if(!is_good)
            throw bad_some_ptr();
    }
};

Таким образом мы просто не создаем объект если обломились входные условия.
Но мне такой изврат ни разу не был нужен.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: vedmed  
Дата: 08.09.03 07:45
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Если уж сравнивать то с std::list. А вчем это он удобней? Кроме того что типо не безопасен? Не может прибивать обхекты которые в нем хранятся при удалении их из себя....


TList не удаляет объекты при удалении элементов т. к. он содержит не объекты, а указатели, для хранения объектов есть TObjectList.

Я не утверждаю, что работа со сложными динамическими типами данных в Delphi сделана идеально, скорее наоборот, но лекарство в виде C++/STL может оказаться хуже болезни.
Re[27]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 08.09.03 09:40
Оценка: +1
Здравствуйте, vedmed, Вы писали:

V>Я не утверждаю, что работа со сложными динамическими типами данных в Delphi сделана идеально, скорее наоборот, но лекарство в виде C++/STL может оказаться хуже болезни.

Ни разу проблем не было. К томуже есть очень удобная библиотека www.boost.org.
STL и BOOST решают практически все задачи связаные с логикой хранения и автоматического удаления сложных динамических объектов. И не только.
Например есть std::sort может сортировать любые массивы. Ктонибудь наконец покажите как это сделать на дельфе.
И очень многое другое.

К томуже в С++ все строго типизировано -> ошибиться много труднее.
А если учитывать шаблоны то можно вобще на этапе компиляции логику проверять
template<class T, int X, int Y>
struct matrix
{
    template<class,int,int>
    friend struct matrix;

    matrix<T, Y, X> transposition()
    {
        matrix<T, Y, X> tmp;
        for(int i=0;i<X;++i)
            for(int j=0;j<Y;++j)
                tmp[j][i]=(*this)[i][j];
        return tmp;
    }
    matrix& operator+=(const matrix& that)
    {
        for(int i=0;i<X;++i)
            for(int j=0;j<Y;++j)
                (*this)[i][j]+=that[i][j];
        return *this;
    }
    matrix operator+(const matrix& that)const
    {
        matrix tmp(*this);
        return tmp+=that;
    }
//...
};
int main()
{
    matrix<int, 3, 6> m_i_3_6_a;
    matrix<int, 3, 6> m_i_3_6_b;
    matrix<int, 6, 3> m_i_6_3;
    m_i_6_3=(m_i_3_6_a+m_i_3_6_b).transposition();
    return 0;
}

Если не совпадут размерности или типы то оно не скомпилится.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.09.03 09:59
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>> Вопрос тебе сортировку массивов элементарных типов или сложных структур.

WH>И тех и других в одном флаконе.
S>>Иногда легче применять ссылочные массивы с функцией сравнения или при динамической сортировке применять Б деревья.
WH>Типа std::map и std::set это из другой оперы у меня есть массив хочу его отсортировать.
S>>Все о чем ты говришь с применением шаблонов легко решается с помощью Replace или заменой типа соответсвенно скопировав модуль и переименовав его. Не очень сложная задача.
WH>cope/paste это не решение это проблема.
S>>Можно вспомнить про GetIdsOfNames и Invoke, MakeCreateInstace. Несовместимост Дельфийных и Сишных классов. Суть в совместимости. И почему сишники пишут на Delphi совмещаяя с С++????? А их огромное множество.
WH>Ни чего не понял.

Почти на чистейшем Виртовском Паскале.


unit SortAnyArray;

interface

 Type
  TCompareProc= Function(Var Item1,Item2):Integer;
  TSwapProc= Procedure(Var Item1,Item2);
Procedure SortArray3(Var a; Len:Integer; CompareProc:TCompareProc;SwapProc:TSwapProc);// Для несовсем ленивых
  Procedure SortArray( Var a; Len:Integer; CompareProc:TCompareProc); // для ленивых
implementation
      Procedure SortArray(Var a; Len:Integer; CompareProc:TCompareProc);
     Var TempBuffer:Pointer;
         BeginArray:Cardinal;
         MidlVar:Pointer;

  procedure QuickSort(L, R: Integer);
var
  I, J: Integer;
begin


    I :=L;
    J :=R;
   Move(Pointer(BeginArray +((((L+R-BeginArray-BeginArray) div len)  shr 1)* len ))^,MidlVar^,Len);

    repeat
      while CompareProc(Pointer(I)^, MidlVar^) < 0 do
        Inc(I,Len);
      while CompareProc(Pointer(J)^, MidlVar^) > 0 do
        Dec(J,len);
      if I <= J then
      begin
        Move(Pointer(I)^,TempBuffer^,Len);
        Move(Pointer(J)^,Pointer(I)^,Len);
        Move(TempBuffer^,Pointer(J)^,Len);

        Inc(I,Len);
        Dec(J,Len);
      end;
    until I > J;


    if L < J then
      QuickSort(L,J);
     if R>I then
     QuickSort(I,R);

end;



     Begin
      GetMem(TempBuffer,2*Len);
      MidlVar:=Pointer(Cardinal(TempBuffer)+len);
      BeginArray:=PCardinal(@a)^;
      QuickSort(BeginArray,BeginArray+(PCardinal(BeginArray-4)^-1)*len);
      Dispose(TempBuffer);
     End;

       Procedure SortArray3(Var a; Len:Integer; CompareProc:TCompareProc;SwapProc:TSwapProc);
     Var TempBuffer:Pointer;
         BeginArray:Cardinal;
         MidlVar:Pointer;

  procedure QuickSort(L, R: Integer);
var
  I, J: Integer;
begin


    I :=L;
    J :=R;
   Move(Pointer(BeginArray +((((L+R-BeginArray-BeginArray) div len)  shr 1)* len ))^,MidlVar^,Len);

    repeat
      while CompareProc(Pointer(I)^, MidlVar^) < 0 do
        Inc(I,Len);
      while CompareProc(Pointer(J)^, MidlVar^) > 0 do
        Dec(J,len);
      if I <= J then
      begin
//        Move(Pointer(I)^,TempBuffer^,Len);
//        Move(Pointer(J)^,Pointer(I)^,Len);
//        Move(TempBuffer^,Pointer(J)^,Len);
       SwapProc(Pointer(I)^,Pointer(J)^);
        Inc(I,Len);
        Dec(J,Len);
      end;
    until I > J;


    if L < J then
      QuickSort(L,J);
     if R>I then
     QuickSort(I,R);

end;



     Begin
      GetMem(TempBuffer,2*Len);
      MidlVar:=Pointer(Cardinal(TempBuffer)+len);
      BeginArray:=PCardinal(@a)^;
      QuickSort(BeginArray,BeginArray+(PCardinal(BeginArray-4)^-1)*len);
      Dispose(TempBuffer);
     End;
end.


//=================================================
Type
 TType = packed record
      d:Double;
      b:Byte;
      end;
function CmpDoubleByte(var item1, item2): Integer;
var
  i1: TType absolute item1;
  i2: Ttype absolute item2;
  r: Double;
begin
  r := i1.d-i2.d;
  if (Abs(r) < 1.0E-100) then
    Result := 0
  else if (r < 0) then
    Result := -1
  else
    Result := 1;
 If Result:=0 Then
    Begin
       Result:=i1.B;
       Dec(result,i2.B
    end;
end;

Procedure SwapDoubleByte(Var Item1,Item2);
   var I1:TType absolute Item1;
        I2:TType absolute Item2;
        Temp:TType;
    Begin
    Temp:=i1;
    i1:=i2;
    i2:=temp;
    end;

///====================================================
Var a:Array of TType;
begin
//.................
 SortArray3(a,SizeOf(TType),CmpDoubleByte,SwapDoubleByte); 
// или
SortArray3(a,SizeOf(TType),CmpDoubleByte); // но в 2 раза медленнее

end;
и солнце б утром не вставало, когда бы не было меня
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sergey Россия  
Дата: 08.09.03 10:18
Оценка: +1
Hello, DOOM!
You wrote on Mon, 08 Sep 2003 07:59:58 GMT:

DOO>>> Пожалуйста:

WH>> Ага проверяем параметры и если не правильные то создаем частично
WH>> инициализированый объект. Очень крутая логика.

D> Естественно дальше предполагалось кидать Exception



Тогда тут весь вопрос в том, что это за условия. Я лично вижу 2 варианта:

1) невыполнение условий не позволяет создать TAnotherClass. Ну и проверяем их в конструкторе TAnotherClass, при невыполнении — кидать Exception. Проверка их в TMyClass — нарушение инкапсуляции.

2) невыполнение условий не позволяет создать TMyClass. Создаем TAnotherClass, проверяем условия, принимаем решение о создании TMyClass. Отложенный вызов конструктора родителя не требуется.

Best regards,
Sergey.
Posted via RSDN NNTP Server 1.7 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[27]: По просьбам трудящихся: Delphi vs C++(VS)
От: ArtDenis Россия  
Дата: 08.09.03 11:04
Оценка: +1
Здравствуйте, DOOM, Вы писали:
D> Вы всегда массив одинаковыми значениями заполняете?

Ну хорошо, давай заполним массив значениями, которые возвращает функция
random(1000):
  std::generate( data.begin(), data.end(),  boost::bind(random, 1000) );

И вообще, в стандартной библиотеке более 50-ти функций для работы с
последовательостями. ПричTм эти последовательности могут быть любыми
(массив, vector, deque и т.д.), и этим функциям без разницы с элементами
какого типа (int, float, bool, class) они работают.

D> std::fill — готов поспорить из memcpy слеплена.

Ничего подобного.

AD>> Не забывай, что кроме std::vector в STL еще есть std::deque,

AD>> std::list, std::map, std::stack, std::set и т.д. Что тебе нужно, то и
применяешь.

D> А в Дельфи есть еще TStack, TQueue и т.п.


Они наверное похожи на TList?

Я вообще не понимаю, зачем программист должен писать лишний код (например,
приведение типов, удаление объектов, постоянный try-finnaly), когда можно
обойтись и без этого. Мне например, платят не за размер кода, а за результат
работы, который выражается в том, что доволен или недоволен заказчик
программным продуктом.

---------------------------------------------------------
СНП, Artyomov Denis. E-mail: artyomov <at> inbox.ru
Posted via RSDN NNTP Server 1.7 beta
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 08.09.03 12:31
Оценка: -1
Здравствуйте, ArtDenis, Вы писали:


AD>Мне например, платят не за размер кода, а за результат работы, который выражается в том, что доволен или недоволен AD>заказчик программным продуктом.

Вот именно! Главное программный продукт. И вот тут-то получается, что на Delphi быстрее и надежнее.Несмотря на все template, smartpointer и т.д.
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.09.03 12:36
Оценка: -1
Здравствуйте, desperado_gmbh, Вы писали:

Я не хочу вдаваться в полемику . Скажу одно в Delphi нет Inline, нет Шаблонов нет перегрузки операторов. Плохо, но есть много много другого. Кроме всего прочего эти препятствия легко обходятся. Мой пример тому доказательство (меня просили показать я показал). По поводу типизации ее легко сделать обвернув код одной типизированной функцией, но так как код достоверен то применение небезопасного кода оправдано. По поводу повторенного тобой скорости в 2 раза это относится только к Интежерам он особый тип, ко всем другим типам эта разница будет практически сведена к 0.
Опять же повторюсь мне намного больше нравится Net чем Native языки.
Там по поводу шаблонов идут поиски, перегрузка операторов тоже не такая огульная, зато продуманность классов и структур во много раз выше.

И в итоге скажу главное уметь программировать а на чем не важно.
Я голосую за Net (в том числе С# и Delphi.Net). А там сортировка массива встроена в сам объект Array.
и солнце б утром не вставало, когда бы не было меня
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 10.09.03 08:19
Оценка: +1
Здравствуйте, mihailik, Вы писали:

M>Смысл этого примера в том, что компаратор (указатель на функцию сортировки) передаётся в метод TList.Sort, который при помощи компаратора сортирует список.


А можно вопрос? Спасибо.
Что мне делать, если я хочу отсортировать встроенный массив или вообще какой-то свой контейнер? Придумал! Копировать его в этот TList, а потом забирать назад! Прекрасное решение!
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.09.03 10:35
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>> Еще раз проверь

S>>std::iterator_traits<Iter>::value_type midl=*(begin+(end-begin)/2);
WH>Нафига? Я с нетипизироваными адресами (в отличии от некоторых) не работаю.
WH>end-begin возвращает количество элементов. потом оно делится на 2(оптимизатору виднее как делить или смещать он умный) и на результат смещается итератор начала. Полученый итератор разименовается.
WH>Учим мат часть.

Ну не знаю насчет "некоторых", только сишный код только и пестрит нетипизированными указателями. По поводу Мат части и (оптимизатору виднее как делить или смещать он умный) так лично мне интересней ручками, а то мозги совсем засохнут. Например для size=2^n выравнивание лего решается через Adress = Adress and (cardinal( not (size-1))). Для других dec(address, Adress mod size) и через div и * size.

Пройдусь немного по нахваленным шаблонам. Согласен применение их очень удобно и надеюсь они появятся как в Delphi так и Net особенно для уже разработааных больших классов-шаблонов. Но хочу добавить одну Весчь что Copy-Paste-Replace лет 20 решали проблему шаблонов, но кроме всего прочего получался исходный код, который легко оптимизировался под конкретный тип.

А для С# учту (почему то только + и — n отложились, что адресс увеличивается на размер типа * n как и в Delphi при inc dec для типизированных указателей. Спасибо.
и солнце б утром не вставало, когда бы не было меня
Re[25]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 10.09.03 11:35
Оценка: +1
Здравствуйте, mihailik, Вы писали:

C>> Что мне делать, если я хочу отсортировать встроенный массив или вообще какой-то свой контейнер? Придумал! Копировать его в этот TList, а потом забирать назад! Прекрасное решение!

M>Встроенных типов не так много, легче простого написать небольшую библиотечку с функциями типа SortIntegerArray и т.п.
Да а потом SortMyCoolType1Array, SortMyCoolType2Array, SortMyCoolType3Array,...
А потом нам будет нужен бинарный поиск по отсортированому массиву, а потом удаление элементов при выполнение какого либо условия,...
M>Или крутизна шаблонов как раз и заключается в работе со встроенными типами?
Не со встроеными, а со всеми.
M>Игрушечки какие-то
Эти игрушеччки сокращают размер кода в разы и значительно повышают надежность. Отсутствие возможностей для реализации элементарных смартпоинтеров использование которых не требует каких либо телодвижений и накладных расходов просто убивает.
Ну не возможно в таких условиях работать. Каменный век.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.09.03 12:16
Оценка: +1
Здравствуйте, Joker6413, Вы писали:

J>Что за бред? Ты вообще понимаешь что такое конструктор? И что за указатель на класс? Ты про метакласс говоришь или все таки про объект класса?

Я тебе очень рекомендую для прочтения Object Pascal Reference из комплекта Delphi. Тогда тебе станет понятно, о чем идет речь. Нельзя слепо применять термины в трактовке одного языка к другому языку. То, что в С++ не бывает виртуальных конструкторов и нет понятия "указатель на класс", не есть универсальное свойство ООП.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 05:56
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Зачем публиковать? Мой сериализатор может сериализовать приватные поля.

Дельфийский тоже. Для этого оставлен ровно такой же выход — можно перегрузить некий метод, и в нем сделать все, что захочется. Именно так сериализуются всякие штуки типа картинок, у которых нет публичных свойств, отвечающих за контент. Просто часть работы уже берет на себя компилятор.
WH>А привел кусок кода который включает поддержку сериализации vector'ов.
В дельфи коллекции тоже сериализуются.
WH> Аналогично можно добавить сериализацию любого контейнера лаже не существовавшего в момент написания библиотеки.
Ну естественно. Ведь контейнер — это класс
WH>Обычно происходит так: Описаваем человека имя, фамилия, пол, рост, вес. Черед некоторое время выяснилось что надо еще цвет глаз, цвет волос. Еще через некоторое время понадобился IQ...
Ну естественно. При программировании неизбежно в какой-то момент начинает требоваться IQ
На самом деле я говорил о том, что тот "человек", который был тогда, и тот, который теперь — это два разных класса. В рамках С++ нет такого понятия, как эволюция класса. С этой точки зрения более правильным является создание нового класса, который оборудован конструктором от старого (который никуда не делся!). И мы десериализуем старый объект, конвертируем в новый, а потом убиваем. Но практически, как я уже сказал, версионность запрограммировать проще.
Сериализация, а точнее persistence — это вообще достаточно плохо исследованная область ООП.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 11.09.03 06:30
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH> ... А если надо вызывать несколоко функций залпом? Как на дельфях делать будешь?


Метод напишу. И вызову. Вариант 2: базовый класс.

И разговор этот из плоскости "поиск аналогий".

WH>Запомни это не в С++ нет чегото что есть в дельфе это в дельфе нет много чего что есть в С++.


С++ — типа язык, эквивалент этому — то, что называют язык Object Pascal.

Дельфи — это конкретная реализация, (ещё FreePascal, BP,...) аки Студия, Билдер, gcc. Одно плохо — мало этих реализаций OP, и нет поддержки на уровне ОС. А напиши кто ОС, взяв за базу синтаксис OP, то получился бы ... такой же монстр, как Cxxx...
... << RSDN@Home 1.1 beta 3 >>
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 11:14
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>ЧДТ на реальных иерархиях от дельфевого сериализатора толу нет.(в смысле по сравнению в плюсовым не дает преймуществ)

Э-э, парень. Вот тут ты не прав. Сериализатор чего угодно в XML на дельфи пишется за один день. При этом ни строчки пользовательского кода править не надо. Преимущество — скорость разработки. Код, который ты привел, научить сериализовать в XML невозможно (в хуман-ридабле, ессно. в СDATA, ясен хрен, ты запихаешь и не такое
А сейчас, увы, рулит Time To Market.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: AlexK Украина  
Дата: 11.09.03 13:17
Оценка: +1
Здравствуйте, DOOM, Вы писали:

DOO>Сразу некоторые ответы на вопросы, возникшие в этом
Автор: DOOM
Дата: 26.08.03
топике.


DOO>Дельфи действительно швыряет EAbstractError при попытке создания экземпляра абстрактного класса, и это правильно, что в именно в run-time, поскольку пусть у меня следующая иерархия классов:

DOO>TAbstractClass = class ....
DOO>TClass1 = class(TAbstractClass)...
DOO>TClass2 = class(TAbstractClass)...
DOO>Я хочу создать массив, в котором будут и TClass1 и TClass2 — понятно, что надо создать массив TAbstractClass. В С это можно решить только используя указатели на класс, а в Дельфи есть только указатели на класс, просто это все неявно. И при их организации ООП это единственный способ. Поэтому-то мне и интересно как это сделано в С. К сожалению сейчас у меня нет времени покопаться в VS-ке и погладет как на asm'е все это выглядит.

DOO>По поводу того, что у Дельфи меньше возможностей... Приведите хоть один пример, который нельзя реализовать на Дельфи, но можно на C++. Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов, но это все очень, на мой взгляд, сомнительные вещи без которых вполне можно обойтись(макрос меняется inline функцией и результат одинаковый, шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).



DOO>По поводу IDE — тут по-моему вопросов нет. В дельфи оно факт удобнее.


DOO>По поводу библиотек — MFC vs VCL. VCL — действительно объектная библиотека, в которой обработка событий инкапсулированна в объект, а не реализуется посредством вставляемых куда-то макросов и т.п.


DOO>Теперь ваща очередь...


помоему вы равняете вещи котрые сравнивать не надо...
1. Делфи без своей библиотеки VCL как язык вообще не рассматриваеться!
2. если и говорить то о Паскале и С++... а сравниваться смешно... потому как просто языки под разные темы заточенны! С++ — алгоритмистика, память, скорость, близость к машинному уровню
Delphi — абстракция, начальная алгоритмистика.

И вообще далеко ходить не надо сам автор Паскаля сказал что свой язык придумал только для обучения студентов. У некотрых просто склонность есть капать вглубь, а у других вширь... вот и вся разница как на меня.

с++ — вглубь
Delphi — вширь
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: AndrewJD США  
Дата: 11.09.03 19:35
Оценка: :)
Здравствуйте, AlexK, Вы писали:
автор Паскаля сказал что свой язык придумал только для обучения студентов.

Однако на паскале писали популярные операционные системы...
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 12.09.03 15:06
Оценка: -1
WH>А потом нам будет нужен бинарный поиск по отсортированому массиву, а потом удаление элементов при выполнение какого либо условия,...

А чем TList не устраивает? Религиозные причины?

M>>Или крутизна шаблонов как раз и заключается в работе со встроенными типами?

WH>Не со встроеными, а со всеми.

А какие проблемы применить TList ко всем типам?

M>>Игрушечки какие-то


WH>Эти игрушеччки сокращают размер кода в разы и значительно повышают надежность. Отсутствие возможностей для реализации элементарных смартпоинтеров использование которых не требует каких либо телодвижений и накладных расходов просто убивает.

WH>Ну не возможно в таких условиях работать. Каменный век.

Хм. Ты хочешь сказать, что размер C-плюснутого кода в разы меньше Дельфийского? Что-то сомневаюсь.

Возможно, смартпойнтеры действительно помогают в разы — но только по сравнению с тем же C++ без смартпойнтеров. А в Дельфи и без них всё уже легко, аккуратно и прозрачно.
... << RSDN@Home 1.1 beta 1 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.09.03 08:43
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>>>Нда? Смотри выделеное и скажи что из этого не нужно в ЯВУ? Разве что смартпоинтеры там где есть GC и то иногда хочется детерминированого управления жизнью объекта.

S>> В Net есть возможность детерминированого управления жизнью объекта.
WH>Ну знаю я по using жутко не удобно. К томуже Dispose может бросать исключения
using в Net нужен только для освобождения системных ресурсов для их немедленного освобождения, во всех других объектах нет деструкторов в в обычном понимании, т.к. за освобождение памяти занятой объектом следит GC. Но через GC а так же через выделение памяти неподвласное GC итд можно многое, к сожалению еще не во все дебри Net залез.
S>> Inline не нужен т.к. JIT компилятор следит за возможностью вставки кода и при этом оптимизируя под конкретный процессор.
WH>А что это как не инлайн? А в дельфе инлайнов вобще нет.
S>> Про шаблоны уже прошелся.
WH>Где?

WH>>>>>Вот только пока далеко не все лучшие идеи используются в шарпе.

S>>>> Например???? Шаблоны будут, что еще???
WH>>>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
Насчет шаблонов в Net посмотри http://www.dotsite.ru/Publications/PublicationDetails.aspx?ID=115

Почитай очень интересно, плю что предлагают SUN. Так что ты со своими шаблонами уже отстал от жизни.

Шаблоны,макросы по сути являются Copy-Paste-Replace и ни о каком ООП не идет и речи и легко реализуются без компиляторов путем генерации соответсвующих модулей на основании "Шаблона".
А вот шаблоны в Net это действительно ООП.
Небольшая выдержка

"Когда шаблонный класс откомпилирован, между ним и обычным классом фактически нет никакой разницы. На самом деле, результатом компиляции является не что иное как метаданные и промежуточный язык (IL). IL, конечно же, параметризован, чтобы принимать поставляемые пользователем типы где-то в коде. Отличие в использовании IL для шаблонного типа основано на том, является ли поставляемый параметр типа типом значения или ссылочным типом.

При первичном создании шаблонного типа с типом значения в качестве параметра, среда выполнения создает специализированный шаблонный тип с предоставленным параметром (или параметрами), подставленными в соответствующие места в IL. Специализированные шаблонные типы создаются единожды для каждого уникального типа значения, используемого в качестве параметра."
Кроме всего прочего на данном этапе надежность кода встает на первый план (хотя мне это и не импонирует)
и солнце б утром не вставало, когда бы не было меня
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка: :)
WH>>>Нет не так. ГУЙ это в большинстве задачь ничтожно малая часть работы.
FWP>>Это в Delphi ничтожно малая часть. Потому ручная работа сведена к минимуму. А в C++ все ручками, да ручками

WH>Вот только шаблоны сводят ручную работу практически на нет.


Ну да, конечно. Найди-ка хоть одно приложеньице на C++ и COM, в котором нет ручной работы.

WH>А если учесть что очень многим приложениям не нужно куча диалогов...


Ага. Многим. Давай посчитаем. Для строгости будем считать "приложением" только то, что устанавливается с помощью какого-нибудь инсталлера. Какой процент таких "приложений" на твоём компьютере использует меньше 4 окон?

WH> и написать интерфейс при помощи WTL не состовляет большого труда...


Да и на Дельфи написать интерфейс не составляет труда. И на C# можно интерфейсы писать. Только почему-то все их рисуют в дизайнере.

Видимо, есть всё-таки разница между "не составляет труда" и "имеет смысл". Писать интерфейс вручную — такая дурь, которая практически не имеет смысла.

WH>>>>>Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.

FWP>>И он в некотрых случаях может принять неправильное решение.
WH>Конкретно пожалуйста. Ни разу не встречал.

Примерно так (псеводкод):

public void Copy(str1,str2)
{
    Файл file1=Файл(str1);
    
    Буфер buf=file1.ПрочитатьСодержимое();
    ФункцияОбработки(buf);

    Файл file2=Файл(str1); // *
    file2.ЗаписатьСодержимое(buf);
}


Объект file1 не освобождается до конца метода. Если файлы открываются в блокирующем режиме и str1==str2, на строке со звёздочкой получим ошибку.
... << RSDN@Home 1.1 beta 1 >>
Re[4]: Некоторые итоги:
От: Sergey Россия  
Дата: 16.09.03 15:57
Оценка: +1
Hello, mihailik!
You wrote on Tue, 16 Sep 2003 13:52:29 GMT:

S>> А что, ты можешь предложить хоть один широко распространенный

S>> скриптовый язык со строгой статической типизацией? Если нет, то
S>> ты нифига не понял из того, что тебе говорил Wolfhound.

m> Статическая типизация — не панацея, как её старается представить

m> Wolfhound.

Однако, ему, как не сложно заметить, нужна именно она. Ну и нафиг тогда скрипты советовать, если они ее не умеют?



Best regards,
Sergey.
Posted via RSDN NNTP Server 1.7 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 17.09.03 08:09
Оценка: -1
WH>>>Вот только шаблоны сводят ручную работу практически на нет.
M>>Ну да, конечно. Найди-ка хоть одно приложеньице на C++ и COM, в котором нет ручной работы.
WH>А что далеко ходить. Мой OPC server. Всю работу по поддержке COM сделали ATL'ные шаблоны.

Это хорошо.

WH>>>А если учесть что очень многим приложениям не нужно куча диалогов...

M>>Ага. Многим. Давай посчитаем. Для строгости будем считать "приложением" только то, что устанавливается с помощью какого-нибудь инсталлера. Какой процент таких "приложений" на твоём компьютере использует меньше 4 окон?
WH>Ну есть парачка. А большинство вобще собственные контролы используют.

Таким образом, большинству приложений нужна куча диалогов.

WH>>> и написать интерфейс при помощи WTL не состовляет большого труда...

M>>Да и на Дельфи написать интерфейс не составляет труда. И на C# можно интерфейсы писать. Только почему-то все их рисуют в дизайнере.
M>>Видимо, есть всё-таки разница между "не составляет труда" и "имеет смысл". Писать интерфейс вручную — такая дурь, которая практически не имеет смысла.
WH>А ты попрубуй нарисуй на дельфе интерфейс как в седьмой студии...

Docking в Дельфи встроенный есть. Менюшки в стиле Ofice XP есть. Закладки есть, правда чуть другой формы. Даже редактор для тулбаров есть. Всё вроде, или ты ещё каких-нибудь рюшечек хочешь?

M>>Примерно так (псеводкод):

WH>хъ
M>>Объект file1 не освобождается до конца метода. Если файлы открываются в блокирующем режиме и str1==str2, на строке со звёздочкой получим ошибку.

WH>Просто гениальный пример. И что тебе мешает наступить на теже грабли в другом языке? Это уже ошибка ЛОГИКИ и на сколько мне извесно еще не создан язык который может поймать ВСЕ логические ошибки.


На теже грабли в другом языке я сознательно об этих вопросах беспокоюсь. А в C++ мне Wolfhound, авторитетно сказал, что о времени жизни беспокоиться не нужно.

Или всё-таки нужно?
... << RSDN@Home 1.1 beta 1 >>
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 17.09.03 09:52
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

WH>>Все что GC попало уже не детерминировано. И using не всегда спасти может.

S> Есть области памяти неподвласные GC. Например когда using может не спасти если главная цель деструктора освобождение хэндлов системных ресурсов ????
Ну например если логика работы с ресурсов выходит за приделы одной функции.

WH>>Да ни фига подобного. Слова дилетанта. Это .НЕТ шаблоны можно генерить генератором, а С++ требуют информации о типах на много больше.

S> То есть ты утвержаешь что невозможно создать программу, которая генерит исходники из определенным образом написанных заготовок с конролем типов и выбора наилучшего алгоритма????
Я утверждаю что это на порядки болие сложная задача чем шаблон аля .НЕТ и в конце концов у тебя получится С++ компилятор.

WH>>Какие проблемы с надежностью С++ шаблонов мне ктонибудь обьяснит наконец?

S> Да втом, что шаблон он и в африке "Шаблон".
ГДЕ ПРОБЛЕМЫ С НАДЕЖНОСТЬЮ?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: _MarlboroMan_ Россия  
Дата: 17.09.03 13:24
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Dimonka, Вы писали:


WH>>>Нет не так. ГУЙ это в большинстве задачь ничтожно малая часть работы.

D>>В моей работе 90% времени клиенты рассматривают именно ГУИ. Им наплевать на функциональность, функциональность проверят тестеры.
WH>А в моей работе ГУИ вобще нет. Я серверы пишу. И тут дельфевые издержки становятся абсолютно не приемлемы.

ну и к чему это всё нас приводит???

а к тому, что попытка сравнивать "мягкое" с "теплым" может привести только к одному выводу: "оно разное!", но вот оценить из в наминациях "хуже" и "лучше" уже не получится.

в обзем есть задача, есть спектр инструментов, есть поблемма выбора.
пусть каждый выбирает сам: у каждого своя дорога в ад...

единственный светлый момент в этой дискуссии — это возможность новичкам удвидеть "+"-ы и "-"-ы инструментов в разного рода применениях, но здесь главное — "не пересолить", а то новичек это блюдо есть не будет и получится не дискуссия, а спор ради спора. оно нам надо?
... << RSDN@Home 1.1 beta 2 >>

— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 17.09.03 15:44
Оценка: :)
M>>Правильно, а фиг ли что файл не сохранился. Нужно было почаще Backup делать
WH>flush в деструкторе... гениально.

А, так ты Flush в try/finally делаешь?

А шуму-то было, мол, в C++ try/finally не нужен никогда.

А>>>4) Рекомендательный характер вызова Dispose(). Поубивал бы за это

M>>Ага, не поняли они в Редмонде твоей таинственной русской души.
WH>Ага и потом народ долго думает почему на тачке с 256М программа работает прекрасно, а на серваке с двумя гигами вешается в месте с виндой.

А при чём здесь объём памяти? В C# всё прозрачно расписано, когда и в каких случаях стоит вызывать Dispose. Если не следуешь советам, сам виноват.
... << RSDN@Home 1.1 beta 1 >>
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: alexkro  
Дата: 18.09.03 04:51
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>VC++7.1

WH>...

WH>Ну как? А какие результаты даст дельфя? Причем это очень простые примеры.

WH>Но практака показывает что запутать компилятор практически не возможно.

Оптимизация, говоришь... You ain't seen nothing yet! Небольшой этюд на тему (ручной) оптимизации виртуальных методов (испольнитель (компилятор) все тот же):

#include <iostream>
#include <vector>
#include <boost/progress.hpp>

using namespace std;
using namespace boost;

#define TYPEID_CALL( TYPE, METHOD ) \
    if ( type_info_ == TYPE::s_type_info ) return static_cast< TYPE * >( this )->METHOD

class CA
{
    int type_info_;

public:
    static const int s_type_info = 1;

    CA( int ti = s_type_info )
        : type_info_( ti )
    {}

    int a();
    int b();
    int c();
    int d();
    int e();

    int a_impl() { return 55; }
    int b_impl() { return 55; }
    int c_impl() { return 55; }
    int d_impl() { return 55; }
    int e_impl() { return 55; }
};

class CB : public CA
{
public:
    static const int s_type_info = 2;

    CB()
        : CA( s_type_info )
    {}

    int a_impl() { return 110; }
    int b_impl() { return 110; }
    int c_impl() { return 110; }
    int d_impl() { return 110; }
    int e_impl() { return 110; }
};

class CC : public CA
{
public:
    static const int s_type_info = 3;

    CC()
        : CA( s_type_info )
    {}

    int a_impl() { return 220; }
    int b_impl() { return 220; }
    int c_impl() { return 220; }
    int d_impl() { return 220; }
    int e_impl() { return 220; }
};


int CA::a()
{
    TYPEID_CALL( CA, a_impl )();
    TYPEID_CALL( CB, a_impl )();
    TYPEID_CALL( CC, a_impl )();
}
int CA::b()
{
    TYPEID_CALL( CA, b_impl )();
    TYPEID_CALL( CB, b_impl )();
    TYPEID_CALL( CC, b_impl )();
}
int CA::c()
{
    TYPEID_CALL( CA, c_impl )();
    TYPEID_CALL( CB, c_impl )();
    TYPEID_CALL( CC, c_impl )();
}
int CA::d()
{
    TYPEID_CALL( CA, d_impl )();
    TYPEID_CALL( CB, d_impl )();
    TYPEID_CALL( CC, d_impl )();
}
int CA::e()
{
    TYPEID_CALL( CA, e_impl )();
    TYPEID_CALL( CB, e_impl )();
    TYPEID_CALL( CC, e_impl )();
}

int test()
{
    CA a1;
    CB a2;
    CC a3;
    CA *c[ 3 ];
    c[ 0 ] = & a3;
    c[ 1 ] = & a1;
    c[ 2 ] = & a2;

    int s = 0;

    for (int k = 0; k < 10000000; ++k)
    {
        for (int m = 0; m < 3; ++m)
        {
            CA * x = c[ m ];
            s += x->a();
            s += x->b();
            s += x->c();
            s += x->d();
            s += x->e();
        }
    }

    return s;
}

int main()
{
    progress_timer t;

    cout << test() << endl;
}

Asm:
; 172  :     cout << test() << endl;

    mov    DWORD PTR _a1$19959[esp+32], 1
    mov    DWORD PTR _a2$19960[esp+32], 2
    mov    DWORD PTR _a3$19961[esp+32], 3
    xor    eax, eax
    mov    ecx, 10000000                ; 00989680H
    npad    1
$L19965:
    add    eax, 1925                ; 00000785H
    dec    ecx
    jne    SHORT $L19965


Всё!

Двадцать методов, цикл, массив, условия, статик касты... Всё как в трубу . Этот компилятор невозможно использовать для написания простых тестов .
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 10:20
Оценка: :)
Здравствуйте, ArtDenis, Вы писали:

AD>Здравствуйте, mihailik, Вы писали:

AD>>>
AD>>> 2mihailik: большая просьба, обдумывать свои ответы собеседнику, иначе
AD>>> есть вероятность того, что модератор перенесёт эту ветку в "Коллеги,
AD>>> улыбнитесь"
m>> Если мои рассуждения народ задолбали, я могу и заткнуться. Делов-то
m>> Кстати, а почему ты переводишь стрелу на модератора. Я считаю, у каждого
m>> должен быть свой внутренний модератор. Так что давай конструктивно. Что
m>> конкретно тебе не понравилось в моём сообщении?

AD>Ещё раз повторюсь: — это привет от моего внутреннего модератора.


AD>Теперь конструктивно:


m>> По функциональности C++ опережает Дельфи только в возможности

m>> компилировать драйвера.

AD>Так вот, если заглянуть в стандарт С++, то не найдёшь ни одной строчки о

AD>компиляции драйверов. Это первое. Теперь, задумаемся, а что такое
AD>функциональность языка. На мой взгляд, — это возможности (и связанные с ними
AD>особенности), предоставляемые программисту в переводе формально поставленной
AD>задачи в программный код. Т.е. с этой точки зрения, в С++ есть какая-то
AD>"изюминка", которая позволила после компиляции превратить программный код в
AD>драйвер ?

AD>А теперь сравним функциональности языков (звёздочкой помечены, на мой

AD>взгляд, наиболее используемые вещи)

AD>Функциональность дельфи:

AD>1. Переменные *
AD>2. Типы *
AD>3. Процедуры, функции (в т.ч. вложенные)
AD>4. Классы
AD>5. Абстакция, наследование, полиморфизм *
AD>6. Тип "Ссылка на класс"
AD>7. Виртуальные конструкторы
AD>8. Глобальная фабрика объектов.
Если это касается СОМ, то наследоваников от TComObjectFactory великое множество.
AD>9. Довольно богатое RTTI *
AD>10. Указатель на функцию в классе
AD>11. VCL
AD>12. Что-то ещё...
Set (очень удобно с побитовыми операциями)
Встроенная поддержка Строк (в том числе и WideString),Интерфейсов,Вариантов**
Классы поддерживающие интерфейсы c автоматическим подсчетом ссылок и приведение к интерфейсу через As

Динамические массивы (умные)
Единая иерархия классов а также Is и As *
Явное разделение структур и объектов ( хотя записи с методами и не помешали)+-
и многое другое.
AD>Функциональность С++:
AD>1. Переменные *
AD>2. Типы *
AD>3. функции *
AD>4. Классы *
AD>5. Абстакция, наследование, полиморфизм *
AD>6. Перегрузка операторов *
AD>7. Нормальная(!) перегрузка функций *
AD>8. Множественное наследование *
AD>9. Понятие "объект класса" *
AD>10. Поименованные области *
AD>11. Шаблоны и STL:
AD> — типизированные контейнеры и массивы *
AD> — итераторы и типонезависимые алгоритмы *
AD> — "умные" указатели и массивы *
AD> — функторы и связыватели *
AD> — ANSI/UNICODE строки *
AD> — Указатели на функцию в классе
AD> — фабрики объектов *
AD> ... ещё куча того, что реализуется за счёт шаблонов.
AD>12. RTTI
AD>13. Может кто ещё чего добавит, а то я забыл

AD>Информация предоставлена, можешь сравнивать.


AD>---------------------------------------------------------

AD>СНП, Artyomov Denis. E-mail: artyomov <at> inbox.ru
и солнце б утром не вставало, когда бы не было меня
от модератора
От: _MarlboroMan_ Россия  
Дата: 18.09.03 10:32
Оценка: +1
Здравствуйте, Serginio1

Не могли бы Вы воздерживаться от избыточного цитирования?
... << RSDN@Home 1.1 beta 2 >>

— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 10:52
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

AD>>8. Глобальная фабрика объектов.

S> Если это касается СОМ, то наследоваников от TComObjectFactory великое множество.
Ну и нафига этот геморой? В С++ все ATL делает. Ни разу фабрику ручками не писал.
S> Set (очень удобно с побитовыми операциями)
Ну и нафига это на уровне языка надо?
S> Встроенная поддержка Строк (в том числе и WideString),Интерфейсов,Вариантов**
Ну интерфейсы еще куда ни шло, а вот строки и темболие варианты на уровне языка
S> Классы поддерживающие интерфейсы c автоматическим подсчетом ссылок и приведение к интерфейсу через As
Ну и нафига во все интерфейсы подсчет ссылок запихивать? В С++ это делается на раз, а для привидения типов служит dynamic_cast.
S> Динамические массивы (умные)
И чтоже в них такого умного чего не может std::vector?
S> Единая иерархия классов а также Is и As *
Вот уж нафиг не упало все классы от одного наследовать. И dynamic_cast никто не отменял.
S> Явное разделение структур и объектов ( хотя записи с методами и не помешали)+-
А смысл?
S> и многое другое.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 12:41
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>>>>Да ни хрена ты не понял. Посошник САМ совободит память и вызовет деструкторы у объектов если в процессе заполнения произойдет сбой.

M>>>В Дельфи объекты нельзя распределить в какой-то особенной памяти, кроме как в стандартной куче. Да я и не вижу необходимости.
S>> Небольшая поправочка в менеджере памяти, так как от обычного Heap имеют большое различие и скорость удаления в 10 раз выше чем при удалении из хиппа за счет не возврата памяти а вторичного использования. Хорошо продуманная индексация и объединения неиспользуемых блоков памяти. Почти идеал.
WH>Пишем аллокатор на пуле и он что хочешь уделает. Вот только всегда ли оно надо?
Не знаю как в M$ но МП в Delphi покрывает 99.9%. Хиппы, аллоки применяю только для списков для быстрого удаления всей кучи,или для связанных страниц большого размера например для отхода от изменяющейся непрерывной памяти и их проблемах с реалоками. Там МП не нужен.
http://www.rsdn.ru/article/Delphi/memmanager.xml
Автор(ы): Андрей Мистик
Дата: 21.02.2003
В данной статье я постараюсь в общих чертах описать принципы работы менеджера памяти Delphi.
Зачем это нужно? Ведь, казалось бы, работает себе и работает, зачем его трогать? Это нужно по нескольким причинам. Во-первых, никогда не помешает разбор чужого кода, особенно если это грамотный код. Это возможность научиться чему-либо новому, а также получить эстетическое наслаждение. Во-вторых, никогда не лишне поглубже разобраться в чем-то, убедиться в тех вещах, в которых вы ранее не были уверены или же, наоборот, найти слабые места, о которых вы ранее и не подозревали, чтобы в будущем писать более эффективный код.

Может нечто подобное и реализованио в С++.
Но я получил огромное удовольствие от изучения GetMem.inc
и солнце б утром не вставало, когда бы не было меня
Re[14]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 13:40
Оценка: +1
Здравствуйте, AlexK, Вы писали:


AK>Делфи как раз и была попытка сделать упрощенный вариант программинга в целом... согласен оно заняло достойную нишу и туда перекачивало не мало толковых людей... подстегнуло отросль компайлеров и языков програмирования к развитию... только теперь приходит очередь нового поколения — НЕТ фреймворка. а что вот делать с программерами старой закалки?

Я сам вроде не мальчик, но и по старому жить не хочется. Тяга к знаниям остается.

AK>Только макрософты их переплюнули на много больше, мало того что написали либу отдаленно напоминающую vcl, но и дали возможность старым программерам не меняя языка делать свое дело... вот только реализация подкачала... пока там больше багов чем может себе позволить комерческий софт.

Не долго сказка сказывается, да долго.. Идеи заложенные в Net для меня лично грандиозны и очень перспективны. По сложности и по количеству нововведений намного превышает все Native языки. Этакий симбиоз транслятора и компилятора. JIT компиляторы должны развиваться, в этом заинтересованы все производители CPU впервую очередь Intel (какой самый быстрый компилятор С++???). Долой х86, даешь многоядерные процессоры со стековой архитектурой и распределенными вычислениями.

А на С++ не одни профи кодируют, а как везде. А начем программировать побольшому счету по барабану,главное что и было бы интересно, а не муторно.
и солнце б утром не вставало, когда бы не было меня
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 16:16
Оценка: +1
M>>Чтобы засечь этот "раз в год", я должен думать об этой возможности каждую секунду. Где же экономия?

WH>Тебе знакомо такое слово "проектирование"? То о чем ты сейчас говоришь относится именно туда. Если архитектура хреновая то отгребещь по полной в любом случае, а когда нормальная то на С++ работы много меньше.


Если архитектура нормальная для C++, то на C++ работы меньше. Если архитектура нормальная для Дельфи — соотвественно.
... << RSDN@Home 1.1 beta 1 >>
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 16:16
Оценка: -1
AD>12. Что-то ещё...

Свойства.
Позднее связывание.

AD>Функциональность С++:

AD>1. Переменные *
AD>2. Типы *
AD>3. функции *

Почему в Дельфи Процедуры и функции, причём даже "в т.ч. вложенные" не удостоились звезды, а в C++ простые функции удостоились?

AD>4. Классы *


Почему в Дельфи Классы не удостоились звезды, а в C++ удостоились?

AD>5. Абстакция, наследование, полиморфизм *

AD>6. Перегрузка операторов *
AD>7. Нормальная(!) перегрузка функций *

В Дельфи, значит, ненормальная?

Кстати, в твоём списке её не было.

AD>8. Множественное наследование *

AD>9. Понятие "объект класса" *

Что такое за понятие?

AD>10. Поименованные области *

AD>11. Шаблоны и STL:

Ну да, а для Дельфи есть VirtualTreeView — очень удобный компонент. Если уж пошли библиотеки сравнивать.

AD> — типизированные контейнеры и массивы *


В Дельфи, вроде бы отстутсвуют. В Дельфи все массивы, кажется, нетипизированные
... << RSDN@Home 1.1 beta 1 >>
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 18:14
Оценка: +1
Здравствуйте, mihailik, Вы писали:

WH>>Ну и нахрена это надо?

M>Для однообразности и простоты. Все объекты ведут себя с памятью одинаково. Мозги не парятся.
Супер аргумент.

WH>>Вот и приходится городить try/finally постоянно.

M>Не постоянно. В Дельфи тоже есть способ уйти от ручного вызова деструкторов к подсчёту ссылок. Интерфейсы всегда работают по учёту ссылок.
Ага это мне для каждого объекта придется писать интерфейсы... и всегда через них таскать
А слабо integer by ref сделать? Я не знаю зачем но в С++ это делается на раз boost::shared_ptr<int>

WH>>Это еще почему?

M>А вот чтобы приколисты вроде Страуструпа не выдумывали разных новых значений оператора сдвига. Сдвиг — он в Дельфи всегда сдвиг.
Хм. А я уже не помню когда последней раз использовал << как сдвиг.
Но если тебя это не устраивает то не используй стандартные потоки и все.
К томуже под это попадают вектора для которых прегрузить + сам бог велел...

WH>>В том то и засада что не всегда объект можно просто скопировать.

M>А все объекты byref, то есть ничего и не копируется. Чтобы сделать копию, нужно как и в .NET вызвать какой-нибудь Clone.
Да ради бога. В С++ можно тоже пользоваться только by ref и что? Просто я предпочитаю иметь выбор.

WH>>Ага. И использование полиморвных контейнеров ведет к чистоте, простоте и надежности

M>Тут ты прав. Действительно удобно.
Тормоза, отсутствие контроля типов со стороны компилятора это без сомнения очень практично.

WH>>При написании ГУИ к БД согласен, а вот на счет всего остального.

M>Ты что, предлагаешь и в браузерах скрипты на C++ писать? Или ты какое-то конкретное "остальное" имеешь ввиду?
Ты дурочку не валяй. Прекрасно понял о чем речь.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 19.09.03 16:41
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>>>А чем чисто абстрактный класс без данных отличается от интерфейса?

S>> Чем ??? Посмотри на реализацию придуманную M$.
WH>Еще раз: ФИЗИЧЕСКОЕ устройчтво меня не волнует. А ЛОГИЧЕСКИ это тоже самое.
S>>Дла каждого объекта (не класса) генерятся в памяти функции заглушки, которые генерят вызов методов класса с передачей данных объекта (Self) в методы класса.
WH>Ты сам понял что сказал?
Понял прекрасно.
WH>На всякий случай скажу как дело обстоит на самом деле.
WH>Для каждого класса(не объекта)компилятор генерирует таблицу виртуальных функций при вызове просто берем указатель из таблици и вывываем this передается через ECX.
Еще повнимательней посмотри окошечко CPU.
Посмотри внимательней на VTBL и поймешь обсурд для каждого объекта генерить функции заглушки. Прав.
S>> Вот и поймешь в чем причина. Не прав.

S>> Гхы-Гхы. WolfHound хоть ты и RSDN но рассыждаешь как зеленоротый птенец.

WH>НА ЛИЧНОСТИ ПЕРЕХОДИТЬ ЗАПРЕЩЕНО ПРАВИЛАМИ ФОРУМА.
Я действительно хочу выпить с Ним несколько кружечек Водки. В чем проблема????
S>>По сути объекты 1С++ схожи со структурами.
WH>Не понял.
S>>Но виртуальность накладывает на обязательное поле
WH>Какое поле?
На VMT
S>>ссылки на VMT,
S>>в Delphi с отрицательным смещение хранится куча информации о типе , интерфейсах итд.
WH>Я не копался в дельфе но что-то мне подсказавает что там лежит только указатель. Но если они в каждай объект запихали всю метоинформацию то...
Мой совет Покапайся. Очень интересно!!! В Net развито больше.
S>>Кроме всего прочего вариантный подход, тоже требует определенных методов по преобразованию.
WH>Какой подход? Ах да. Я же забыл что дельфя с типами не дружит. И временами под скрипт пытается косить.
Гхы-Гхы, больше нечего сказать.
S>>Я лично ну ни как не пойму какие проблемы у С++ с БД.
WH>Я тоже.
S>> А как насчет InheritedForm,,,,
WH>А как на чсет типизированых контейнеров, адаптивных алгоритмов, смартпоинтеров,... А ведь это нужно на много чаще чем RTTI.
Контейнеры только на этапе компиляции, а дальше...
Аналоги Сишных контейнеров (правда без типизации) делаются в легкую.

WH>>>НАФИГА? Создал в стеке пусть лежит в стеке, создал в хипе пусть будет в хипе. Нафига это разделение?

S>> Создал структуру как в Net и пусть себе лежит.
WH>Почему один и тотже класс нельзя разместить в стеке, в хипе, как часть другого?
Размещай. Только потом проблемы возникают. Ялично ни за что не агитирую.
Каждый делает выбор для себя. Оссобенно когда считают однин язык превалирующим над другими. В добрый пыть от чистого сердца.

S>>Какие проблемы. Неотвечаешь на предыдущие вопросы.

WH>Какие именно? Ссылки пожалуйста.
Смотри предыдущий диалоги меня и WolfHound
S>>Единственный аргумент Шаблоны. И все???
WH>А что мало? Ах да. Я все время забываю что ты не имеешь представления о возможностях С++ шаблонов.
Да как бы смотрю и нравятся, но для чего руки то даны (о голове молчу).
S>> Честно говоря, как оппонент Вы WolfHound, очень не интересны.
WH> А чтож тогда разговариваешь?
Не разговариваю, а нажимаю на клавиши. А поговорить действительно интересно.
S>>Абсолютно нет никакого конструктивизма и анализа.
WH>Что анализировать? Нетипизированые контейнеры или варианты в языке? Им самое место в библиотеке.
S>>Уперся рогом и все.
WH>А ты чтоли нет?
S>>Но в Net Я нашел, то что искал и ищу.
WH>Плюсы есть но и минусов не мало. Хотя после дельфей их не видно ибо не знаешь куда смотреть.
S>> С++ умрет, а Виртовский Паскаль останется.
WH> И это еще мне говорят что я рогом уперся
S>>И уже доказал свою состоятельнось, не взирая на свой возраст. Главное фундамент.
WH>И чтоже в паскале такаго чего нет в С++?
Посмотри и сравни с Net. Зачем толочь одно и тоже.
S>> Если Ты в Москве готов в личном поединке обсудить общеязыковые проблемы за кружечкой Водки.
WH>Я не в Москве и водку не пью.
Ну вот они какие Сишники. А у нас народный русский (Российский) напиток Водка.
Срочно нужно новый Язык изобретать МежНациональный.
И пойми если бы в С++ было то, что мне хотелось сразу перешел бы на него.
А вот Net действительно берет своей мощью. И если мои посты только в защиту Delphi, то твои претендуют на абсолютную истинность. Такая небольшая разница.
ПРошу простить меня Модератор. Пятница однако.
и солнце б утром не вставало, когда бы не было меня
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: AndrewJD США  
Дата: 20.09.03 10:19
Оценка: +1
Здравствуйте, AlexK, Вы писали:

AK>НЕту.. но при этом простым классов-шаблоном-врапером можно это сделать... полная гибкость!

AK>вобще понятия проперти/ивентов появилось только когда придумали и внедрили COM... идея может и до этого в воздухе летала, но достойной реализации небыло до COM... если не очень ошибаюсь в библиотке boost есть наработка на эту тему — создание пропертей и создание ивентов. И заметьте язык позволяет достаточно легко выкрутиться и расшириться собственными средствами

Только этими свойствами очень неудобно пользоваться. На rsdn даже есть статья посвященная реализации свойств на плюсах. Нормального так ничего и не придумали...
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 21.09.03 06:39
Оценка: +1
Здравствуйте, mihailik, Вы писали:

M>Операторы, слава богу, не перегружаются.

Уже. Custom Variant Types начиная с 6 позволяют реализовать нечто похожее на перегрузку операторов.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 23.09.03 14:38
Оценка: -1
WH>>>А почему нет?
M>>Потому, что рантайм-библиотеки не писались для этого применения. Мало ли, каким образом там память выделяется, какие дополнительные функции вызываются.
WH>STL и CRT это немного разные вещи не находишь?

Я не знаю, насколько STL зависит от платформы.

M>>В некоторых местах в драйвере нельзя никакой лишней работы делать. Чтобы не дай бог ни подкачки, ни задержки никакой не было. Ну, закрепишь ты свой собственный код в памяти от свопирования. Но служебные библиотеки мало ли как там закреплять — это отдельно тестировать нужно.


WH>Слова человека не знающего о существовании такого понятия в STL как allocator.


Для профессионального программиста на C++ ты делаешь удивительно тривиальные выводы. Да, я не знаю, что такое STL allocator. И именно поэтому, я не понимаю твоего аргумента

WH>Но даже если забить на STL то ни что не мешает просто пользоваться всеми благами шаблонов.


Думаю, без хороших библиотек шаблоны среднеполезны.
... << RSDN@Home 1.1 beta 1 >>
Re[16]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 24.09.03 15:03
Оценка: :)
M>>И как это работает? Посдчёт ссылок, как я понимаю.
M>>Это старьё, и алгоритм типа AddRef/Release давно признан архитектурно убогим. На цикличных ссылках не пашет.

WF>Зато быстро, эффективно и детерминировано. К тому же есть механизм слабых ссылок, для разрешения проблемы циклических ссылок.


Ага. И это "продают" под видом простоты и надёжности.

WF>P.S. А у тебя есть другой вариант? Более новый, чем циклические ссылки, с детерминированным освобождением? Интересно было бы послушать.


А что такое детерминированное освобождение? Ты можешь описать это другим образом кроме как "также, как AddRef/Release"?

WF>P.P.S. Кстати, кем признан ? Мировым сообществом Java/.NET программистов?


А ты сам разве не согласен с мировым сообществом?
... << RSDN@Home 1.1 beta 1 >>
Re[20]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 25.09.03 14:25
Оценка: :)
M>>А без C++ можно определение дать? А то получается, детерминированное осовобождение — чисто внутренне понятие C++.

WF>Детерминированное == определенное. Т.е когда точно известен момент (и им можно управлять), например, смерти объекта.


Определённое? Кем определённое?

В .NET объекты освобождаются тоже строго в определённый срок. Этот срок определяет GC.

Конечно, ты скажешь, что определять время освобождения должен программист. Но тогда встаёт вопрос, какой программист? Если один компонент использует другой, то на ком должна лежать ответственность за освобождение?

С одной стороны, это дело автора компонента, с другой — только пользователь компонента знает, когда он уже перестал его использовать.

Циклические ссылки внутри одной библиотеки можно (со скрипом) разешить. Но как быть с циклическими ссылками между компонентами разных библиотек? Кто тут будет определять время жизни?

WF>Кстати, потенциальные циклические графы можно ведь и автоматически искать. Например есть модель в Розе ("умный" указатель — ассоциация с неким стереотипом, например, "shared ptr"). А потом просто все циклы таких ассоциаций искать. На бейсике наверняка довольно быстро ищется.


А междубиблиотечные циклы?

WF>По аналогии. Если важный сервер в банке будет падать "не так уж часто" (от нехватки памяти), ребята будут очень недовольны.


Ну тут не .NET виноват, а программисты. Нечего делегаты использовать не по назначению.

M>>Проблема автоматического вызова деструкторов — та же архитектурная проблема циклических ссылок.


WF>Проблема в том, что когда я подписываю на событие (например, в конструкторе, да еще и на статическое событие) — это часть логики. Если я забуду подписаться, это, скорее всего, легко обнаружится. А вот отписывание — уже не часть логики, я могу с легкостью забыть отписаться и получу утечку. Вот почему "умные" указатели существенно облегчают работу — нужно лишь захватить ресурс, а освободится он сам, причем управляемо.


Как тенденция это хорошо. Но дело-то происходит на реальной земле. А тут автоматически не всё можно сделать.
... << RSDN@Home 1.1 beta 1 >>
Re[24]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 15:42
Оценка: -1
M>>Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.

WF>Слово "например" видел?


Через примеры можно только описать, но нельзя определить.

WF>Попробуем определить так: детерминированность — это когда событие не зависит от внешних к системе факторов.


Освобождение ДОЛЖНО зависеть от внешних к системе факторов. У объекта может быть несколько систем-"пользователей".
... << RSDN@Home 1.1 beta 1 >>
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 15:42
Оценка: :)
WH>В место Thread.Sleep может быть любая операция прерывающая поток.
WH>В реальной жизни на сервак который обрабатывает пользователей в отдельных потоках пришла бешеная нагрузка.

Ого, ты попробуй там while(true), тоже экстремальные ощущения.
... << RSDN@Home 1.1 beta 1 >>
Re[43]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 29.09.03 16:25
Оценка: +1
Здравствуйте, mihailik, Вы писали:

WH>> Это как?

M>Препроцессор написать. Object Pascal, кстати, очень легко поддаётся синтаксическому разбору. Есть бесплатные реализации.
Сколько можно повторять реализовать шаблоны как в С++ сложнее чем написать компилятор дельфей с нуля.(имеется в виду только front-end)
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: Oxy  
Дата: 09.12.03 11:21
Оценка: +1
Интересно, а где модератор? Спит что ли.
Такие религиозные войны надо прекращать в зародыше. Они, ИМХО, не несут никакой смысловой нагрузки и только засоряют форум. Ну поумнчают здесь любители этого дела, померцают гранями, а толку? Никто никого не убедит и не переубедит.
Re[3]: Эффективное использование WTL
От: Oxy  
Дата: 17.12.03 08:51
Оценка: +1
Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Нет, я с дельфями завязал. Сначала кажется, что удобно. VCL хороша, работа с БД, IDE... Но потом это всё вылазит боком.

ЕК>Во-первых, тормоза. Как в работе с БД, так и просто в перерисовке окон.

Про окна это вообще. Держите меня.

ЕК>Во-вторых, нет STL и вообще типизированных контейнеров

ЕК>В-третьих, всё API и все библиотеки на C.
ЕК>В-четвёртых, нет контроля над ситуацией.

ЕК>Год назад с дуру решил проект делать на Delphi. Готов себя тогдашего убить за дурость. Если бы писал на C++ & WinAPI, всё было бы

ЕК>уже готово!!!

У, батенька, складывается впечатление, что вы залезли в коробку с эфективными и удобными инструментами, не прочитали инструкции и хотели сотворить чудо. А чудо без знаний невозможно, какой инструмент не бери. Не получилось — все отстой. Разобраться сначала было надо. Но видать вам этого не понять. С таким подходом никакой проект не получится. И глючить все будет, и окна будут долго перерисовываться
Re[2]: Идём дальше
От: Аноним  
Дата: 09.02.04 23:41
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>В программах на С++ классы делятся на

Ага, размножаются почкованием...

Сам придумал? Или может в книге какой прочитал? Может в какой-то тайной книге для избранных от Страуструпа?

WH>1)Помошники(как правило шаблоны)

WH>Делают всю грязную работу типа захват/освобождение ресурса причем полностью автоматически
WH>В подовляющем большинстве на дельфе не реализуемы
WH>2)Синглетоны
Синглтон — всего-лишь один из патернов. При чем далеко не самый значительный.
Smartpointer` или там object factory на мой взгляд куда полезнее...
WH>3)Логика(самые многочисленые)
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: Jenyay http://jenyay.net
Дата: 27.08.03 05:05
Оценка:
Здравствуйте, DOOM, Вы писали:

Надеюсь не дойдет со стадии (Win мы Lin)?

DOO>Дельфи действительно швыряет EAbstractError при попытке создания экземпляра абстрактного класса, и это правильно, что в именно в run-time, поскольку пусть у меня следующая иерархия классов:

DOO>TAbstractClass = class ....
DOO>TClass1 = class(TAbstractClass)...
DOO>TClass2 = class(TAbstractClass)...
DOO>Я хочу создать массив, в котором будут и TClass1 и TClass2 — понятно, что надо создать массив TAbstractClass. В С это можно решить только используя указатели на класс, а в Дельфи есть только указатели на класс, просто это все неявно. И при их организации ООП это единственный способ. Поэтому-то мне и интересно как это сделано в С. К сожалению сейчас у меня нет времени покопаться в VS-ке и погладет как на asm'е все это выглядит.

В С++ компилятор не дает сделать экземпляр абстрактного класса, т.е. ошибка найдется еще при компиляции.

DOO>По поводу того, что у Дельфи меньше возможностей... Приведите хоть один пример, который нельзя реализовать на Дельфи, но можно на C++.

DOO>Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов, но это все очень, на мой взгляд, сомнительные вещи без которых вполне можно обойтись(макрос меняется inline функцией и результат одинаковый, шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).

С перегрузкой как-то красивее будет.

DOO>По поводу IDE — тут по-моему вопросов нет. В дельфи оно факт удобнее.


А вот здесь совсем не согласен (пишу по впечатлениям от Билдера):
1. В Дельфях/Билдере тормозят подсказки (метода класса), когда в VC все быстро.
2. В студии сами ставятся закрывающиеся } (Или это уже VA?)

Что-то не нравилось еще, но это было давно, поэтому не помню. А если поставить VisualAssist, то после него не то что с Дельфей невозможно работать, со студией без этого Assist.
... << RSDN@Home 1.1 beta 1 >>
Софт, исходники и фото
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 27.08.03 05:19
Оценка:
Здравствуйте, Jenyay, Вы писали:

J>Здравствуйте, DOOM, Вы писали:


J>Надеюсь не дойдет со стадии (Win мы Lin)?


Кстати, совсем забыл!!! Библиотеки Дельфи кросс-платформенные!

J>В С++ компилятор не дает сделать экземпляр абстрактного класса, т.е. ошибка

найдется еще при компиляции.

Сейчас не помню, но по-моему при компиляции дельфи warning выдаст.

J>С перегрузкой как-то красивее будет.


Да перегрузка операторов это хорошо. Но, когда я увидел, что у _bstr_t перегружен char * — меня это возмутило, ведь это в корне не верно!

DOO>>По поводу IDE — тут по-моему вопросов нет. В дельфи оно факт удобнее.


J>А вот здесь совсем не согласен (пишу по впечатлениям от Билдера):

J>1. В Дельфях/Билдере тормозят подсказки (метода класса), когда в VC все быстро.

В дельфи не встречал такого. Может в Builder'e. Меня как раз возмутило, что, если в VS хочешь посмотреть объявление чего-то, то надо откомпилить поект в начале(на моем PIII 600 это долго(!)). А в дельфи навел мышью и уже пишут в каком файле, в какой строке. А если нажел Ctrl и щелкнул мышью, то моментально перейдешь туда.


J>2. В студии сами ставятся закрывающиеся } (Или это уже VA?)


Это VA и эту вещь я вырубил. Больше мешает.

J>Что-то не нравилось еще, но это было давно, поэтому не помню. А если поставить VisualAssist, то после него не то что с Дельфей невозможно работать, со студией без этого Assist.


Да VA сильно улучшает VS, но у моего коллеги после VA полностью заглючил ClassWizard...
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 27.08.03 05:33
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:


WH>
WH>procedure some
WH>var
WH>  ptr:SomeAbstractClass
WH>begin
WH>  ptr:=SomeAbstractClass.Create;
WH>end
WH>

WH>Вопрос: Почему во время КОМПИЛЯЦИИ не происходит ошибки? С++ компилятор при попытке СОЗДАТЬ абстрактный класс будет громко ругаться во время компиляции.

По-моему есть warning. Но сейчас сказать точно не могу.
А по поводу exception — в Дельфи базовый класс TException позволяет видеть что же случилось, даже если ты его не ловишь.


DOO>>По поводу того, что у Дельфи меньше возможностей... Приведите хоть один пример, который нельзя реализовать на Дельфи, но можно на C++.

DOO>>Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов,
WH>Если без этого то язики почти эквивалентны

DOO>>(макрос меняется inline функцией и результат одинаковый,

WH>Макросы в место инлайн функций спользуют только [censured]...
Конкретнее. В чем разница?


DOO>>шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).

WH>Ты спутал с макросами. Шаболы в С++ дают тАкие преймущества что по сравнению с ними некоторое разбухание ехешника это ничто.

В одной книжке я встретил правильную фразу, дословно не помню, что-то вроде, что существует объектно ориентированное пргораммирование и шаблонное программирование.
Очень разные вещи, поскольку в STL нет никакого наследования, например.

WH>Одни смартпоинтеры чего стоят... я давно забыл что существует оператор delete.

WH>А STL это вобще чудо света на дельфях низачно так просто не создашь строго типизированый список ассациотивных массивов
WH>std::list<std::map<std::string, boost::shared_ptr<object> > >
WH>Только не спрашиавй зачем это надо я не знаю но когда понадобится то...

А указатели-то никто не отменял. Все можно творить используя их. И логика программы по-моему тогда на порядок понятнее.
Мне просто это больше нравится(ну просто псле программирования на asm'е появились такие привычки)




WH>Вот про MFC не надо. Этого динозавра давно пора пристрелить чтобы ни кто не мучался. Все прогрессивное человечество либо уже переползло на WTL либо собирается.


Видимо MS это не прогрессивное человечество . Все ведь говорят, что WTL больше не поддерживается и не документируется.
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: Jenyay http://jenyay.net
Дата: 27.08.03 05:55
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Кстати, совсем забыл!!! Библиотеки Дельфи кросс-платформенные!


Ну к Сям тоже можно найти кроссплатформенные.

J>>С перегрузкой как-то красивее будет.


DOO>Да перегрузка операторов это хорошо. Но, когда я увидел, что у _bstr_t перегружен char * — меня это возмутило, ведь это в корне не верно!


А что за _bstr_t? А вообще испахабить все можно.

DOO>В дельфи не встречал такого. Может в Builder'e. Меня как раз возмутило, что, если в VS хочешь посмотреть объявление чего-то, то надо откомпилить поект в начале(на моем PIII 600 это долго(!)). А в дельфи навел мышью и уже пишут в каком файле, в какой строке. А если нажел Ctrl и щелкнул мышью, то моментально перейдешь туда.


А зачем компилить? Или я этим не пользовался. VA вверху вроде бы пишет объявление (я этим как-то редко пользуюсь).

J>>2. В студии сами ставятся закрывающиеся } (Или это уже VA?)


DOO>Это VA и эту вещь я вырубил. Больше мешает.


Впранципе, про IDE спорить вообще бесполезно — слишком субъективно, а при желании можно найти другой редактор.

J>>Что-то не нравилось еще, но это было давно, поэтому не помню. А если поставить VisualAssist, то после него не то что с Дельфей невозможно работать, со студией без этого Assist.


DOO>Да VA сильно улучшает VS, но у моего коллеги после VA полностью заглючил ClassWizard...


У меня вроде бы нет.
... << RSDN@Home 1.1 beta 1 >>
Софт, исходники и фото
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: Odi$$ey Россия http://malgarr.blogspot.com/
Дата: 27.08.03 06:02
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Видимо MS это не прогрессивное человечество . Все ведь говорят, что WTL больше не поддерживается и не документируется.


что значит "больше"? разве WTL когда поддерживалась или документировалась MS официально?
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 27.08.03 10:16
Оценка:
Здравствуйте, centurn, Вы писали:

C> Да ту все... Смысл в том, что макросы плохо, но все же лучше, чем copy-paste, и у них есть гораздо более важные применения, чем inline-функции, а вот шаблонные функции гораздо лучше макросов. И опять же, шаблонные функции — только самое очевидное и примитивное применение шаблонов.

C> А вот что такого есть в Делфях кроме copy-paste?

class reference, ключевые слова is и as и т.п. Хотя, конечно, надо будет все писать самому и очень аккуратно.


J>>>Насчет STL не знаю — как то не приходилось от них ничего наследовать (хотя, вроде бы можно), но никто не мешает сувать шаблоны в свои классы и наследовать от них.

DOO>>Получается очень странный малопонятный гибрид. Пример:
C>...

DOO>>И что в итоге получается? CSon1 и CSon2 сложно называть детьми CTemplateClass.


C> Они дети специализированного CTemplateClass. А вообще-то может так подразумевалось?

C>
C>template <class T>
C>class CTemplateClass
C>{
C> T member;
C>}
C>template <class T>
C>class CSon : public CTemplateClass<T>
C>{
C>}
C>

C> Так можно. Честно. Кстати, STL сама обычно использует наследование шаблонов налево и направо. Можно глянуть ее реализацию...

Глядел... выглядит жутковато.

C> все из-за возможности обойтись без всяких там RTTI...


RTTI не так уж много занимает места в результирующем коде. На порядок меньше, чем копии шаблонных функций и классов.

DOO>>Я предпочитаю и сам конструктор вызвать и деструктор. И как-то использование owner у TComponent прозрачнее и понятнее.


C> А забыть вызвать деструктор в случае "ветвистого" кода, например?

C> В C++ я могу создавать автоматические объекты, а могу, если надо, сам говорить, года ему создасться, а когда умереть. Всегда лучше, если есть выбор...

В дельфи есть property owner у TComponent — которое, тоже контролирует время жизни объектов, причем не зависимо от языка — это можно реализовать и в С.

И например в Дельфи я могу сделать такой юнит:
Есть некий объект, который должен быть создан, но ровно один раз, хотя сам по себе не будет использоваться(напрямую), но его будут скрыто использовать другие объекты. Это все можно написать так, что человек, использующий этот модуль не должен даже будет забивать себе голову такими премудростями.
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 27.08.03 10:33
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>И например в Дельфи я могу сделать такой юнит:

DOO>Есть некий объект, который должен быть создан, но ровно один раз, хотя сам по себе не будет использоваться(напрямую), но его будут скрыто использовать другие объекты. Это все можно написать так, что человек, использующий этот модуль не должен даже будет забивать себе голову такими премудростями.
Можно подумать что в С++ это нельзя сделать
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 27.08.03 13:38
Оценка:
C>> Так можно. Честно. Кстати, STL сама обычно использует наследование шаблонов налево и направо. Можно глянуть ее реализацию...
DOO>Глядел... выглядит жутковато.

Эт с непривычки... Впрочем, их внутренние имена порой имхо действительно странноватые...

C>> все из-за возможности обойтись без всяких там RTTI...

DOO>RTTI не так уж много занимает места в результирующем коде. На порядок меньше, чем копии шаблонных функций и классов.

А что обычно более важный критерий оптимизации — объем, или скорость. Уж по скорости-то шаблоны занимают _минимум_. Там, где вместо RTTI — вообще 0 на этапе выполнения.
А если критичен объем... Что ж, можно писАть и так, чтобы объем был минимален...

DOO>И например в Дельфи я могу сделать такой юнит:

DOO>Есть некий объект, который должен быть создан, но ровно один раз, хотя сам по себе не будет использоваться(напрямую), но его будут скрыто использовать другие объекты. Это все можно написать так, что человек, использующий этот модуль не должен даже будет забивать себе голову такими премудростями.

Интересный аргумент. Статические и anonymous namespace переменные в С++, насколько мне известно, еще никто не отменял... Как и побочные действия конструкторов (иногда бывает очень полезно).
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: bkat  
Дата: 27.08.03 13:59
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, Аноним, Вы писали:


А>>Еще один факт. Число инсталляций VS значительно больше,

А>>чем продукта от Борланда.
А>>Это означает, что работы для того, кто владеет VS больше,
А>>чем работы для дельфистов.
А>>Причем не просто работы, а интересной работы.
А>>Для меня это гораздо больше значит, чем маниакальная любовь
А>>одной группы программеров к одному продукту и такая же нелюбовь к другому.

DOO>Я ни разу не попадал на такую работу, чтоб мне сказали, вот тебе задача, пиши на чем хочешь. Всегда на работе говорят: пиши на том-то. К сожалению, мне нравиться(сложилось так) паскаль и все, что из него выросло, а везде заставляют писать на С. Причем видел я и такой идиолтизм как написание достаточного громоздского интерфейса средствами чистого API. Больно было смотреть как маятся люди, делая тривиальные вещи, стоит только начать использовать VCL.


Это только подверждает мои слова.
Выбор инструмента разработки — это не только твое (или мое) личное желание,
а куча других факторов, про которые ты видимо не очень то думаешь.
Например, наработанные командой библиотеки, знание средтсва разработки другими
членами команды, стоимость средтства разработки и прочее.
Так вот, по совокупности факторов на рынке сложилась такая ситуация,
что число инсталляция VS больше, чем Дельфи.
Ты думаешь это случайно?

PS Прошу прощения, что прошлое сообщение отправил как Аноним
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 27.08.03 14:18
Оценка:
Забей. Это уже устаревший вопрос.

Все нормальные Дельфисты переезжают или уже переехали под Microsoft .NET. Архитектура — тот же Дельфи, но библиотеки поразнообразнее, поудобнее, и вообщё всё поновее.
... << RSDN@Home 1.1 beta 1 >>
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: Jenyay http://jenyay.net
Дата: 27.08.03 15:30
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Дак это плюсы макросов что ли? По-моему Вы не ту точку зрения стали отстаивать

DOO>И вообще — макром наворот текстового редактора, а не языка.

Так я это, наоборот про минусы.

DOO>Получается очень странный малопонятный гибрид. Пример:


DOO>
DOO>template <class T>
DOO>class CTemplateClass
DOO>{
DOO>  T member;
DOO>}
DOO>class CSon1 : public CTemplateClass<class1>
DOO>{
DOO>}
DOO>class CSon2 : public CTemplateClass<class2>
DOO>

DOO>И что в итоге получается? CSon1 и CSon2 сложно называть детьми CTemplateClass.

И, имхо, ничего особенного. В WTL наподобие такого с окнами вытворяют.

DOO>Волков бояться в лес не ходить

DOO>В JScript и выделять-тоо память не обязательно, но это не плюс по-моему.

Так тут другое дело, что память и выделяется и освобождается, когда надо, но сама. Хотя такими указателями я сам редко пользуюсь, но это не из-за глючности, а просто редко бывает запутанный код, что можно забыть освободить. Просто я стараюсь сразу после выделения памяти писать, где она освобождается.

J>>А зачем нам MS


DOO>Мне на работе сказали WTL — хорошо, но MS не поддерживает. Поэтому пиши на MFC.


Ну это уже вопрос к начальству. Хотя позиция странная.
... << RSDN@Home 1.1 beta 1 >>
Софт, исходники и фото
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: Jenyay http://jenyay.net
Дата: 27.08.03 15:30
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Ну ладно, отвлечемся, а как еще удобно BSTR'ами работать?


Я с СОМ только начинаю разбираться.

DOO>У меня тоже вроде нет. Но VS вообще довольно глючная...


Не знаю как сейчас и Дельфи, но когда я писал на 4-м Билдере, глюков было до фига.
... << RSDN@Home 1.1 beta 1 >>
Софт, исходники и фото
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.08.03 15:40
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Забей. Это уже устаревший вопрос.


M>Все нормальные Дельфисты переезжают или уже переехали под Microsoft .NET. Архитектура — тот же Дельфи, но библиотеки поразнообразнее, поудобнее, и вообщё всё поновее.


Посмотрите на С# и сравните его Delphi vs C++(VS) (Борланд официально просит называть не Object Pascal а Delphi). Delphi здесь явно выигрывает и неудивительно ито и другое разрабатывал Хейлсберг. В Net не торопятся с шаблонами , хотя перегрузка операторов явно не помешала бы в Delphi, как впрочем и продуманные шаблоны. Лучше немного подождать Delphi.Net. Наверняка многочисленные изменения коснутся и Native Delphi.
А так это уже религиозный вопрос. В любом случае дельфистам предпочтительнее знать vs C++, а обратное по желанию. Но читабельность и скотрость разработки на .... выше.
и солнце б утром не вставало, когда бы не было меня
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 27.08.03 15:56
Оценка:
S> А так это уже религиозный вопрос. В любом случае дельфистам предпочтительнее знать vs C++,

Да не нужны эти плюсы Дельфистам. На C# лучше смотреть, он и понятнее и перспективнее.

S> а обратное по желанию. Но читабельность и скотрость разработки на .... выше.


По моим впечатлениям, C# в обоих категориях лучше Дельфи. Delphi.NET мог бы исправить положение, но слишком опаздывает. The time is almost up (Matrix 2).
... << RSDN@Home 1.1 beta 1 >>
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 27.08.03 16:30
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>По-моему есть warning. Но сейчас сказать точно не могу.

Зачем варнинг? Это же стопроцентная ошибка.
DOO>А по поводу exception — в Дельфи базовый класс TException позволяет видеть что же случилось, даже если ты его не ловишь.
Ой... ексепшены... у меня в плюсах эксепшены оочень разговорчивые единственное что стектрейс не пишут.

DOO>В одной книжке я встретил правильную фразу, дословно не помню, что-то вроде, что существует объектно ориентированное пргораммирование и шаблонное программирование.

DOO>Очень разные вещи, поскольку в STL нет никакого наследования, например.
STL это набор базовых контейнеров и базовых алгоритмов.
Внимание вопрос:Какое отношение ООП имеет к сортировке? А к двухсвязному списку?
Ну скажи мне тебе часто приходит в голову наследоваться от массива? А потом подумай чем логически stl'ные контейнеры отличаются от простых массивов?

DOO>А указатели-то никто не отменял. Все можно творить используя их. И логика программы по-моему тогда на порядок понятнее.

Слегка перефразируем. Вот такой контейнер очень даже может понадобиться
std::map<std::string, std::list<boost::shared_ptr<object> > >
Это ассациотивный массив списков смартпоинтеров на объекты. Нука покажи мне как ты это сделаешь на дельфях? Ы? Причем сложность поиска в std::map log(N).

DOO>Мне просто это больше нравится(ну просто псле программирования на asm'е появились такие привычки)

Что нравится? Писать тонну кода ручками каждый раз когда нужен ассациотивный массив на красно-черном дереве?
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: Igor Trofimov  
Дата: 27.08.03 16:36
Оценка:
M>>Все нормальные Дельфисты переезжают или уже переехали под Microsoft .NET. Архитектура — тот же Дельфи, но библиотеки поразнообразнее, поудобнее, и вообщё всё поновее.

Я бы не кидался громкими фразами что "Все нормальные...".
Но некоторые — точно
Именно потому что нашли в C# хороший компромис.

>Лучше немного подождать Delphi.Net. Наверняка многочисленные изменения коснутся и Native Delphi.


В том-то и дело, что не так уж и лучше.

Было Delphi. Нормальной альтернативы в данной нише не было.
Теперь есть C#. От того же производителя, что и массовая операционка. С потугами на будущую кроссплатформенность (Kylix — тоже не более, чем потуги). Уже написана масса компонент и скоро это примет те же масштабы, что и у Delphi.

НЕЗАЧЕМ стало ОСТАВАТЬСЯ на Delphi.
Я Delphi всегда очень любил (с первой версии), но сейчас просто НЕЗАЧЕМ на ней оставаться.
Кое-что пока в Delphi IDE удобнее, чем в VS.NET, но в целом — за C#/VS.NET примущество.

Воздадим Delphi почести и поставим красивый памятник.

Это все мое ИМХО.
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.08.03 16:46
Оценка:
Здравствуйте, Igor Trofimov, Вы писали:


iT>Воздадим Delphi почести и поставим красивый памятник.


iT>Это все мое ИМХО.


Навряд ли. Достаточно много проектов написанных на Delphi легче перенести на Delphi.Net чем все заного переписывать. Да и Delphi для Net изначально лучше всех подходит под Net. Да и огромный контингент дельфистов по тем или иным причинам не перешедших на VS C# ( кто то Builder C# юзает) дождуться Net версии, тогда и посмотрим. Время покажет, а разнообразие языков еще никогда не мешало.
и солнце б утром не вставало, когда бы не было меня
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 27.08.03 16:59
Оценка:
Здравствуйте, Jenyay, Вы писали:

DOO>>У меня тоже вроде нет. Но VS вообще довольно глючная...

J>Не знаю как сейчас и Дельфи, но когда я писал на 4-м Билдере, глюков было до фига.
Я сейчас пишу на шестом. Сказать что он глючит это ничего не сказать.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 27.08.03 16:59
Оценка:
Здравствуйте, Jenyay, Вы писали:

J>Так тут другое дело, что память и выделяется и освобождается, когда надо, но сама. Хотя такими указателями я сам редко пользуюсь, но это не из-за глючности, а просто редко бывает запутанный код, что можно забыть освободить. Просто я стараюсь сразу после выделения памяти писать, где она освобождается.

А вто это очень зря. Для того чтобы я не использовал смартпоинтер нужна ооочень веская причина. Я даже с ходу придумать не могу.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: Jenyay http://jenyay.net
Дата: 27.08.03 17:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

J>>Так тут другое дело, что память и выделяется и освобождается, когда надо, но сама. Хотя такими указателями я сам редко пользуюсь, но это не из-за глючности, а просто редко бывает запутанный код, что можно забыть освободить. Просто я стараюсь сразу после выделения памяти писать, где она освобождается.

WH>А вто это очень зря. Для того чтобы я не использовал смартпоинтер нужна ооочень веская причина. Я даже с ходу придумать не могу.

Ну что ж, попробую пользоваться ими везде.
... << RSDN@Home 1.1 beta 1 >>
Софт, исходники и фото
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 06:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Jenyay, Вы писали:


DOO>>>У меня тоже вроде нет. Но VS вообще довольно глючная...

J>>Не знаю как сейчас и Дельфи, но когда я писал на 4-м Билдере, глюков было до фига.
WH>Я сейчас пишу на шестом. Сказать что он глючит это ничего не сказать.

Билдеры к делу не относятся, там по-моему даже компилятор сишный стоит доисторический, а весь VCL перегнан с паскаля(не руками).
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 06:09
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, DOOM, Вы писали:


DOO>>Теперь ваща очередь...

LVV> Давайте не путать язык, компилятор и IDE.
LVV>1. Язык. С++ ИМНО богаче будет. Как раз за счет перегрузки операций и шаблонов. В остальном ИМХО — совпадают.
Согласен.
LVV>Но!!! STL, как ни крути, стандарт С++! до чего Дельфям топать и топать.
Дельфи вообще не стандарт, а VCL дает огромную функциональность.
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 06:10
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Забей. Это уже устаревший вопрос.


M>Все нормальные Дельфисты переезжают или уже переехали под Microsoft .NET. Архитектура — тот же Дельфи, но библиотеки поразнообразнее, поудобнее, и вообщё всё поновее.


Что значит забей? .NET языковонезависимая, т.е. начнется что лучше C#,C++,Delphi.NET и еще бог знает что.
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 06:18
Оценка:
Здравствуйте, mihailik, Вы писали:

S>> А так это уже религиозный вопрос. В любом случае дельфистам предпочтительнее знать vs C++,


M>Да не нужны эти плюсы Дельфистам. На C# лучше смотреть, он и понятнее и перспективнее.


S>> а обратное по желанию. Но читабельность и скотрость разработки на .... выше.


M>По моим впечатлениям, C# в обоих категориях лучше Дельфи. Delphi.NET мог бы исправить положение, но слишком опаздывает. The time is almost up (Matrix 2).


Может я и консерватор, но к C# я отношусь не лучше, чем к скрипту, поскольку Java так и не добилась хоть сколько-нибудь приличной скорости работы. Сомневаюсь, что это получится у C#(немного устаревшие результаты есть в статье на rsdn Средства разработки->сравнительные характеристики->кто сегодня самый шустрый)
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: LaptevVV Россия  
Дата: 28.08.03 06:34
Оценка:
Здравствуйте, DOOM, Вы писали:

LVV>> Давайте не путать язык, компилятор и IDE.

LVV>>1. Язык. С++ ИМНО богаче будет. Как раз за счет перегрузки операций и шаблонов. В остальном ИМХО — совпадают.
DOO>Согласен.
LVV>>Но!!! STL, как ни крути, стандарт С++! до чего Дельфям топать и топать.
DOO>Дельфи вообще не стандарт, а VCL дает огромную функциональность.
В том-то и дело, что не стандарт!
VCL — это не язык, это IDE. А тут VC делфей задавит:
MFC — практически стандарт, функциональности до черта.
ATL, WTL — функциональности немеряно.
Так что единственное, в чем дельфи явно превосходит ВСЕ (имно) сишные компиляторы — это скорость компиляции. Вот за это его можно любить.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 28.08.03 06:45
Оценка:
DOO>Тоже самое можно реализовать везде. Я просто имел ввиду, что пойнтер он и в Африке пойнтер, не важно на что указывает. И в роли type cast'а после asm'а я признаю логичные вещи типа Dword Ptr и т.п., соответственно, когда _bstr_t перегоняется в char * простым type cast'ом — это на мой взгляд не верно.

А самое смешное то, что этого самого одиозного _bstr_t в С++ не существует — это дикий Microsoft-specific, который ей понадобился для какого-то там сопряжения с COM, кажись. Лично мне он понадоблся всего один раз... Кстати, я тогда тоже плевался. А operator const char*, впрочем, и у CString есть. И это все действительно очень плохо, но, в общем, не фатально. Кстати, при этом тип не "перегоняется", а только отдает указатель на внутренний буфер...
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 28.08.03 06:49
Оценка:
B>>Ты думаешь это случайно?
DOO>Конечно нет! Просто VS дешевле(намного, VS7 по-моему вообще была бесплатной, у нас ее из нета качали), чем Дельфи(если брать все легально).

Ага, афайк, VS7 enterprize стоит 7 килобаксов. Врочем, для промышленной разработки это копейки. А из инета можно много чего скачать, иногда даже раньше, чем продаваться начнет...
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 06:59
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Спор пошел не в ту сторону. Я просто сказал, что шаблонное прграммирование — это совершенно иная техника программирования, которая, на мой взгляд не очень сочетается с ООП(не в том случае, если создаются только разного рода контейнеры).

Еще как сочетается.

DOO>TStringList у которого объекты это TList, в котором хранятся указатели на нужные объекты — не вижу проблемы.

DOO>P.S. Конкрентные примеры из языка мне давать тяжело, поскольку инет на работе, а тут под рукой только VS
Производительность. Типобезопасность. Гарантия удаления объекта.
Нука напиши как будут выглядить удаление группы объектов в твоейсистеме на дельфях?
На С++ это выглядит так
container.erase(group_name);
Есть ГАРАНТИЯ того что все объекты из группы будут корректно удалены.
А добавляем объект в группу так
container[group_name].push_back(instance);
А перебераем так
std::for_each(container[group_name].begin(), container[group_name].end(), some_functor);
Или берем мой перегруженый
template<class T, class F>
F for_each(T& t, F f)
{ 
    return std::for_each(t.begin(), t.end(), f);
}

for_each(container[group_name], some_functor);

А если так
std::map<my_cool_class, std::list<boost::shared_ptr<object> > >
Ы?

DOO>Почему тонну кода? Возьмем, к примеру, Array из JScript — умеет сортировать свои элементы qsort'ом, для счастья надо только функцию сравнения.

Производительность. Типобезопасность.

DOO>Тоже самое можно реализовать везде. Я просто имел ввиду, что пойнтер он и в Африке пойнтер, не важно на что указывает. И в роли type cast'а после asm'а я признаю логичные вещи типа Dword Ptr и т.п., соответственно, когда _bstr_t перегоняется в char * простым type cast'ом — это на мой взгляд не верно.

Да что ты к _bstr_t прицепился? По моему тем кто писал микросовтовские библиотеки надо оторвать руки за то что они там натворили.
К С++ это не имеет никакого отношения. Единственная библиотека имеющея отношение к С++ это STL все остальное шито по воде белыми вилами.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 07:04
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>А, между прочим, один препод у нас заявил, что в "Европе и лучших домах Филадельфии "

Малоли что заявил препод... ничего личного но я таких преподов видел

DOO>(за бугром, одним словом) ОТКАЗАЛИСЬ от С в промышленной разработке ПО, поскольку, цитирую, "этот язык похабен".

Во первых С и С++ это совершнно разные языки.
Во вторых если человек не умеет использовать С++ то естественно он не сможет на нем работать
В третьих что-то я не слышал чтобы там применяли дельфю
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 07:06
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Что значит забей? .NET языковонезависимая, т.е. начнется что лучше C#,C++,Delphi.NET и еще бог знает что.

А то и значит. Если надо ГУИ и клиентов к БД то прямая дорога на .НЕТ
Во всех остальных областях дельфи проигрывает С++ с треском.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 07:13
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Может я и консерватор, но к C# я отношусь не лучше, чем к скрипту, поскольку Java так и не добилась хоть сколько-нибудь приличной скорости работы. Сомневаюсь, что это получится у C#(немного устаревшие результаты есть в статье на rsdn Средства разработки->сравнительные характеристики->кто сегодня самый шустрый)

10% кода который выполняется 90% времени можно и на С++ написать нативные длл к шарпу цепляются на раз. Хотя на МС++ можно делать смешеные сборки
К томуже не такой уж он и тормозной.
А вот 90% кода который состоит в основном из ГУИ легче на шарпе написать. К томуже за гуи можно и "обезьянок" посадить.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: Дарней Россия  
Дата: 28.08.03 07:27
Оценка:
DOO>Спор пошел не в ту сторону. Я просто сказал, что шаблонное прграммирование — это совершенно иная техника программирования, которая, на мой взгляд не очень сочетается с ООП(не в том случае, если создаются только разного рода контейнеры).

значит, нужно читать Александреску. еще как сочетается

DOO>TStringList у которого объекты это TList, в котором хранятся указатели на нужные объекты — не вижу проблемы.


тип элементов этого контейнера фиксирован. как насчет не String, а чего-то другого? TMySuperPuperObjectList?

DOO>Тоже самое можно реализовать везде. Я просто имел ввиду, что пойнтер он и в Африке пойнтер, не важно на что указывает. И в роли type cast'а после asm'а я признаю логичные вещи типа Dword Ptr и т.п., соответственно, когда _bstr_t перегоняется в char * простым type cast'ом — это на мой взгляд не верно.


и чего прицепились к _bstr_t? то, что он приводится к char* — всего лишь дурной тон в проектировании. Если не забывать о накладности этой операции, ни к чему плохому не приводит. В любом случае — это часть ATL, а не C++.
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: Begun Ulad Беларусь  
Дата: 28.08.03 07:31
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Почему тонну кода? Возьмем, к примеру, Array из JScript — умеет сортировать свои элементы qsort'ом, для счастья надо только функцию сравнения.

DOO>Тоже самое можно реализовать везде. Я просто имел ввиду, что пойнтер он и в Африке пойнтер, не важно на что указывает. И в роли type cast'а после asm'а я признаю логичные вещи типа Dword Ptr и т.п., соответственно, когда _bstr_t перегоняется в char * простым type cast'ом — это на мой взгляд не верно.

Почему простым type cast-ом? Вы код смотрели?

// Extract a const char_t*
//
inline _bstr_t::operator const char*() const 
{
    return (m_Data != NULL) ? m_Data->GetString() : NULL;
}

// Extract a char_t*
//
inline _bstr_t::operator char*() const 
{
    return const_cast<char*>((m_Data != NULL) ? m_Data->GetString() : NULL);
}


в свою очередь m_Data->GetString() это:

inline const char* _bstr_t::Data_t::GetString() const 
{
    if (m_str == NULL) {
        m_str = _com_util::ConvertBSTRToString(m_wstr);
    }

    return m_str;
}


смотри comutil.h
... << RSDN@Home 1.1 alpha 1 >>
\n Give me MSDN and I'll show you the world
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: LaptevVV Россия  
Дата: 28.08.03 08:00
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, LaptevVV, Вы писали:


LVV>>Так что единственное, в чем дельфи явно превосходит ВСЕ (имно) сишные компиляторы — это скорость компиляции. Вот за это его можно любить.

WH>Да ну фигня какая. Если PCH нормально настроены, то С++ тоже летает. Если фаил компилится меньше полсекунды я этого не замечаю, а с нормальными настройками так и происходит.
WH>А пара минут на полный билд большого проекта это смешно.
WH>Тут главное PCH ручками настроить, а это за несколько кликов можно сделать.

1. Я дельфи последние совсем не знаю. Наверное стал такой же монстр, как и все остальное. Вполне возможно, что и компилирует медленно.
2. РСН — это как расшифровать? (Ну не понял я Вашу аббревиатуру )
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 28.08.03 08:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

LVV>>Так что единственное, в чем дельфи явно превосходит ВСЕ (имно) сишные компиляторы — это скорость компиляции. Вот за это его можно любить.

WH>Да ну фигня какая. Если PCH нормально настроены то С++ тоже летает. Если фаил компилится меньше полсекунды я этого не замечаю, а с нормальными настроеками так и происходит.
WH>А пара минут на полный билд большого проекта это смешно.

А у нас полмиллиона строк ребилдятся час и линкер свопит даже на 512 мегах памяти. Настройки уже нормальные.
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: SYN0ptik  
Дата: 28.08.03 08:29
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:


DOO>>Что значит забей? .NET языковонезависимая, т.е. начнется что лучше C#,C++,Delphi.NET и еще бог знает что.

WH>А то и значит. Если надо ГУИ и клиентов к БД то прямая дорога на .НЕТ
WH>Во всех остальных областях дельфи проигрывает С++ с треском.
Правильно! Если нужно компактное и шустрое приложение. То на Дельфях его писать смысла нет.
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 09:01
Оценка:
Здравствуйте, Begun Ulad, Вы писали:

BU>Здравствуйте, DOOM, Вы писали:


DOO>>Почему тонну кода? Возьмем, к примеру, Array из JScript — умеет сортировать свои элементы qsort'ом, для счастья надо только функцию сравнения.

DOO>>Тоже самое можно реализовать везде. Я просто имел ввиду, что пойнтер он и в Африке пойнтер, не важно на что указывает. И в роли type cast'а после asm'а я признаю логичные вещи типа Dword Ptr и т.п., соответственно, когда _bstr_t перегоняется в char * простым type cast'ом — это на мой взгляд не верно.

BU>Почему простым type cast-ом? Вы код смотрели?


Смотрел. Я знаю, что char* перегружен, но изначально смысл на него налагался другой. Это как тоже в какой-то книжке было сказано: конечно вы можете навесить операцию присваивания на значок "+" — но кто это потом поймет
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: Дарней Россия  
Дата: 28.08.03 09:04
Оценка:
DOO>Смотрел. Я знаю, что char* перегружен, но изначально смысл на него налагался другой. Это как тоже в какой-то книжке было сказано: конечно вы можете навесить операцию присваивания на значок "+" — но кто это потом поймет

Какой другой смысл?
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 09:12
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, WolfHound, Вы писали:


WH>>Здравствуйте, LaptevVV, Вы писали:


LVV>2. РСН — это как расшифровать? (Ну не понял я Вашу аббревиатуру )


Имелись ввиду Pre Compiled Headers — но разве это сильно ускорит компиляцию?
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 09:15
Оценка:
Здравствуйте, elmm_, Вы писали:


_>Вобщем делфи штука не плохая, но у C++ (VS) охватываемое поле деятельности куда шире, где-то они пересикаются где-то нет. Все что можно сделать на делфе можно повторить на C++, наоборот вряд ли...


Пример, пожалуйста.
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 09:18
Оценка:
Здравствуйте, Дарней, Вы писали:

DOO>>А, между прочим, один препод у нас заявил, что в "Европе и лучших домах Филадельфии "(за бугром, одним словом) ОТКАЗАЛИСЬ от С в промышленной разработке ПО, поскольку, цитирую, "этот язык похабен".

DOO>>P.S. По его словам все прогрессивное человечество использует Аду.

Д>всегда подозревал, что ни один толковый програмер не полезет в ВУЗ преподавателем. Если только от большой любви к преподаванию (но я ни разу таких не встречал )


Он не программер, а математик, вел теорию чисел. И Кнута может почти наизусть рассказать. Короче, человек, равного которому здесь, я думаю, не так просто найти
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 09:25
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>1. Я дельфи последние совсем не знаю. Наверное стал такой же монстр, как и все остальное. Вполне возможно, что и компилирует медленно.

Дельфи та она конечно всеравно быстрее. Это я к тому что мне по барабану сколько момпилится один фаил 0.5с или 0.05
А пару тройку минут раз в день на полный ребилд я подождать могу.
LVV>2. РСН — это как расшифровать? (Ну не понял я Вашу аббревиатуру )
Pre Compiled Header
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 28.08.03 09:32
Оценка:
Здравствуйте, elmm_, Вы писали:

_>Здравствуйте, WolfHound, Вы писали:


WH>>Здравствуйте, DOOM, Вы писали:


DOO>>>Что значит забей? .NET языковонезависимая, т.е. начнется что лучше C#,C++,Delphi.NET и еще бог знает что.

WH>>А то и значит. Если надо ГУИ и клиентов к БД то прямая дорога на .НЕТ
WH>>Во всех остальных областях дельфи проигрывает С++ с треском.

_>Вот именно... А вы попробуйте написать что нибудь на делфях или НЕТе не офисно-ДБшной направлености, да еще если оно должно не только под виндой работать... Топик правда про C++ в VS, но сделав свой проект в комфортной IDEшке в визуале и погоняв там же, без проблем переношу пот линукс... Да в делфе есть кайликс, но во первых дальше линукса не сунешся, а во вторых — если мне надо кросплатформенное гуи — я выбираю то что мне нравится из тонны библиотек (мне лично wxWindows понравился почему-то) и получаю подобную функциональность удобными для МЕНЯ средствами + еще большие возможности по портированию... Да и к томуже кода на C/C++ на сегодняшний день гараздо больше чем на Delphi — как ни как существует он дольше и пишут на нём больше людей... Вобщем единственное что мне понравилось при знакомстве с Delphi это более быстрая возможность рисовать окошки — в свое время такое же радостное впечатление было при виде VB, но со временем VB был за ненадобностью забыт... А поигравшись с делфей и получив состояние, близкое к экстазу, при виде красивых кнопочек намалеваных за 5 минут, забил на это дело за не надобностью...


_>Вобщем если мне предется писать какую-нибудь прогу для работы с БД и красивым интерфейсом — буду учить делфи — там это быстро и легко — это его явное преимущество, как по мне.


_>Пока что такой необходимости нет, так что моя верность к C++ (VS) не поколебима


_>Но это все не преимущества и недостатки самого языка, а скорее совокупность — язык, средства разработки, имеющиеся библиотеки, возмодность переноса и распостранненость...


_>Вобщем делфи штука не плохая, но у C++ (VS) охватываемое поле деятельности куда шире, где-то они пересикаются где-то нет. Все что можно сделать на делфе можно повторить на C++, наоборот вряд ли...


Вот опять начались религиозные войны. Нужно брать пример с азиатов, онм веруют в несколько вер и используют по необходимости.
Бывает смешно смотреть на Сишный код сравнивая его с дельфийным при одинаковой скорости выполнения (как по читабельности так и по размеру). Но вот интересно, что нельзя сделать на Delphi, учитывая возможность применения Ассемблера, доступ ко всем апишным функциям итд ?????
А вот несовместимость классов в Delphi и С++ наверное все таки недостаток, который исправляет NET (причем продуманность их очень радует), да и решает огромное количество недостатков Native компиляторов особенно когда появляется большое количество различных по архитектуре процессоров и надежность программ становится на первое место.
Давайте верить в ПРОГРАММИРОВАНИЕ.
и солнце б утром не вставало, когда бы не было меня
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 09:37
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Он не программер, а математик, вел теорию чисел. И Кнута может почти наизусть рассказать.

И какое это отношение имеет к написанию больших програм? А в алгоритмах и я неплохо разбираюсь. На олимпиадах без этого никуда.
DOO>Короче, человек, равного которому здесь, я думаю, не так просто найти
Смотря в чем. Мне почемуто кажется что С++ я знаю знАчительно лучше чем он.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 09:41
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Какой другой смысл?


(char *)name — указатель на байт. Занимает 4-ре байта. Посмотри на первые четыре байта от метки name как на указатель на байт. Такой вроде всегда был смысл(если не ошибаюсь reinterpret_cast в С++)
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 28.08.03 09:50
Оценка:
Здравствуйте, SYN0ptik, Вы писали:

SYN>Правильно! Если нужно компактное и шустрое приложение. То на Дельфях его писать смысла нет.


Почему? Кто сказал, что на Дельфи нельзя написать компактное и быстрое приложение?
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 28.08.03 09:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>А у нас полмиллиона строк ребилдятся час и линкер свопит даже на 512 мегах памяти. Настройки уже нормальные.

WH> А на пару десятков длл разрезать не пробовали? Говорят помогает...

У vc6 (все, кроме меня, работают на нем) проблемы с экспортом stl-контейнеров. Да и резать по живому придется.
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: Дарней Россия  
Дата: 28.08.03 10:11
Оценка:
DOO>Он не программер, а математик, вел теорию чисел. И Кнута может почти наизусть рассказать. Короче, человек, равного которому здесь, я думаю, не так просто найти

вот с этого и надо было начинать. и еще добавить в конец: ", в своей области"
когда сапожники берутся печь пироги, из этого еще никогда ничего хорошего не выходило
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: Mamut Швеция http://dmitriid.com
Дата: 28.08.03 10:48
Оценка:
Любит у нас народ еще всплывающие подсказки сравнивать...
Насчет подсказок:


/*1*/  class CSomeClass{
/*2*/    private:
/*3*/      CMyClass ci;
/*4*/
/*5*/    public:
/*6*/      
/*7*/      void SomeFunc(){
/*8*/         ci.func();
/*9*/         ci.otherfunc();
/*10*/      }
/*11*/  }



В МС в 8-ой строчке показывает member-list из CMyClass, а в 9-ой орет "ci is not a structure or a class". Причем такие глюки повсеместно.

В 6-ой версии как минимум Builderа всплывающая подсказка показывает только те функции, методы и т.п., которые имеют смысл в данной конкретной ситуации, а не содержание всех заголовочных файлов SDK.

В Борландовских продуктов гораздо умнее расставлена клавиатура. Одно только то, что Add Watch в студии не снабжен коьбинацией клавиш, меня полностью убило.

Правда это все — интерфейсные, и не всегда кстати нужные, прибамбасы.

Самый главный минус Дельфей, и их внебрачного урода Builderа, — это именно завязка всего под VCL. В Дельфях все обьекты автоматически наследуются от TObject, что в результирующий экзешник добавляет такое количество кода, что потом листинг функций в файле смотреть страшно.

Про TStringList и вообще любые списки, TListView и прочие Борландовские извращения говорить не буду. Например, почему TListItem::Data имеет тип данных TObject*? Я в эту самую дату загоняю свои типы дынных, и пользоваться огромадным кол-вом reinterpret_cast меня уже плющит.

Что еще нельзя делать в Delphi/Builder? Нельзя эффективно перехватывать оконные сообщения для создания кустомизированных контролов "на лету". Необходимо создавать свои собственные компоненты.

Код Дельфи не кроссплатформенный, как здесь кто-то утверждал, если не пользоваться CLX. Если пользовать, придется таскать n-мегабайтовые библиотеки. Правда, в случае Buildera, это и так приходится делать...

Ну спорю, Borland'овские продукты красивы и в общем удобны, но... Писать не-GUI и серьезные вещи IMHO надо на С++.


dmitriid.comGitHubLinkedIn
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 11:00
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>У vc6 (все, кроме меня, работают на нем)

А... Ну тогда понятно. У него PCH тормозные. Чего про 7.1 не скажешь.
_>проблемы с экспортом stl-контейнеров.
А STLPort не пробовали?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 28.08.03 11:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

_>>У vc6 (все, кроме меня, работают на нем)

WH>А... Ну тогда понятно. У него PCH тормозные. Чего про 7.1 не скажешь.

Нет никакой разницы — у меня компилит даже чуть медленнее. Зато у других на 256 мегах линкует, не так злобно тряся винчестером, как у меня на 512 — новая студия жрет много памяти.

_>>проблемы с экспортом stl-контейнеров.

WH>А STLPort не пробовали?

Один маньяк у себя использует параллельно с динкумовским, но я на 7.1 это отключил ифдефами. Основная проблема все-таки в том, чтобы раскачать народ и обрубить кучу левых зависимостей между компонентами.
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 28.08.03 11:12
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

WH>>А STLPort не пробовали?

_>Один маньяк у себя использует параллельно с динкумовским, но я на 7.1 это отключил ифдефами.
У 7.1 нормальный STL.
_>Основная проблема все-таки в том, чтобы раскачать народ и обрубить кучу левых зависимостей между компонентами.
А так: Не пробовали?
А если серьезно то это архитектора бить надо.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sergey Россия  
Дата: 28.08.03 11:42
Оценка:
Hello, desperado_gmbh!
You wrote on Thu, 28 Aug 2003 09:53:12 GMT:

dg> Здравствуйте, WolfHound, Вы писали:


_>>> А у нас полмиллиона строк ребилдятся час и линкер свопит даже на 512

_>>> мегах памяти. Настройки уже нормальные.
WH>> А на пару десятков длл разрезать не пробовали? Говорят
WH>> помогает...

dg> У vc6 (все, кроме меня, работают на нем) проблемы с экспортом

dg> stl-контейнеров. Да и резать по живому придется.


Нет там никаких проблем с экспортом давно. Сходи на сайт dinkumware за фиксами к VC'шному STL'у.

Best regards,
Sergey.
Posted via RSDN NNTP Server 1.7 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 28.08.03 11:56
Оценка:
Здравствуйте, Sergey, Вы писали:

dg>> У vc6 (все, кроме меня, работают на нем) проблемы с экспортом

dg>> stl-контейнеров. Да и резать по живому придется.
S>Нет там никаких проблем с экспортом давно. Сходи на сайт dinkumware за фиксами к VC'шному STL'у.

Да это просто отговорка, чтобы не делать Проблема-то больше организационная и психологическая.
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 28.08.03 12:21
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, WolfHound, Вы писали:


_>>>А у нас полмиллиона строк ребилдятся час и линкер свопит даже на 512 мегах памяти. Настройки уже нормальные.

WH>> А на пару десятков длл разрезать не пробовали? Говорят помогает...

_>У vc6 (все, кроме меня, работают на нем) проблемы с экспортом stl-контейнеров. Да и резать по живому придется.


Раза в два-три скорость может увеличить.
У нас проект как раз в три раза больше , а полный билд идет всего час.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 28.08.03 12:53
Оценка:
S> Да и Delphi для Net изначально лучше всех подходит под Net.

Это что значит? Delphi.NET лучше подходит для .NET, чем C#?

Неправда.
... << RSDN@Home 1.1 beta 1 >>
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 28.08.03 12:53
Оценка:
DOO>Может я и консерватор, но к C# я отношусь не лучше, чем к скрипту, поскольку Java так и не добилась хоть сколько-нибудь приличной скорости работы.

А Java здесь не при чём.

DOO>Сомневаюсь, что это получится у C#(немного устаревшие результаты есть в статье на rsdn Средства разработки->сравнительные характеристики->кто сегодня самый шустрый)


Не знаю, что ты там усмотрел в результатах крамольного, только скорость C# вполне достаточная для работы. Во всяком случае, по сравнению с Дельфи уж точно никаких тормозов нету.
... << RSDN@Home 1.1 beta 1 >>
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 28.08.03 13:06
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Раза в два-три скорость может увеличить.

_O_>У нас проект как раз в три раза больше , а полный билд идет всего час.

Наверное, шаблонами мало пользуетесь

Скорость ребилда не увеличится — линкер работает только последние пять минут из часа. А вот скорость билда после мелких изменений возрастет многократно. Только пока все это в мечтах...
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 28.08.03 13:07
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, elmm_, Вы писали:



_>>Вобщем делфи штука не плохая, но у C++ (VS) охватываемое поле деятельности куда шире, где-то они пересикаются где-то нет. Все что можно сделать на делфе можно повторить на C++, наоборот вряд ли...


DOO>Пример, пожалуйста.


Не видел ни одного промышленного CAD/CAM/CASE средства, ориентированного на разработку софта для real-time и embedded систем (и для разработки самих систем), которое бы было сделано на Delphi.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 28.08.03 13:09
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, _Obelisk_, Вы писали:


_O_>>Раза в два-три скорость может увеличить.

_O_>>У нас проект как раз в три раза больше , а полный билд идет всего час.

_>Наверное, шаблонами мало пользуетесь


Наоборот, очень часто пользуемся.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 28.08.03 13:11
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>>>У нас проект как раз в три раза больше , а полный билд идет всего час.

_>>Наверное, шаблонами мало пользуетесь
_O_>Наоборот, очень часто пользуемся.

Тогда странно. Какие конструкции замедляют компиляцию больше всего, я пока не выяснял.
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: Mamut Швеция http://dmitriid.com
Дата: 28.08.03 14:41
Оценка:
Что я себе действительно уяснил — что идеальных компиляторов и средств разработки не бывает


dmitriid.comGitHubLinkedIn
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: Анатолий Широков СССР  
Дата: 28.08.03 15:21
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, WolfHound, Вы писали:


WH>>Здравствуйте, Jenyay, Вы писали:


DOO>>>>У меня тоже вроде нет. Но VS вообще довольно глючная...

J>>>Не знаю как сейчас и Дельфи, но когда я писал на 4-м Билдере, глюков было до фига.
WH>>Я сейчас пишу на шестом. Сказать что он глючит это ничего не сказать.

DOO>Билдеры к делу не относятся, там по-моему даже компилятор сишный стоит доисторический, а весь VCL перегнан с паскаля(не руками).


Ну, VCL вообще никто не трогал. Просто под Cбилдером были написаны врапперы и только. А так при отладке ты заходишь в обычный код на Delphi(Pascal).
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: Аноним  
Дата: 28.08.03 15:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, LaptevVV, Вы писали:


LVV>>1. Я дельфи последние совсем не знаю. Наверное стал такой же монстр, как и все остальное. Вполне возможно, что и компилирует медленно.

WH>Дельфи та она конечно всеравно быстрее. Это я к тому что мне по барабану сколько момпилится один фаил 0.5с или 0.05
WH>А пару тройку минут раз в день на полный ребилд я подождать могу.
LVV>>2. РСН — это как расшифровать? (Ну не понял я Вашу аббревиатуру )
WH>Pre Compiled Header

А мне вот на полный ребилд более 40 минут ждать надо.
Никакие РСН не помогут.
Без РСН я даже боюсь предположить, сколько уйдет времени
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 28.08.03 16:30
Оценка:
M>В Дельфи принято исправлять ошибки компиляции в таком режиме. Компилируем, IDE выбрасывает курсор на первую ошиюку. Исправляем — и опять компилируем. Курсор на следующей ошибке.
M>Это получается ровно столько же по времени, как и просто для перехода к следующей ошибке.
M>Такая вот скорость компиляции. Это тебе не полсекунды, это просто моментально.

А в С++ принято стараться не делать ошибки. Это и компиляцию ускоряет, и вообще.
А если серьезно, я в таких случаях компилирую только текущий файл, а это на любом проекте быстро. А большинство опечаток мне и VA без всякой компиляции показывает...
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 28.08.03 16:36
Оценка:
C> А в С++ принято стараться не делать ошибки. Это и компиляцию ускоряет, и вообще.

... << RSDN@Home 1.1 beta 1 >>
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 29.08.03 06:25
Оценка:
_>>Вобщем делфи штука не плохая, но у C++ (VS) охватываемое поле деятельности куда шире, где-то они пересикаются где-то нет. Все что можно сделать на делфе можно повторить на C++, наоборот вряд ли...
DOO>Пример, пожалуйста.

Чтобы особо не фантазировать, спрошу, ты драйверов/операционок много на Делфах написанных видел? А 3D шутеров каких-нить? Знаю, что последнее можно, но какой ценой...
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 29.08.03 07:03
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Что я себе действительно уяснил — что идеальных компиляторов и средств разработки не бывает


А идеального вообще в реальности ничего не бывает — закон природы.
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: AndrewJD США  
Дата: 29.08.03 07:48
Оценка:
Здравствуйте, centurn, Вы писали:


C>Чтобы особо не фантазировать, спрошу, ты драйверов/операционок много на Делфах написанных видел? А 3D шутеров каких-нить? Знаю, что последнее можно, но какой ценой...


На Дельфях не видел. Зато видел на паскале. MAC OS например...
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: alexkro  
Дата: 29.08.03 08:34
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, mihailik, Вы писали:


WH>>>Во всех остальных областях дельфи проигрывает С++ с треском.

M>>Кгм. В удобстве C++ проигрывает всем, кому только можно. Разве что ассемблеру не проигрывает.
WH>
WH>Типа я никогда на дельфе не писал...
WH>В дельфе надо следить за ресурсами ручками, а это так задалбывает...
WH>А если писать с использованием исключений то код превращается в кучу try/finally что не добавляет ни читабельности ни скорости, а как оно задалбывает...

Как я с тобой согласен! И в C# подобная дребедень. using немного спасает ситуацию, но только в самых простых случаях. Особенно меня прикалывает тот факт, что IDispose.Dispose() может выбросить исключение. После этого я не могу понять как на C# можно писать надежные программы.

WH> В С++ все куда проще захватил ресурс в конструкторе, освободил в деструкторе и плевать хотел на исключения и ветвистую логику. И обрабатывать исключения буду там где удобно, а не там где ресурс захватил.

WH>Еще очень часто есть куча рутинной работы которую в 99% случаев можно свалить на шаблоны.
WH>STL контейнеры это вобще штука не заменимая. Если знаешь что тебе надо и свойства контейнеров то самопальные контейнеры не нужны в 99.999% случаев.
WH>И многое другое...
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: Mamut Швеция http://dmitriid.com
Дата: 29.08.03 08:44
Оценка:
Самый главный минус Дельфей, и их внебрачного урода Builderа, — это завязка всего под VCL. В Дельфях все обьекты автоматически наследуются от TObject, что в результирующий экзешник добавляет такое количество кода, что потом листинг функций в файле смотреть страшно.

Про TStringList и вообще любые списки, TListView и прочие Борландовские извращения говорить не буду. Например, почему TListItem::Data имеет тип данных TObject*? Я в эту самую дату загоняю свои типы дынных, и пользоваться огромадным кол-вом reinterpret_cast меня уже плющит.

Что еще нельзя делать в Delphi/Builder? Нельзя эффективно перехватывать оконные сообщения для создания кустомизированных контролов "на лету". Необходимо создавать свои собственные компоненты.

Код Дельфи не кроссплатформенный, как здесь кто-то утверждал, если не пользоваться CLX. Если пользовать, придется таскать n-мегабайтовые библиотеки. Правда, в случае Buildera, это и так приходится делать...

Нe спорю, Borland'овские продукты красивы и в общем удобны, но... Писать не-GUI и серьезные вещи IMHO надо на С++.


dmitriid.comGitHubLinkedIn
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 29.08.03 09:49
Оценка:
M>Самый главный минус Дельфей, и их внебрачного урода Builderа

А Билдер никто не любит. Те же самый плюсы, только глючные.

M>- это завязка всего под VCL. В Дельфях все обьекты автоматически наследуются от TObject, что в результирующий экзешник добавляет такое количество кода, что потом листинг функций в файле смотреть страшно.


Тю. Ты бы ещё на машкоды смотрел, как там всё неоптимально. Поменьше нужно заморачиваться такой ерундой. Главное — чтобы программа работала в соответствии с Т.З.

M>Про TStringList и вообще любые списки, TListView и прочие Борландовские извращения говорить не буду. Например, почему TListItem::Data имеет тип данных TObject*? Я в эту самую дату загоняю свои типы дынных, и пользоваться огромадным кол-вом reinterpret_cast меня уже плющит.


Это проблемы Билдера. На Дельфи никаких проблем нету.

M>Что еще нельзя делать в Delphi/Builder? Нельзя эффективно перехватывать оконные сообщения для создания кустомизированных контролов "на лету". Необходимо создавать свои собственные компоненты.


Бр-бр. Что это значит, "на лету перехватывать"?

M>Код Дельфи не кроссплатформенный, как здесь кто-то утверждал, если не пользоваться CLX. Если пользовать, придется таскать n-мегабайтовые библиотеки. Правда, в случае Buildera, это и так приходится делать...


Во, конечно! То ли дело C++ — это ж просто идеал многплатформенноси. Зачем только Яву изобрели не знаю. Писали бы всё на C++.

Вон Микрософт как поступает — берёт Word под Windows, перекомпилирует его для MacOS и продаёт. А за стыковкой с платформой сам дюже вумный компилятор C++ следит.

M>Нe спорю, Borland'овские продукты красивы


Красивы?

M>и в общем удобны, но... Писать не-GUI и серьезные вещи IMHO надо на С++.


Естественно, писать надо на C++. Пусть там неудобно, зато платят больше.
... << RSDN@Home 1.1 beta 1 >>
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 29.08.03 11:20
Оценка:
Здравствуйте, mihailik, Вы писали:

M>C++ вызывает деструкторы только для объектов в стеке. Если объект используется через указатель — точно так же заботится приходится самому. Просто в Дельфи все объекты — указатели.

А в С++ нормальные люди "голые указатели" вобще не используют. Ибо смартпоинтеры рулят.

M>Ну уж не знаю, как можно писать безопасный код без try/finally. Даже на C++. Разве что на WinAPI да ручками проверять каждый возврат на 0 или INVALID_FILE_HANDLE или что там ещё.

А вот так. Все ресурсы будут освобождены в деструкторах, а потом исключение ловится геднибудь на верху.

WH>>Еще очень часто есть куча рутинной работы которую в 99% случаев можно свалить на шаблоны.

M>Хе-хе. Это кто же виноват, что в C++ столько рутины?
Не в С++, а в проектах отличных от клиента к БД.

M>В Дельфи и без шаблонов рутинной работы практически нет.



M>Возьми вон сделай простейшую Dll с одним экспортом. На C++ это будет куча мелкий хидеров, файликов и всяких деклараторов. А на Дельфи — один скромный исходник.

Ой не смешите мои тапочки
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
extern "C"
__declspec(dllexport)
void __stdcall my_cool_export_function()
{
}
BOOL APIENTRY DllMain( HANDLE hModule, 
                       DWORD  ul_reason_for_call, 
                       LPVOID lpReserved
                     )
{
    return TRUE;
}

Все.

M>Что, и типизированные коллекции для COM можно на одних шаблонах сбацать?

Ты емеешь в виду IEnumXXX? Ну интерфейс в IDL по любому прописать придеться, а типовую реализацию легко.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: Alex Black Украина http://www.adept7.kiev.ua
Дата: 29.08.03 11:47
Оценка:
Здравствуйте, DOOM, Вы писали:


WH>>Вот про MFC не надо. Этого динозавра давно пора пристрелить чтобы ни кто не мучался. Все прогрессивное человечество либо уже переползло на WTL либо собирается.


DOO>Видимо MS это не прогрессивное человечество . Все ведь говорят, что WTL больше не поддерживается и не документируется.


Неподдерживается????
Особенное если учесть планируемый в районе осени выход 7.1 версии.
Или это у меня неверые данные?
Радость от нахождения ошибки часто омрачаеться осознанием собственой глупости.
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: mister-AK Россия  
Дата: 29.08.03 11:56
Оценка:
Здравствуйте, Igor Trofimov, Вы писали:

iT>Теперь есть C#. От того же производителя, что и массовая операционка. С потугами на будущую кроссплатформенность (Kylix — тоже не более, чем потуги). Уже написана масса компонент и скоро это примет те же масштабы, что и у Delphi.


и может после этого open source воплотиться в святом лике MS под сенью Била,
который хитрее всех зверей полевых ("Деяния апостолов")

iT>НЕЗАЧЕМ стало ОСТАВАТЬСЯ на Delphi.


слушай, после тех "достопамятных чтений", где мы слидели... я долго в делегаты ещё въезжал и въезжал у ларька с пивом ,
а потом на этом форуме где-то почитал про них инстересные мысли народа:

тема была "Отличия событий от делегатов"

От: Mishka rsdn
Дата: 22.11.02 21:08
...
Делегат — это класс, в задачу которого входит хранение ссылки на метод типа. При вызове метода Invoke (BeginInvoke при асинхронном вызове) делегата происходит вызов хранимого в нём метода (или методов).
Событие — это объект делегата + четыре метода: Add, Remove, Fire и Other (имена этих методов, генерируемые компилятором C#, на самом деле зависят от имени события).
...


фразу "метод типа" я только маленько не понял... Это что — "чисто сишная речь, в шарпе"?

эх! как все сложно в энтаких сущностях наварено!

кстати а на счёт того, что я тебе там пытался "впарить" про языковую конструкцию "expanse для class", если конечно припомнишь,
то это в Delphi.net хотят по-моему helper class-ами назвать... умные люди

iT>Воздадим Delphi почести и поставим красивый памятник.


и окантуем его оными барельефами:
— Anders Hejlsberg — Anders Hejlsberg — Anders Hejlsberg —
а у монументального фонтана .NET разобъем клумбу стилизованную под С#

я всегда c нами,
</mister-AK>
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: EugenF Украина  
Дата: 29.08.03 14:13
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Он не программер, а математик, вел теорию чисел. И Кнута может почти наизусть рассказать. Короче, человек, равного которому здесь, я думаю, не так просто найти


А я могу кирпичи кулаками бить, мне я думаю тоже здесь немного равных Но это не даёт мне ни малейшего повода учить других ПРОГРАММИРОВАТЬ. А разговоры по поводу ущербности плюсов я слышу с самого начала своей профессиональной карьеры ( около 10 лет ), но тем не менее самые прибыльные и большие проекты именно на них.
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 29.08.03 14:51
Оценка:
WH>Ой не смешите мои тапочки
WH>
...
WH>    return TRUE;
WH>}
WH>

WH>Все.

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

expor.c
expor.c(3) : error C2059: syntax error : 'string'

... << RSDN@Home 1.1 beta 1 >>
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: jhfrek Россия  
Дата: 29.08.03 14:56
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>По поводу того, что у Дельфи меньше возможностей... Приведите хоть один пример, который нельзя реализовать на Дельфи, но можно на C++. Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и


А... Сэмулируй мне, плеазе, друзей на Дельфях. Страдаю без них жутко...
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: mister-AK Россия  
Дата: 29.08.03 15:05
Оценка:
Здравствуйте, jhfrek, вы писали:

J>А... Сэмулируй мне, плеазе, друзей на Дельфях. Страдаю без них жутко...


ну да, и Protect виден только в рамках одного unit
ну и что — средство не идеальное, но работать проще...
а вот может придеться еще и пострадаешь без "приличных" доверительных отношений между unit-ами , как в ActiveDirectory в рамках модели namespace на C#?

Страдаю жутко....
</mister-AK>
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: jhfrek Россия  
Дата: 29.08.03 15:24
Оценка:
Здравствуйте, mister-AK, Вы писали:

MA>Здравствуйте, jhfrek, вы писали:

J>>А... Сэмулируй мне, плеазе, друзей на Дельфях. Страдаю без них жутко...
MA>ну да, и Protect виден только в рамках одного unit

А это вообще засада... Напишешь obj.FValue := ... вместо obj.Value := ... и кирдык всему тому что должно происходить внутри SetValue. А компилятор, зараза, не обругает...
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: Dym On Россия  
Дата: 29.08.03 15:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>В третьих что-то я не слышал чтобы там применяли дельфю

Был случай, с нашими программистами. Решили они на "забугорного" дядю поработать, им прислали ТЗ и требование, чтобы код был написан на Delphi 3, чем повегли всех в недоумение. Все исходники отправлялись в США (чего они там с ними делали я не знаю).
Счастье — это Glück!
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: Igor Trofimov  
Дата: 29.08.03 16:53
Оценка:
iT>>НЕЗАЧЕМ стало ОСТАВАТЬСЯ на Delphi.

MA>слушай, после тех "достопамятных чтений", где мы слидели... я долго в делегаты ещё въезжал и въезжал у ларька с пивом ,

MA>кстати а на счёт того, что я тебе там пытался "впарить" про языковую конструкцию "expanse для class", если конечно припомнишь,

Боюсь, ты меня с кем-то путаешь
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 29.08.03 18:31
Оценка:
Здравствуйте, mihailik, Вы писали:
M>

M>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
M>Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

M>expor.c
M>expor.c(3) : error C2059: syntax error : 'string'

Ну и что ты этим сказать хотел?
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: Аноним  
Дата: 31.08.03 11:30
Оценка:
Здравствуйте, Igor Trofimov, Вы писали:

iT>Боюсь, ты меня с кем-то путаешь


Ты был в феврале с Лёхой на чтениях али нет? — проверка
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 01.09.03 05:03
Оценка:
Здравствуйте, mihailik, Вы писали:

M>В Дельфи принято исправлять ошибки компиляции в таком режиме. Компилируем, IDE выбрасывает курсор на первую ошиюку. Исправляем — и опять компилируем. Курсор на следующей ошибке.


M>Это получается ровно столько же по времени, как и просто для перехода к следующей ошибке.


M>Такая вот скорость компиляции. Это тебе не полсекунды, это просто моментально.


Вообще-то VS долго компилирует и безошибочный проект. А выдеть 100 ошибок на экране, которые на самом деле вызваны 1-й(самой первой) не вижу смысла. Кстати, Delphi выкидывает на первую, но если внимательно посмотреть, то внизу и все другие написаны так же как в VS.
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 01.09.03 05:19
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Здравствуйте, DOOM, Вы писали:


DOO>>Здравствуйте, elmm_, Вы писали:



_>>>Вобщем делфи штука не плохая, но у C++ (VS) охватываемое поле деятельности куда шире, где-то они пересикаются где-то нет. Все что можно сделать на делфе можно повторить на C++, наоборот вряд ли...


DOO>>Пример, пожалуйста.


_O_>Не видел ни одного промышленного CAD/CAM/CASE средства, ориентированного на разработку софта для real-time и embedded систем (и для разработки самих систем), которое бы было сделано на Delphi.


Это не значит, что это нельзя сделать. Я считаю, что было проще разработать такое средство на Delphi
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 01.09.03 05:24
Оценка:
Здравствуйте, centurn, Вы писали:


_>>>Вобщем делфи штука не плохая, но у C++ (VS) охватываемое поле деятельности куда шире, где-то они пересикаются где-то нет. Все что можно сделать на делфе можно повторить на C++, наоборот вряд ли...

DOO>>Пример, пожалуйста.

C>Чтобы особо не фантазировать, спрошу, ты драйверов/операционок много на Делфах написанных видел? А 3D шутеров каких-нить? Знаю, что последнее можно, но какой ценой...


Но написать-то можно! Да пол Дельфи нет DDK, но он и существует только под VS.
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 01.09.03 05:50
Оценка:
Здравствуйте, jhfrek, Вы писали:

J>Здравствуйте, mister-AK, Вы писали:


MA>>Здравствуйте, jhfrek, вы писали:

J>>>А... Сэмулируй мне, плеазе, друзей на Дельфях. Страдаю без них жутко...
MA>>ну да, и Protect виден только в рамках одного unit

J>А это вообще засада... Напишешь obj.FValue := ... вместо obj.Value := ... и кирдык всему тому что должно происходить внутри SetValue. А компилятор, зараза, не обругает...


warning скажет! Сделай warnings as errors раз так жить проще.
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 01.09.03 07:28
Оценка:
Здравствуйте, DOOM, Вы писали:


_O_>>Не видел ни одного промышленного CAD/CAM/CASE средства, ориентированного на разработку софта для real-time и embedded систем (и для разработки самих систем), которое бы было сделано на Delphi.


DOO>Это не значит, что это нельзя сделать. Я считаю, что было проще разработать такое средство на Delphi



Угу, как говорится, флаг вам в руки.
Отсутствие множественного наследования и шаблонов ( smartpointer-ы здесь ОЧЕНЬ нужны) приведут к огромным проблемам при реализации внутреннего представления для модели.
Никто не говорит, что нельзя. Можно, но не эффективно и долго.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 01.09.03 10:45
Оценка:
C>>Чтобы особо не фантазировать, спрошу, ты драйверов/операционок много на Делфах написанных видел? А 3D шутеров каких-нить? Знаю, что последнее можно, но какой ценой...
DOO>Но написать-то можно! Да пол Дельфи нет DDK, но он и существует только под VS.

Ты сам-то хоть представляещь себе шутер, написАнный на Делфях? Я говорю, что можно, но только можно ли всерьез воспринимать такую возможность? Кстати, я именно про шутер — какую-нить турновую стратегию довольно нормально можно сделать... А драйвера и операционки тоже на Делфях писАть будем...
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 02.09.03 05:59
Оценка:
Здравствуйте, centurn, Вы писали:

C> Ты сам-то хоть представляещь себе шутер, написАнный на Делфях? Я говорю, что можно, но только можно ли всерьез воспринимать такую возможность? Кстати, я именно про шутер — какую-нить турновую стратегию довольно нормально можно сделать... А драйвера и операционки тоже на Делфях писАть будем...


Разница-то в чем??? Я на Дельфи не только "окошки с клиентами БД" писал. Я, например, писал полноценный сканер портов(ничем не хуже nmap'а) и NetBios сканнер. И утверждаю, что это намного проще чем на сях!
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 02.09.03 08:33
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, centurn, Вы писали:



DOO>Разница-то в чем??? Я на Дельфи не только "окошки с клиентами БД" писал. Я, например, писал полноценный сканер портов(ничем не хуже nmap'а) и NetBios сканнер. И утверждаю, что это намного проще чем на сях!


Попробуй реализовать внутренние представление для UML 2.0 мета(и мета-мета)модели на Delphi. (~1500 классов).



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 02.09.03 15:28
Оценка:
J>А... Сэмулируй мне, плеазе, друзей на Дельфях. Страдаю без них жутко...

Френдов-то? Да там все, кто внутри одного файла — френды.
... << RSDN@Home 1.1 beta 1 >>
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 02.09.03 15:52
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Френдов-то? Да там все, кто внутри одного файла — френды.

Плохо. Френдом должен быть только тот кого френдом назвали, а не все в одном модуле.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 03.09.03 06:43
Оценка:
DOO>А как же например, работа с сетью? Написать сервер на Дельфи раз плюнуть.
DOO>Написать многопотоковое приложение тоже очень просто.

Наш подход Давай, переходи на дотнет. Тут вообще всё легко делается.
... << RSDN@Home 1.1 beta 1 >>
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 03.09.03 06:43
Оценка:
M>>В Дельфи принято исправлять ошибки компиляции в таком режиме. Компилируем, IDE выбрасывает курсор на первую ошиюку. Исправляем — и опять компилируем. Курсор на следующей ошибке.

M>>Это получается ровно столько же по времени, как и просто для перехода к следующей ошибке.


M>>Такая вот скорость компиляции. Это тебе не полсекунды, это просто моментально.


DOO>Вообще-то VS долго компилирует и безошибочный проект.


Так я же и говорю — в Дельфи скорость компиляции примерно такая же, как пару раз нажать стрелочку вниз. Даже C# до этой скорости далеко. А уж C++ ни в жизнь не догонит.
... << RSDN@Home 1.1 beta 1 >>
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 03.09.03 08:17
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Запускаю компилироваться — не работает.

Заходишь в студию, создаешь пустой Win32 DLL проект, создаешь cpp фаил, копируешь туда.
M>Наверное, там ещё кучу всяких makefile и т.п. нужно? Вот так я о том и говорю.
Все делает студия. Да и дельфя тоже проектные файлы генерит.

M>И всё, ни тебе препроцессорных директив, ни тебе двойных подчёркиваний, ни даже поганенькой ссылки на подключаемые модули. Текст прозрачен и чист, просто хоть в рамочку бери. На C++ так безмятежно не покодируешь.

Вот только когда появляется необходимость в обобщенных контейнерах, в обобщенных алгоритмах, сильных и слабых ссылках,... без оверхеда и со сторогим контолем типов.
Тогда в дельфе начинается ад, а в С++ нирвана. Не веришь? Нука изобрази мне обобщенную сортировку на дельфях. На С++ смотри std::sort. Или сильные и слабые ссылки см boost::shared_ptr и boost::weak_ptr. И многое другое.

А то что ты написал это из серии begin end vs {}...
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 03.09.03 09:39
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>Попробую ответить на основные претензии к Delphi.


FWP>М.б. мы их просто не знаем. Но к примеру значительная часть бортовой математики для космоса и военной авиации у нас была написана на Modula2. А это ведь ближе к Delphi, чем к С++.


Delphi — это IDE+VCL+компилятор + etc.
Так вот, конкретно сам язык ObjectPascal толком не стандартизирован, меняется от версии к версии и в общем и целом не нацелен на одиночное использование. (Помимо этого с переносимостью проблемы есть.)


Я знаю, кстати, один промышленный кодогенератор в С который сам написан на какой-то странной разновидности Паскаля (эта разновидность есть смешение Паскаля и С, там есть, к примеру, препроцессор как в С). Не знаю чем был в свое время обусловлен данный выбор, но есть подозрение, что тот проект просто начинался в академической среде, склонной к использованию соответствующих языков.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[13]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 03.09.03 10:26
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>-На Delphi нет STL

FWP>Сдается мне, что в абревиатуре STL буквочка L обозначает LIBRARY.
Сдается мне что ты не представляешь себе что такое STL и почему при всем жилание ее нельзя написать на дельфе.
Подсказка: standard template library
К томуже STL это фактически часть языка.
FWP>Ну и кто вам сказал, что для Delphi нет соответствующих библиотек.
Нет и быть не может.
FWP>Другое дело, что STL явлется стандартом для С++, а для Delphi библиотеки пишутся третьими фирмами и их еще нужно искать .
Еслиб фирмами, а то в подавляющем большинстве студентами.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 03.09.03 12:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Сдается мне что ты не представляешь себе что такое STL и почему при всем жилание ее нельзя написать на дельфе.

А кто говорил, что нужно повторить STL? Нужно предоставить функциональность. А шаблоны для Delphi есть. Не знаю уж насколько хороши. Не люблю я их. Даже в C++.

WH>Подсказка: standard template library

WH>К томуже STL это фактически часть языка.
Это я отметил.

FWP>>Ну и кто вам сказал, что для Delphi нет соответствующих библиотек.

WH>Нет и быть не может.
Это уже обсудили

FWP>>Другое дело, что STL явлется стандартом для С++, а для Delphi библиотеки пишутся третьими фирмами и их еще нужно искать .

WH>Еслиб фирмами, а то в подавляющем большинстве студентами.
Хороший аргумент. Неотразимый
Re[14]: По просьбам трудящихся: Delphi vs C++(VS)
От: Dimonka Верблюд  
Дата: 03.09.03 13:36
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, FWP, Вы писали:


FWP>>-На Delphi нет STL

FWP>>Сдается мне, что в абревиатуре STL буквочка L обозначает LIBRARY.
WH>Сдается мне что ты не представляешь себе что такое STL и почему при всем жилание ее нельзя написать на дельфе.
WH>Подсказка: standard template library
WH>К томуже STL это фактически часть языка.
FWP>>Ну и кто вам сказал, что для Delphi нет соответствующих библиотек.
WH>Нет и быть не может.
FWP>>Другое дело, что STL явлется стандартом для С++, а для Delphi библиотеки пишутся третьими фирмами и их еще нужно искать .
WH>Еслиб фирмами, а то в подавляющем большинстве студентами.

Что ж в этом STL такого, чего на Delphi не досягаемо?
По-моему некоторые библиотеки вообще не имеют реальных аналогов и написаны на чистом паскале/BCB коде к тому же далеко не студентами. Например компоненты у DeveloperExpress. Сейчас они делают примерно то же под .NET.
У нас на фирме была написана программа по статистической симуляции болезни диабетом. В моём случае переход на Delphi был идеальным решением после MFC и VC++ (до этого она была написана каким-то американцем). Подобных программ в мире совсем немного и у нашей программы можно смело сказать самый юза-френдли интерфейс. Может это и частный случай использования Delphi, но вполне оправданный.
Re[15]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 03.09.03 15:36
Оценка:
Здравствуйте, Dimonka, Вы писали:

FWP>>>-На Delphi нет STL

D>Что ж в этом STL такого, чего на Delphi не досягаемо?
Нука изобрази аналог на дельфях.
int main()
{
    enum{N=100};
    int int_arr[N];
    float float_arr[N];
    double double_arr[N];
    std::string string_arr[N];
    //....
    std::sort(int_arr, int_arr+N);
    std::sort(float_arr, float_arr+N);
    std::sort(double_arr, double_arr+N);
    std::sort(string_arr, string_arr+N);
    return 0;
}

Заметь объекты разного размера и природы. А тагже мы не получаем никакого оверхеда.
Еще сюда
Автор: WolfHound
Дата: 28.08.03
глянь.
И это только цветочки...
D>По-моему некоторые библиотеки вообще не имеют реальных аналогов и написаны на чистом паскале/BCB коде к тому же далеко не студентами. Например компоненты у DeveloperExpress. Сейчас они делают примерно то же под .NET.
Что? GC? Reflection? Runtime code generation? Или ты говоришь что окошки похожи?
D>У нас на фирме была написана программа по статистической симуляции болезни диабетом. В моём случае переход на Delphi был идеальным решением после MFC и VC++ (до этого она была написана каким-то американцем). Подобных программ в мире совсем немного и у нашей программы можно смело сказать самый юза-френдли интерфейс. Может это и частный случай использования Delphi, но вполне оправданный.
Ну окошки на дельфе рисовать это нормально но писать логику
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 03.09.03 15:36
Оценка:
Здравствуйте, FWP, Вы писали:

WH>>Сдается мне что ты не представляешь себе что такое STL и почему при всем жилание ее нельзя написать на дельфе.

FWP>А кто говорил, что нужно повторить STL? Нужно предоставить функциональность.
Ну предоставь Кое о чем я уже говорил.
FWP>А шаблоны для Delphi есть. Не знаю уж насколько хороши.
Если ты про ту шутку которая на королевстве описана то это даже до препроцессора недотягивает.
FWP>Не люблю я их. Даже в C++.
Просто не знаешь.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 04.09.03 04:47
Оценка:
Здравствуйте, FWP, Вы писали:

WH>>Ну предоставь Кое о чем я уже говорил.

FWP>Если ты об этом:
[]
FWP>то все просто. Берем библиотеку, в которой реализована сортировка для этих типов и все.
Я же говорю что не предстовляешь что такое STL. std::sort реализована для ЛЮБЫХ типов у которых определен оператор <, а если хочешь отсортировать типы для которых не определен < просто пишешь свой компатор и все.

FWP>>>Не люблю я их. Даже в C++.

WH>>Просто не знаешь.
FWP>Имею представление. Но не нравятся они мне. М.б. потому, что приходится использовать BCB. А это такая глючность
Поверь так говорят очень многие но большенство знают только поверхность, а реально знают очень не многие.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 04.09.03 09:21
Оценка:
Здравствуйте, Dimonka, Вы писали:

D>Сортировка, это конечно замечательно, но не так критично.

Если ты считаешь что в STL есть только сортировка то ты ошибаешься.
STL это набор базовых алгоритмов и структур данных которых хватает на 99% случаев.
WH>>Что? GC? Reflection? Runtime code generation? Или ты говоришь что окошки похожи?
D>А логика на Дельфи выглядит, имхо, гораздо более читаемо, чем на Си++, а это тоже немаловажно.
Во первых не уходи от вопроса.
Во вторых нука приведи кусок кода не дельфях, а я посмотрю...
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 04.09.03 10:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, mihailik, Вы писали:


M>>Френдов-то? Да там все, кто внутри одного файла — френды.

WH>Плохо. Френдом должен быть только тот кого френдом назвали, а не все в одном модуле.
Это тоже из серии begin end vs {}. Кстати begin end прикольнее
Поскольку неприкольно описывать 10-ок функций друзьями для объекта. Проще их скидать в один файл.



По поводу STL. Ну сдох у меня дома CD-ROM, Дельфу не могу поставить и что-нибудь изобразить. Но ведь сам должен понимать, что используя указатели можно создать контейнер для произвольного типа данных, что используя функции сравнения можно отсортировать/найти элемент за log в массиве с любыми элементами. С ними же можно реализовать произвольный map. ЕДИНСТВЕННЫЙ минус это функции сравнения вместо перегруженных операторов. Но это тоже не принципиально.


P.S. И где это встречаются программы с такой хитрой логикой? Что прям таки 99% времени на реализауию подобных конструкций уходит?
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 04.09.03 14:51
Оценка:
M>>Френдов-то? Да там все, кто внутри одного файла — френды.

WH>Плохо. Френдом должен быть только тот кого френдом назвали, а не все в одном модуле.


Конечно плохо. Это компромисс между простотой и изощрённостью. Плохо в одном аспекте — хорошо в другом.

В C++ можно много чего хитромудрого наворотить, только вот простоты в нём маловато. И человеку с этим синтаксисом нелегко, и компилятор долго колдует.

Конечно, есть люди, которым по долгу службы приходится на ассемблере писать. Слава богу, я к таким не принадлежу.
... << RSDN@Home 1.1 beta 1 >>
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 04.09.03 14:51
Оценка:
C>> А драйвера и операционки тоже на Делфях писАть будем...

DOO>Разница-то в чем??? Я на Дельфи не только "окошки с клиентами БД" писал.


Дельфи-компилятор может генерировать только PE-формат на выходе. Это значит EXE или DLL. У файлов драйверов другой формат.

Соответственно, на Дельфи по любому драйвер не напишешь
... << RSDN@Home 1.1 beta 1 >>
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sergey Россия  
Дата: 04.09.03 15:12
Оценка:
Hello, mihailik!
You wrote on Thu, 04 Sep 2003 14:51:07 GMT:

m> Дельфи-компилятор может генерировать только PE-формат на выходе. Это

m> значит EXE или DLL. У файлов драйверов другой формат.

Этим вообще-то линкер занимается.

m> Соответственно, на Дельфи по любому драйвер не напишешь


Ну если MS'овским editbin OMF'ные объектники конвертнуть в COFF, а потом MS'овским же линкером попробовать собрать LE — может и получится. Хотя пробовать надо, конечно

Best regards,
Sergey.
Posted via RSDN NNTP Server 1.7 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 04.09.03 15:32
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>По поводу STL. Ну сдох у меня дома CD-ROM, Дельфу не могу поставить и что-нибудь изобразить. Но ведь сам должен понимать, что используя указатели можно создать контейнер для произвольного типа данных, что используя функции сравнения можно отсортировать/найти элемент за log в массиве с любыми элементами. С ними же можно реализовать произвольный map. ЕДИНСТВЕННЫЙ минус это функции сравнения вместо перегруженных операторов. Но это тоже не принципиально.

Вот только у тебя там все будет в злых кастах следовательно не типобезопасно следовательно куча ошибок....
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 04.09.03 16:17
Оценка:
M>>Запускаю компилироваться — не работает.
WH>Заходишь в студию, создаешь пустой Win32 DLL проект, создаешь cpp фаил, копируешь туда.

M>>Наверное, там ещё кучу всяких makefile и т.п. нужно? Вот так я о том и говорю.

WH>Все делает студия. Да и дельфя тоже проектные файлы генерит.

Ничего Дельфи не создаёт. Проект — этот файл на паскале, к примеру тот, что я привёл. Ну, когда формы используются ещё есть DFM.

А в этом случае просто берёшь тот текстик, что я накропал и вызываешь ему "dcc32 myfile.pas". Без всякой среды скоренько компилируется в добротную небольшую DLL.

M>>И всё, ни тебе препроцессорных директив, ни тебе двойных подчёркиваний, ни даже поганенькой ссылки на подключаемые модули. Текст прозрачен и чист, просто хоть в рамочку бери. На C++ так безмятежно не покодируешь.


WH>Вот только когда появляется необходимость в обобщенных контейнерах, в обобщенных алгоритмах, сильных и слабых ссылках,... без оверхеда и со сторогим контолем типов.

WH>Тогда в дельфе начинается ад, а в С++ нирвана. Не веришь? Нука изобрази мне обобщенную сортировку на дельфях. На С++ смотри std::sort.

Что есть обобщённая сортировка? TList.Sort, насколько я помню, всё отлично сортировал при помощи пользовательской реализации сравнения.

WH>Или сильные и слабые ссылки см boost::shared_ptr и boost::weak_ptr. И многое другое.


"И многое другое" — это да, тут ты прав. В каждом языке есть своё "многое другое". Но в данном случае я говорил о читабельности и простоте кодирования.

WH>А то что ты написал это из серии begin end vs {}...


Не совсем. Посмотри, сколько в твоём сишном коде "мусорных" словечек типа __declspec или #define. В конце концов те же LPVOID. А код на Дельфе читается без напряга. Каждое слово обозначает именно то, что подразумевается по названию.
... << RSDN@Home 1.1 beta 1 >>
Re[16]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 04.09.03 16:17
Оценка:
WH>Нука изобрази аналог на дельфях.
WH>
WH>    std::sort(int_arr, int_arr+N);
WH>    std::sort(float_arr, float_arr+N);
WH>    std::sort(double_arr, double_arr+N);
WH>    std::sort(string_arr, string_arr+N);
WH>    return 0;
WH>}
WH>


Я вот не знаком с std::sort. Что такое этот код?

Сортировка и в Дельфи есть. Если нужно сортировать объекты некоторого типа, пишем функцию сравнения — и передаём задачу в функции стандартной библиотеки.

Если ты имеешь ввиду именно простую форму записи, тогда да. В этом случае запись на C++ действительно компактнее и проще. Но это частный случай, в реальных программах сишный код наоборот очень забористый.

WH>Заметь объекты разного размера и природы. А тагже мы не получаем никакого оверхеда.


В Дельфе тоже никакого оверхеда. Разве что, возможно, лишний уровень indirection, который в случае с шаблонами, возможно, компилятор исключит.

Ну, это оверхед просто гигантский. Особенно будет заметно на реальных задачах.

WH>Ну окошки на дельфе рисовать это нормально но писать логику


Да уж, логику-то точно в сях писать хреново. Кто потом её читать будет, эту вот логику?

На сях нужно системные примочки делать, всякие критичные места. А логику нужно делать на таком языке, чтоб любой чужой человек прочитал с листа. К примеру, C#, Дельфи. На худой конец, VB.
... << RSDN@Home 1.1 beta 1 >>
Re[18]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 04.09.03 16:17
Оценка:
D>>Сортировка, это конечно замечательно, но не так критично.

WH>Если ты считаешь что в STL есть только сортировка то ты ошибаешься.

WH>STL это набор базовых алгоритмов и структур данных которых хватает на 99% случаев.

99% случаев чего?

Если тебя послушать, получается Дельфёвый софт можно сократить в сто раз, введи Борланд в Дельфю шаблоны?
... << RSDN@Home 1.1 beta 1 >>
Re[18]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 04.09.03 16:17
Оценка:
WH> а если хочешь отсортировать типы для которых не определен < просто пишешь свой компатор и все.

Во-во. То же, что и в Дельфи.

Как будто трудно сделать сортировку на компараторах без шаблонов. Бедные явщики, мучаются
... << RSDN@Home 1.1 beta 1 >>
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 04.09.03 16:17
Оценка:
M>>Так я же и говорю — в Дельфи скорость компиляции примерно такая же, как пару раз нажать стрелочку вниз. Даже C# до этой скорости далеко. А уж C++ ни в жизнь не догонит.

VD>Ну, ну. У нас был проектик который компилировался минуту. Отлаживаться было очень не комфортно.


Вот оно, преимущество компилятора Дельфи в чистом виде.

Старый Дельфист, покопавшись в памяти, вспомнил проект, который компилировался аж МИНУТУ!
... << RSDN@Home 1.1 beta 1 >>
Re[12]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 04.09.03 16:57
Оценка:
m>> Дельфи-компилятор может генерировать только PE-формат на выходе. Это
m>> значит EXE или DLL. У файлов драйверов другой формат.

S>Этим вообще-то линкер занимается.


Это в сях — линкер. Устарелая технология.

А в Дельфе никакого линкера нету, тут всё сплошной компилятор делает.

m>> Соответственно, на Дельфи по любому драйвер не напишешь


S>Ну если MS'овским editbin OMF'ные объектники конвертнуть в COFF, а потом MS'овским же линкером попробовать собрать LE — может и получится. Хотя пробовать надо, конечно


Тогда уж лучше "голову" драйвера сделать на сях, а остальное грузить DLL-кой. Загрузить, проинициализировать и в памяти закрепить, чтоб не дай бог не свопанулось.

Хотя всё равно это фигня. Не Дельфёвое это дело — драйвера писать.
... << RSDN@Home 1.1 beta 1 >>
Re[19]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 04.09.03 16:59
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Как будто трудно сделать сортировку на компараторах без шаблонов. Бедные явщики, мучаются


type
    my_cool_type=record
        w:word;
        r1, r2, r3:real;
        b:byte;
    end;
var
    arr_of_integer:array[0..4] of integer;
    arr_of_extended:array[0..7] of extended;
    arr_of_string:array[0..5] of string;
    arr_of_real:array[0..6] of real;
    arr_of_my_cool_type:array[0..7] of my_cool_type;
begin
{заполнили}
{А тут попрошу отсортировать.}
end.

Ты от ответа не уходи ты функцию напиши. Пусть для каждого типа придется писать компатор это ерунда ты напиши сортировку для любых массивов.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 04.09.03 16:59
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Да уж, логику-то точно в сях писать хреново. Кто потом её читать будет, эту вот логику?

Ты мне это не втирай ладно. Я на паскакале и дельфях кучу кода написал.
Отсутствие автоматических объектов превращает жизнь в ад вернее в try finaly что тоже самое.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.09.03 00:48
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Старый Дельфист, покопавшись в памяти, вспомнил проект, который компилировался аж МИНУТУ!


Если бы ты был в досягаемости программистов которым приходилось мучится с этим, то в живых бы ты не остался.

На С++ компиляция может идти и долше. Но там 1) ошибки выдавали залпом, 2) был рогресс компиляции (а на дельфи он появился позже), 3) небыло психологического привыкания к такому долгому процессу компиляции.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 05.09.03 04:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Ты мне это не втирай ладно. Я на паскакале и дельфях кучу кода написал.


    arr_of_real:array[0..6] of real;

По этой строке это особенно заметно.

WH>Отсутствие автоматических объектов превращает жизнь в ад вернее в try finaly что тоже самое.

Борьба с неопределенным поведением автоматических объектов ничем ни лучше. Читай вашего любимого классика Б.Страуструпа.
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 05.09.03 04:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>На С++ компиляция может идти и долше. Но там 1) ошибки выдавали залпом, 2) был прогресс компиляции (а на дельфи он появился позже), 3) небыло психологического привыкания к такому долгому процессу компиляции.

1) На Delphi ошибки "выдаются залпом" с первой версии.
2) Прогресс компиляции существует с первой версии.
3) Это я чего-то недопонял
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 05.09.03 04:45
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:


DOO>>По поводу STL. Ну сдох у меня дома CD-ROM, Дельфу не могу поставить и что-нибудь изобразить. Но ведь сам должен понимать, что используя указатели можно создать контейнер для произвольного типа данных, что используя функции сравнения можно отсортировать/найти элемент за log в массиве с любыми элементами. С ними же можно реализовать произвольный map. ЕДИНСТВЕННЫЙ минус это функции сравнения вместо перегруженных операторов. Но это тоже не принципиально.

WH>Вот только у тебя там все будет в злых кастах следовательно не типобезопасно следовательно куча ошибок....

Проблема с типобезопасностью возникнет только с record'ами.
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 05.09.03 04:59
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Проблема с типобезопасностью возникнет только с record'ами.

А на С++ она вобще не возникает.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 05.09.03 05:05
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>
FWP>    arr_of_real:array[0..6] of real;
FWP>

FWP>По этой строке это особенно заметно.
Может просветишь?
Из хелпа к билдеру
Delphi    Size/Values    C++ implementation    Implementation

ShortInt    8-bit integer    signed char    typedef
SmallInt    16-bit integer    short    typedef
LongInt    32-bit integer    int    typedef
Byte    8-bit unsigned integer    unsigned char    typedef
Word    16-bit unsigned integer    unsigned short    typedef
Integer    32-bit integer    int    typedef
Cardinal    32-bit unsigned integer    unsigned int    typedef
Boolean    true/false    bool    typedef
ByteBool    true/false or 8-bit unsigned integer    unsigned char    typedef
WordBool    true/false or 16-bit unsigned integer    unsigned short    typedef

LongBool    true/false or 32-bit unsigned integer    BOOL (WinAPI)    typedef
AnsiChar    8-bit unsigned character    char    typedef
WideChar    word-sized Unicode character    wchar_t    typedef
Char    8-bit unsigned character    char    typedef
AnsiString    Delphi AnsiString    AnsiString    class
String[n]    old style Delphi string, n = 1..255 bytes    SmallString<n>    template class
ShortString    old style Delphi string, 255 bytes    SmallString<255>    typedef
String    Delphi AnsiString    AnsiString    typedef

Single    32-bit floating point number    float    typedef
Double    64-bit floating point number    double    typedef
Extended    80-bit floating point number    long double    typedef
Real    32-bit floating point number    double    typedef
Pointer    32-bit generic pointer    void *    typedef
PChar    32-bit pointer to characters    unsigned char *    typedef
PAnsiChar    32-bit pointer to ANSI characters    unsigned char *    typedef
Comp    64-bit floating point number    Comp    class
OleVariant    OLE variant value    OleVariant    class



WH>>Отсутствие автоматических объектов превращает жизнь в ад вернее в try finaly что тоже самое.

FWP>Борьба с неопределенным поведением автоматических объектов ничем ни лучше. Читай вашего любимого классика Б.Страуструпа.
Каким не определенным поведением? Нука обьясни.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: По просьбам трудящихся: Delphi vs C++(VS)
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.09.03 07:07
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>1) На Delphi ошибки "выдаются залпом" с первой версии.


Сказки расказываем в милиции. Первая дельфи ошбки по одной отплевывала.

FWP>2) Прогресс компиляции существует с первой версии.


Вот тут уже не помню. Но по умолчанию во всех версиях выключено.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 05.09.03 07:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Сказки расказываем в милиции. Первая дельфи ошбки по одной отплевывала.

М.б. Теперь 95й год трудно вспомнить. Но отложилось в памяти,что Delphi ошибки вываливала не так как TP/BP. Вот они точно по одной.

VD>Вот тут уже не помню. Но по умолчанию во всех версиях выключено.

Это да.
Re[20]: По просьбам трудящихся: Delphi vs C++(VS)
От: Dimonka Верблюд  
Дата: 05.09.03 07:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, FWP, Вы писали:


FWP>>[code]


WH>Single 32-bit floating point number float typedef

WH>Double 64-bit floating point number double typedef
WH>Extended 80-bit floating point number long double typedef
WH>Real 32-bit floating point number double typedef
WH>[/ccode]

Насколько я помню, тип Real остался для совместимости со старыми версиями Delphi (2,3,4?), Borland рекомендует пользоваться обьявлениями типа Single и Double..
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.09.03 08:11
Оценка:
Здравствуйте, mihailik, Вы писали:

S>> Да и Delphi для Net изначально лучше всех подходит под Net.


M>Это что значит? Delphi.NET лучше подходит для .NET, чем C#?


M>Неправда.

Очень даже правда и любой Дельфист это скажет перешедший или изучающий Net. Подождем Delphi.Net и тогда уж сравним с C# ( уже по анонсам много интересного и много отличного от C#) Хотя это два языка Брата и родитель у них один Андреас Хейлсберг. Прошу не обижаться поклонников Вирта (я сам его поклонник).
http://sumdu.edu.ua/~chekalov/teach/net_is_borland03.htm
и солнце б утром не вставало, когда бы не было меня
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 05.09.03 08:23
Оценка:
Здравствуйте, Lloyd, Вы писали:


L>Было бы удивительно, если бы они ее написали в 70-ых на С++, которого тогда еще не было.


И современные разработки продолжают вести на C. И вообще все unix'оиды не признают C++, нас препод долго обсмеивал за то, что на парах по Linux'у мы пытались писать программки с использованием new и т.п. И утверждал при этом, что лишь С достоин существования. Вот так.
Re[21]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 05.09.03 08:32
Оценка:
Здравствуйте, FWP, Вы писали:

WH>>Каким не определенным поведением? Нука обьясни.

FWP>Пожалуйста:
FWP>И такими перлами эта книга прямо напичкана под завязку.
Вот только не надо путать кривизну рук с неопределенным поведением.
Тут все четко и понятно. Все определено все действия предсказуемы.
Нужно всеголишь описать конструктор копирования и копиующие присваивание.
Этот пример был дан как предостережение и не болие того.
И вобще std::stack никто не отменял.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 05.09.03 08:41
Оценка:
Здравствуйте, Dimonka, Вы писали:

D>Насколько я помню, тип Real остался для совместимости со старыми версиями Delphi (2,3,4?), Borland рекомендует пользоваться обьявлениями типа Single и Double..

Может и так я этим не интересовался. Просто продолжал писать по инерции после перехода с багланд паскакаля.

Дык конибудь покажите мне уневерсальную сортировку на паскакале. Пусть жаде придеться писать коматоры. Слабо?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 05.09.03 08:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:


DOO>>И современные разработки продолжают вести на C. И вообще все unix'оиды не признают C++, нас препод долго обсмеивал за то, что на парах по Linux'у мы пытались писать программки с использованием new и т.п. И утверждал при этом, что лишь С достоин существования. Вот так.

WH>Давай его сюда. Сначала я ему обьясню почему С++ круче чем С, а потом Влад и AVK почему надо все бросать и писать на C#.

И тем самым уподобитесь тому же преподу
Есть задачи, где С — оптимален. (например decode/encode для ASN.1)



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[22]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sergey Россия  
Дата: 05.09.03 09:09
Оценка:
Hello, WolfHound!
You wrote on Fri, 05 Sep 2003 08:41:33 GMT:

W> Дык конибудь покажите мне уневерсальную сортировку на паскакале.

W> Пусть жаде придеться писать коматоры. Слабо?


Да так же как на C, наверное. Указатели там вроде были, указатели на функции я в дельфах точно ни разу не использовал, но наверно тоже были, а там и qsort наваять недолго.

Best regards,
Sergey.
Posted via RSDN NNTP Server 1.7 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 05.09.03 09:39
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, WolfHound, Вы писали:


WH>>Здравствуйте, FWP, Вы писали:


DOO>1-е Какого черта пости для каждого объекта я должен писать такую тучу конструкторов.



Программирование есть занятие вообще сложное, нудное, много рутины, так что если выбрать себе иную профессию, то работать станет вдвойне приятней



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[14]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 05.09.03 10:07
Оценка:
Здравствуйте, FWP, Вы писали:

VD>>Сказки расказываем в милиции. Первая дельфи ошбки по одной отплевывала.

FWP>М.б. Теперь 95й год трудно вспомнить. Но отложилось в памяти,что Delphi ошибки вываливала не так как TP/BP. Вот они точно по одной.

16-битный компилятор первой дельфи был развитием bp7. Посмотри глазами bpc.exe и dcc.exe — они очень похожи.
Re[14]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 05.09.03 10:09
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Есть задачи, где С — оптимален. (например decode/encode для ASN.1)


Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.
Re[22]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 05.09.03 10:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Каким не определенным поведением? Нука обьясни.

FWP>>Пожалуйста:
FWP>>И такими перлами эта книга прямо напичкана под завязку.
WH>Вот только не надо путать кривизну рук с неопределенным поведением.
WH>Тут все четко и понятно. Все определено все действия предсказуемы.
WH>Нужно всеголишь описать конструктор копирования и копиующие присваивание.
WH>Этот пример был дан как предостережение и не болие того.
WH>И вобще std::stack никто не отменял.
Да в том и дело, что по всей книге таких "предостережений" десятки, если не сотни.
Почему лично я предпочитаю виртовские языки заместо Сиплюхплюха, так это потому, что мне не надо помнить сотни всяких исключений из правил. В этом смысле даже С более безопасен, чем С++. Если конечно не извращаться с адресной арифметикой.
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sergey Россия  
Дата: 05.09.03 10:27
Оценка:
Hello, DOOM!
You wrote on Fri, 05 Sep 2003 09:06:37 GMT:

WH>>>> Каким не определенным поведением? Нука обьясни.

FWP>>> Пожалуйста:
FWP>>> И такими перлами эта книга прямо напичкана под завязку.
WH>> Вот только не надо путать кривизну рук с неопределенным поведением.
WH>> Тут все четко и понятно. Все определено все действия предсказуемы.
WH>> Нужно всеголишь описать конструктор копирования и копиующие
WH>> присваивание. Этот пример был дан как предостережение и не болие того.
WH>> И вобще std::stack никто не отменял.

D> 1-е Какого черта пости для каждого объекта я должен писать такую тучу

D> конструкторов.

Потому что компялятор генерит конструктор копирования и оператор присваиваивания с "неглубокой" семантикой копирования (почленное копирование), и если тебе нужна другая семантика для операций копирования, то приходится этот факт отражать в коде явно.

D> 2-е Почему в объекте сыне я могу вызвать конструктор

D> родителя только перед выполнением своего конструктора.

Потому что кое-кто решил, что от этого бывает меньше всего проблем. И правильно.

Best regards,
Sergey.
Posted via RSDN NNTP Server 1.7 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[24]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 05.09.03 10:58
Оценка:
Здравствуйте, Sergey, Вы писали:


D>> 2-е Почему в объекте сыне я могу вызвать конструктор

D>> родителя только перед выполнением своего конструктора.

S>Потому что кое-кто решил, что от этого бывает меньше всего проблем. И правильно.


И почему же это правильно? Не сложно придумать ситуацию, когда это как раз таки не верно.
S>Best regards,
S> Sergey.
Re[25]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sergey Россия  
Дата: 05.09.03 11:02
Оценка:
Hello, DOOM!
You wrote on Fri, 05 Sep 2003 10:58:59 GMT:

D>>> 2-е Почему в объекте сыне я могу вызвать конструктор

D>>> родителя только перед выполнением своего конструктора.

S>> Потому что кое-кто решил, что от этого бывает меньше всего проблем. И

S>> правильно.

D> И почему же это правильно?


Потому что не следует поперек батьки в пекло лезть

D> Не сложно придумать ситуацию, когда это как раз таки не верно.


Ты придумай, а я постараюсь тебе показать, где ты неправ


Best regards,
Sergey.
Posted via RSDN NNTP Server 1.7 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 05.09.03 11:09
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>2-е Почему в объекте сыне я могу вызвать конструктор родителя только перед выполнением своего конструктора.


Родитель (а их, кстати, бывает и несколько) почти ничем не отличается от членов сына, у которых тоже надо вызвать конструкторы. В следующей серии захочется и их вызывать когда вздумается?
Re[15]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 05.09.03 11:28
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, _Obelisk_, Вы писали:

_O_>>Есть задачи, где С — оптимален. (например decode/encode для ASN.1)
_>Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.
В отпуске немного поковырялся с Linux. Посмотрел тектсты ядра, а там, какой ужас , ни шаблонов, ни классов. Значит жив курилка! В смысле голенький С. Хотя, конечно это не тот С, который был в 1972 году.
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 05.09.03 11:43
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>1-е Какого черта пости для каждого объекта я должен писать такую тучу конструкторов.

Не для каждого, а только для тех в которых ты мудришь с ресурсами. А их поверь очень мало.
Ибо нужно только один раз написать класс хозин какого либо ресурса и дальше пользоваться им.
В 99% случаев компилятор генерирует правильные конструктор копирования и копирующие присваивания.
DOO>2-е Почему в объекте сыне я могу вызвать конструктор родителя только перед выполнением своего конструктора.
Потомучно в дельфе нет конструкторов. Те то что там называется конструктором в самом деле является лиш процедурой которая вызывается после создания объекта.
DOO>3-е (к другому вопросу) Универсальная сортировка это TList.Sort.
Еще раз отсортируй мне массив.
Ы?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 05.09.03 11:48
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>Да в том и дело, что по всей книге таких "предостережений" десятки, если не сотни.

FWP>Почему лично я предпочитаю виртовские языки заместо Сиплюхплюха, так это потому, что мне не надо помнить сотни всяких исключений из правил. В этом смысле даже С более безопасен, чем С++. Если конечно не извращаться с адресной арифметикой.
Нука приведи мне хотябы десяток
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 05.09.03 11:48
Оценка:
Здравствуйте, FWP, Вы писали:

_>>Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.

FWP>В отпуске немного поковырялся с Linux. Посмотрел тектсты ядра, а там, какой ужас , ни шаблонов, ни классов. Значит жив курилка! В смысле голенький С. Хотя, конечно это не тот С, который был в 1972 году.

Кобол тоже жив. Но я все равно не понимаю, ради какой великой цели (кроме поддержки старого продукта) надо описывать переменные в начале функции, а не при первом использовании, много раз писать typedef struct structtag structname, закрывать однострочные комментарии, делать #define вместо inline и кучу других устаревших глупостей? И зачем заводить кусты функций, берущих первым параметром указатель на структуру, если синтаксис obj.fn(...) удобнее, чем fn(obj, ...) и сокращает код этой самой fn за счет избавления от кучи "this->"?
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 05.09.03 11:49
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>Здравствуйте, WolfHound, Вы писали:


WH>>Дык конибудь покажите мне уневерсальную сортировку на паскакале. Пусть жаде придеться писать коматоры. Слабо?

FWP>Ну почему ты такой упертый! Ну хорошо я повторю:
FWP>В Delphi шаблонов нет. Поэтому это сделать нельзя приемлемым для практического использования способом. Но всегда можно найти соответствующую ПРАКТИЧЕСКИМ НУЖДАМ библиотеку!
Вот только приходится использовать какойнибудь изварат типа TList либо писать ручками...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 05.09.03 12:08
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

FWP>>В отпуске немного поковырялся с Linux. Посмотрел тектсты ядра, а там, какой ужас , ни шаблонов, ни классов. Значит жив курилка! В смысле голенький С. Хотя, конечно это не тот С, который был в 1972 году.


_>Кобол тоже жив. Но я все равно не понимаю, ради какой великой цели (кроме поддержки старого продукта) надо описывать переменные в начале функции, а не при первом использовании, много раз писать typedef struct structtag structname, закрывать однострочные комментарии, делать #define вместо inline и кучу других устаревших глупостей? И зачем заводить кусты функций, берущих первым параметром указатель на структуру, если синтаксис obj.fn(...) удобнее, чем fn(obj, ...) и сокращает код этой самой fn за счет избавления от кучи "this->"?

Вы видимо плохо представляете современный ANSI C. Ничего такого писать не надо. Да и Linux назвать устаревшим продуктом — это, пожалуй слишком черезчур.
Re[24]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 05.09.03 12:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Вот только приходится использовать какойнибудь изварат типа TList либо писать ручками...

Да уж приходится. Не все ж мышкой программить . Ну и в VC тож кое-что ручками писать приходится. То что в Delphi уже есть.
Я ж согласился, что шаблонов нет и это можно с натягом считать недостатком. Но ведь как-то обходятся без них миллионы программеров на VB, Java, C#, Oberon, Ada и т.д. И мы как-нибудь
Re[18]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 05.09.03 12:19
Оценка:
Здравствуйте, FWP, Вы писали:

_>>описывать переменные в начале функции, а не при первом использовании,

_>>много раз писать typedef struct structtag structname,
_>>закрывать однострочные комментарии,
_>>делать #define вместо inline
FWP>Вы видимо плохо представляете современный ANSI C. Ничего такого писать не надо.

Пожалуйста, по пунктам, по возможности ссылаясь на стандарт. И ни слова о C99 — под "голеньким C" понимается вовсе не он, а C89.
Re[15]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 05.09.03 12:40
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, _Obelisk_, Вы писали:


_>Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.


Иногда не нужны ни виртуальные функции, ни RTTI ни даже динамическая память.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[19]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 05.09.03 12:42
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:


_>Пожалуйста, по пунктам, по возможности ссылаясь на стандарт. И ни слова о C99 — под "голеньким C" понимается вовсе не он, а C89.


Вы не сталкивались просто с разработкой под DSP, RTOS-ы и Embedded платформы.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[16]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 05.09.03 12:50
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_>>Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.

_O_>Иногда не нужны ни виртуальные функции, ни RTTI ни даже динамическая память.

То есть для таких задач не надо использовать C, потому что в нем есть malloc? Никто же не заставляет использовать ненужную функциональность, а про RTTI и exceptions, добавляющие оверхед, я уже написал двумя строками выше.
Re[20]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 05.09.03 12:57
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_>>Пожалуйста, по пунктам, по возможности ссылаясь на стандарт. И ни слова о C99 — под "голеньким C" понимается вовсе не он, а C89.

_O_>Вы не сталкивались просто с разработкой под DSP, RTOS-ы и Embedded платформы.

Разве? Пять лет мучался с ТКМ-51, где архитектура не очень-то заточена под C, даже push кладет два байта в стек в неправильном порядке. Кстати, приходилось использовать на тамошнем C структуры указателей на функции, чтобы эмулировать VMT. Или это уже на МФК...
Re[24]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.09.03 13:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:


DOO>>1-е Какого черта пости для каждого объекта я должен писать такую тучу конструкторов.

WH>Не для каждого, а только для тех в которых ты мудришь с ресурсами. А их поверь очень мало.
WH>Ибо нужно только один раз написать класс хозин какого либо ресурса и дальше пользоваться им.
WH>В 99% случаев компилятор генерирует правильные конструктор копирования и копирующие присваивания.
DOO>>2-е Почему в объекте сыне я могу вызвать конструктор родителя только перед выполнением своего конструктора.
WH>Потомучно в дельфе нет конструкторов. Те то что там называется конструктором в самом деле является лиш процедурой которая вызывается после создания объекта.
DOO>>3-е (к другому вопросу) Универсальная сортировка это TList.Sort.
WH> Еще раз отсортируй мне массив.
WH>Ы?

Вопрос тебе сортировку массивов элементарных типов или сложных структур. Иногда легче применять ссылочные массивы с функцией сравнения или при динамической сортировке применять Б деревья. Все о чем ты говришь с применением шаблонов легко решается с помощью Replace или заменой типа соответсвенно скопировав модуль и переименовав его. Не очень сложная задача. Можно вспомнить про GetIdsOfNames и Invoke, MakeCreateInstace. Несовместимост Дельфийных и Сишных классов. Суть в совместимости. И почему сишники пишут на Delphi совмещаяя с С++????? А их огромное множество.
и солнце б утром не вставало, когда бы не было меня
Re[17]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 05.09.03 13:16
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, _Obelisk_, Вы писали:


_>>>Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.

_O_>>Иногда не нужны ни виртуальные функции, ни RTTI ни даже динамическая память.

_>То есть для таких задач не надо использовать C, потому что в нем есть malloc? Никто же не заставляет использовать ненужную функциональность, а про RTTI и exceptions, добавляющие оверхед, я уже написал двумя строками выше.


Меньше функциональности — проще компилятор, зачем стрелять из пушки по воробъям ?



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[21]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 05.09.03 13:18
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Разве? Пять лет мучался с ТКМ-51, где архитектура не очень-то заточена под C, даже push кладет два байта в стек в неправильном порядке. Кстати, приходилось использовать на тамошнем C структуры указателей на функции, чтобы эмулировать VMT. Или это уже на МФК...


Есть С заточенные под архитектуру. А вообще, в данном случае лучше рассматривать С как язык кодогенерации из чего-то другого.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[22]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 05.09.03 13:34
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_>>Разве? Пять лет мучался с ТКМ-51, где архитектура не очень-то заточена под C, даже push кладет два байта в стек в неправильном порядке. Кстати, приходилось использовать на тамошнем C структуры указателей на функции, чтобы эмулировать VMT. Или это уже на МФК...

_O_>Есть С заточенные под архитектуру.

Если они держат хотя бы C89, то плюсы под эту же архитектуру затачиваются так же легко — в отсутствие exceptions вся разница только в удобстве программирования, на плюсах надо писать меньше буковок для решения той же задачи и получать более поддерживаемый и расширяемый код.

_O_>А вообще, в данном случае лучше рассматривать С как язык кодогенерации из чего-то другого.


У нас так и было. Но рантайм и драйвера к платам ввода-вывода приходилось писать, естественно, на C и ассемблере. Ассемблер оставим в покое, но в сишном коде и проявлялись все неудобства по сравнению с плюсами, на которых был написан кросс-компилятор и IDE.
Re[20]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 05.09.03 17:03
Оценка:
WH>Ты от ответа не уходи ты функцию напиши.

TList.Sort — вот эта функция.
... << RSDN@Home 1.1 beta 1 >>
Re[13]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 05.09.03 17:03
Оценка:
FWP>>1) На Delphi ошибки "выдаются залпом" с первой версии.

VD>Сказки расказываем в милиции. Первая дельфи ошбки по одной отплевывала.


В третьей точно залпом было. Правда, мало кто этим пользовался, по той причине которую я уже упоминал. Быстрее Ctrl+F9 нажать, чем табуляции да стрелочки.

FWP>>2) Прогресс компиляции существует с первой версии.


VD>Вот тут уже не помню. Но по умолчанию во всех версиях выключено.


Ага. Это точно во второй было. Включи, будь так любезен.
... << RSDN@Home 1.1 beta 1 >>
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.09.03 17:36
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>> Вопрос тебе сортировку массивов элементарных типов или сложных структур.

WH>И тех и других в одном флаконе.
S>>Иногда легче применять ссылочные массивы с функцией сравнения или при динамической сортировке применять Б деревья.
WH>Типа std::map и std::set это из другой оперы у меня есть массив хочу его отсортировать.
S>>Все о чем ты говришь с применением шаблонов легко решается с помощью Replace или заменой типа соответсвенно скопировав модуль и переименовав его. Не очень сложная задача.
WH>cope/paste это не решение это проблема.
S>>Можно вспомнить про GetIdsOfNames и Invoke, MakeCreateInstace. Несовместимост Дельфийных и Сишных классов. Суть в совместимости. И почему сишники пишут на Delphi совмещаяя с С++????? А их огромное множество.
WH>Ни чего не понял.

Что именно не понятно??? По сортировке тот же QuickSort + функция сравнения + размер записи легко решается без всяких шаблонов (см _DynArrayXXX в System). То что доступ к интерфейсам идет через процедуры а не методы объекта не есть хорошо. То есть для каждого объекта програмно в памяти создается процедура заглушка которая уже вызывает метод объекта передавая в нее данные объекта (Self). По поводу MakeObjectInstace опять для каждого экземпляра нужно городить функцию заглушку так как в API нет классов. А сишные классы не совместимы с Дельфийными. И можно сколько угодно говорить о достоинствах одного языка перед другим но если сама база трухлява ничего путного сделать нельзя.

По поводу Copy-Paste-Replace по скорости то же самое и по объему генерирумого кода. В свое время стандартном Паскале (Виртовском на ДК-2) когда не было динамических массивов итд все ограничения языка легко обходились и не вызывали как у ВАС такого раздражения.

Но меня лично до появления Net раздражало не совместимость языков. Я не думаю ( а во многих случаях знаю), что будь так плох Delphi как ВЫ говорите Сишники по каким то причинам на него переходили или совмещали два языка. В Net хоть засовмещайся и выбирай тот который более всего подходит для решения конкретной задачи.
В любом случае приходится изучать несколько Языков,хотя бы ради того что бы изучать чужой опыт.

В любом случае "КАЖДОМУ СВОЕ". И не нужно спорить и отдаляться. Все Мы выполняем одну и туже задачу только на разных языках.
и солнце б утром не вставало, когда бы не было меня
Re[21]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 05.09.03 18:52
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Ты от ответа не уходи ты функцию напиши.

M>TList.Sort — вот эта функция.
Ты ручками сортировку написать можешь?
Сортировка(на дубость алгоритма не смотрим лень было нормальный писать)
template<class Iter, class Cmp>
void select_sort(Iter begin, Iter end, const Cmp& cmp)
{
    for(;begin!=end;++begin)
    {
        Iter cur=begin, best=begin;
        for(++cur;cur!=end;++cur)
            if(cmp(*cur, *best))
                best=cur;
        if(best!=begin)
            std::iter_swap(best, begin);
    }
}
template<class Iter>
void select_sort(Iter begin, Iter end)
{
    select_sort(begin, end, std::less<typename std::iterator_traits<Iter>::value_type>());
}

Функция помошник
template<class T, size_t N>
T* end_of_array(T(&arr)[N])
{
    return arr+N;
}

Тест
//Встроеное сравнение
struct test1
{
    test1(int i)
        :i_(i)
    {}
    int i_;
    bool operator<(const test1& lhs)const
    {
        return i_<lhs.i_;
    }
};
//Внешний компатор
struct test2
{
    test2(int i)
        :i_(i)
    {}
    int i_;
};
struct test2_less
{
    bool operator()(const test2& rhs, const test2& lhs)const
    {
        return rhs.i_<lhs.i_;
    }
};
int main()
{
    std::string arr_string[]={"sdfs", "xvc", "afs", "sdf", "w3fd", "yeq"};
    int arr_int[]={12, 4, 8, 3, 5, 24, 63, 9};
    double arr_double[]={12, 4, 8, 3, 5, 24, 63, 9};
    test1 arr_test1[]={12, 4, 8, 3, 5, 24, 63, 9};
    test2 arr_test2[]={12, 4, 8, 3, 5, 24, 63, 9};
    select_sort(arr_string, end_of_array(arr_string));
    select_sort(arr_int, end_of_array(arr_int));
    select_sort(arr_double, end_of_array(arr_double));
    select_sort(arr_test1, end_of_array(arr_test1));
    select_sort(arr_test2, end_of_array(arr_test2), test2_less());
}

Изобрази тоже самое на паскакале.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 08.09.03 06:29
Оценка:
Здравствуйте, Sergey, Вы писали:


S>Ты придумай, а я постараюсь тебе показать, где ты неправ

S>Best regards,
S> Sergey.

Пожалуйста:
TAnotherClass = class(TComponent)
...
TMyClass = class(TComponent)
 constructor Create(Owner:TAnotherClass);
...

constructor TMyClass.Create(Owner:TAnotherClass)
begin
  //проверяем какие-нибудь условия на Owner'a
  ...
  if good then
   inherited Create(Owner)
end;
Re[25]: По просьбам трудящихся: Delphi vs C++(VS)
От: ArtDenis Россия  
Дата: 08.09.03 07:25
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, WolfHound, Вы писали:


WH>>Вот только приходится использовать какойнибудь изварат типа TList либо писать ручками...


DOO>А почему TList это изврат, а std::vector нет? По мне дак TList поудобнее...


Да уж, хранить указатели на объекты, когда это нафиг не нужно, конечно удобнее.

Вот прога на C++:

std::vector<double> data;
double result;

// задаём размер
data.resize(100);

// заполняем значениями
std::fill(data.begin(), data.end(), 10.0);

// суммируем
result = std::accumulate(data.begin(), data.end(), 0.0);


Всё красиво и понятно

Теперь тоже самое на Pascal'е (заранее извиняюсь за ошибки):

var
  list : TList;
  res  : double;
  ptr  : ^double;
  i    : integer;
begin
  // создаём TList
  list := TList.Create();

  // задаём размер
  list.Count := 100;

  // интциализируем
  for i := 0 to list.Count-1 do
  begin
    New(ptr);
    list.Items[i] := ptr;
  end;

  // заполняем
  for i := 0 to list.Count-1 do
  begin
    ptr := list.Items[i];
    ptr^ := 10;
  end;

  // суммируем
  res := 0;
  for i := 0 to list.Count-1 do
  begin
    ptr := list.Items[i];
    ptr^ := 10;
  end;

  // очищаем
    for i := 0 to list.Count-1 do Dispose(list.Items[i]);

  // удаляем TList
  list.destroy();


Чёрт ногу сломит. И чем же TList удобнее?

Не забывай, что кроме std::vector в STL еще есть std::deque, std::list, std::map, std::stack, std::set и т.д. Что тебе нужно, то и применяешь.


Денис.
... << RSDN@Home 1.1 beta 1 >>
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: ArtDenis Россия  
Дата: 08.09.03 07:28
Оценка:
AD>Теперь тоже самое на Pascal'е (заранее извиняюсь за ошибки):

AD>
AD>...
AD>  // суммируем
AD>  res := 0;
AD>  for i := 0 to list.Count-1 do
AD>  begin
AD>    ptr := list.Items[i];
AD>    res := res + ptr^; // вот она - ошибочка, за которую я извинился :-)
AD>  end;
AD>
... << RSDN@Home 1.1 beta 1 >>
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 08.09.03 07:57
Оценка:
Здравствуйте, ArtDenis, Вы писали:

AD>Здравствуйте, DOOM, Вы писали:


DOO>>Здравствуйте, WolfHound, Вы писали:


WH>>>Вот только приходится использовать какойнибудь изварат типа TList либо писать ручками...


DOO>>А почему TList это изврат, а std::vector нет? По мне дак TList поудобнее...


AD>Да уж, хранить указатели на объекты, когда это нафиг не нужно, конечно удобнее.


AD>Вот прога на C++:


AD>[ccode]

AD>std::vector<double> data;
AD>double result;

AD>// задаём размер

AD>data.resize(100);

AD>// заполняем значениями

AD>std::fill(data.begin(), data.end(), 10.0);

Вы всегда массив одинаковыми значениями заполняете?
std::fill — готов поспорить из memcpy слеплена. В Дельфи есть Move, Copy, FillChar


AD>Не забывай, что кроме std::vector в STL еще есть std::deque, std::list, std::map, std::stack, std::set и т.д. Что тебе нужно, то и применяешь.


А в Дельфи есть еще TStack, TQueue и т.п.

AD>Денис.
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 08.09.03 07:59
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:


DOO>>Пожалуйста:

WH>Ага проверяем параметры и если не правильные то создаем частично инициализированый объект. Очень крутая логика.

Естественно дальше предполагалось кидать Exception
Re[27]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 08.09.03 09:48
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Вы всегда массив одинаковыми значениями заполняете?

DOO>std::fill — готов поспорить из memcpy слеплена. В Дельфи есть Move, Copy, FillChar
Во первых почитай в MSDN про memcpy...
Во вторых
template<class _FwdIt,
    class _Ty> inline
    void fill(_FwdIt _First, _FwdIt _Last, const _Ty& _Val)
    {    // copy _Val through [_First, _Last)
    for (; _First != _Last; ++_First)
        *_First = _Val;
    }

А это уже вольности реализации для оптимизации.
inline void fill(char *_First, char *_Last, int _Val)
    {    // copy char _Val through [_First, _Last)
    ::memset(_First, _Val, _Last - _First);
    }

inline void fill(signed char *_First, signed char *_Last, int _Val)
    {    // copy signed char _Val through [_First, _Last)
    ::memset(_First, _Val, _Last - _First);
    }

inline void fill(unsigned char *_First, unsigned char *_Last, int _Val)
    {    // copy unsigned char _Val through [_First, _Last)
    ::memset(_First, _Val, _Last - _First);
    }

В третьих в STL есль практически все что необходимо.

DOO>А в Дельфи есть еще TStack, TQueue и т.п.

Ага. Тормозное и не типизированое...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[27]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 08.09.03 10:43
Оценка:
Здравствуйте, Serginio1, Вы писали:


S> Почти на чистейшем Виртовском Паскале.

Что и требовалось доказать.
Кошмар поскипан.
А теперь сравни с этим
Автор: WolfHound
Дата: 05.09.03
.
А ведь сортировка это очень примитивный пример но и на нем пришлось ТАК извращаться.
Ну и кто еще после этого осмелится говорить что на дельфе писать проще?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.09.03 10:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:



S>> Почти на чистейшем Виртовском Паскале.

WH>Что и требовалось доказать.
WH>Кошмар поскипан.
WH>А теперь сравни с этим
Автор: WolfHound
Дата: 05.09.03
.


WH>А ведь сортировка это очень примитивный пример но и на нем пришлось ТАК извращаться.

WH>Ну и кто еще после этого осмелится говорить что на дельфе писать проще?

Не понял в чем сложность???? Обычный QuickSort. Что может быть легче?????
Прошу QuickSort на C++ и сравним.
и солнце б утром не вставало, когда бы не было меня
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.09.03 11:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:



S>> Почти на чистейшем Виртовском Паскале.

WH>Что и требовалось доказать.
WH>Кошмар поскипан.
WH>А теперь сравни с этим
Автор: WolfHound
Дата: 05.09.03
.


Хехе чем то смахивает на пузырьковую сортироку. Просто мне стыдно такой алгоритм на Паскале писать. Уверяю Вас Нет ничего лешче переписть и по количеству кода будет индентичным
для пузырьковой сртировки без применения индексов зато бысрее на 30% (если смотреть ассемблерный код то доступ идет как АдрессМассива+индекс*размерЭлемента).


WH>А ведь сортировка это очень примитивный пример но и на нем пришлось ТАК извращаться.

WH>Ну и кто еще после этого осмелится говорить что на дельфе писать проще?

Еще раз очень хочется посмотреть на QuickSort в шаблонах C++ и сравнить с http://www.rsdn.ru/Forum/Message.aspx?mid=377407&amp;only=1
Автор: Serginio1
Дата: 08.09.03

. Кроме всего прочего данный код не разбухает от применения шаблонов (Copy-Paste-Replace);
И на 10 милионном массиве время сортировки массива интежеров 4.5 сек (на специальном алгоритме под массив интежеров 2 сек без применения индексов). А сколько на Вашем алгоритме???

Кроме всего пользовательский вызов ничем очень даже прост.
Ну а если для Вас это очень сложно, то .....
и солнце б утром не вставало, когда бы не было меня
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 08.09.03 11:37
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> . Кроме всего прочего данный код не разбухает от применения шаблонов (Copy-Paste-Replace);

S> И на 10 милионном массиве время сортировки массива интежеров 4.5 сек (на специальном алгоритме под массив интежеров 2 сек без применения индексов).

Афигеть. В два раза медленнее, зато код не разбухает. А если хочется в два раза быстрее — вперед copy-paste-replace, код так же разбухнет, но, в отличие от С++, заодно и исходник.

Чем ты там занимаешься, что размер бинарника настолько важнее скорости работы? Однократная инициализация таблицы в 64k intro на дельфи?
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.09.03 11:46
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, Serginio1, Вы писали:


S>> . Кроме всего прочего данный код не разбухает от применения шаблонов (Copy-Paste-Replace);

S>> И на 10 милионном массиве время сортировки массива интежеров 4.5 сек (на специальном алгоритме под массив интежеров 2 сек без применения индексов).

_>Афигеть. В два раза медленнее, зато код не разбухает. А если хочется в два раза быстрее — вперед copy-paste-replace, код так же разбухнет, но, в отличие от С++, заодно и исходник.


_>Чем ты там занимаешься, что размер бинарника настолько важнее скорости работы? Однократная инициализация таблицы в 64k intro на дельфи?


Покажи код на С++. Это только маленький пример. Такого кода с размерными типами может набраться и поболее. А в два раза быстрее за счет не применения функции сравнения, но на 30% быстрее чем с применением индексов. Опять же давай сравним код шаблонов С++ и мой со сравнением по нескольким полям и вынесем на всеобщее обсуждение какой код сложнее. По моему легче не бывает.
И поясни "Однократная инициализация таблицы в 64k intro на дельфи".
и солнце б утром не вставало, когда бы не было меня
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 08.09.03 12:02
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Покажи код на С++.


Код уже лежит в vs2003\vc7\include\algorithm. Здесь я не даю make_heap, sort_heap — они вызываются для клинического случая, если quicksort тормозит. Еще нет всяких сервисных функций типа rotate и iter_swap.

В этом коде нет ни одной нетипизированной операции (CmpDoubleByte(var item1, item2) и absolute в твоем примере).

S> И поясни "Однократная инициализация таблицы в 64k intro на дельфи".


Есть такой жанр — 64k intros. В них действительно важнее размер кода, но про эффективность тоже нельзя забывать, поэтому такие в два раза более медленные решения годятся там разве что для однократного выполнения. А вот сэкономить несколько десятков и даже сотен килобайт бинарника в рендеринге или шахматах, замедлив работу в два раза, — смерти подобно.

        // TEMPLATE FUNCTION sort WITH PRED
template<class _BidIt,
    class _Pr> inline
    void _Insertion_sort(_BidIt _First, _BidIt _Last, _Pr _Pred)
    {    // insertion sort [_First, _Last), using _Pred
    if (_First != _Last)
        for (_BidIt _Next = _First; ++_Next != _Last; )
            if (_Pred(*_Next, *_First))
                {    // found new earliest element, rotate to front
                _BidIt _Next1 = _Next;
                std::rotate(_First, _Next, ++_Next1);
                }
            else
                {    // look for insertion point after first
                _BidIt _Dest = _Next;
                for (_BidIt _Dest0 = _Dest; _Pred(*_Next, *--_Dest0); )
                    _Dest = _Dest0;
                if (_Dest != _Next)
                    {    // rotate into place
                    _BidIt _Next1 = _Next;
                    std::rotate(_Dest, _Next, ++_Next1);
                    }
                }
    }

template<class _RanIt,
    class _Pr> inline
    void _Med3(_RanIt _First, _RanIt _Mid, _RanIt _Last, _Pr _Pred)
    {    // sort median of three elements to middle
    if (_Pred(*_Mid, *_First))
        std::iter_swap(_Mid, _First);
    if (_Pred(*_Last, *_Mid))
        std::iter_swap(_Last, _Mid);
    if (_Pred(*_Mid, *_First))
        std::iter_swap(_Mid, _First);
    }

template<class _RanIt,
    class _Pr> inline
    void _Median(_RanIt _First, _RanIt _Mid, _RanIt _Last, _Pr _Pred)
    {    // sort median element to middle
    if (40 < _Last - _First)
        {    // median of nine
        int _Step = (_Last - _First + 1) / 8;
        _Med3(_First, _First + _Step, _First + 2 * _Step, _Pred);
        _Med3(_Mid - _Step, _Mid, _Mid + _Step, _Pred);
        _Med3(_Last - 2 * _Step, _Last - _Step, _Last, _Pred);
        _Med3(_First + _Step, _Mid, _Last - _Step, _Pred);
        }
    else
        _Med3(_First, _Mid, _Last, _Pred);
    }

template<class _RanIt,
    class _Pr> inline
    pair<_RanIt, _RanIt> _Unguarded_partition(_RanIt _First, _RanIt _Last,
        _Pr _Pred)
    {    // partition [_First, _Last), using _Pred
    _RanIt _Mid = _First + (_Last - _First) / 2;
    _Median(_First, _Mid, _Last - 1, _Pred);
    _RanIt _Pfirst = _Mid;
    _RanIt _Plast = _Pfirst + 1;

    while (_First < _Pfirst
        && !_Pred(*(_Pfirst - 1), *_Pfirst)
        && !_Pred(*_Pfirst, *(_Pfirst - 1)))
        --_Pfirst;
    while (_Plast < _Last
        && !_Pred(*_Plast, *_Pfirst)
        && !_Pred(*_Pfirst, *_Plast))
        ++_Plast;

    _RanIt _Gfirst = _Plast;
    _RanIt _Glast = _Pfirst;

    for (; ; )
        {    // partition
        for (; _Gfirst < _Last; ++_Gfirst)
            if (_Pred(*_Pfirst, *_Gfirst))
                ;
            else if (_Pred(*_Gfirst, *_Pfirst))
                break;
            else
                std::iter_swap(_Plast++, _Gfirst);
        for (; _First < _Glast; --_Glast)
            if (_Pred(*(_Glast - 1), *_Pfirst))
                ;
            else if (_Pred(*_Pfirst, *(_Glast - 1)))
                break;
            else
                std::iter_swap(--_Pfirst, _Glast - 1);
        if (_Glast == _First && _Gfirst == _Last)
            return (pair<_RanIt, _RanIt>(_Pfirst, _Plast));

        if (_Glast == _First)
            {    // no room at bottom, rotate pivot upward
            if (_Plast != _Gfirst)
                std::iter_swap(_Pfirst, _Plast);
            ++_Plast;
            std::iter_swap(_Pfirst++, _Gfirst++);
            }
        else if (_Gfirst == _Last)
            {    // no room at top, rotate pivot downward
            if (--_Glast != --_Pfirst)
                std::iter_swap(_Glast, _Pfirst);
            std::iter_swap(_Pfirst, --_Plast);
            }
        else
            std::iter_swap(_Gfirst++, --_Glast);
        }
    }

template<class _RanIt,
    class _Diff,
    class _Pr> inline
    void _Sort(_RanIt _First, _RanIt _Last, _Diff _Ideal, _Pr _Pred)
    {    // order [_First, _Last), using _Pred
    _Diff _Count;
    for (; _ISORT_MAX < (_Count = _Last - _First) && 0 < _Ideal; )
        {    // divide and conquer by quicksort
        pair<_RanIt, _RanIt> _Mid =
            _Unguarded_partition(_First, _Last, _Pred);
        _Ideal /= 2, _Ideal += _Ideal / 2;    // allow 1.5 log2(N) divisions

        if (_Mid.first - _First < _Last - _Mid.second)    // loop on larger half
            _Sort(_First, _Mid.first, _Ideal, _Pred), _First = _Mid.second;
        else
            _Sort(_Mid.second, _Last, _Ideal, _Pred), _Last = _Mid.first;
        }

    if (_ISORT_MAX < _Count)
        {    // heap sort if too many divisions
        std::make_heap(_First, _Last, _Pred);
        std::sort_heap(_First, _Last, _Pred);
        }
    else if (1 < _Count)
        _Insertion_sort(_First, _Last, _Pred);    // small, insertion sort
    }

template<class _RanIt,
    class _Pr> inline
    void sort(_RanIt _First, _RanIt _Last, _Pr _Pred)
    {    // order [_First, _Last), using _Pred
    _Sort(_First, _Last, _Last - _First, _Pred);
    }
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 08.09.03 12:08
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Хехе чем то смахивает на пузырьковую сортироку.

Я же сказал мне лень.
S>Просто мне стыдно такой алгоритм на Паскале писать.
Ой какие мы надменные.
S>Уверяю Вас Нет ничего лешче переписть и по количеству кода будет индентичным
Ты дурочку не валяй. Та прекрасно понимаешь о чем я.

S> Еще раз очень хочется посмотреть на QuickSort в шаблонах C++ и сравнить с http://www.rsdn.ru/Forum/Message.aspx?mid=377407&amp;only=1
Автор: Serginio1
Дата: 08.09.03

Ну сравнивай.
template<class Iter, class Cmp>
void qsort_sort(Iter begin, Iter end, const Cmp& cmp)
{
    std::iterator_traits<Iter>::value_type midl=*(begin+(end-begin)/2);
    Iter begin_=begin;
    Iter end_=end;
    --end_;
    do
    {
        while(cmp(*begin_, midl)&&(begin_<=end_))
            ++begin_;
        while(cmp(midl, *end_)&&(begin_<=end_))
            --end_;
        if(begin_<=end_)
        {
            std::iter_swap(begin_, end_);
            ++begin_;
            --end_;
        }
    }while(begin_<end_);
    ++end_;
    if(begin<end_)
        qsort_sort(begin, end_, cmp);
    if(begin_<end)
        qsort_sort(begin_, end, cmp);
}
template<class Iter>
void qsort_sort(Iter begin, Iter end)
{
    qsort_sort(begin, end, std::less<std::iterator_traits<Iter>::value_type>());
}

S> . Кроме всего прочего данный код не разбухает от применения шаблонов (Copy-Paste-Replace);
И кого это волнует?
S> И на 10 милионном массиве время сортировки массива интежеров 4.5 сек (на специальном алгоритме под массив интежеров 2 сек без применения индексов). А сколько на Вашем алгоритме???
А это смотря на какой тачке. На работе 2.5, а дома я так думаю быстрее раза в два будет.
    std::vector<int> vec_int(10000000);
    std::generate(vec_int.begin(), vec_int.end(), rand);
    __int64 begin, end, freq;
    QueryPerformanceFrequency((LARGE_INTEGER*)&freq);
    QueryPerformanceCounter((LARGE_INTEGER*)&begin);
    qsort_sort(vec_int.begin(), vec_int.end());
    QueryPerformanceCounter((LARGE_INTEGER*)&end);
    std::cout<<(double(end-begin)/freq)<<std::endl;


S> Кроме всего пользовательский вызов ничем очень даже прост.

О да
function CmpInteger(var item1, item2): Integer;
var
  i1: Integer absolute item1;
  i2: Integer absolute item2;
begin
  result:=i2-i1; 
end;

Procedure SwapInteger(Var Item1,Item2);
   var I1:Integer absolute Item1;
        I2:Integer absolute Item2;
        Temp:Integer;
    Begin
    Temp:=i1;
    i1:=i2;
    i2:=temp;
    end;

///====================================================
Var a:Array of TType;
begin
//.................
 SortArray3(a,SizeOf(TType),CmpDoubleByte,SwapDoubleByte); 

end;

и
    qsort_sort(vec_int.begin(), vec_int.end());

S> Ну а если для Вас это очень сложно, то .....
От такого слышу...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 08.09.03 13:01
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Опять же повторюсь мне намного больше нравится Net чем Native языки.

S> Там по поводу шаблонов идут поиски, перегрузка операторов тоже не такая огульная, зато продуманность классов и структур во много раз выше.

Вот с появлением generics в .NET и отпадут проблемы, аналогичные дельфийским: 17 классов System.Data.Common.XXXStorage, почти копия System.Collections.Hashtable в System.Windows.Forms.NativeWindow (хранить забоксенные хэндлы окон накладно), постоянные реализации с нуля наследников ICollection и IList (только в System.Windows.Forms.ListView их шесть штук), четыре копии двоичного поиска в System.Windows.Forms (Menu.FindMergePosition, PropertyStore.LocateIntegerEntry, PropertyStore.LocateObjectEntry и TreeNode.AddSorted) и бессчетное повторение линейного поиска, бесконечные if(array.Length = count){T[] newarray = new T[2*count];Array.Copy(array, 0, newarray, 0, count;array = newarray;} там, где не устраивает производительность ArrayList.

S> Я голосую за Net (в том числе С# и Delphi.Net). А там сортировка массива встроена в сам объект Array.


Там она именно такая, как у тебя на дельфи — на виртуальном вызове.
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: DrMom  
Дата: 08.09.03 13:03
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Ну а если для Вас это очень сложно, то .....


ДА!!! Понтов-то, понтов... А я например в своей программе использую множество различных массивов с разными типами данных и мне надо сортировать их. Я так понимаю, что нормальным подходом для тебя будет использование твоего собственного примера скоприванного в 10ке вариантах. И в каждом варианте путем замены ты будешь править тип данных. Когда же код достигнет внушительных размеров и сотен файлов, то при обнаружении ошибки в алгоритме сортировки ты будешь лопатить файлы в поисках этих копий алгоритма с целью исправления ошибки. Если это так тебе нравится то наверно тебе не нужны шаблоны.

Что касается сортировки, то это просто элементарный пример, а вот что ты скажешь если придется писать например какой нить интерпритатор но не только для тривиального посимвольного текста, а например для какого нить потока данных где атомом является нечто более сложное, чем символ. Да к примеру хотябы слово или предложение, а затем более крупные единици. Во всех случаях возможно использовать один алгоритм, но типы данных разные. При последовательном применении данных анализаторов к тексту можно получить весьма сильные вещи, да и в случае ошибок их не придется искать в каждом отдельном случае. Вот я бы посмотрел на твой код при размере алгоритма > 500 строк и количестве модулей больше 5ти.

ЗЫ Я не раз видел подобные решения при задачах типа уравнений мат физики, которые реализовывались для нескольких типов данных одновременно. ИЗВРАТ.
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: Joker6413  
Дата: 08.09.03 13:11
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, DOOM, Вы писали:


DOO>>Теперь ваща очередь...

LVV> Давайте не путать язык, компилятор и IDE.
LVV>1. Язык. С++ ИМНО богаче будет. Как раз за счет перегрузки операций и шаблонов. В остальном ИМХО — совпадают.
LVV>Но!!! STL, как ни крути, стандарт С++! до чего Дельфям топать и топать.
LVV>2. IDE — ИМХО дело вкуса.
LVV>3. Компилер — тут, без сомнения, дельфи по скорости давит все с++компилеры.

LVV>Кто возразит?


Дык их сравнивать нельзя в дельфе компилятор однопроходной, а в C++ двухпроходной...
Поэтому в делфе и можно абстрактные классы создавать, это костыль для имитирования поддержки ООП.
В этом плане паскаль вообще пример еще тот, так как все механизмы ООП в него "вдавливали", кто во что горазд... т.к. стандарта языка не было.

Игорь
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.09.03 13:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>template<class Iter, class Cmp>

WH>void qsort_sort(Iter begin, Iter end, const Cmp& cmp)
WH>{
WH> std::iterator_traits<Iter>::value_type midl=*(begin+(end-begin)/2);


WH> Iter begin_=begin;

WH> Iter end_=end;
WH> --end_;
WH> do
WH> {
WH> while(cmp(*begin_, midl)&&(begin_<=end_))
WH> ++begin_;
WH> while(cmp(midl, *end_)&&(begin_<=end_))
WH> --end_;
WH> if(begin_<=end_)
WH> {
WH> std::iter_swap(begin_, end_);
WH> ++begin_;
WH> --end_;
WH> }
WH> }while(begin_<end_);
WH> ++end_;
WH> if(begin<end_)
WH> qsort_sort(begin, end_, cmp);
WH> if(begin_<end)
WH> qsort_sort(begin_, end, cmp);
WH>}
WH>template<class Iter>
WH>void qsort_sort(Iter begin, Iter end)
WH>{
WH> qsort_sort(begin, end, std::less<std::iterator_traits<Iter>::value_type>());
WH>}
WH>[/ccode]




WH>
WH>    std::vector<int> vec_int(10000000);
WH>    std::generate(vec_int.begin(), vec_int.end(), rand);
WH>    __int64 begin, end, freq;
WH>    QueryPerformanceFrequency((LARGE_INTEGER*)&freq);
WH>    QueryPerformanceCounter((LARGE_INTEGER*)&begin);
WH>    qsort_sort(vec_int.begin(), vec_int.end());
WH>    QueryPerformanceCounter((LARGE_INTEGER*)&end);
WH>    std::cout<<(double(end-begin)/freq)<<std::endl;
WH>


Называется найти 10 различий.

Procedure SortArray3(Var a; Len:Integer; CompareProc:TCompareProc;SwapProc:TSwapProc);
Var TempBuffer:Pointer;
BeginArray:Cardinal;
MidlVar:Pointer;

procedure QuickSort(L, R: Integer);
var
I, J: Integer;
begin


I :=L;
J :=R;
// Move(Pointer(BeginArray +((((L+R-BeginArray-BeginArray) div len) shr 1)* len ))^,MidlVar^,Len);
// Спасибо четого с мозгами стало, но проверь у себя на невыровненных данных по 4
Move(Pointer(L+(((R-l) div len) shr 1)*len)^,MidlVar^,Len);

repeat
while CompareProc(Pointer(I)^, MidlVar^) < 0 do
Inc(I,Len);
while CompareProc(Pointer(J)^, MidlVar^) > 0 do
Dec(J,len);
if I <= J then
begin
SwapProc(Pointer(I)^,Pointer(J)^);
Inc(I,Len);
Dec(J,Len);
end;
until I > J;


if L < J then
QuickSort(L,J);
if R>I then
QuickSort(I,R);

end;



Begin
GetMem(TempBuffer,2*Len);
MidlVar:=Pointer(Cardinal(TempBuffer)+len);
BeginArray:=PCardinal(@a)^;
QuickSort(BeginArray,BeginArray+(PCardinal(BeginArray-4)^-1)*len);
Dispose(TempBuffer);
End;
end.

не в Моем примере было
Type
TType = packed record
d:Double;
b:Byte;
end;
function CmpDoubleByte(var item1, item2): Integer;
var
i1: TType absolute item1;
i2: Ttype absolute item2;
r: Double;
begin
r := i1.d-i2.d;
if (Abs(r) < 1.0E-100) then
Result := 0
else if (r < 0) then
Result := -1
else
Result := 1;
If Result:=0 Then
Begin
Result:=i1.B;
Dec(result,i2.B
end;
end;

Procedure SwapDoubleByte(Var Item1,Item2);
var I1:TType absolute Item1;
I2:TType absolute Item2;
Temp:TType;
Begin
Temp:=i1;
i1:=i2;
i2:=temp;
end;

WH>///====================================================

WH>Var a:Array of TType;
WH>begin
WH>//.................
WH> SortArray3(a,SizeOf(TType),CmpDoubleByte,SwapDoubleByte);

WH>end;

WH>[/pascal]
WH>и
WH>
WH>    qsort_sort(vec_int.begin(), vec_int.end());
WH>


Еще раз проверь
std::iterator_traits<Iter>::value_type midl=*(begin+(end-begin)/2);

проверь на невыравненных данных . Возьми мой тип а не кратный 4.
Move(Pointer(L+(((R-l) div len) shr 1)*len)^,MidlVar^,Len);



Вы можете кричать здесь хоть до ночи, А Я перехожу на Net (С# и жду Delphi.Net).
Если кого задел ПРОШУ ПРОЩЕНИЯ.
и солнце б утром не вставало, когда бы не было меня
Re[22]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 08.09.03 13:25
Оценка:
WH>>>Ты от ответа не уходи ты функцию напиши.

M>>TList.Sort — вот эта функция.


WH>Ты ручками сортировку написать можешь?


А зачем писать сам алогритм сортировки? Ты что, сомневаешься, что TList.Sort правильно сортирует?

Смысл этого примера в том, что компаратор (указатель на функцию сортировки) передаётся в метод TList.Sort, который при помощи компаратора сортирует список.

Type
  TMyComparableObj = class
    private
      i: integer;
    end;

function CompareObjects(Item1, Item2: Pointer): Integer;
begin
  Result := CompareValue((Item1 as TMyComparableObject).i, (Item1 as TMyComparableObject).i);
end;

var List1: TList;
begin
 List1:=TList.Create;
 // заполнение List1...
 
 List1.Sort(@CompareObjects)

end.
... << RSDN@Home 1.1 beta 1 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.09.03 13:38
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, Serginio1, Вы писали:


Посмотрим обещают http://www.dotsite.ru/Publications/PublicationDetails.aspx?ID=115
Не нравится, что нет директивы Implements для Интерфейсов как в Delphi.
Посмотрим, что выдаст Borland в конце года.
и солнце б утром не вставало, когда бы не было меня
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.09.03 13:49
Оценка:
Здравствуйте, DrMom, Вы писали:

DM>Здравствуйте, Serginio1, Вы писали:


S>> Ну а если для Вас это очень сложно, то .....


DM>ДА!!! Понтов-то, понтов... А я например в своей программе использую множество различных массивов с разными типами данных и мне надо сортировать их. Я так понимаю, что нормальным подходом для тебя будет использование твоего собственного примера скоприванного в 10ке вариантах. И в каждом варианте путем замены ты будешь править тип данных. Когда же код достигнет внушительных размеров и сотен файлов, то при обнаружении ошибки в алгоритме сортировки ты будешь лопатить файлы в поисках этих копий алгоритма с целью исправления ошибки. Если это так тебе нравится то наверно тебе не нужны шаблоны.


DM>Что касается сортировки, то это просто элементарный пример, а вот что ты скажешь если придется писать например какой нить интерпритатор но не только для тривиального посимвольного текста, а например для какого нить потока данных где атомом является нечто более сложное, чем символ. Да к примеру хотябы слово или предложение, а затем более крупные единици. Во всех случаях возможно использовать один алгоритм, но типы данных разные. При последовательном применении данных анализаторов к тексту можно получить весьма сильные вещи, да и в случае ошибок их не придется искать в каждом отдельном случае. Вот я бы посмотрел на твой код при размере алгоритма > 500 строк и количестве модулей больше 5ти.


DM>ЗЫ Я не раз видел подобные решения при задачах типа уравнений мат физики, которые реализовывались для нескольких типов данных одновременно. ИЗВРАТ.


Был поставлен вопрос. Дано решение http://www.dotsite.ru/Publications/PublicationDetails.aspx?ID=115
И слабо отличающийся по коду от шаблонов С++
Будет следующий вопрос тоже будет найдено решение вплоть до генерации исходного кода.
Но опять же повторюсь пока нет шаблонов в Delphi и Inline , перегрузки и что помирать что ли. Зачем переходить на С++ может лучше на С#. Borland выйдет в конце года с новыми решениями как в Net так и в Native компилятором. Все идет все меняется.
А насчет "понтов " это ответ на аналогичные высказывания по теме выше, не относящиеся к ВАМ лично.
и солнце б утром не вставало, когда бы не было меня
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.09.03 13:51
Оценка:
Здравствуйте, Joker6413, Вы писали:
J>Поэтому в делфе и можно абстрактные классы создавать, это костыль для имитирования поддержки ООП.
Ничего подобного. Для справки: тот самый однопроходный компилятор Delphi выдает warning, обнаруживая прямое конструирование экземпляра абстрактного класса.
А возможность создавать эти экземпляры прямо связана с такой штукой, как указатель на класс. Который есть реализация шаблона "Абстрактная фабрика". В связи с этим, у компилятора нет никакой информации о том, чей ты конструктор вызываешь.
... << RSDN@Home 1.1 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 08.09.03 18:03
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Еще раз проверь

S>std::iterator_traits<Iter>::value_type midl=*(begin+(end-begin)/2);
Нафига? Я с нетипизироваными адресами (в отличии от некоторых) не работаю.
end-begin возвращает количество элементов. потом оно делится на 2(оптимизатору виднее как делить или смещать он умный) и на результат смещается итератор начала. Полученый итератор разименовается.
Учим мат часть.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 10.09.03 05:26
Оценка:
Здравствуйте, ArtDenis, Вы писали:


AD>Кроме того, Delphi предоставляет программисту такие вольности в приведении типов указателей, что даже программисту на C и не снились. А подобная вольность — источник повышенного количества ошибок.


А по-моему я не маленький и мне можно разрешать смотреть на память как я хочу. Это не источник ошибок, а повышение возможностей. Это лучше всяких там шаблонов, поскольку здесь я до конца представляю, что происходит при подобных действиях, а следовательно в случае ошибки я буду грешить не на "Майкрософт", а на свою прогу!

И вообще я уже говорил: юзайте VB — там вообще ничего не надо создавать да удалаять.
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 10.09.03 06:17
Оценка:
Приехали граждане... Оказывается в С нет понятия указатель на метод произвольного класса(аналог of object в Дельфи). Что на это скажете?
Re[2]: Эффективное использование WTL
От: Евгений Коробко  
Дата: 10.09.03 06:51
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Приехали граждане... Оказывается в С нет понятия указатель на метод произвольного класса(аналог of object в Дельфи). Что на это скажете?


Скажем "Слава богу"!!! Понятие произвольного класса возникает из-за того, что в Delphi существует предок всх объектов.
Однако создание такого самого главного класса — элементарное нарушение ООД. Если нужно, создайте класс-"примесь" и "подмешайте"
его к тем классам, к которым нужно.

Нет, я с дельфями завязал. Сначала кажется, что удобно. VCL хороша, работа с БД, IDE... Но потом это всё вылазит боком.
Во-первых, тормоза. Как в работе с БД, так и просто в перерисовке окон.
Во-вторых, нет STL и вообще типизированных контейнеров
В-третьих, всё API и все библиотеки на C.
В-четвёртых, нет контроля над ситуацией.

Год назад с дуру решил проект делать на Delphi. Готов себя тогдашего убить за дурость. Если бы писал на C++ & WinAPI, всё было бы
уже готово!!!
Евгений Коробко
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 10.09.03 07:55
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, centurn, Вы писали:


C>> Ты сам-то хоть представляещь себе шутер, написАнный на Делфях? Я говорю, что можно, но только можно ли всерьез воспринимать такую возможность? Кстати, я именно про шутер — какую-нить турновую стратегию довольно нормально можно сделать... А драйвера и операционки тоже на Делфях писАть будем...


DOO>Разница-то в чем???


Да разница, собственно, в том, что драйвер и операционку ты просто никак на делфях не напишешь, принципиально. Ну кроме, возможно, того извращенческого маневра, что тут про драйвера говорили...
А в шутере нужна максимальная производительность, которой в делфях и не пахнет. И дело даже не в качестве компилятора, а в том, что в С++ можно более тонко управлять тем, что тебе сделает компилятор. И на надо платить за то, что тебе не сейчас не нужно — это было и остается чуть ли не самым главным при развитии С++. И главное — не в ущерб функциональности.
Короче, шутер на делфах можно сделать, но на это уйдет намного больше времени, чем на С++, и будет этот шутер похож на слайд-шоу под аккомпанемент жутко свопящего винта.

DOO>Я на Дельфи не только "окошки с клиентами БД" писал. Я, например, писал полноценный сканер портов(ничем не хуже nmap'а) и NetBios сканнер. И утверждаю, что это намного проще чем на сях!


А ты на сях это писАл? Знаешь, я тоже на Делфях писал кой-чего, работающее с NetBios. Во-первых, я задолбался переводить структурки, используемые для общения с NetBios, с С на Pascal (кстати, С-шные структырки были в хелпе по WinAPI, поставляемом с Делфями, других я не нашел). А во-вторых в парочке мест я уже, грязно матерясь, просто сорвался на ассемблерные вставкм, т.к. не хватило терпения воротить все эти конструкции на паскале. И это при том, что тогда моим основным языком был как раз Делфи, а С я знал только "слегка"...

И еще, раз уж меня потянуло кнопки понажимать, выскажусь по поводу, так сказать, общепринятого удобства Делфи в создании GUI. Как я уже сказал, Делфи я знаю дольше С/С++. В основном, правда, еще с 3.0 работал, с 4.0 меньше, а на 5.0 вообще их забросил. Сейчас на работе я в основном делаю редакторы и всякие вспомогательные утилиты для игрушки. Ясное дело, там _очень _ много GUI. Так вот, я бы ни за какие плюшки (кроме _очень_ серьезной прибавки к зарплате) не променял VC на Делфю. Даже если не брать в расчет то, что надо стыковаться с кодом движка, который, ясное дело, на С++, да еще значительная часть кода используется в Plugin'е для 3DMax, у которого SDK... можно догадаться на каком языке. Я не буду по этому поводу приводить особых аргументов, т.к. удобство все-таки понятие чисто субъективное, но еще раз: заметь, что Делфи я знаю дольше, и к С++ приходилось привыкать (кстати, тогда я тоже малость плевался .
И еще мысль: практически не бывает "чистого" GUI, обычно за ним стоит еще нетривиальный код (иначе вообще непонятно, зачем нужен нужен язык программирования).
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: Joker6413  
Дата: 10.09.03 09:57
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Joker6413, Вы писали:

J>>Поэтому в делфе и можно абстрактные классы создавать, это костыль для имитирования поддержки ООП.
S>Ничего подобного. Для справки: тот самый однопроходный компилятор Delphi выдает warning, обнаруживая прямое конструирование экземпляра абстрактного класса.
S>А возможность создавать эти экземпляры прямо связана с такой штукой, как указатель на класс. Который есть реализация шаблона "Абстрактная фабрика". В связи с этим, у компилятора нет никакой информации о том, чей ты конструктор вызываешь.

1. Очень интересно что же создается при конструировании абстрактного класса. vptr то нет...
2. У указателя нет конструктора.
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 10.09.03 11:15
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Ну не знаю насчет "некоторых", только сишный код только и пестрит нетипизированными указателями.

А С и использование кривыми руками С++ тут причем? При правильной работе в С++ нетипизированая память используется только при работе с оочень низкоуровневым API
S>По поводу Мат части и (оптимизатору виднее как делить или смещать он умный) так лично мне интересней ручками, а то мозги совсем засохнут. Например для size=2^n выравнивание лего решается через Adress = Adress and (cardinal( not (size-1))). Для других dec(address, Adress mod size) и через div и * size.
Мне архитектурных заморочек хватает выши крыши.

S> Пройдусь немного по нахваленным шаблонам. Согласен применение их очень удобно и надеюсь они появятся как в Delphi так и Net особенно для уже разработааных больших классов-шаблонов. Но хочу добавить одну Весчь что Copy-Paste-Replace лет 20 решали проблему шаблонов, но кроме всего прочего получался исходный код, который легко оптимизировался под конкретный тип.

Ну и кто тебе сказал что нельзя при использовании шаблонов настроить на конкретный тип? А что касается 20 лет там чегото решал то ИМХО больше проблем чем пользы бало. Ну сам подумай написал десяток алгоритмов на 100-200 строк раскопировал каждый на десяток типов, а потом нашол маленькую ошибку и давай исправлять... пока будешь исправлять еще наделаешь....

Copy-Paste-Replace
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.09.03 11:36
Оценка:
Здравствуйте, Joker6413, Вы писали:

J>1. Очень интересно что же создается при конструировании абстрактного класса. vptr то нет...

Ну куда бы она делась? Другое дело, что в слоты абстрактных методов записан адрес специальной процедурки из модуля System. См. здесь
Автор(ы): Антон Злыгостев
Дата: 18.02.2003
Данная статья описывает метод получения дополнительной информации при вызове абстрактного метода во время выполнения. В Delphi такой вызов технически возможен и является ошибкой.
Стандартная библиотека лишь регистрирует факт возниконовения этой ошибки, не предоставляя никой информации о контексте. Предлагаемый метод позволяет выяснить имя класса и номера слотов VMT, соответствующих абстрактным методам.
.
J>2. У указателя нет конструктора.
Ну куда бы он делся? Если в классе задекларировать виртуальный конструктор, то его можно будет вызывать по указателю на класс.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: Joker6413  
Дата: 10.09.03 11:53
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Joker6413, Вы писали:


J>>1. Очень интересно что же создается при конструировании абстрактного класса. vptr то нет...

S>Ну куда бы она делась? Другое дело, что в слоты абстрактных методов записан адрес специальной процедурки из модуля System. См. здесь
Автор(ы): Антон Злыгостев
Дата: 18.02.2003
Данная статья описывает метод получения дополнительной информации при вызове абстрактного метода во время выполнения. В Delphi такой вызов технически возможен и является ошибкой.
Стандартная библиотека лишь регистрирует факт возниконовения этой ошибки, не предоставляя никой информации о контексте. Предлагаемый метод позволяет выяснить имя класса и номера слотов VMT, соответствующих абстрактным методам.
.


То есть реализации методов нет но сконструировать можно, хоть указывает черт знает куда но можно использовать? Так в C еще проще было пишу void *ptr = 0; и опа! у меня создан объект абстрактного класса? Могу его пользовать...

J>>2. У указателя нет конструктора.

S>Ну куда бы он делся? Если в классе задекларировать виртуальный конструктор, то его можно будет вызывать по указателю на класс.

Что за бред? Ты вообще понимаешь что такое конструктор? И что за указатель на класс? Ты про метакласс говоришь или все таки про объект класса?
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.09.03 11:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>> Пройдусь немного по нахваленным шаблонам. Согласен применение их очень удобно и надеюсь они появятся как в Delphi так и Net особенно для уже разработааных больших классов-шаблонов. Но хочу добавить одну Весчь что Copy-Paste-Replace лет 20 решали проблему шаблонов, но кроме всего прочего получался исходный код, который легко оптимизировался под конкретный тип.

WH>Ну и кто тебе сказал что нельзя при использовании шаблонов настроить на конкретный тип? А что касается 20 лет там чегото решал то ИМХО больше проблем чем пользы бало. Ну сам подумай написал десяток алгоритмов на 100-200 строк раскопировал каждый на десяток типов, а потом нашол маленькую ошибку и давай исправлять... пока будешь исправлять еще наделаешь....

Но если я захотел изменить (добавить) функциональность для конкрентого типа, которая для других типов не нужна ????? Есть в шаблонах наследование ???
Объясню подробнее. Есть база 1С. На основании метаданных можно построить объекты для прямого доступа к файлам опирающихся на несколько связанных таблиц от базового объекта. Решение через формирование исходников есть http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019.
Как такую проблему можно решить через шаблоны????
Это не "Понты" а практический вопрос, т.к. по понятной причине не имею с ними практики. Заранее благодарен за ответ.
WH>Copy-Paste-Replace
и солнце б утром не вставало, когда бы не было меня
Re[25]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sergey Россия  
Дата: 10.09.03 12:03
Оценка:
Hello, mihailik!
You wrote on Wed, 10 Sep 2003 11:08:07 GMT:

m> Вот тебе тоже вопрос на тему как применить микроскоп для забивания

m> гвоздей. Как в C++ отсортировать виндовый SafeArray, причём в режиме
m> thread-safe?


Замечательный вопрос А как его вообще отсортировать, если часть объектов, что в нем лежат, могут оказаться многомерными массивами, часть — указателями на объекты (IDispatch), а остальные — типа currency

Best regards,
Sergey.
Posted via RSDN NNTP Server 1.7 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.09.03 12:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, mihailik, Вы писали:


C>>> Что мне делать, если я хочу отсортировать встроенный массив или вообще какой-то свой контейнер? Придумал! Копировать его в этот TList, а потом забирать назад! Прекрасное решение!

M>>Встроенных типов не так много, легче простого написать небольшую библиотечку с функциями типа SortIntegerArray и т.п.
WH>Да а потом SortMyCoolType1Array, SortMyCoolType2Array, SortMyCoolType3Array,...
WH>А потом нам будет нужен бинарный поиск по отсортированому массиву, а потом удаление элементов при выполнение какого либо условия,...


Ну на этот вопрос уже дан ответ http://www.rsdn.ru/Forum/Message.aspx?mid=377407&amp;only=1
Автор: Serginio1
Дата: 08.09.03

Слабо отличающийся от твоего примера на шаблонах. Зачем повторять одно и тоже ????

И бинарный поиск и удаление делается элементарно.

M>>Или крутизна шаблонов как раз и заключается в работе со встроенными типами?

WH>Не со встроеными, а со всеми.
M>>Игрушечки какие-то
WH>Эти игрушеччки сокращают размер кода в разы и значительно повышают надежность. Отсутствие возможностей для реализации элементарных смартпоинтеров использование которых не требует каких либо телодвижений и накладных расходов просто убивает.
А есть в С++ директива Implements которая говорит, что за реализацию определенных интерфейсов объекта отвечает объект являющийся полем данного объекта??? В С# нет. Тоесть для уже готовой реализации нужно для каждого объекта выполнять реализацию всех методов????

WH>Ну не возможно в таких условиях работать. Каменный век.


смартпоинтеров легко реализуются через наследование от TtypedObject или включение реализации любого интерфейса в наследнике от TComponent при этом мы получаем гибкость. Или включеннии объекта в спсок который при уничтожении вызывает деструктор каждого внедренного объекта.
и солнце б утром не вставало, когда бы не было меня
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: Joker6413  
Дата: 10.09.03 12:58
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Joker6413, Вы писали:


J>>Что за бред? Ты вообще понимаешь что такое конструктор? И что за указатель на класс? Ты про метакласс говоришь или все таки про объект класса?

S>Я тебе очень рекомендую для прочтения Object Pascal Reference из комплекта Delphi. Тогда тебе станет понятно, о чем идет речь. Нельзя слепо применять термины в трактовке одного языка к другому языку. То, что в С++ не бывает виртуальных конструкторов и нет понятия "указатель на класс", не есть универсальное свойство ООП.

Ладно сорри, увлекся holy war...
Re[27]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 10.09.03 20:14
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Ну на этот вопрос уже дан ответ http://www.rsdn.ru/Forum/Message.aspx?mid=377407&amp;only=1
Автор: Serginio1
Дата: 08.09.03

S> Слабо отличающийся от твоего примера на шаблонах. Зачем повторять одно и тоже ????
СТРОГАЯ ТИПИЗАЦИЯ эти слова тебе чтонибудь говорят? А еще имея информация о типах можно проводить оптимизации например можно узнать является ли тип POD типом и если да то можно использовать memcpy...
А уж как я реализовал сериализацию...
struct some_type
{
    std::string name;
    std::vector<std::string> vec_str;
    std::vector<int> vec_int;
    std::vector<std::vector<std::string> > vec_vec_str;
    SERIALIZE()
    {
        serializer
        .version(1)
            (name)
            (vec_str)
        .version(2)
            (vec_int)
            (vec_vec_str)
        ;
    }
};

Этого достаточно для того чтобы класс умел себя сохранять/загружать из банарного потока.

Вот все что нужно ядру для того чтобы сериализовать вектора. Данная реализация может применяться рекурсивно что позволяест сериализовать вектора векторов.
template<class Type, class Allocator>
struct serialize_save_load<std::vector<Type, Allocator> >
{
    typedef std::vector<Type, Allocator>    container;
    typedef typename container::size_type    size_type;
    template<class T>
    static void save(T& st, const container& cont)
    {
        st.save(cont.size());
        st.save(cont.begin(), cont.end());
    }
    template<class T>
    static void load(T& st, container& cont)
    {
        size_type size;
        st.load(size);
        cont.resize(size);
        st.load(cont.begin(), cont.end());
    }
};

Ну и где твоя дельфя?

S> А есть в С++ директива Implements которая говорит, что за реализацию определенных интерфейсов объекта отвечает объект являющийся полем данного объекта??? В С# нет. Тоесть для уже готовой реализации нужно для каждого объекта выполнять реализацию всех методов????

В С++ есть куда болие гибкие средства от банального наследования реализации
struct test_interface
{
};
struct test_interface_impl
    :test_interface
{
};
struct test1
    :test_interface_impl
{
};

до внедрения кода в тип
#define mixin_impl()\
self_type* self()\
{\
    return static_cast<self_type*>(this);\
}\
const self_type* self()const\
{\
    return static_cast<const self_type*>(this);\
}

template<class self_type>
struct test_interface_mixin_impl
    :test_interface
{
    mixin_impl()
    test_interface_mixin_impl()
    {
        self()->hello_world();//Ни какого оверхеда. В плоть до инлайна.
    }
};
struct test2
    :test_interface_mixin_impl<test2>
{
    void hello_world()
    {
    }
};


S> смартпоинтеров легко реализуются через наследование от TtypedObject или включение реализации любого интерфейса в наследнике от TComponent при этом мы получаем гибкость.

А если я не хочу мой класс ни от чего наследовать? А если мне нужны слабые ссылки? А если мне не нужен оверхед? А если.... В С++ я могу создать смартпоинтер с любыми необходимыми здесь и сейчас параметрами.
Например писал я OPC server там куча методов должны возвращать массивы созданные при помощи CoTaskMemAlloc. На С++ я за пять минут сотворил шаблон помошник который проверял былали выделена память, следил за выделеной памятью, инициализировал память и в случае чего вызывал деструкторы, а самое главное прикидывался массивом и уже когда все закончино и гарантировано не будет исключений я забирал заполненый массив и возвращал из функции.
Использование ваглядит примерно так
STDMETHODIMP COPCServer::GetItemProperties( 
/* [in] */                                LPWSTR szItemID,
/* [in] */                                DWORD dwCount,
/* [size_is][in] */                        DWORD *pdwPropertyIDs,
/* [size_is][size_is][out] */            VARIANT **ppvData,
/* [size_is][size_is][out] */            HRESULT **ppErrors
)
try
{
    ....
    CoArray<CComVariant> data(dwCount);
    CoArray<HRESULT> errors(dwCount);
    ....тут можно творить что угодно...
    *ppvData=data.Detach();
    *ppErrors=errors.Detach();
    return S_OK;
}
com_catch_all()//Ловит определенный типы исключений, достает из них HRESULT и возвращает. 
//Если прилетело не поймешь что просто возвращает E_FAIL

А тебе на дельфях слабо?
S>Или включеннии объекта в спсок который при уничтожении вызывает деструктор каждого внедренного объекта.
Вот еще

Короче извращаться с нетипизированой памятью можно и на асме для этого не нужен ЯВУ, а дельфя именно на это звание претендует.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 10.09.03 20:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я тебе очень рекомендую для прочтения Object Pascal Reference из комплекта Delphi. Тогда тебе станет понятно, о чем идет речь. Нельзя слепо применять термины в трактовке одного языка к другому языку. То, что в С++ не бывает виртуальных конструкторов и нет понятия "указатель на класс", не есть универсальное свойство ООП.

А оно РЕАЛЬНО надо? Почему бы просто не сотворить абстрактную фабрику?
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 10.09.03 23:52
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Но если я захотел изменить (добавить) функциональность для конкрентого типа, которая для других типов не нужна ????? Есть в шаблонах наследование ???


Есть, конечно. Надо — пользуйся. Есть и наследование и более экономный механизм — специализация. Конкретную специализацию можно и допилить, если не устраивает обобщённый вариант. Нередко это закладывается ещё при проектировании шаблона.

Ну, например:


template<typename T>
class X
{
    T m_t;
  // ...
  public:
    void some_operation();
};


// Это - общая структура операции для всех типов-аргументов T
template<typename T>
void X<T>::some_operation() { m_t = m_t * 2; }

// Теперь сделаем специализацию для some_operation()
// для некоего отдельного типа, например int
template<>
void X<int>::some_operation() { m_t = m_t / 2; }

// Всё, теперь для такого экземпляра:
X<int> x1;
// ... в вызове some_operation(), m_t будет делиться на 2, а для таких:

X<float> xf; X<double> xd;
// m_t будет умножаться на 2


S> Объясню подробнее. Есть база 1С. На основании метаданных можно построить объекты для прямого доступа к файлам опирающихся на несколько связанных таблиц от базового объекта. Решение через формирование исходников есть http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019.

S> Как такую проблему можно решить через шаблоны????

Можно и исходники сгенерировать, только их скомпилить потом отдельно нужно.

Хотя, конечно, можно и не генерировать исходников, а просто воспользоваться чтением описания БД и компоновкой предварительно скомпилированных объектов, обрабатывающих доступ к отдельным полям.

Шаблоны могут помочь здесь тем, что позволят или сильно сократить объём генерируемого кода или вообще отказаться от какой-либо генерации дополнительным средством, ограничившись почти что одним только перечислением имён полей и их типов непосредственно в программе на C++, особенно, если воспользоваться ещё и препроцессором... сахара ради...

Проблема в другом, в том, что нужно ещё знать: кто и как результатами генерации будет пользоваться. Иначе зачем со всем этим возиться?

А потому лучше решать задачу с противоположной стороны. Не "от файлов", а "от программы". Не файлы, а вернее — внешние хранилища данных определяют структуру классов, а структура классов определяет наиболее приемлемые способы их хранения.

Поясню подход подробнее. Есть задача. Есть её объектная декомпозиция, сделанная исходя из требований задачи и квалификации проектировщика. Есть некое хранилище, к которому, возможно, надо адаптироваться. Или десяток разных хранилищ, к которым тоже надо адаптироваться. Исходя из декомпозиции строим адаптеры к той или иной БД. Всё!

S> Это не "Понты" а практический вопрос, т.к. по понятной причине не имею с ними практики. Заранее благодарен за ответ.


Ну, если помог, то — пожалуйста.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 03:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А уж как я реализовал сериализацию...

Вот по поводу сериализации — не надо. В дельфи она уже есть. Достаточно объявить проперть как published, чтобы ее можно было сериализовать автоматом. Это отстает от .NET, но извините — технологии уж 10 лет как. А в плюсах ты, как ни парься, должен писать код руками.
Со всем остальным согласен
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 04:41
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>А уж как я реализовал сериализацию...

S>Вот по поводу сериализации — не надо. В дельфи она уже есть. Достаточно объявить проперть как published, чтобы ее можно было сериализовать автоматом. Это отстает от .NET, но извините — технологии уж 10 лет как. А в плюсах ты, как ни парься, должен писать код руками.
Особенно мне нравится вот это.(дельфи под рукой нет из хелпа к билдеру)

No constructors or destructors are allowed in a __published section. Properties, Pascal intrinsic or VCL or CLX derived data-members, member functions, and closures are allowed in a __published section. Fields defined in a __published section must be of a class type. Properties defined in a __published section cannot be array properties. The type of a property defined in a __published section must be an ordinal type, a real type, a string type, a small set type, a class type, or a method pointer type.

К томуже страдает инкапсуляция, да и с производительность если мне не изменяет сколероз проблемы...
Моя сериализация расширяется легко и на что угодно, поддерживает версии...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 05:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

Поля публиковать особого смысла нет. Это как раз и есть потеря инкапсуляции. Дырка для ссылок на объекты оставлена для специального случая дизайна форм. Я бы сделал по-другому, но в старые времена предпочли добавить такую штуку усложнению среды.
WH>К томуже страдает инкапсуляция,
В каком-то смысле да. Но там вся система сериализации строится на предположении, что набор значений хранимых свойств однозначно определяет состояние объекта.
WH>да и с производительность если мне не изменяет сколероз проблемы...
Это верно. Я бы с большим удовольствием получил документацию на Dll компилятора, которая используется в среде Delphi. Это позволило бы генерировать код в рантайме, и он был бы не менее быстрым, чем плюсовый. Но увы.
WH>Моя сериализация расширяется легко и на что угодно, поддерживает версии...
Не знаю, что такое "на что угодно", но про поддержку версий — согласен. Ясно, что при изменении описания класса мы огребем... Хотя, если честно, это все-таки архитектурный косяк. Вот мы сериализовали обезъяну, а потом восстановили ее как человека. Ну не бред ли? Это не описание человека. Даже если оба класса случайно называются "примат". Но это долгая дискуссия теоретического плана. А на практике удобнее иметь версионность в сериализаторе.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 05:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Поля публиковать особого смысла нет. Это как раз и есть потеря инкапсуляции. Дырка для ссылок на объекты оставлена для специального случая дизайна форм. Я бы сделал по-другому, но в старые времена предпочли добавить такую штуку усложнению среды.

Зачем публиковать? Мой сериализатор может сериализовать приватные поля.

WH>>Моя сериализация расширяется легко и на что угодно, поддерживает версии...

S>Не знаю, что такое "на что угодно",
А привел кусок кода который включает поддержку сериализации vector'ов. Аналогично можно добавить сериализацию любого контейнера лаже не существовавшего в момент написания библиотеки.
S>но про поддержку версий — согласен. Ясно, что при изменении описания класса мы огребем... Хотя, если честно, это все-таки архитектурный косяк. Вот мы сериализовали обезъяну, а потом восстановили ее как человека. Ну не бред ли? Это не описание человека.
Обычно происходит так: Описаваем человека имя, фамилия, пол, рост, вес. Черед некоторое время выяснилось что надо еще цвет глаз, цвет волос. Еще через некоторое время понадобился IQ...
S>Даже если оба класса случайно называются "примат". Но это долгая дискуссия теоретического плана. А на практике удобнее иметь версионность в сериализаторе.
Во-во. Особенно если не делать из обезьяны человека.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 11.09.03 06:30
Оценка:
Здравствуйте, Joker6413, Вы писали:

J>То есть реализации методов нет но сконструировать можно, хоть указывает черт знает куда но можно использовать? Так в C еще проще было пишу void *ptr = 0; и опа! у меня создан объект абстрактного класса? Могу его пользовать...


Не чёрти-куда, а на заглушку. Которая сообщит об ошибке, если программись проморгает. Интерфейсы не сразу появились.

J>Что за бред? Ты вообще понимаешь что такое конструктор? И что за указатель на класс? Ты про метакласс говоришь или все таки про объект класса?


Есть экземпляры класса, есть класс с методами, свойствами, событиями, конструкторами и деструктором.

Указатель на класс — это типа ссылка на экземпляр, переменная, имеющая тип того или иного класса.
... << RSDN@Home 1.1 beta 3 >>
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 11.09.03 06:30
Оценка:
Здравствуйте, Joker6413, Вы писали:

S>>Я тебе очень рекомендую для прочтения Object Pascal Reference ...


J>Ладно сорри, увлекся holy war...


Ну правда, как можно рассуждать о другом языке (синтаксисе, шаблонах решений и т.п.), элементарно с ним не познкамившись... Надо книжку почитать, пописать что-нить, потом уже сравнивать, но не в плоскости хорошо-плохо (потому как выливается в привычно-не привычно), а в плоскости "что соответствует/похоже" и как это можно применить.
... << RSDN@Home 1.1 beta 3 >>
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 11.09.03 06:30
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Почему? Кто сказал, что на Дельфи нельзя написать компактное и быстрое приложение?


Правильно. Можно. Используем компилятор, Windows.pas и ещё немного, не используем ООП и классы — и получаем в итоге дёшево и сердито.

А можно задействовать классы, и написать библиотеку, аналогичную по функциональности официальной VCL, но с требуемой компактностью. Пример: KOL.
... << RSDN@Home 1.1 beta 3 >>
Пример того как
От: akasoft Россия  
Дата: 11.09.03 06:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Производительность. Типобезопасность. Гарантия удаления объекта.

WH>Нука напиши как будут выглядить удаление группы объектов в твоейсистеме на дельфях?
WH>...

Ну, например, используя TCollection и TCollectionItem.

Делаем свой итем, если не нужно бОльшей функциональности, а для примера — не нужно, то коллекцию не трогаем.

type
    TMyItem = class(TCollectionItem)
    ...
    end;


теперь создаём, и так далее...

var
    C: TCollection;
    Item: TMyItem;
begin
    C := TCollection.Create(TMyItem);
    Item := C.Add; // Создаём и добавляем
    with Item do
    begin
        // Модифицируем
    end;
    C.Clear; // Удаляем с гарантией корректности
    for i := 0 to C.Count - 1 do
        with C.Items[i] do
        begin
            // Перебираем
        end;
... << RSDN@Home 1.1 beta 3 >>
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 11.09.03 06:30
Оценка:
Здравствуйте, centurn, Вы писали:

C> Да разница, собственно, в том, что драйвер и операционку ты просто никак на делфях не напишешь, принципиально. Ну кроме, возможно, того извращенческого маневра, что тут про драйвера говорили...


Это не проблема языка, это проблема конкретной реализации. Ну не позционирует Борланд свой этот инструмент, как на все случаи жизни...

C>А в шутере нужна максимальная производительность, которой в делфях и не пахнет. И дело даже не в качестве компилятора, а в том, что в С++ можно более тонко управлять тем, что тебе сделает компилятор.


Ой, неправда. Оптимизатор кода и в Дельфи есть, и неслабо оптимизирует. А если вопрос в том, где больше не всякому понятных галочек и рюшечек, так...

C> И на надо платить за то, что тебе не сейчас не нужно — это было и остается чуть ли не самым главным при развитии С++. И главное — не в ущерб функциональности.


Для С++ — да, возможно. Не спорю. Дельфи тоже в трёх редакциях поставляется. Покупаем стандарт, самую дешёвую, и юзаем Сеть, покупаем библиотеки по мере необходимости.

C> Короче, шутер на делфах можно сделать, но на это уйдет намного больше времени, чем на С++, ...


А потому, что надо будет найти .pas эквиваленты граф. бибилиотеки (DirectXx, OpenGlx), теорию изучить... А если это уже есть, найдено, тогда неправда ваша.

C> ...и будет этот шутер похож на слайд-шоу под аккомпанемент жутко свопящего винта.


Не будет. Это же дуалистический принцип использования сельскохозяйственных орудий на гидроповерхности...

C> ...Во-первых, я задолбался переводить структурки, используемые для общения с NetBios, с С на Pascal (кстати, С-шные структырки были в хелпе по WinAPI, поставляемом с Делфями, других я не нашел).


И чья это проблема? Языка? IDE? Борланда? Или моя? Вот, вот! Производители этих всяких API, пользуясь своей монопольность, чхать хотели на программистов-дельфинистов... Не замечаете аналогию с ОС?

C> ... А во-вторых в парочке мест я уже, грязно матерясь, просто сорвался на ассемблерные вставкм, т.к. не хватило терпения воротить все эти конструкции на паскале...


Всё же это от незнания либо от цейтнота, когда "давай, давай, чего телешся...".

C> И еще, раз уж меня потянуло кнопки понажимать...

C>... Я не буду по этому поводу приводить особых аргументов, т.к. удобство все-таки понятие чисто субъективное, ...

И что из этого следует? Всё то же — монополизм на API. А как же разные подходы, взгляд со стороны, альтернатива?

C>И еще мысль: практически не бывает "чистого" GUI, обычно за ним стоит еще нетривиальный код (иначе вообще непонятно, зачем нужен нужен язык программирования).


Соглашусь, что код стоит. Несомненно. В то же время есть абстракция, когда я скажу "лабел", у всех в мозгу возникнет почти одинаковый образ.
... << RSDN@Home 1.1 beta 3 >>
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 11.09.03 06:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Особенно мне нравится вот это.(дельфи под рукой нет из хелпа к билдеру)...


Ну сказано же, 10 лет, тянут совместимость, как резину.

А вот плюнули на неё и перевели бы XML — можно было бы и арраи сериализовать, и ещё что...

WH>Моя сериализация расширяется легко и на что угодно, поддерживает версии...


Хи-хи, так в C# это заложено изначально, как требование. Им тянуть совместимость не надо... Поживём-ка хотябы и лет пять, посмотрим...
... << RSDN@Home 1.1 beta 3 >>
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 08:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:


DOO>>По-моему есть warning. Но сейчас сказать точно не могу.

WH>Зачем варнинг? Это же стопроцентная ошибка.
Ну, не совсем. Дело в том, что в Delphi в любом случае вполне законным способом можно сконструировать объект абстрактного класса. Поэтому они и сделали Warning, а не Error — толку бы все равно не было.
Вообще, конечно, на мой взгляд, тут у них косяк. Я, когда столкнулся с этим их невнятным исключением, вынужден был слегка похакать, в результате чего и напсиал свою статью. Ибо есть довольно-таки трудноуловимые ситуации, которые бы борланду было не так и сложно разрулить.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: Аноним  
Дата: 11.09.03 09:21
Оценка:
Здравствуйте, akasoft, Вы писали:


A>Дельфи — это конкретная реализация, (ещё FreePascal, BP,...) аки Студия, Билдер,


если верить фирме борланд, то начиная с 7 версии делфи — это язык ...
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 09:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>Зачем публиковать? Мой сериализатор может сериализовать приватные поля.

S>Дельфийский тоже. Для этого оставлен ровно такой же выход — можно перегрузить некий метод, и в нем сделать все, что захочется. Именно так сериализуются всякие штуки типа картинок, у которых нет публичных свойств, отвечающих за контент. Просто часть работы уже берет на себя компилятор.
Ага! Это получается в общем случае для каждого приватного поля (а в нормальных архитектурах все поля приватные) свой паблишед метод. Этож работы будет больше чем на С++ + тормоза...

WH>> Аналогично можно добавить сериализацию любого контейнера лаже не существовавшего в момент написания библиотеки.

S>Ну естественно. Ведь контейнер — это класс
Дельфевые контейнеры это отдельная песня заслужившая очень много мата.
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Пример того как
От: WolfHound  
Дата: 11.09.03 09:24
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Ну, например, используя TCollection и TCollectionItem.

Ага! Через задницу.
A>Делаем свой итем, если не нужно бОльшей функциональности, а для примера — не нужно, то коллекцию не трогаем.
А если нужно?
A>
A>type
A>    TMyItem = class(TCollectionItem)
A>    ...
A>    end;
A>

Ага. Это каждай объект который я хочу хранить я коллекции должен быть наследником TCollectionItem
A>теперь создаём, и так далее...
Если мне не изменяет скалероз то так
A>
A>var
A>    C: TCollection;
A>    Item: TMyItem;
A>begin
A>    C := TCollection.Create(TMyItem);
A>    Item := C.Add as TMyItem; // Создаём и добавляем
A>    with Item do
A>    begin
A>        // Модифицируем
A>    end;
A>    C.Clear; // Удаляем с гарантией корректности
A>    for i := 0 to C.Count - 1 do
A>        with C.Items[i] as TMyItem do
A>        begin
A>            // Перебираем
A>        end;
A>

Те каждый раз происходит ДИНАМИЧЕСКОЕ привидение тапа

Дельфевые коллекции это пародии на коллекции. Тормозные не типизированые...
... << RSDN@Home 1.1 alpha 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 09:56
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Ага! Это получается в общем случае для каждого приватного поля (а в нормальных архитектурах все поля приватные) свой паблишед метод. Этож работы будет больше чем на С++ + тормоза...
Для этого сделан специальный способ замапить проперть прямо на поле, минуя метод. Да, это сделано из-за ограничений на автоinlining. В большинстве случаев плюсовый компилятор сам бы просек, что к чему, но у него есть возможность "видеть" исходный код этих методов.
WH>Дельфевые контейнеры это отдельная песня заслужившая очень много мата.
Я бы сказал — штука специфическая. С другой стороны, это проблемы VCL. Можно сделать их намного приятнее. Хотя для value-типов в общем случае это все приводит к Copy-Paste из-за отсутствия template. В общем, не будем о них. Хреновые там контейнеры.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 11:03
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>Ага! Это получается в общем случае для каждого приватного поля (а в нормальных архитектурах все поля приватные) свой паблишед метод. Этож работы будет больше чем на С++ + тормоза...

S>Для этого сделан специальный способ замапить проперть прямо на поле, минуя метод.
S>Да, это сделано из-за ограничений на автоinlining. В большинстве случаев плюсовый компилятор сам бы просек, что к чему, но у него есть возможность "видеть" исходный код этих методов.

ЧДТ на реальных иерархиях от дельфевого сериализатора толу нет.(в смысле по сравнению в плюсовым не дает преймуществ)
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 11:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>ЧДТ на реальных иерархиях от дельфевого сериализатора толу нет.(в смысле по сравнению в плюсовым не дает преймуществ)

S>Э-э, парень. Вот тут ты не прав. Сериализатор чего угодно в XML на дельфи пишется за один день. При этом ни строчки пользовательского кода править не надо. Преимущество — скорость разработки. Код, который ты привел, научить сериализовать в XML невозможно (в хуман-ридабле, ессно. в СDATA, ясен хрен, ты запихаешь и не такое
S>А сейчас, увы, рулит Time To Market.
struct some_type
{
    std::string name;
    std::vector<std::string> vec_str;
    std::vector<int> vec_int;
    std::vector<std::vector<std::string> > vec_vec_str;
    XML_SERIALIZE()
    {
        serializer
        .version(1)
            serialize(name)
            serialize(vec_str)
        .version(2)
            serialize(vec_int)
            serialize(vec_vec_str)
        ;
    }
};

Это хуман ридебел? Если да то за день легко.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 11:34
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Sinclair, Вы писали:


WH>
WH>struct some_type
WH>{
WH>    std::string name;
WH>    std::vector<std::string> vec_str;
WH>    std::vector<int> vec_int;
WH>    std::vector<std::vector<std::string> > vec_vec_str;
WH>    XML_SERIALIZE(some_type)
WH>    {
WH>        serializer
WH>        .version(1)
WH>            serialize(name)
WH>            serialize(vec_str)
WH>        .version(2)
WH>            serialize(vec_int)
WH>            serialize(vec_vec_str)
WH>        ;
WH>    }
WH>};
WH>

WH>Это хуман ридебел? Если да то за день легко.
И получаем что-то типа
<some_type>
    <string name="name">
        asdasd
    </string>
    <vector name="vec_str">
        <string>
            asdasd
        </string>
        <string>
            asdasd
        </string>
    </vector>
    <vector name="vec_int">
        <int val=123/>
        <int val=123/>
        <int val=123/>
    </vector>
    <vector name="vec_vec_str">
        <vector>
            <string>
                asdasd
            </string>
            <string>
                asdasd
            </string>
            <string>
                asdasd
            </string>
        </vector>
        <vector>
            <string>
                asdasd
            </string>
            <string>
                asdasd
            </string>
        </vector>
    </vector>
</some_type>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 11.09.03 12:42
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>если верить фирме борланд, то начиная с 7 версии делфи — это язык ...


Это раньше на неё молиться можно было, а сейчас... Не верим мы ей. После того, как она шкуру сменить на Инпри-изе (произносится с чувством, с которым произносится пИ-Иво братьями из-за границы за окном в одноимённом анекдоте) пыталась, мы осторожничаем.

Всё это маркетинговые ходы менеджеров...
... << RSDN@Home 1.1 beta 3 >>
Идём дальше
От: akasoft Россия  
Дата: 11.09.03 12:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

Ну, хорошо. Три вопроса...

Скажи, практика использования инструмента "Дельфи" у тебя большая?

А оная, связанная с "C++"?

С чем из этих двух ты познакомился раньше?

Очень хочется тебя поближе (произносится, как Каа обезьянам третий раз) узнать, потому и спрашиваю. Не для стёба.

A>Ну, например, используя TCollection и TCollectionItem.

WH>Ага! Через задницу.

Для меня это естественно (Естественно, что естественно не "...Через задницу", а использовать TCollection и TCollectionItem). Более того, наглядно понятно. ООП. А запись шаблона смотрится, как на китайском языке. Но это потому, что я с ними не знаком, не пользовал ещё в практике...

A>>Делаем свой итем, если не нужно бОльшей функциональности, а для примера — не нужно, то коллекцию не трогаем.

WH>А если нужно?

Наследуем и добавляем функционал.

WH>Ага. Это каждай объект который я хочу хранить в коллекции должен быть наследником TCollectionItem ...


Ну да. Ты, похоже иерархию не прочувствовал. Всё наследуется от одной базы. Не нравится что? То, что это именно Коллекция, заточенная под ИДЕ? Так нет проблем, по аналогии клепаем свой базовый класс итемов и коллекций, и работаем. Это же 2 мин копи-пастом, где 1,5 мин. марафет наводить и комментарии писать. Чем это хуже? Копи-паст сакс — не аргумент никакой.

Или не нравится, что от одной базы? Ну так, меняем инструмент... Или осваиваем, проникаемся, и понятия "нравится-не нравится, люблю-не навижу" уходят на восьмой план... Появляется "пофигу"...

WH>Те каждый раз происходит ДИНАМИЧЕСКОЕ привидение тапа ...


Не нравится, значит, как я код изложил. Так моей целью была не оптимизация, а демонстрация. Давай так.

Посмотрим-ка, что нам окошечко CPU да и выдаст...

На

    Item := Add as TMyItem; // Создаём и добавляем


mov    eax, [ebp-$0c]
call    TCollection.Add
mov    edx, [$00467204]
call    @AsClass
mov    [ebp-$08], eax


а вот на

    Item := TMyItem(Add); // Создаём и добавляем


уже

mov    eax, [ebp-$0c]
call    TCollection.Add
mov    [ebp-$08], eax


Второй способ использования насчитывает больше лет практики, когда is и as не было.

Я уже не говорю о разработке собственной пары классов, заточенной под мои нужды. Один раз разрабатываю, много раз юзаю. Шаблоны кто-то тоже разрабатывал. Не 10 сек.

WH>Дельфевые коллекции это пародии на коллекции...


Опять же, почему? Это инструмент для работы в Инспекторе. Я, объявив published свойство (или поле) в классе, без никаких доп. затрат получаю возможность редактировать его в дизайн-тайме. Цель, которая ставилась перед инструментом, достигнута.

WH>... Тормозные не типизированые...


И в чём тормоза, см. код на асме выше. Не типизированность отметаем, мы объявляли

var
    Item: TXItem;
    C: TCollection;


типы указаны.
... << RSDN@Home 1.1 beta 3 >>
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.09.03 16:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

Круто, если это и вправду возможно. А как это будет работать? Откуда сериализатор возьмет имена для тэгов?
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 11.09.03 18:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Круто, если это и вправду возможно. А как это будет работать? Откуда сериализатор возьмет имена для тэгов?

Имена типов добавим в
template<class Type, class Allocator>
struct serialize_save_load<std::vector<Type, Allocator> >
{
        typedef std::vector<Type, Allocator>    container;
        typedef typename container::size_type    size_type;
        template<class T>
        static void save(T& st, const container& cont)
        {
...
        }
        template<class T>
        static void load(T& st, container& cont)
        {
...
        }
        //Что-то вроде
        static const char* get_type_name()
        {
            return "vector";
        }
};

А имена полей можно получить используя препроцессор
#define serialize(name).record(#name, name)

А дальше просто немного перерабатываем ядро чтобы создавал XML, а не бинарный поток.

Примерно так. Мне сейчас не до того. Потом возможно сделаю.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 11.09.03 18:58
Оценка:
Здравствуйте, AlexK, Вы писали:

Сразу оговорюсь, что считаю, что есть только язык OP, а Дельфи — это одно из его воплощений.

AK>1. Делфи без своей библиотеки VCL как язык вообще не рассматриваеться!


OP существует независимо от VCL. Что мы теряем, убирая VCL? Быструю визуальную разработку? Ну и шут с ней. Зачем нам не нужна VCL? Большая и не поворотливая, куча лишнего функционала?.. Замечательно. Берём за основу Class TObject и пишем свою иерархию, свою реализацию, всё своё. А-а-а, не хватает визуальности. Тогда разбираемся и пишем эксперта, который будет помогать нам с помощью драг-энд-дропа двигать мышкой уже наши классы.

Пример: KOL. Не так уж это и трудно. Был бы смысл, и можно сделать RSDNL...

AK>... потому как просто языки под разные темы заточенны!


Истинно так! У каждого своя ниша.

AK>Delphi — абстракция, начальная алгоритмистика.


+ близость к человеческой (английской) речи, та же алгоритмистика, прикладные программы...

AK>... язык придумал только для обучения студентов.


Вот, кстати, интересно, как так получилось, что Борланд его подхватил и довёл до сегодняшнего состояния?..
Чего он его подхватил, тянул бы лямку C/++, как все...
... << RSDN@Home 1.1 beta 3 >>
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: AlexK Украина  
Дата: 12.09.03 06:25
Оценка:
Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, AlexK, Вы писали:

AJD> автор Паскаля сказал что свой язык придумал только для обучения студентов.

AJD>Однако на паскале писали популярные операционные системы...


честно говря в первые слышу... просвети темного человека, т.е. меня... что же это на Паскале из ОС'ок писали?
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 12.09.03 06:58
Оценка:
Здравствуйте, AlexK, Вы писали:

AJD>>Однако на паскале писали популярные операционные системы...

AK>честно говря в первые слышу... просвети темного человека, т.е. меня... что же это на Паскале из ОС'ок писали?
Он наверно про ту байку что винду начинали писать на паскале.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.09.03 09:25
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Serginio1, Вы писали:


S>> Но если я захотел изменить (добавить) функциональность для конкрентого типа, которая для других типов не нужна ????? Есть в шаблонах наследование ???


ГВ>Есть, конечно. Надо — пользуйся. Есть и наследование и более экономный механизм — специализация. Конкретную специализацию можно и допилить, если не устраивает обобщённый вариант. Нередко это закладывается ещё при проектировании шаблона.


ГВ>Ну, например:


ГВ>

ГВ>template<typename T>
ГВ>class X
ГВ>{
ГВ>    T m_t;
ГВ>  // ...
ГВ>  public:
ГВ>    void some_operation();
ГВ>};


ГВ>// Это - общая структура операции для всех типов-аргументов T
ГВ>template<typename T>
ГВ>void X<T>::some_operation() { m_t = m_t * 2; }

ГВ>// Теперь сделаем специализацию для some_operation()
ГВ>// для некоего отдельного типа, например int
ГВ>template<>
ГВ>void X<int>::some_operation() { m_t = m_t / 2; }

ГВ>// Всё, теперь для такого экземпляра:
X<int>> x1;
ГВ>// ... в вызове some_operation(), m_t будет делиться на 2, а для таких:

ГВ>X<float> xf; X<double> xd;
ГВ>// m_t будет умножаться на 2

ГВ>


S>> Объясню подробнее. Есть база 1С. На основании метаданных можно построить объекты для прямого доступа к файлам опирающихся на несколько связанных таблиц от базового объекта. Решение через формирование исходников есть http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019.

S>> Как такую проблему можно решить через шаблоны????

ГВ>Можно и исходники сгенерировать, только их скомпилить потом отдельно нужно.


ГВ>Хотя, конечно, можно и не генерировать исходников, а просто воспользоваться чтением описания БД и компоновкой предварительно скомпилированных объектов, обрабатывающих доступ к отдельным полям.


Можно но при этом есть потеря в скорости, т.к. доступ к полю записи нужно стоить через посредника а не напрмую по известеому смещению и типе поля еще на этапе компиляции, да и при загрузке таблици нужно выделять память под посредников. Скорость при это может падать аж в 4 раза. Здесь либо скорость, либо гибкость. Да и если посмотреть на то как в Net генерятся типизированные Table и Bold Soft тоже генерят исходники из схемы базы.

ГВ>Шаблоны могут помочь здесь тем, что позволят или сильно сократить объём генерируемого кода или вообще отказаться от какой-либо генерации дополнительным средством, ограничившись почти что одним только перечислением имён полей и их типов непосредственно в программе на C++, особенно, если воспользоваться ещё и препроцессором... сахара ради...


ГВ>Проблема в другом, в том, что нужно ещё знать: кто и как результатами генерации будет пользоваться. Иначе зачем со всем этим возиться?


ГВ>А потому лучше решать задачу с противоположной стороны. Не "от файлов", а "от программы". Не файлы, а вернее — внешние хранилища данных определяют структуру классов, а структура классов определяет наиболее приемлемые способы их хранения.



ГВ>Поясню подход подробнее. Есть задача. Есть её объектная декомпозиция, сделанная исходя из требований задачи и квалификации проектировщика. Есть некое хранилище, к которому, возможно, надо адаптироваться. Или десяток разных хранилищ, к которым тоже надо адаптироваться. Исходя из декомпозиции строим адаптеры к той или иной БД. Всё!


Так и поступаю. По ссылочке http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019 там есть простенькое Иерархическое хранилище где пляс идет от "программы".

S>> Это не "Понты" а практический вопрос, т.к. по понятной причине не имею с ними практики. Заранее благодарен за ответ.


ГВ>Ну, если помог, то — пожалуйста.


Спасибо. Но перехожу на Net (C#) пока там шаблонов нет, но будут и как появятся буду обязательно использовать.
Но с другой стороны есть возможность генерации и компиляции объектов на лету. Понятно, что шаблоны вещь мощная и не понятно почему они не внедряются в другие языки (не вижу особых проблем, как Inline и смартпоинтеры). Посмотрим, что выдаст Борланд в конце года.
и солнце б утром не вставало, когда бы не было меня
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.09.03 09:42
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>Короче извращаться с нетипизированой памятью можно и на асме для этого не нужен ЯВУ, а дельфя именно на это звание претендует.


Для различного рода задач нужны свои инструменты. Шаблоны, Inline, сматрпоинтеры очень хорошая вещь которой мне не достает, но для различного рода задач можно абсолютно безболезненно без каких либо затруднений обходится без них. По поводу нетипизированой памяти то не вижу в этом криминала особенно при написании универсальных классов (функций) которые оперируют только размером записи, и писать шаблон нет никакого смысла.
С другой стороны не вижу абсолютно никакого смысла на данном этапе сравнивать умирающие технологии.
Лучше смотреть на Net, особенно когда огромный набор процессоров в том числе и 64 разрядных.
А все лучшие идеи должны использоваться в новых технологиях, в том числе и поизвращаться с нетипизированой памятью и там придется, но с большими трудностями.
и солнце б утром не вставало, когда бы не было меня
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: AndrewJD США  
Дата: 12.09.03 09:54
Оценка:
Здравствуйте, AlexK, Вы писали:


AK>честно говря в первые слышу... просвети темного человека, т.е. меня... что же это на Паскале из ОС'ок писали?


MAC OS. Ранние версии были вообще полностю на паскале. Для версий 8.х-9.х конечно много кода написано на С, но API остался паскалевский.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: AndrewJD США  
Дата: 12.09.03 09:54
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Он наверно про ту байку что винду начинали писать на паскале.


Да нет, я про MAC OS
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 12.09.03 10:18
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Для различного рода задач нужны свои инструменты. Шаблоны, Inline, сматрпоинтеры очень хорошая вещь которой мне не достает, но для различного рода задач можно абсолютно безболезненно без каких либо затруднений обходится без них.

Это где? В простеньком калькуляторе?
S>По поводу нетипизированой памяти то не вижу в этом криминала особенно при написании универсальных классов (функций) которые оперируют только размером записи, и писать шаблон нет никакого смысла.
А вот я вижу. Сырая память это потеря надежности, скорости,...
S> С другой стороны не вижу абсолютно никакого смысла на данном этапе сравнивать умирающие технологии.
Дельфя вимерает это факт, а вот на счет С++ это ты оочень зря.
S>Лучше смотреть на Net, особенно когда огромный набор процессоров в том числе и 64 разрядных.
Да смотрел я на него. Сырой.
S> А все лучшие идеи должны использоваться в новых технологиях, в том числе и поизвращаться с нетипизированой памятью и там придется, но с большими трудностями.
Вот только пока далеко не все лучшие идеи используются в шарпе.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: AlexK Украина  
Дата: 12.09.03 10:21
Оценка:
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, AlexK, Вы писали:
AK>>честно говря в первые слышу... просвети темного человека, т.е. меня... что же это на Паскале из ОС'ок писали?
AJD>MAC OS. Ранние версии были вообще полностю на паскале. Для версий 8.х-9.х конечно много кода написано на С, но API остался паскалевский.

не удивительно теперь почему Маки не в чести нынче...

по большому счету С, а не С++ единственный язык который портанут/написан под почти все платформы...
и он пока единственный вариант который дает приемлемое качество и скорости...

да вот еще один стандарт де факто:
— все операционки имеют в своем распоряжении CRT либу (набор минимальных функций, которые позволяют нормально програмить)
— паскаль такой либы не имеет и ссылаеться на системную... разумееться либа эта в основном написана на С или asm (QNX — пример)


а то что на паскале смогли написать — так это герои, которых желательно знать в лицо!
что лишний раз доказывает что не в языке дело, а в ДНК... или руках (смотря кому что роднее)
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.09.03 10:34
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>> Для различного рода задач нужны свои инструменты. Шаблоны, Inline, сматрпоинтеры очень хорошая вещь которой мне не достает, но для различного рода задач можно абсолютно безболезненно без каких либо затруднений обходится без них.

WH>Это где? В простеньком калькуляторе?

Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше. Да и API написан на Asme и С где типизацией если и пахнет то ...
Зачем огульно бросаться словами??? Не прав.
S>>По поводу нетипизированой памяти то не вижу в этом криминала особенно при написании универсальных классов (функций) которые оперируют только размером записи, и писать шаблон нет никакого смысла.
WH>А вот я вижу. Сырая память это потеря надежности, скорости,...

Все можно достаточно хорошо оптимизировать, для этого голова и дана, а не только пользоваться "шаблонами" в прямом смысле этого слова.
S>> С другой стороны не вижу абсолютно никакого смысла на данном этапе сравнивать умирающие технологии.

WH>Дельфя вимерает это факт, а вот на счет С++ это ты оочень зря.


Время рассудит, но Delphi найдет свою нишу в Net да и у Delphi с C# намного больше общего чем у C# с С++, да и M$ помоему не особо горит желанием развивать Native компиляторы.

S>>Лучше смотреть на Net, особенно когда огромный набор процессоров в том числе и 64 разрядных.

WH>Да смотрел я на него. Сырой.

S>> А все лучшие идеи должны использоваться в новых технологиях, в том числе и поизвращаться с нетипизированой памятью и там придется, но с большими трудностями.

WH>Вот только пока далеко не все лучшие идеи используются в шарпе.
Например???? Шаблоны будут, что еще???
и солнце б утром не вставало, когда бы не было меня
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: AndrewJD США  
Дата: 12.09.03 11:06
Оценка:
Здравствуйте, AlexK, Вы писали:


AK>да вот еще один стандарт де факто:

AK>- все операционки имеют в своем распоряжении CRT либу (набор минимальных функций, которые позволяют нормально програмить)
AK>- паскаль такой либы не имеет и ссылаеться на системную... разумееться либа эта в основном написана на С или asm (QNX — пример)

ИМХО — это предрассудки. CRT либа может быть с успехом написана на паскале. Это просто зависит от реализации компилятора. То что паскаль от борланда юзает высокоуровневое API, еще не значит что паскаль _в_принципе_не_мевозможно писать низкоуровневый код (конечно это не так удобно, как на С).


AK>а то что на паскале смогли написать — так это герои, которых желательно знать в лицо!

AK>что лишний раз доказывает что не в языке дело, а в ДНК... или руках (смотря кому что роднее)

Эт верно
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 12.09.03 11:07
Оценка:
Здравствуйте, AlexK, Вы писали:

AK>...что лишний раз доказывает что не в языке дело, а в ДНК... или руках (смотря кому что роднее)


Да нет, дело в рынке.

Ну зачем писать 2 либы, делающие одно и тоже, но на двух языках. Представляете, ядро Windows, написанное на C, и то же самое, но на Fortran-е...

Буржуины началали первыми, а деньги они на ветер не бросают. Не прибыльно это дело. Куда проще сделать одну, а потом к ней описалово дать, ну или там заголовочные файлы для нескольких языков дать...

Отладка одна сколько сил отнимет...
... << RSDN@Home 1.1 beta 2 >>
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 12.09.03 13:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Дельфя вимерает это факт...


"Какие ваши доказательства?!!"

Категорически не согласен. 10 лет работает OP. То, чем мы пользуемся сейчас, придумано когда?.. А... давно придумано. И инструментом для решения определённых задач быть не перестало.

Ложку когда придумали? И что, плохой инструмент и лучше вилкой? Или палоником суп хлебать? Так это на любителя.

Не развивается качественно — да, соглашусь. Одно количество прёт.

Мне кажется, Борланды средства распыляют: Дельфи, Билдер, Куликс, Болд, БДЕ, ИБ, ...

А если бы взяли направление, сделали, перевели средства на другое, опять сделали и т.п. С начала и до ума.

Ностальгия: какой BP7 был, "трёхплатформенный"... А BCPP...
... << RSDN@Home 1.1 beta 2 >>
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 12.09.03 13:25
Оценка:
Здравствуйте, akasoft, Вы писали:

WH>>Дельфя вимерает это факт...

A>"Какие ваши доказательства?!!"

Да очень просто. Дельфи занимала нишу приложений с оочень большим колличеством формочек. Грубо говоря ГУЙ к БД. Сейчас туда пришол C# который делает дельфю по всем параметрам. Он даже частично С++ потеснил.

А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.09.03 13:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, akasoft, Вы писали:


WH>>>Дельфя вимерает это факт...

A>>"Какие ваши доказательства?!!"

WH>Да очень просто. Дельфи занимала нишу приложений с оочень большим колличеством формочек. Грубо говоря ГУЙ к БД. Сейчас туда пришол C# который делает дельфю по всем параметрам. Он даже частично С++ потеснил.


WH>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.


Уважаемый WolfHound, то что Delphi уступает в своем развитии C++ Вам уже много раз говорили. Но это еще не значит, что это уже мертвый Язык. В свое время когда появился первый Паскаль, еще помню писал на ДВК-2 типизация, различные конструкции были намного богаче чем в других языках в том числе и С. (правда в отличие от Васика уж очень долго проходила компиляция, но зато скорость выполнения покрывала все издержки). Но прошло время и тоже появилось и в других языках, но остались и Анахронизмы. Новый Виток новые языки, новые платформы. Если Delphi (в том числе и в Net) умрет, то не думаю, что это пойдет на пользу и Вне конкуренции M$ не особо будет шевелиться.
А может они решили все силы кинуть на Net, что бы не разбрассываться ??? Лучше совсем немного подождать, а потом обратно вернуться к данному разговору.
и солнце б утром не вставало, когда бы не было меня
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 12.09.03 15:06
Оценка:
m>> Вот тебе тоже вопрос на тему как применить микроскоп для забивания
m>> гвоздей. Как в C++ отсортировать виндовый SafeArray, причём в режиме
m>> thread-safe?

S>Замечательный вопрос А как его вообще отсортировать, если часть объектов, что в нем лежат, могут оказаться многомерными массивами, часть — указателями на объекты (IDispatch), а остальные — типа currency


Ну так я о том же.

Шаблоны годятся для сортировки определённых входных данных. Что в C++, что в Delphi.
... << RSDN@Home 1.1 beta 1 >>
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 12.09.03 16:32
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Да очень просто. Дельфи занимала нишу приложений с оочень большим колличеством формочек. Грубо говоря ГУЙ к БД. Сейчас туда пришол C# который делает дельфю по всем параметрам. Он даже частично С++ потеснил.


Ну чего же к БД только. Дельфи позиционируется, как средство разработки прикладных приложений. К БД его повело только потому, что разработчик (Борланд) кроме средств разработки продвигал ещё и СВБД свои.

Для прикладывания Дельфи очень даже ничего.

WH>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.


Речь об "...OP против C++..." или "Дельфи против Студии"?
... << RSDN@Home 1.1 beta 2 >>
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 12.09.03 16:32
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>А может они решили все силы кинуть на Net, что бы не разбрассываться ??? Лучше совсем немного подождать, а потом обратно вернуться к данному разговору.


Нет, это чистой воды сговор, статья ... не помню, какая.

Борланд да Майкрософт в очередной раз решили поделиться/помириться. Потому что, каким бы ты Гигантом не был, а силёнок на всех не хватит.
... << RSDN@Home 1.1 beta 2 >>
Re[27]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 12.09.03 19:31
Оценка:
Здравствуйте, mihailik, Вы писали:

M>А чем TList не устраивает? Религиозные причины?

Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...
M>>>Или крутизна шаблонов как раз и заключается в работе со встроенными типами?
WH>>Не со встроеными, а со всеми.
M>А какие проблемы применить TList ко всем типам?
ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?

M>Хм. Ты хочешь сказать, что размер C-плюснутого кода в разы меньше Дельфийского? Что-то сомневаюсь.

Повторюсь

Например писал я OPC server там куча методов должны возвращать массивы созданные при помощи CoTaskMemAlloc. На С++ я за пять минут сотворил шаблон помошник который проверял былали выделена память, следил за выделеной памятью, инициализировал память и в случае чего вызывал деструкторы, а самое главное прикидывался массивом и уже когда все закончино и гарантировано не будет исключений я забирал заполненый массив и возвращал из функции.
Использование ваглядит примерно так

STDMETHODIMP COPCServer::GetItemProperties( 
/* [in] */                                LPWSTR szItemID,
/* [in] */                                DWORD dwCount,
/* [size_is][in] */                        DWORD *pdwPropertyIDs,
/* [size_is][size_is][out] */            VARIANT **ppvData,
/* [size_is][size_is][out] */            HRESULT **ppErrors
)
try
{
    ....
    CoArray<CComVariant> data(dwCount);
    CoArray<HRESULT> errors(dwCount);
    ....тут можно творить что угодно...
    *ppvData=data.Detach();
    *ppErrors=errors.Detach();
    return S_OK;
}
com_catch_all()//Ловит определенный типы исключений, достает из них HRESULT и возвращает. 
//Если прилетело не поймешь что просто возвращает E_FAIL

Такие помошники позволяют не задумоватся о исключениях, их использование прозрачно и не навязчиво, пишутся раз и навсегда.
Слабо на дельфях написить такого помошника?

M>Возможно, смартпойнтеры действительно помогают в разы — но только по сравнению с тем же C++ без смартпойнтеров. А в Дельфи и без них всё уже легко, аккуратно и прозрачно.

Ой не надо на дельфе начинается try finaly hell.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 12.09.03 19:31
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Для различного рода задач нужны свои инструменты. Шаблоны, Inline, сматрпоинтеры очень хорошая вещь которой мне не достает, но для различного рода задач можно абсолютно безболезненно без каких либо затруднений обходится без них.

WH>>Это где? В простеньком калькуляторе?

S> Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше.

И в какой БД ты не типизированую пимять нашол?
S>Да и API написан на Asme и С где типизацией если и пахнет то ...
И очень на прасно. Хотя в те времена когда это все писалось выбора небыло. К томуже это язаки низкого и среднего уровня, а мы про ЯВУ разговариваем.
S> Зачем огульно бросаться словами??? Не прав.
Нда? Смотри выделеное и скажи что из этого не нужно в ЯВУ? Разве что смартпоинтеры там где есть GC и то иногда хочется детерминированого управления жизнью объекта.

WH>>А вот я вижу. Сырая память это потеря надежности, скорости,...

S> Все можно достаточно хорошо оптимизировать, для этого голова и дана, а не только пользоваться "шаблонами" в прямом смысле этого слова.
Нда? Взять хотябы сортировку сравнение через вызов функции по указателю, swap также и что ты тут оптимизировать собрался?
Или писать сортировку под каждый тип?

S> Время рассудит, но Delphi найдет свою нишу в Net да и у Delphi с C# намного больше общего чем у C# с С++, да и M$ помоему не особо горит желанием развивать Native компиляторы.

Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.

WH>>Вот только пока далеко не все лучшие идеи используются в шарпе.

S> Например???? Шаблоны будут, что еще???
Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
А сейчас все очень убого. Почти на уровне дельфи.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 12.09.03 19:31
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Ну чего же к БД только. Дельфи позиционируется, как средство разработки прикладных приложений. К БД его повело только потому, что разработчик (Борланд) кроме средств разработки продвигал ещё и СВБД свои.

A>Для прикладывания Дельфи очень даже ничего.
Во первых я сказал грубо. Во вторых куда это ты ее приложить собрался? Уж не к задаче ли где 90% ГУИ? И всеравно против шарпа не тянет. Ну ни как.

WH>>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.

A>Речь об "...OP против C++..." или "Дельфи против Студии"?
Смотри сабж. Ну если так хочется можно ОП против С++. Ну и что изменится? В ОП от этого шаблоны не появится.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 12.09.03 19:31
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Уважаемый WolfHound,

Вот на вы переходить не надо выглядит так что драться собрался
S>то что Delphi уступает в своем развитии C++ Вам уже много раз говорили.
Я бы сказал безнадежно уступает. Если с этим ни кто не спорит то почему постоянно появляется какойнибудь "куул программер" который знает дельфю хуже меня(а я ее уже почти забыл и не желею)и начинает вопить С++ сакс?
S>Но это еще не значит, что это уже мертвый Язык.
И чтоже его может спасти? Добавят шаблоны, множественное наследование, приведут в порядок систему типов,...? И чем он тогда будет от С++ отличатся кроме небольшого различия в синтаксисе?
S>В свое время когда появился первый Паскаль, еще помню писал на ДВК-2 типизация, различные конструкции были намного богаче чем в других языках в том числе и С. (правда в отличие от Васика уж очень долго проходила компиляция, но зато скорость выполнения покрывала все издержки). Но прошло время и тоже появилось и в других языках, но остались и Анахронизмы. Новый Виток новые языки, новые платформы. Если Delphi (в том числе и в Net) умрет, то не думаю, что это пойдет на пользу и Вне конкуренции M$ не особо будет шевелиться.
С++ это язык для создания других языков. Причем при наличии определенных знаний и воображения это делается очень легко.
Например boost::sprit позволяет прямо на С++ записывать EBNF граматику.
A simple EBNF grammar snippet:

    group       ::= '(' expression ')'
    factor      ::= integer | group
    term        ::= factor (('*' factor) | ('/' factor))*
    expression  ::= term (('+' term) | ('-' term))*

is approximated using Spirit's facilities as seen in this code snippet:

    group       = '(' >> expression >> ')';
    factor      = integer | group;
    term        = factor >> *(('*' >> factor) | ('/' >> factor));
    expression  = term >> *(('+' >> term) | ('-' >> term));

Ну и естественно смартпоинтеры и прочие чернорабочие.
S>А может они решили все силы кинуть на Net, что бы не разбрассываться ??? Лучше совсем немного подождать, а потом обратно вернуться к данному разговору.
А какое отношение .NET имеет к сабжу?
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: По просьбам трудящихся: Delphi vs C++(VS)
От: VuDZ Россия  
Дата: 12.09.03 22:28
Оценка:
Ну-ну...
Может MS ещё ещё WinAPI для Cobol, Logo, php и пр.?..
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: VuDZ Россия  
Дата: 12.09.03 22:32
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Кстати, а много ли люди видали драйверов написанных на С++, а не на С?

DOO>MS сами рекомендуют невыеживаться и писать не на асмах и С++ дрова, а на обычном С. Да и хороший пример ОС разработанной на языке высокого уровня это *nix — между прочим тоже С, а не C++.

Э... типа... опаньки...
Если Вы не видели критичного ко времени софта, написанного на С++, не надо говорить, что его нет :]
почитайте Страуструпта — Дизай и эволюция С++ — если найдёте, и тогда поймёте многое, а вот такие высказывания — это полная чушь.
Re[20]: По просьбам трудящихся: Delphi vs C++(VS)
От: VuDZ Россия  
Дата: 12.09.03 22:39
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Вы не сталкивались просто с разработкой под DSP, RTOS-ы и Embedded платформы.


И что там такого особенного?
для ARM aDSP133 очсень корявый компилятор С++, но это не мешает его использовать....
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 14.09.03 09:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Вот на вы переходить не надо выглядит так что драться собрался

S>>то что Delphi уступает в своем развитии C++ Вам уже много раз говорили.

(Достал упорством...)

WH>Я бы сказал безнадежно уступает.


Я бы нет. А почему, ответил в нашей беседе.

WH>И чтоже его может спасти? Добавят шаблоны, множественное наследование, приведут в порядок систему типов,...?


Слухи о смерти сильно преувеличены, потому как есть инструмент, есть область применения того, что можно сделать инструментом, есть те, кто умеет пользоваться инструментом.

WH> И чем он тогда будет от С++ отличатся кроме небольшого различия в синтаксисе?


Давай кривую аналогию? На что похож компилятор с C++, пытающийся увеличить скорость компиляции...

Ещё одна. Почему французы упорно говорят на французском, немцы — на немецком, а мы на русском? Хотя, конечно, есть исключения...

WH>С++ это язык для создания других языков. Причем при наличии определенных знаний и воображения это делается очень легко.


Я тоже могу написать библиотеку для создания других языков по тому или иному принципу. Даже писал в своё время. Даже в Сети найти можно и не одну. Так что нет тут монополии у C++, плюс смотри выше.
... << RSDN@Home 1.1 beta 2 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 14.09.03 09:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Во первых я сказал грубо.


А ты не груби, , будь объективнее.

WH> Во вторых куда это ты ее приложить собрался? Уж не к задаче ли где 90% ГУИ?



Dll и Exe. То, что получается на выходе Дельфи. Этим многое сказано. И кроме того, уж не поклонник ли ты "лаконизму командной строки"? Не думаю, что надо объяснять, чего мы достигли в ПО и компьютерах благодаря G.U.I.

Так что это просто близость к человеку, удобному восприятию информации, удобной постановке задачи и получению результатов. Что такое "прикладная программа", думаю, понимаешь.

WH> И всеравно против шарпа не тянет. Ну ни как.


Не так. И вот почему. В существующих ОС (ну может Win2003 server исключение) нет встроенной поддержки .NET. Ну нет её. Надо качать да ставить фреймворк. Подавляемое большинство людей лениво и ничего качать не будет. Более того, скажет, что делать надо всё на существующей базе, потому как это вопрос денег, дополнительных денег. И, может быть, они и согласятся, как это круто — .NET, но ленивы и опять же деньги. "И что, скажут, вы без этого новомодного веяния не можете? Так мы к другим пойдём!..".

Так что сейчас C# сдерживается очень сильно. Вот пройдёт время, MS сделает ротацию своих линеек ОС... Тогда можно будет говорить о прогрессе C#. А так пока, как он ни хорош, другие средства разработки ничего не потеряли.

WH>>>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.


Ну а кто сейчас заботится об оптимизации? Студия 2003 стартует быстро, но открывает проект (Янус) ого-го как долго. Дельфи 7 стардует долго, зато проект (сравнимый по) открывает быстро. Уж не знаю, кт оиз них там всё перебирает, кто только открытые мною 8 окон. Это при том, что Студия для показа форм (design) подшуршовывает, а Дельфи нет.

WH>...В ОП от этого шаблоны не появится.


На Королевстве Дельфи читал, как с помощью include (используя простую type-подмену типов) можно достичь того же эффекта. Но это так, добавление. Ни сколько не пытаюсь аргументированно спорить по вопросу полезности шаблонов.
... << RSDN@Home 1.1 beta 2 >>
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: Аноним  
Дата: 14.09.03 11:23
Оценка:
Здравствуйте, alexkro, Вы писали:



A>Как я с тобой согласен! И в C# подобная дребедень. using немного спасает ситуацию, но только в самых простых случаях. Особенно меня прикалывает тот факт, что IDispose.Dispose() может выбросить исключение. После этого я не могу понять как на C# можно писать надежные программы.


Вот-вот. Тут народ что-то рассказывает про отсутствие в C# шаблонов, перегрузки некоторых операторов и прочей лабудени. В то время как (на мой взгляд) самый реальный шаг назад — отсутствие надёжного механизма детерминированного освобождения ресурсов. using нифига ситуацию не спасает, т. к.:
1) Каждый раз при создании объекта надо проверять поддержку IDisposable = лезть в MSDN. (Все классы не запомнишь.)
2) Попытки систематически использовать using приводят к конструкциям вида:
using(....) {
using(...) {
using(...) {
.
.
.
3) Dispose() может выбрасывать исключения
4) Рекомендательный характер вызова Dispose(). Поубивал бы за это . Dispose() в половине случаев оставляется самой FCL на попечение Finalize, который, разумеется, вызывается, когда мало памяти, а не того ресурса, которого не хватает.
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 06:48
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Dll и Exe. То, что получается на выходе Дельфи. Этим многое сказано. И кроме того, уж не поклонник ли ты "лаконизму командной строки"? Не думаю, что надо объяснять, чего мы достигли в ПО и компьютерах благодаря G.U.I.

Я недовно видел прогу написаную на WTL дельфи отдыхает.

WH>> И всеравно против шарпа не тянет. Ну ни как.

A>Не так. И вот почему. В существующих ОС (ну может Win2003 server исключение) нет встроенной поддержки .NET. Ну нет её. Надо качать да ставить фреймворк. Подавляемое большинство людей лениво и ничего качать не будет. Более того, скажет, что делать надо всё на существующей базе, потому как это вопрос денег, дополнительных денег. И, может быть, они и согласятся, как это круто — .NET, но ленивы и опять же деньги. "И что, скажут, вы без этого новомодного веяния не можете? Так мы к другим пойдём!..".
Ты еще скажи что дельфевый рантайм входит в поставку винды статическая линковка не хило утяжеляет ехешник что при частом обновлении софта выдет бОльшим траффиком.

A>Так что сейчас C# сдерживается очень сильно. Вот пройдёт время, MS сделает ротацию своих линеек ОС... Тогда можно будет говорить о прогрессе C#. А так пока, как он ни хорош, другие средства разработки ничего не потеряли.

Не гони. Выкачать один раз фреймворк если прога ДЕЙСТВИТЕЛЬНО нужна не проблема. А если надо разрабатывать с нуля прогу из дельфевой ниши то на шарпе дешевле и сильно.

WH>>>>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.

A>Ну а кто сейчас заботится об оптимизации?
Я.
A>Студия 2003 стартует быстро, но открывает проект (Янус) ого-го как долго. Дельфи 7 стардует долго, зато проект (сравнимый по) открывает быстро. Уж не знаю, кт оиз них там всё перебирает, кто только открытые мною 8 окон. Это при том, что Студия для показа форм (design) подшуршовывает, а Дельфи нет.
А это все к чему?

WH>>...В ОП от этого шаблоны не появится.

A> На Королевстве Дельфи читал, как с помощью include (используя простую type-подмену типов) можно достичь того же эффекта. Но это так, добавление. Ни сколько не пытаюсь аргументированно спорить по вопросу полезности шаблонов.
Ну видел. А ты их применял? А я вот видел примерчик К томуже это даже до С++ного препроцессора не дотягивает, а ты шаблоны...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 06:48
Оценка:
Здравствуйте, akasoft, Вы писали:

WH>>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...

A>То есть вопрос класса "goto или без goto"?
Да. Только я скажу по другому. Класса прямые руки или кривые.

WH>>ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?

A>Знаем. В основе — массив указателей.
Как гибко А если критична произвольная вставка/удаление? А если поиск? А если вставка/удаление с конца/начала?
A>Для хранения списка чего угодно.
Вот тут и начинаются проблемы.
A>Потому что поддержка вариантов пришла позже.
А вот это совсем изврат
A>Да и в связи сс динамическими массивами поддерживать вариантный TList (а он-то будет типизированным/автопреобразующимся) неактуально.
A>А вот для списка объектов Борланд быстро допёр сделать TObjectList. Я такую штуку в D3 или D4 сам писал, т.к. не было её.
A>В TOjectList храним потомков TObject, список может выступать Owner для этих потомков с вытекающими. При необходимости хранить одинаковых потомков можно заместить свойство Items[].
И как можно добится автоматического уничтожкния при удалении из списка? А если объект надо хранить в нескольких списках? А если мне нужен не список, а КЧ дерево?

A>Понимаю как полиморфизм и инкапсуляцию.

WH>>...Такие помошники позволяют не задумоватся о исключениях, их использование прозрачно и не навязчиво, пишутся раз и навсегда.
A>См. ответ выше. ООП тоже понимает не задумываться о других кирпичиках. Но тут ключевой момент, что чтобы не задумываться, надо сначала отладить.
Это у вас в паскакале надо долго и нудно извращаться, а потом долго и нудно отлаживать. В С++ все просто.
template<class T>
struct co_array_t
{
    co_array_t(size_t count)
        :count_(count)
    {
        if(ptr_=(T*)CoTaskMemAlloc(sizeof(T)*count_))
            new(ptr_)T[count_];
        else
            _com_issue_error(E_OUTOFMEMORY);
    }
    ~co_array_t()
    {
        if(ptr_)
        {
            for(size_t i=0;i<count_;++i)
                ptr_[i].~T();
            CoTaskMemFree(ptr_);
        }
    }
    T& operator[](size_t i)
    {
        return ptr_[i];
    }
    T* begin()
    {
        return ptr_;
    }
    T* end()
    {
        return ptr_+count_;
    }
    T* detach()
    {
        T* ptr=ptr_;
        ptr_=0;
        return ptr;
    }
private:
    T* ptr_;
    size_t count_;
};

Итого: Автоматический массив который можно использовать со вмесно с алгоритмами STL, размещенный при помощи комовского аллокатора что дает возможность возвращать его из методов комсервера.
Ну и что тут отлаживать?
WH>>Слабо на дельфях написить такого помошника?
A>Может и нет, если постановку задачи сделать словами, или хотя бы на C#. А то слова вроде знакомые, а вместе — чехарда в голове.
Ни на дельфе ни на шарпе не реализуемо.
A>Только надо ли?
Однозначно.

WH>>Ой не надо на дельфе начинается try finaly hell.

A>Ну, ну. Я вот тоже не понимал, зачем не просматривается иерархии в блоках try и catch в C#.
Чаво???
A>В обоих случаях эти блоки просты, и их понимание и правильное использование приходит с опытом.
Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.

procedure some;
begin
  try
    захватываем ресурсы
    работаем
  finaly
    освобождаем ресурсы ручками
  end;
end;


void some()
{
  захватываем ресурсы
  работаем
  компилятор генерирует код освобождающий ресурсы
}

Разница заметна или еще нет?
Вот это я и называю try finaly hell ибо каждый раз когда захватываем ресурсы мs должны их отдовать ручками и если мне не изменяет сколероз try finaly не ловит exit.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 06:48
Оценка:
Здравствуйте, akasoft, Вы писали:

WH>>Я бы сказал безнадежно уступает.

A>Я бы нет. А почему, ответил в нашей беседе.
Ни чего ты не ответил.

WH>>И чтоже его может спасти? Добавят шаблоны, множественное наследование, приведут в порядок систему типов,...?

A>Слухи о смерти сильно преувеличены, потому как есть инструмент, есть область применения того, что можно сделать инструментом, есть те, кто умеет пользоваться инструментом.
В эту область применения пришол гораздо болие мощьный инструмент.

WH>> И чем он тогда будет от С++ отличатся кроме небольшого различия в синтаксисе?

A>Давай кривую аналогию? На что похож компилятор с C++, пытающийся увеличить скорость компиляции...
На С++ компилятор
A>Ещё одна. Почему французы упорно говорят на французском, немцы — на немецком, а мы на русском? Хотя, конечно, есть исключения...
Это еще кривее. Разговорные языки по функциональности практически равноценны. Но С++ и делфи... ой не смешите мои тапочки.

WH>>С++ это язык для создания других языков. Причем при наличии определенных знаний и воображения это делается очень легко.

A>Я тоже могу написать библиотеку для создания других языков по тому или иному принципу.
А ну-ну. Напиши boost::spirit на дельфе. Можешь даже не пытаться. Не выдет.
A>Даже писал в своё время.
Ну дай посмотреть.
A>Даже в Сети найти можно и не одну.
Линки пожалуйста.
A>Так что нет тут монополии у C++, плюс смотри выше.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: _MarlboroMan_ Россия  
Дата: 15.09.03 07:10
Оценка:
Здравствуйте, WolfHound, Вы писали:

A>>Ещё одна. Почему французы упорно говорят на французском, немцы — на немецком, а мы на русском? Хотя, конечно, есть исключения...

WH>Это еще кривее. Разговорные языки по функциональности практически равноценны. Но С++ и делфи... ой не смешите мои тапочки.

ну не знаю... в "чукотском" языке для описания "качества" снега не менне двух десятков терминов... вот попробуй на "нормальный" язык это всё перевести...
... << RSDN@Home 1.1 beta 2 >>

— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 08:59
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>Здравствуйте, WolfHound, Вы писали:


WH>>ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?

FWP>Это для С++ программеров такое слово в новинку, а для пишущих на OP это само собой разумеется. Строгая типизация была в языке с самого начала.
Во первых: Не путай С и С++ это разные языки. С++ с самого начала строго типизирован.
Во врорых посмотри на дельфевые контейнеры...
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 15.09.03 09:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

A>>Так что сейчас C# сдерживается очень сильно. Вот пройдёт время, MS сделает ротацию своих линеек ОС... Тогда можно будет говорить о прогрессе C#. А так пока, как он ни хорош, другие средства разработки ничего не потеряли.

WH>Не гони. Выкачать один раз фреймворк если прога ДЕЙСТВИТЕЛЬНО нужна не проблема. А если надо разрабатывать с нуля прогу из дельфевой ниши то на шарпе дешевле и сильно.

Это получится как в известном ералаше: "Ты куда? А батарейки?". Очень плохой тон, когда программа требует для своей работы дополнительного софта.

WH>>>>>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.

A>>Ну а кто сейчас заботится об оптимизации?
WH>Я.
Что-то помнится, что рост exe-шника за счет шаблонов Вас не напугал. Да и в чем Дельфи так не оптимально? Работает во многом даже быстрее.
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 15.09.03 09:27
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, akasoft, Вы писали:
WH>>>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...
A>>То есть вопрос класса "goto или без goto"?
WH>Да. Только я скажу по другому. Класса прямые руки или кривые.

Видимо в основе у нас лежат диаметрально противоположные школы, поскольку, если Вас послушать то Сшный union это вообще ужас какой-то который надо убрать подальше. А я не представлаю себе нормальной работы без возможности смотреть на память так как это угодно мне, а не компилятору!
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.09.03 10:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А какое отношение .NET имеет к сабжу?

Имеет и очень большое. Прежде всего как соотношение его к Delphi и С++.
Если брать иерархию классов,их продуманность, поддержка интерфейсов и компонентность то все это из Delphi.
Если в С++ разницы между структурами и классами практически нет, то классы в Net однозначно ссылочные как в Delphi. Структуры же играют по сути роль классов С++. Реализация множественного наследования в структурах легко проходит через агрегирование (включение структур как полей и при этом ссумарная структура получается аналогичной как при множественном наследовании) без конфликтов при одинаковых именах функций. А вот этого в Delphi нет, а нужно было бы, для скорости.
Но Структуры Net поддерживают интерфейсы (хотя боксинг и убивает все премущество, но позволяеи работать как с объектом). Хотя на данном этапе в Net и нет шаблонов , то универсальность достигается за счет поддержки объетов определенных интерфейсов или перегрузки соответствующих функций, так как все объекты наследуются от одного общего предка как в Delphi. Скорость при этом падает в 2 раза, но намного удобнее и читабельней чем в шаблонах.
Твои любимые СмартПоинтеры решены так же как и в Delphi наследники TInterfeicedObject за счет автоматического подсчета ссылок и GC.
Перегрузка операторов то же не помешала бы в Delphi.
Программировать можно на чем угодно, но на данном этапе выбор определяется набором компонент для решения той или иной задачи и знанием технологий. По сути языки не играют решающей роли и само программирование выхолащивается. Яркий пример 1С и Васик и зарплата у них выше чем у большинства Сишников.
Просто Delphi изначально занял среднюю позицию. Но время идет и ....
А вот при грамотном внедрении Net как офисные программы, базы данных (Юкон) может повернуть все вспять.
И при этом при кажущейся простоте C# он намного сложнее и гибче чем С++.
Сразу оговорюсь, что мои познания С++ весьма поверхностны (но читаю сищный код бегло), поэтому прошу извинить меня за возможные неточности. Но суть заключается в какой мере повлияли на новую платформу идеи заложенные в этих двух языках. А в том, что Net уже в скором времени займет главенствующие роли у меня лично сомнений не вызывает.
и солнце б утром не вставало, когда бы не было меня
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.09.03 10:22
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>>>> Для различного рода задач нужны свои инструменты. Шаблоны, Inline, сматрпоинтеры очень хорошая вещь которой мне не достает, но для различного рода задач можно абсолютно безболезненно без каких либо затруднений обходится без них.

WH>>>Это где? В простеньком калькуляторе?

S>> Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше.

WH>И в какой БД ты не типизированую пимять нашол?
Как по твоему обрабатываются записи таблицы являющиеся некой структурой ?????? Наверное на лету генерятся структуры и на их основе с использованием шаблонов генерятся и компилируются алгоритмы выборки????
А мои примеры как раз из этой области.
А вот в Юкон это действительно воможно используя премущество Net.
И по поводу C# и Delphi.Net не рано ли говорить кто кого вытеснит????
и солнце б утром не вставало, когда бы не было меня
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 10:27
Оценка:
Здравствуйте, DOOM, Вы писали:

WH>>>>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...

A>>>То есть вопрос класса "goto или без goto"?
WH>>Да. Только я скажу по другому. Класса прямые руки или кривые.
DOO>Видимо в основе у нас лежат диаметрально противоположные школы, поскольку, если Вас послушать то Сшный union это вообще ужас какой-то который надо убрать подальше. А я не представлаю себе нормальной работы без возможности смотреть на память так как это угодно мне, а не компилятору!
Именно. Оно реально бывает нужно раз в два года.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 10:38
Оценка:
Здравствуйте, DOOM, Вы писали:

WH>>Не гони. Выкачать один раз фреймворк если прога ДЕЙСТВИТЕЛЬНО нужна не проблема. А если надо разрабатывать с нуля прогу из дельфевой ниши то на шарпе дешевле и сильно.

DOO>Это получится как в известном ералаше: "Ты куда? А батарейки?". Очень плохой тон, когда программа требует для своей работы дополнительного софта.
Так можно договориться что под винду писать дурной тон.

A>>>Ну а кто сейчас заботится об оптимизации?

WH>>Я.
DOO>Что-то помнится, что рост exe-шника за счет шаблонов Вас не напугал.
Оптимизация по размеру давно ни кого не волнует(ну кроме кристальщиков). К томуже это очень не плохо ужимается.
DOO>Да и в чем Дельфи так не оптимально? Работает во многом даже быстрее.
Конкретней.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.09.03 11:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.


Посмотри
http://www.osp.ru/news/soft/2003/09/15_01_print.htm
А JIT компиляторы одни и теже а в сгенерить IL код думаю не представляет особого труда .
Будут идти рука об руку и благодаря этому быстрее совершенствоваться.
и солнце б утром не вставало, когда бы не было меня
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 11:06
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше.

WH>>И в какой БД ты не типизированую пимять нашол?
S> Как по твоему обрабатываются записи таблицы являющиеся некой структурой ??????
И где ты нашол базу которая может в бинарных данных копаться? Засунуть в базу блоб это я еще понимаю но чтобы БАЗА в нем копалась это уже слишком.
хъ
S> И по поводу C# и Delphi.Net не рано ли говорить кто кого вытеснит????
Ну мне так думается что те кто на дельфе не писал не будут и на Delphi.Net писать, а учитывая что он опаздывает относительно С# и сильно то многие дельфисты уже перешли на шарп, а начатый проект переписывать... И вернутся ли они после пары лет шарпа на дельфю очень большой вопрос.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[28]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 15.09.03 15:42
Оценка:
M>>А чем TList не устраивает? Религиозные причины?
WH>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...

Ох уж мне эти суеверные старушки!

M>>>>Или крутизна шаблонов как раз и заключается в работе со встроенными типами?

WH>>>Не со встроеными, а со всеми.
M>>А какие проблемы применить TList ко всем типам?
WH>ТИПИЗАРОВАНОСТЬ такое слово знаешь?

Типизированость? Не знаю такого слова. Знаю "надёжность". Знаю "удобство". Знаю "скорость разработки". А типизированность ради типизированности — это какие-то эстетские категории.

M>>Хм. Ты хочешь сказать, что размер C-плюснутого кода в разы меньше Дельфийского? Что-то сомневаюсь.

WH>Повторюсь
...
WH>Такие помошники позволяют не задумоватся о исключениях, их использование прозрачно и не навязчиво, пишутся раз и навсегда.
WH>Слабо на дельфях написить такого помошника?

Что-то сложное. Я в C++ не силён, ты бы словами кратко сказал.

Видимо, этот помощник — это что-то универсальное и крутое. Только толку-то от всего этого хитроумия? Если мои классы должны действовать некоторым стандартным образом — я их в соответствующей иерархии и скомпоную. И сэкономлю вагон времени.

M>>Возможно, смартпойнтеры действительно помогают в разы — но только по сравнению с тем же C++ без смартпойнтеров. А в Дельфи и без них всё уже легко, аккуратно и прозрачно.


WH>Ой не надо на дельфе начинается try finaly hell.


Не вижу в этой конструкции ничего инфернального. Можно, конечно, придумать случай, где try/finally будет доставать. Но я лично такого практически не встречал.
... << RSDN@Home 1.1 beta 1 >>
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 15.09.03 18:43
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Во первых: Не путай С и С++ это разные языки. С++ с самого начала строго типизирован.


А посмотреть историю. C, Pascal, Object Pascal, C++, ??? (то чудо, которое некоторые называют "язык Дельфи", а на самом деле всё тот же OP. Ну, да, мощный RAD, IDE, ...) OP — он древний, кто-бы взял смелость его немного "подправить" в соответствии с накопленным опытом ООП... Ну а C++ так долго обсуждали, стандартизировали...

WH>Во врорых посмотри на дельфевые контейнеры...


Старые мы, древние, приходится использовать старые способы без поддержки на уровне языка.

Это и не плюс, и не большой минус. Хотя хочется развития языка, очень хочется. А Борланд всё мямлит да тянет.
... << RSDN@Home 1.1 beta 2 >>
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 15.09.03 18:43
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>> И всеравно против шарпа не тянет. Ну ни как.


Я признаю C# одним из желаемых вариантов развития OP. Дело за Борланд, что она предложит...

WH>Ты еще скажи что дельфевый рантайм входит в поставку винды


А то! И C/C++ тоже. А вот C# ни ногой...

WH> статическая линковка не хило утяжеляет ехешник что при частом обновлении софта выдет бОльшим траффиком.


Абсолютно согласен. Пример — тот же компактный KOL и "изврат", которым это достигнуто. А будь компилятор поумнее, выкусывай он и dynamic/virtual, создавай ресурсы по требованию — мы бы резко уменьшились в размерах.

WH>Не гони. Выкачать один раз фреймворк если прога ДЕЙСТВИТЕЛЬНО нужна не проблема. А если надо разрабатывать с нуля прогу из дельфевой ниши то на шарпе дешевле и сильно.


Не гоню. Пример — Янус. А о тех случаях, когда действительно что-то нужно... Так это кому нужно? Кто платит деньги, тот заказывает музыку. Не убедишь в правильности своего подхода, и этот уйдёт к другим или конкурентам.

A>>Ну а кто сейчас заботится об оптимизации?

WH>Я.

Ну вот, на двое будет. Время это, однако, отнимает.

WH>А это все к чему?


Пример жрущих приложений.
... << RSDN@Home 1.1 beta 2 >>
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 15.09.03 18:43
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>... А в том, что Net уже в скором времени займет главенствующие роли у меня лично сомнений не вызывает.


Как только выпустят такую винду, в которой фреймворк будет составной частью плюс она займёт нишу порядка 25-25% парка компьютеров.

И ещё Борланд с Майкрософт снова дружат.

Но насчёт полезности этого Net для программирования и применения компьютеров можно долго рассуждать. Это же чёртов новый взгляд на интерпретаторы при ощутимом росте мощностей и производительности компьютеров...
... << RSDN@Home 1.1 beta 2 >>
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 15.09.03 18:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Я бы сказал безнадежно уступает.

A>>Я бы нет. А почему, ответил в нашей беседе.
WH>Ни чего ты не ответил.

Я имел ввиду в других ветках. Мы тут в нескольких сразу беседу ведём, повторться не хотелось.

WH>В эту область применения пришол гораздо болие мощьный инструмент.


Я осторожно заявляю, что он только стучится в дверь. Где-то робко, где-то бревном на раз-два-взяли... Его надо обеспечить поддержкой функционирования. Прикажете мне (разработчику ПО) распространять и устанавливать фреймворки? Я себе денюшку зарабатываю, сам кушать хочу.

WH>На С++ компилятор


Не скромничай.

A>>Ещё одна. Почему французы упорно говорят на французском, немцы — на немецком, а мы на русском? Хотя, конечно, есть исключения...

WH>Это еще кривее. Разговорные языки по функциональности практически равноценны. Но С++ и делфи... ой не смешите мои тапочки.

Лингвисты думают иначе. Каждый язык сформирован культурой того или иного народа, его потребностями для общения и выражения.

A>>Даже писал в своё время.

WH>Ну дай посмотреть.

Не могу. Скрипт-язык в коммерческой программе. На BP.

A>>Даже в Сети найти можно и не одну.

WH>Линки пожалуйста.

Пока не пощупаешь — не поверишь? И само собой простенькие скромные скриптоподобные языки тебе не подойдут? Типа из RA Lib? Т.е. надо подать в студию как минимум реализацию клона C/C++, но на Паскале?...
... << RSDN@Home 1.1 beta 2 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 15.09.03 18:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Ну мне так думается что те кто на дельфе не писал не будут и на Delphi.Net писать, а учитывая что он опаздывает относительно С# и сильно то многие дельфисты уже перешли на шарп, а начатый проект переписывать... И вернутся ли они после пары лет шарпа на дельфю очень большой вопрос.


Ну а как же хвалёная (заявленная) совместимость и независимость от языка. Просто дописываем блоки на C#, и используем их уже на Дельфи.
... << RSDN@Home 1.1 beta 2 >>
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 18:46
Оценка:
Здравствуйте, Serginio1, Вы писали:

WH>>Нда? Смотри выделеное и скажи что из этого не нужно в ЯВУ? Разве что смартпоинтеры там где есть GC и то иногда хочется детерминированого управления жизнью объекта.

S> В Net есть возможность детерминированого управления жизнью объекта.
Ну знаю я по using жутко не удобно. К томуже Dispose может бросать исключения
S> Inline не нужен т.к. JIT компилятор следит за возможностью вставки кода и при этом оптимизируя под конкретный процессор.
А что это как не инлайн? А в дельфе инлайнов вобще нет.
S> Про шаблоны уже прошелся.
Где?

WH>>>>Вот только пока далеко не все лучшие идеи используются в шарпе.

S>>> Например???? Шаблоны будут, что еще???
WH>>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
WH>>А сейчас все очень убого. Почти на уровне дельфи.
S>А вот на шаблонах ты зря зациклился.
И что ты предлагаешь? Copy-Paste-Replace? Писать скрипты для генерации?
S>Шаблоны по сравнению со ссылками на определенные структуры (с применением виртуальных функций ли интерфесов) имеют премущество в скорости и полную типизацию, но при этом значительно выигрывают только при вызове быстрых функций.
S>Кроме всего прочего полно вариантов, где должны хранится ссылки на различные объекты и здесь премущество шаблонов как корова языком слизала.
S> И при всей твоей нелюбви к Copy-Paste-Replace названные тобой аргументы (ошибки в базовом классе, неудобство) не выдерживают критики.
Что ты тут нагнал вобще не понятно. Если ты про хранение потомков какого либо класса в одном контейнере то в С++ это делается на раз. Вот только генерацию такого контейнера берут на себя шаблоны.
typedef boost::shared_ptr<base> base_ptr;
std::list<base_ptr> base_list;
base_list.push_back(base_ptr(new derived));

Или используя мои смартпоинтеры и объекты со встроенным подсчетом ссылок
std::list<ref_t<base_ptr> > base_list;
base_list.push_back(new derived);
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 19:33
Оценка:
Здравствуйте, akasoft, Вы писали:

WH>>Как гибко А если критична произвольная вставка/удаление? А если поиск? А если вставка/удаление с конца/начала?

A>А мы будем выбирать тогда, как реализовать. К услугам [коллекции, списки] (это для объектов), [динамические массивы, тип записи, вариантные массивы] для чего другого. Нужно очень быстро — возмём массивы и record.
А я просто возму STL.

A>>>Для хранения списка чего угодно.

WH>>Вот тут и начинаются проблемы.
A>Да нет. Опыт сказывается.
А ну-ну.

A>>>Потому что поддержка вариантов пришла позже.

WH>>А вот это совсем изврат
A>Даже соглашусь. Зачем их так в COM любят? Или зачем Дельфи позволяет передавать/получать от COM-объектов эти OleVariant и Variant? Нет бы динмассивы...
А нафига их на уровень языка выводить было?

WH>>И как можно добится автоматического уничтожкния при удалении из списка? А если объект надо хранить в нескольких списках?

A>Разумным проектированием.

A>Перекрытием (перегрузкой, override) методов, написанием своих классов-оболочек.
А нафига это все писать если это может сделать компилятор?
У меня есть совершенно не зависимый шаблон коллекции.
Есть совершенно не зависимый умный указатель.
Есть совершенно не зависимый базовый класс.
И я просто создаю контейнер смартпоинтеров на мой класс. Зачем что-то еще писать?

WH>> А если мне нужен не список, а КЧ дерево?

A>Написанием класса-оболочки, инкапсулирующего это дело. Возможно, он и есть, мне не было нужды в таком.
Опять что-то писать

A>Нет, вы (к другим слушателям ) мне скажите! Нас обвиняют в смертном грехе — кликерстве, настройке свойств и поведения классов визуально. Более того, мы уши опускаем, согдашаясь, что да, виновны, уровень знаний падает, т.к. для кликанья много знать не надо.

Я хоть слово сказал что рисовать ГУЙ это плохо?
хъ
A>Ну, не так?
Нет не так. ГУЙ это в большинстве задачь ничтожно малая часть работы.

WH>>Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.


A>Вот, вот, вот! Та же лень. Думаешь, я не знаю про эти манипуляции с временем жизни и областью видимости. Знаю. Я даже знаю, какую цену я плачу за необходимость объявлять типы и переменные заранее. Я проникся этой идеей настолько, что она для меня также естественна, как дышать. Я не ошибусь с декларированием переменных и буду всегда знать, где их найти. Для проверки мне достаточно распечатать блок var, а на C# надо лазить по телу метода да собирать переменные по сусекам...

Вопрос: А нафига искать переменные? У меня таких проблем нет. Ибо и дроблю функции строчек по 10 максимум(ну за ооочень редким исключением). Ах да я же забыл в дельфе нет инлайнов и дробление сказывается на производительности...

A>И мы ещё не затронули любимый мозоль — case sensetive.

Чесное слово не мой.

WH>>... и если мне не изменяет сколероз try finaly не ловит exit.

A>Правда? Надо будет покопаться что-ли...
Ну покопайся. А то мне дельфи ставить не охота.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 19:33
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...

M>Ох уж мне эти суеверные старушки!
От старушки слышу.

M>Типизированость? Не знаю такого слова. Знаю "надёжность". Знаю "удобство". Знаю "скорость разработки". А типизированность ради типизированности — это какие-то эстетские категории.

Нет типизированиесть нежна для повышения надежности, удобства и корости разработки.

M>Что-то сложное. Я в C++ не силён, ты бы словами кратко сказал.

http://www.rsdn.ru/forum/Message.aspx?mid=383399&amp;only=1
Автор: WolfHound
Дата: 15.09.03

M>Видимо, этот помощник — это что-то универсальное и крутое. Только толку-то от всего этого хитроумия? Если мои классы должны действовать некоторым стандартным образом — я их в соответствующей иерархии и скомпоную. И сэкономлю вагон времени.
ХА. Я же сказал это ПОМОШНИК он делает грязную работу.

WH>>Ой не надо на дельфе начинается try finaly hell.

M>Не вижу в этой конструкции ничего инфернального. Можно, конечно, придумать случай, где try/finally будет доставать. Но я лично такого практически не встречал.
Сам факт его существования достает. Зачем он нужен? Я не понимаю. (вернее зачем это надо в дельфе я знаю) В С++ этого нет вобще и никто не жалеет об этом.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 15.09.03 19:33
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Пока не пощупаешь — не поверишь? И само собой простенькие скромные скриптоподобные языки тебе не подойдут? Типа из RA Lib? Т.е. надо подать в студию как минимум реализацию клона C/C++, но на Паскале?...

Ни фига ты не понял. С++ САМ превращается в другие язаки. boost::spirit превращает его в язык для записи EBNF грамматики. Дельфя на такое не спасобна.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Некоторые итоги:
От: FWP Россия  
Дата: 16.09.03 04:01
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Очень часто в потверждение превосходства С++(а именно VC++), над Дельфи люди начинают сравнивать его(С++) с BCB. Я этим BCB в жизни не пользовался и насколько понял не зря, поскольку, видимо, это хуже даже Visual Studio.

Ну это ты зря. VS7 неплохой продукт.
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 16.09.03 04:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, FWP, Вы писали:


WH>>>Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.

FWP>>C# и Delphi — это близнецы братья (или сестры?)
WH>Общего у них только то что редактор форм немного похож.
Ну если ты так говоришь, то видимо Delphi ты и вправду забыл или не знал или знал какую-либо древнюю версию.

FWP>>Какое самомнение! Ну почти господь бог.

WH> А что не похож?

FWP>>А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов.
WH>Ибо реализовать их нАмного сложнее чем кажется.
Вот и я о том же.
FWP>>Разговоры идут, планы ввода есть. А реализаций нет. И в C# тож самое. Видно не все так просто с надежностью.
WH>С надежностью то как раз все хорошо, а вот реализовать это...
... без ущерба надежности!
FWP>>А ведь для разработки именно НАДЕЖНЫХ приложений создавались эти среды.
WH>А это тут причем?
А при том, что из языков были сознательно удалены заманчивые, но потенциально опасные возможности.
FWP>>А вот интересно! После ввода шаблонов в С# куда они будут отнесены: к безопасному программированию или нет?
WH>К безопасному. К томуже в шарпе шаблоны не будут обладать такойже мощью как в С++.
Вот и я о том же.
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 04:44
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>>>C# и Delphi — это близнецы братья (или сестры?)

WH>>Общего у них только то что редактор форм немного похож.
FWP>Ну если ты так говоришь, то видимо Delphi ты и вправду забыл или не знал или знал какую-либо древнюю версию.
Ну и что же у них общего? Если заглянешь шарпу под капот то сам увидишь что ни чего общего.

FWP>>>Разговоры идут, планы ввода есть. А реализаций нет. И в C# тож самое. Видно не все так просто с надежностью.

WH>>С надежностью то как раз все хорошо, а вот реализовать это...
FWP>... без ущерба надежности!
Это где это ты ущерб надежности нашол? Мне очень интересно.

FWP>>>А ведь для разработки именно НАДЕЖНЫХ приложений создавались эти среды.

WH>>А это тут причем?
FWP>А при том, что из языков были сознательно удалены заманчивые, но потенциально опасные возможности.
А шаблоны тут причем?

WH>>К безопасному. К томуже в шарпе шаблоны не будут обладать такойже мощью как в С++.

FWP>Вот и я о том же.
Это о том что опять придется извращаться для того что в С++ делалось на раз и без проблем?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 05:09
Оценка:
Здравствуйте, FWP, Вы писали:

WH>>Нет не так. ГУЙ это в большинстве задачь ничтожно малая часть работы.

FWP>Это в Delphi ничтожно малая часть. Потому ручная работа сведена к минимуму. А в C++ все ручками, да ручками
Вот только шаблоны сводят ручную работу практически на нет. А если учесть что очень многим приложениям не нужно куча диалогов... и написать интерфейс при помощи WTL не состовляет большого труда...

WH>>>>Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.

FWP>И он в некотрых случаях может принять неправильное решение.
Конкретно пожалуйста. Ни разу не встречал.
FWP>И следить за этим надо и обходить такие ситуации вручную. Да и надежности это не добавляет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 16.09.03 07:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Так можно договориться что под винду писать дурной тон.


Какая-нибудь ОС всегда на машине стоит, а вот приходить и говорить, что надо бы вам еще оффис поставить к вашей винде — это дурной тон!

DOO>>Да и в чем Дельфи так не оптимально? Работает во многом даже быстрее.

WH> Конкретней.

Ссылку на соответствующую статью я уже давал.
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 16.09.03 07:41
Оценка:
Здравствуйте, WolfHound, Вы писали:

Ах да я же забыл в дельфе нет инлайнов и дробление сказывается на производительности...

Они есть! Просто их не надо описывать ручками, а это сделает за нас компилятор.
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 07:45
Оценка:
Здравствуйте, DOOM, Вы писали:

WH>>Ах да я же забыл в дельфе нет инлайнов и дробление сказывается на производительности...

DOO>Они есть! Просто их не надо описывать ручками, а это сделает за нас компилятор.
А ты с С++ не путаешь? Если мне не изменяет скалероз дельфя вобще ни чего не подставляет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 16.09.03 07:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Сам факт его существования достает. Зачем он нужен? Я не понимаю. (вернее зачем это надо в дельфе я знаю) В С++ этого нет вобще и никто не жалеет об этом.


ОПА!!! В сях нету finally!!!!!! Как я мог про это забыть... Не нужен говоришь... а если ты соединен с сервером, для которого лишнее повисшее соединение это непозволительная роскошь, а ты еще и отладку ведешь и вылетаешь с завидным постоянством? Как в такой ситуации встроенные в С++ механизмы помогут разорвать соединение? Или в STL есть какой-нибудь std::protocol, который сделает всю грязную работу?
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: Другой Аноним  
Дата: 16.09.03 07:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Нет типизированиесть нежна для повышения надежности, удобства и корости разработки.


Re[3]: Некоторые итоги:
От: DOOM Россия  
Дата: 16.09.03 07:50
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>Здравствуйте, DOOM, Вы писали:


FWP>Ну это ты зря. VS7 неплохой продукт.


Согласен. Но сейчас приходится пользоваться VS6.0 по политическим соображениям.
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 08:04
Оценка:
Здравствуйте, DOOM, Вы писали:

WH>>Сам факт его существования достает. Зачем он нужен? Я не понимаю. (вернее зачем это надо в дельфе я знаю) В С++ этого нет вобще и никто не жалеет об этом.


DOO>ОПА!!! В сях нету finally!!!!!! Как я мог про это забыть... Не нужен говоришь... а если ты соединен с сервером, для которого лишнее повисшее соединение это непозволительная роскошь, а ты еще и отладку ведешь и вылетаешь с завидным постоянством? Как в такой ситуации встроенные в С++ механизмы помогут разорвать соединение? Или в STL есть какой-нибудь std::protocol, который сделает всю грязную работу?

Ты вобще о чем? Что такого может finally чего не могут автоматические объекты? Приведи минимальный демонстрирующий код.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.09.03 08:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>>>> Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше.

WH>>>И в какой БД ты не типизированую пимять нашол?
S>> Как по твоему обрабатываются записи таблицы являющиеся некой структурой ??????
WH>И где ты нашол базу которая может в бинарных данных копаться? Засунуть в базу блоб это я еще понимаю но чтобы БАЗА в нем копалась это уже слишком.
WH>хъ

Любая таблица базы данных представляет из себя грубо говоя массив записей, но так как используется позднее связывание на основании описания записи (длины,определения полей) строятся для каждого поля объекты содержащие смещение поля и в зависимости от типа поля длину записи и соответственно происходит боксинг и дальнейшая обработка. Понятно, какое увеличение скорости приносит прямая работа с записью без посредников, а учитывая кроме всего прочего что SQL еще и интерпретатор то....
Кроме всего прочего существуют ООяБД которые могут хранить объекты, но так как объект можно представить как структуру или структуру связанных структур через ссылки то все же лучше сводить к табличному хранению или сериализации в зависимости от размера.

S>> И по поводу C# и Delphi.Net не рано ли говорить кто кого вытеснит????

WH>Ну мне так думается что те кто на дельфе не писал не будут и на Delphi.Net писать, а учитывая что он опаздывает относительно С# и сильно то многие дельфисты уже перешли на шарп, а начатый проект переписывать... И вернутся ли они после пары лет шарпа на дельфю очень большой вопрос.

А вот здесь ты опять неправ, те кто сидит на C# может быть, но те кто сидит на Delphi со своими проектами, легче дождаться Delphi.Net чтобы с минимальными затратами перевести на Net. Кроме всего прочего не может быть универсальных языков, какой либо может вырываться в том или ином направлении, но так как C# и Delphi очень похожи то совместное использование не представляет труда. Этим кроме всего прочего Net и ценен.
Кроме всего прочего учитывая недостатки предшественника можно подкоректировать язык в лучшую сторону, посмотрим.
и солнце б утром не вставало, когда бы не было меня
Re: Идём дальше
От: centurn Россия  
Дата: 16.09.03 08:56
Оценка:
A>Посмотрим-ка, что нам окошечко CPU да и выдаст...

A>На


A>
A>    Item := Add as TMyItem; // Создаём и добавляем
A>


A>
A>mov    eax, [ebp-$0c]
A>call    TCollection.Add
A>mov    edx, [$00467204]
A>call    @AsClass
A>mov    [ebp-$08], eax
A>


Кроме того, что WolfHound уже сказал, хочу обратить внимание на выделенную строчку. Как ты думаешь, что значит эта "одна" строчка асмового кода? И еще что она будет значить, если хранимый тип не совпадает с тем, к чему ты приводишь.
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.09.03 08:59
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, Serginio1, Вы писали:


S>>... А в том, что Net уже в скором времени займет главенствующие роли у меня лично сомнений не вызывает.


A>Как только выпустят такую винду, в которой фреймворк будет составной частью плюс она займёт нишу порядка 25-25% парка компьютеров.

Здесь проблема еще в великом множестве процессоров и встает вопрос оптимизации. Net снимает эти вопросы т.к. в идеале под каждый процессор свой JIT компилятор.

A>И ещё Борланд с Майкрософт снова дружат.

Теория: MS .Net — продукт Borland
http://sumdu.edu.ua/~chekalov/teach/net_is_borland03.htm
это третья статья
http://sumdu.edu.ua/~chekalov/teach/net_is_borland01.htm
http://sumdu.edu.ua/~chekalov/teach/net_is_borland02.htm



A>Но насчёт полезности этого Net для программирования и применения компьютеров можно долго рассуждать. Это же чёртов новый взгляд на интерпретаторы при ощутимом росте мощностей и производительности компьютеров...

Net это не интерпритатор, а компиляция на лету из IL кода. Вот, что говорит НАШ человек в M$
http://www.gotdotnet.ru/default.aspx?s=doc&amp;d_no=32&amp;c_no=10
и солнце б утром не вставало, когда бы не было меня
Re[12]: По просьбам трудящихся: Delphi vs C++(VS)
От: centurn Россия  
Дата: 16.09.03 09:28
Оценка:
C>> Да разница, собственно, в том, что драйвер и операционку ты просто никак на делфях не напишешь, принципиально. Ну кроме, возможно, того извращенческого маневра, что тут про драйвера говорили...
A>Это не проблема языка, это проблема конкретной реализации. Ну не позционирует Борланд свой этот инструмент, как на все случаи жизни...

Ну вообще-то в этой подветке были высказывания что тиа не делфе все сделать можно. И еще. Если говорить о "конкретной" реализации, то... разве есть другие реализации Делфи.

C>>А в шутере нужна максимальная производительность, которой в делфях и не пахнет. И дело даже не в качестве компилятора, а в том, что в С++ можно более тонко управлять тем, что тебе сделает компилятор.

A>Ой, неправда. Оптимизатор кода и в Дельфи есть, и неслабо оптимизирует. А если вопрос в том, где больше не всякому понятных галочек и рюшечек, так...

Я не про галочки. Я про то, что я в С++ когда пишу _код_ могу более точно управлять тем, что у меня получится после компиляции. О галочках я при этом вообще не думаю. Например, никакой оптимизатор не сможет убрать dynamic_cast, или его делфийский эквивалент, кроме разве что критических случаев. А я в С++ почти всегда могу обойтись без динапического приведения. Не буду повторяться, тут половина топика об этом...

C>> И на надо платить за то, что тебе не сейчас не нужно — это было и остается чуть ли не самым главным при развитии С++. И главное — не в ущерб функциональности.

A>Для С++ — да, возможно. Не спорю. Дельфи тоже в трёх редакциях поставляется. Покупаем стандарт, самую дешёвую, и юзаем Сеть, покупаем библиотеки по мере необходимости.

Ты не понял вообще о чем я. Я имел ввиду платить _эффективностью_. Деньги — это уже отдельный разговор

C>> Короче, шутер на делфах можно сделать, но на это уйдет намного больше времени, чем на С++, ...

A>А потому, что надо будет найти .pas эквиваленты граф. бибилиотеки (DirectXx, OpenGlx), теорию изучить...

И это тоже...

A>А если это уже есть, найдено, тогда неправда ваша.


И почему же не принято писать на Делфях игрушки? Всех Микрософт задавил.


C>> ...и будет этот шутер похож на слайд-шоу под аккомпанемент жутко свопящего винта.

A>Не будет. Это же дуалистический принцип использования сельскохозяйственных орудий на гидроповерхности...

По крайней мере, есть куча шутеров, написанных на С++, а вот насчет Делфи... сплошные "сельскохозяйственные орудия".

C>> ...Во-первых, я задолбался переводить структурки, используемые для общения с NetBios, с С на Pascal (кстати, С-шные структырки были в хелпе по WinAPI, поставляемом с Делфями, других я не нашел).

A>И чья это проблема? Языка? IDE? Борланда? Или моя?

А теперь посмотри на выделенные 2 слова в исходном сообщении. Неужели нельзя было перевести структурки, когда хелп писАли?

A>Вот, вот! Производители этих всяких API, пользуясь своей монопольность, чхать хотели на программистов-дельфинистов... Не замечаете аналогию с ОС?


И при чем тет API...

C>> ... А во-вторых в парочке мест я уже, грязно матерясь, просто сорвался на ассемблерные вставкм, т.к. не хватило терпения воротить все эти конструкции на паскале...

A>Всё же это от незнания либо от цейтнота, когда "давай, давай, чего телешся...".

Ну, знашь, на С++ _у меня же_ почему-то таких порывов не возникало даже когда я его знал хуже Делфей...

C>> И еще, раз уж меня потянуло кнопки понажимать...

C>>... Я не буду по этому поводу приводить особых аргументов, т.к. удобство все-таки понятие чисто субъективное, ...
A>И что из этого следует? Всё то же — монополизм на API. А как же разные подходы, взгляд со стороны, альтернатива?

Да причем тут API?! Ну кто мешал тем же Делфям его использовать, если уж на то пошлО...
Я совсем не поклонник мелкософта. Больше того, я мечтаю, чтобы эта контора наконец накрылась. Я смотрю на альтернативы и немножко надеюсь, что хотя бы Линух заставит этих ... "бизънессментов" подвинуться. Но! Реальность в том, что работать приходится под виндой и _пока что_ я не вижу более удобного средства разработки _под винду_, чем VS.
И если смотреть на языки без привязки, я не вижу лучшего языка программирования, чем C++. А чисто субъективно мне больше всего нравится ассемблер, но практически на нем очень мало что стОит решать...
Кстати насчет С#. Читал я, что они собираются ввести под названием generics. Эта убогая пародия и близко не заменит шаблонов C++...

C>>И еще мысль: практически не бывает "чистого" GUI, обычно за ним стоит еще нетривиальный код (иначе вообще непонятно, зачем нужен нужен язык программирования).

A>Соглашусь, что код стоит. Несомненно. В то же время есть абстракция, когда я скажу "лабел", у всех в мозгу возникнет почти одинаковый образ.

Это к чему?
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 09:30
Оценка:
Здравствуйте, Dimonka, Вы писали:

WH>>Нет не так. ГУЙ это в большинстве задачь ничтожно малая часть работы.

D>В моей работе 90% времени клиенты рассматривают именно ГУИ. Им наплевать на функциональность, функциональность проверят тестеры.
А в моей работе ГУИ вобще нет. Я серверы пишу. И тут дельфевые издержки становятся абсолютно не приемлемы.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Некоторые итоги:
От: centurn Россия  
Дата: 16.09.03 09:40
Оценка:
FWP>>Ну это ты зря. VS7 неплохой продукт.
DOO>Согласен. Но сейчас приходится пользоваться VS6.0 по политическим соображениям.

А каким-нибудь Deplhi 3.0 по политическим соображениям не заставляют пользоваться для сравнения?
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
WH>>>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...
M>>Ох уж мне эти суеверные старушки!
WH>От старушки слышу.

Старушки делятся на суеверных и нормальных.

M>>Типизированость? Не знаю такого слова. Знаю "надёжность". Знаю "удобство". Знаю "скорость разработки". А типизированность ради типизированности — это какие-то эстетские категории.

WH>Нет типизированиесть нежна для повышения надежности, удобства и корости разработки.

Вот именно. В случае с TList надёжность, удобство и скорость разработки уже есть, и никакой типизированности, слава богу, не нужно.

M>>Что-то сложное. Я в C++ не силён, ты бы словами кратко сказал.

WH>http://www.rsdn.ru/forum/Message.aspx?mid=383399&amp;only=1
Автор: WolfHound
Дата: 15.09.03


Чего?

M>>Видимо, этот помощник — это что-то универсальное и крутое. Только толку-то от всего этого хитроумия? Если мои классы должны действовать некоторым стандартным образом — я их в соответствующей иерархии и скомпоную. И сэкономлю вагон времени.

WH>ХА. Я же сказал это ПОМОШНИК он делает грязную работу.

ТЫ делаешь эту грязную работу, когда пишешь помощника. А в Дельфи я напишу базовый класс и грязную работа будет в базовом классе..

WH>>>Ой не надо на дельфе начинается try finaly hell.

M>>Не вижу в этой конструкции ничего инфернального. Можно, конечно, придумать случай, где try/finally будет доставать. Но я лично такого практически не встречал.

WH>Сам факт его существования достает. Зачем он нужен? Я не понимаю. (вернее зачем это надо в дельфе я знаю) В С++ этого нет вобще и никто не жалеет об этом.


Бедные сишники! А как же они с WinAPI работают без try/finally? Сделали CreateFile, поковырялись, получили Exception — и файл остался висеть?

Как говорил Карабас Барабас, это ж просто праздник какой-то!
... << RSDN@Home 1.1 beta 1 >>
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
DOO>>Видимо в основе у нас лежат диаметрально противоположные школы, поскольку, если Вас послушать то Сшный union это вообще ужас какой-то который надо убрать подальше. А я не представлаю себе нормальной работы без возможности смотреть на память так как это угодно мне, а не компилятору!

WH>Именно. Оно реально бывает нужно раз в два года.


Что вообще стоит писать на C++, если не низкоуровневый код, с использованием WinAPI и т.п.? А во всех этих WinAPI union'ы кругом торчат.
... << RSDN@Home 1.1 beta 1 >>
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
WH>>>... и если мне не изменяет сколероз try finaly не ловит exit.

A>>Правда? Надо будет покопаться что-ли...


WH>Ну покопайся. А то мне дельфи ставить не охота.


Всё он ловит, нафиг он иначе нужен был
... << RSDN@Home 1.1 beta 1 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
WH>куда это ты ее приложить собрался? Уж не к задаче ли где 90% ГУИ? И всеравно против шарпа не тянет. Ну ни как.

Против шарпа?

В C# на редкость унылая и скромная библиотека визуальных компонентов. За какой аспект ни возьмись — практически всё хуже Дельфёвого.

Сдаётся мне, что ты по GUI просто мало работаешь. Мне для одной сложной формы пришлось даже импортировать Delphi-компонент как COM-объект.
... << RSDN@Home 1.1 beta 1 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
WH> почему постоянно появляется какойнибудь "куул программер" который знает дельфю хуже меня(а я ее уже почти забыл и не желею)и начинает вопить С++ сакс?

Наверное, потому же, почему постоянно появляется какойнибудь "куул программер" который начинает вопить Дельфи сакс.

Дельфи — отличный инструмент. Примерно, как хороший складной нож. Кому-то нравятся швейцарские ножи, на шестьдесят четыре лезвия, кому-то добротные одинарные.

И всем-то этот C++ хорош, только постоянно из него какое-нибудь лишнее лезвие выскакивает. А чтобы открыть некоторые лезвия, нужно вначале сбоку куда-то нажать. Короче, инструмент для фанатов.
... << RSDN@Home 1.1 beta 1 >>
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
A>Но насчёт полезности этого Net для программирования и применения компьютеров можно долго рассуждать. Это же чёртов новый взгляд на интерпретаторы при ощутимом росте мощностей и производительности компьютеров...

Интерпретаторы? Причём здесь интерпретаторы?
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
WH>Ни фига ты не понял. С++ САМ превращается в другие язаки. boost::spirit превращает его в язык для записи EBNF грамматики. Дельфя на такое не спасобна.

А на фиг это надо?

Если вам нужна ножовка, вы берёте в руки ножовку. Если вым нужен утюг, вы берёте утюг. Но кому нужа пила с дополнительными функциями утюга?
... << RSDN@Home 1.1 beta 1 >>
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
WH>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.

WH>А сейчас все очень убого. Почти на уровне дельфи.


Полностью согласен. Сейчас всё почти на уровне дельфи/Java. А если кому нужны выкрутасы — пройдёмте в С++/MC++. В поликлинику, для опытов, как говорил Печкин.
... << RSDN@Home 1.1 beta 1 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
S>> В Net есть возможность детерминированого управления жизнью объекта.
WH>Ну знаю я по using жутко не удобно.

Ну мало ли. Главное, что всем удобно. Ради одного человека менять не будут.

WH>К томуже Dispose может бросать исключения


В отличие от деструкторов C++, как я понимаю?

S>>Кроме всего прочего полно вариантов, где должны хранится ссылки на различные объекты и здесь премущество шаблонов как корова языком слизала.


WH>Что ты тут нагнал вобще не понятно. Если ты про хранение потомков какого либо класса в одном контейнере то в С++ это делается на раз. Вот только генерацию такого контейнера берут на себя шаблоны.


В Delphi есть готовый контейнер для потомков какого-либо класса. TObjectList.

Для объектов с подсчётом ссылок TInterfaceList.
... << RSDN@Home 1.1 beta 1 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
FWP>>C# и Delphi — это близнецы братья (или сестры?)
WH>Общего у них только то что редактор форм немного похож.

Редактор форм? По-моему, ты не очень хорошо рассмотрел эти редакторы форм. С таким сравнением все редакторы форм похожими покажутся.

FWP>>А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов.

WH>Ибо реализовать их нАмного сложнее чем кажется.

Ага. Компилятор Java написали. Интерпретатор и JIT'тер написали. А шаблоны — нет, тут сложность невероятно высока.
... << RSDN@Home 1.1 beta 1 >>
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
FWP>>>>C# и Delphi — это близнецы братья (или сестры?)
WH>>>Общего у них только то что редактор форм немного похож.
FWP>>Ну если ты так говоришь, то видимо Delphi ты и вправду забыл или не знал или знал какую-либо древнюю версию.
WH>Ну и что же у них общего? Если заглянешь шарпу под капот то сам увидишь что ни чего общего.

Редакторы форм действительно совсем не похожи.

А вот главные, архитектурные части — очень похожи. В трёх ключевых точках:

RTTI (aka Reflection)
Свойства
Упор на простоту синтаксиса

Значительная часть преимуществ как Делфи, так и C# коренится в этих трёх пунктах.
... << RSDN@Home 1.1 beta 1 >>
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
А>1) Каждый раз при создании объекта надо проверять поддержку IDisposable = лезть в MSDN.

Это разве что в первые пару месяцев.

Классы, которые поддерживают IDisposable, видны невооружённым глазом: это те классы, которые инкапсулируют вненшние ресурсы.

А>2) Попытки систематически использовать using приводят к конструкциям вида:


Бред какой-то. У меня почему-то такого не встречается. Если у тебя поползновения использовать using систематически, то возникают подозрения в архитектуре приложения..

А>3) Dispose() может выбрасывать исключения


А деструкторы C++, очевидно, не выбрасывают исключений? То-то прикольно, когда какой-нибудь Flush в деструкторе не вызовется и твоё приложение скромно об этом умолчит.

Правильно, а фиг ли что файл не сохранился. Нужно было почаще Backup делать

А>4) Рекомендательный характер вызова Dispose(). Поубивал бы за это


Ага, не поняли они в Редмонде твоей таинственной русской души.
... << RSDN@Home 1.1 beta 1 >>
Re[2]: Некоторые итоги:
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
DOO>И еще. Очень часто в потверждение превосходства С++(а именно VC++), над Дельфи люди начинают сравнивать его(С++) с BCB. Я этим BCB в жизни не пользовался и насколько понял не зря

Во-во, правильно. Задолбали уж тут специалисты по Билдеру.
... << RSDN@Home 1.1 beta 1 >>
Re[3]: Некоторые итоги:
От: mihailik Украина  
Дата: 16.09.03 13:52
Оценка:
S>А что, ты можешь предложить хоть один широко распространенный скриптовый язык со строгой статической типизацией? Если нет, то ты нифига не понял из того, что тебе говорил Wolfhound.

Статическая типизация — не панацея, как её старается представить Wolfhound.
... << RSDN@Home 1.1 beta 1 >>
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 19:02
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Нет типизированиесть нежна для повышения надежности, удобства и корости разработки.

M>Вот именно. В случае с TList надёжность, удобство и скорость разработки уже есть, и никакой типизированности, слава богу, не нужно.
Ну-ну. Такой контейнер на С++ будут долго высмеевать и ни когда не станут использовать.

WH>>http://www.rsdn.ru/forum/Message.aspx?mid=383399&amp;only=1
Автор: WolfHound
Дата: 15.09.03

M>Чего?
Чего чего co_array_t смотри.

WH>>ХА. Я же сказал это ПОМОШНИК он делает грязную работу.

M>ТЫ делаешь эту грязную работу, когда пишешь помощника. А в Дельфи я напишу базовый класс и грязную работа будет в базовом классе..
Мне нужен типизированый, автоматический массив созданный КОМовским аллокатором с возможностью вернуть его из функции.
А тепер скажи какой такой базовый класс может быть у массива?

WH>>Сам факт его существования достает. Зачем он нужен? Я не понимаю. (вернее зачем это надо в дельфе я знаю) В С++ этого нет вобще и никто не жалеет об этом.

M>Бедные сишники! А как же они с WinAPI работают без try/finally? Сделали CreateFile, поковырялись, получили Exception — и файл остался висеть?
Вот только жалеть нас не надо. Ибо с WinAPI без враперов работают только [censured]. А враперы уже и человеческий интерфейс предоставят и ресурс отдать не забудут.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 19:02
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Вот только шаблоны сводят ручную работу практически на нет.

M>Ну да, конечно. Найди-ка хоть одно приложеньице на C++ и COM, в котором нет ручной работы.
А что далеко ходить. Мой OPC server. Всю работу по поддержке COM сделали ATL'ные шаблоны.

WH>>А если учесть что очень многим приложениям не нужно куча диалогов...

M>Ага. Многим. Давай посчитаем. Для строгости будем считать "приложением" только то, что устанавливается с помощью какого-нибудь инсталлера. Какой процент таких "приложений" на твоём компьютере использует меньше 4 окон?
Ну есть парачка. А большинство вобще собственные контролы используют.

WH>> и написать интерфейс при помощи WTL не состовляет большого труда...

M>Да и на Дельфи написать интерфейс не составляет труда. И на C# можно интерфейсы писать. Только почему-то все их рисуют в дизайнере.
M>Видимо, есть всё-таки разница между "не составляет труда" и "имеет смысл". Писать интерфейс вручную — такая дурь, которая практически не имеет смысла.
А ты попрубуй нарисуй на дельфе интерфейс как в седьмой студии...

WH>>Конкретно пожалуйста. Ни разу не встречал.

M>Примерно так (псеводкод):
хъ
M>Объект file1 не освобождается до конца метода. Если файлы открываются в блокирующем режиме и str1==str2, на строке со звёздочкой получим ошибку.
Просто гениальный пример. И что тебе мешает наступить на теже грабли в другом языке? Это уже ошибка ЛОГИКИ и на сколько мне извесно еще не создан язык который может поймать ВСЕ логические ошибки.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 19:02
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Именно. Оно реально бывает нужно раз в два года.

M>Что вообще стоит писать на C++, если не низкоуровневый код, с использованием WinAPI и т.п.? А во всех этих WinAPI union'ы кругом торчат.
КОМ серверы например. И вобще все что нужно. С++ дает неизмеримо больше возможностей и контроля чем дельфи.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 19:02
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Дельфи — отличный инструмент. Примерно, как хороший складной нож. Кому-то нравятся швейцарские ножи, на шестьдесят четыре лезвия, кому-то добротные одинарные.


M>И всем-то этот C++ хорош, только постоянно из него какое-нибудь лишнее лезвие выскакивает. А чтобы открыть некоторые лезвия, нужно вначале сбоку куда-то нажать. Короче, инструмент для фанатов.

Интересно когда это доказательства по аналогии чегото стоили?
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 19:02
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Мне кажется, твоя обувь слишком много на себя берёт.

Нда?
M>По функциональности C++ опережает Дельфи только в возможности компилировать драйвера.
Ржут даже мои носки у которых вобще нет чувства юмора.
Хотя что еще можно ждать от человека который не понимает зачем нужны и чем отличяются классы помошники от базовых классов. Но это и не удивительно в дельфе нет помошников.

WH>>А ну-ну. Напиши boost::spirit на дельфе. Можешь даже не пытаться. Не выдет.

M>Какой-то дыбильный boost::spirit. На Дельфи он попросту не нужен никому. Ты бы ещё попросил на C# Hashtable написать.
Вот когда тебе будет нужен парсер низкой или средней сложности я посмотрю как ты на дельфе будешь корячиться...

M>А ты вот напиши на C++ доступ к COM-объектам по позднему связыванию. Хоть поприкалываемся над небывалой простотой C++

Чаво?
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 19:02
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Ну знаю я по using жутко не удобно.

M>Ну мало ли. Главное, что всем удобно. Ради одного человека менять не будут.
ОДНОГО? Да все мои знакомые С++ники плюются на этот изврат.

WH>>К томуже Dispose может бросать исключения

M>В отличие от деструкторов C++, как я понимаю?
Да. Или хочешь сказать не понимаешь по чему это плохо?

WH>>Что ты тут нагнал вобще не понятно. Если ты про хранение потомков какого либо класса в одном контейнере то в С++ это делается на раз. Вот только генерацию такого контейнера берут на себя шаблоны.

M>В Delphi есть готовый контейнер для потомков какого-либо класса. TObjectList.
А в STL их 7 штук с разными свойствами. Массив, список...
Плюс смартпоинтер с множественным владением.

M>Для объектов с подсчётом ссылок TInterfaceList.

Все теже самые 7 штук плюс смартпоинтер который делает AddRef/Release.

И это только стандартные.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 19:02
Оценка:
Здравствуйте, mihailik, Вы писали:

FWP>>>А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов.

WH>>Ибо реализовать их нАмного сложнее чем кажется.
M>Ага. Компилятор Java написали. Интерпретатор и JIT'тер написали. А шаблоны — нет, тут сложность невероятно высока.
Ты просто не представляешь возможности шаблонов.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 19:02
Оценка:
Здравствуйте, mihailik, Вы писали:

M>А вот главные, архитектурные части — очень похожи. В трёх ключевых точках:


M>RTTI (aka Reflection)

Рефлекшен в дельфе... Бедные мои тапочки... Ну не надо сравнивать бумажный самолетик с истребителем пятого поколения.
M>Свойства
О да это величайшая АРХИТЕКТУРНАЯ особенность. К стати VC++ поддерживает свойства в качестве расширения.
M>Упор на простоту синтаксиса
Или убогость? Так чтобы [censured] поняли?

M>Значительная часть преимуществ как Делфи, так и C# коренится в этих трёх пунктах.

Особенно два последних.... величайшие преймущества.

И вобще при чем тут C#? Вы на сабж посмотрите.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 19:02
Оценка:
Здравствуйте, mihailik, Вы писали:

А>>3) Dispose() может выбрасывать исключения

M>А деструкторы C++, очевидно, не выбрасывают исключений? То-то прикольно, когда какой-нибудь Flush в деструкторе не вызовется и твоё приложение скромно об этом умолчит.
А теперь подумай что будет еслидеструкторы начнут кидать исключения:
Летит исключение прибивая объекты и в друг один из деструкторов сам кинул исключение и того два исключения одновременно. Что делать?

M>Правильно, а фиг ли что файл не сохранился. Нужно было почаще Backup делать

flush в деструкторе... гениально.

А>>4) Рекомендательный характер вызова Dispose(). Поубивал бы за это

M>Ага, не поняли они в Редмонде твоей таинственной русской души.
Ага и потом народ долго думает почему на тачке с 256М программа работает прекрасно, а на серваке с двумя гигами вешается в месте с виндой.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 19:02
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Короче, хотите программировать под Windows — читайте Страуструпа. Там всё написано. MSDN — для лохов. А если ваша программа заглючила, это всё бредни и чушь. Всё равно Страуструп круче в сто раз!

Ну что за бред ты тут несешь. MSDN ни кто не отменял. А вот слушать все что говорит братва из MS
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 16.09.03 19:55
Оценка:
Здравствуйте, mihailik, Вы писали:

A>>Но насчёт полезности этого Net для программирования и применения компьютеров можно долго рассуждать. Это же чёртов новый взгляд на интерпретаторы при ощутимом росте мощностей и производительности компьютеров...


M>Интерпретаторы? Причём здесь интерпретаторы?


Я же не говорю, что это интерпретатор, я говорю о взглядах.

Похожая схема, только дополнительные преобразования в некий промежуточный код, который потом ещё преобразовывается, но не сразу, а по необходимости, по требованию.

В Бейсиках есть похожая вещь, одни реализации интерпретируют те словоблудия, что видит и человек, другие (Access VBA) могут чего-то там прекомпилировать, и интерпретировать потом это быстрее...
... << RSDN@Home 1.1 beta 2 >>
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 16.09.03 19:55
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>> Разговорные языки по функциональности практически равноценны. Но С++ и делфи... ой не смешите мои тапочки.


M>Мне кажется, твоя обувь слишком много на себя берёт.


Вот это в точку! Это стоит баллов. WH сам провоцировал, так часто употреблял этот "аргумент" в разговорах...
... << RSDN@Home 1.1 beta 2 >>
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 16.09.03 19:55
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Ни фига ты не понял. С++ САМ превращается в другие язаки. boost::spirit превращает его в язык для записи EBNF грамматики. Дельфя на такое не спасобна.


M>А на фиг это надо?


M>Если вам нужна ножовка, вы берёте в руки ножовку. Если вым нужен утюг, вы берёте утюг. Но кому нужа пила с дополнительными функциями утюга?


Нет, ну как же тебе не понятно, с помощью буста можно C++ назвать другим языком, потому что он легко самостоятельно превращается во что ... нужно? ... угодно? ... в Дельфи? ... другой С++. Во что он САМ превращается, кстати?

Ну а не прикалываясь, я из нашего разговора вынес информацию о удобстве, богатстве, многофункциональности и простоте шаблонов. Про простоту писал. Остальные вещи обсуждаемы и признаваемы полезными. По-дельфийски я бы сказал, что библиотека у них хорошая, с хорошей поддержкой...
... << RSDN@Home 1.1 beta 2 >>
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 20:14
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> using в Net нужен только для освобождения системных ресурсов для их немедленного освобождения, во всех других объектах нет деструкторов в в обычном понимании, т.к. за освобождение памяти занятой объектом следит GC. Но через GC а так же через выделение памяти неподвласное GC итд можно многое, к сожалению еще не во все дебри Net залез.

Все что GC попало уже не детерминировано. И using не всегда спасти может.

S>>>>> Например???? Шаблоны будут, что еще???

WH>>>>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
S>Насчет шаблонов в Net посмотри http://www.dotsite.ru/Publications/PublicationDetails.aspx?ID=115
S> Почитай очень интересно, плю что предлагают SUN. Так что ты со своими шаблонами уже отстал от жизни.
Ну прочитал. После С++ шаблонов каменный век. Конечно не на столько плохо как сейчас но всеравно близко нет той мощи.
И ни слова о подключении реализации. Такое впечатление что ни кому не надо. Неполные типы это ИМХО штука безполезная особенно если сделать нормальное подключение реализации.

S> Шаблоны,макросы по сути являются Copy-Paste-Replace и ни о каком ООП не идет и речи и легко реализуются без компиляторов путем генерации соответсвующих модулей на основании "Шаблона".

Да ни фига подобного. Слова дилетанта. Это .НЕТ шаблоны можно генерить генератором, а С++ требуют информации о типах на много больше.
S> А вот шаблоны в Net это действительно ООП.
Обьясни мне пожалуйста кого волнует ФИЗИЧЕСКОЕ ООП. А что касается логической состовляющей то шаблоны в С++ очень объектно ориентированые.
При помощи С++ шаблонов можно не только создавать обобщенные контейнеры но и выберать алгоритм наиболие подходящий типу.
Например так Кто хотел определения наличия функции-члена?
Автор: MaximE
Дата: 13.09.03

И много чего еще.

S> Кроме всего прочего на данном этапе надежность кода встает на первый план (хотя мне это и не импонирует)

Какие проблемы с надежностью С++ шаблонов мне ктонибудь обьяснит наконец?
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 16.09.03 20:30
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Нет, ну как же тебе не понятно, с помощью буста можно C++ назвать другим языком, потому что он легко самостоятельно превращается во что ... нужно? ... угодно? ... в Дельфи? ... другой С++. Во что он САМ превращается, кстати?

Во что хотим в то и превращаем хотим EBNF грамматики пишим, хотим FSM задаем...
//Реализация finite_state_machine тривиальна
enum Events
{
    letter,
    digit,
    space,
};
struct EventsCallBack
{
    template<class T, class U>
    bool operator()(const T& cur, const T& next, U event)
    {
        std::cout<<cur.get_info()<<"  "<<next.get_info()<<std::endl;
        return true;
    }
};
struct test_machine
    :finite_state_machine<Events, std::string>
{
    test_machine()
        :empty("empty")
        ,number("number")
        ,identifier("identifier")
        ,unknown("unknown")
    {
        start(empty);
        empty
            =    (letter>>identifier)[EventsCallBack()]
            |    (digit>>number)[EventsCallBack()]
            ;
        identifier
            =    (letter>>identifier)[EventsCallBack()]
            |    (digit>>identifier)[EventsCallBack()]
            ;
        number
            =    (digit>>number)[EventsCallBack()]
            |    (letter>>unknown)[EventsCallBack()]
            ;
        unknown
            =    default_state(unknown)[EventsCallBack()]
            ;
    }
    state empty, number, identifier, unknown;
};

Причем используя туже систему FSM может быть задан динамически. Ну это я так для развлечения писал.

A>Ну а не прикалываясь, я из нашего разговора вынес информацию о удобстве, богатстве, многофункциональности и простоте шаблонов. Про простоту писал. Остальные вещи обсуждаемы и признаваемы полезными. По-дельфийски я бы сказал, что библиотека у них хорошая, с хорошей поддержкой...
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 17.09.03 05:14
Оценка:
Здравствуйте, mihailik, Вы писали:

M>По функциональности C++ опережает Дельфи только в возможности компилировать драйвера.

Не опережает. Компилировать драйверы для ОС Windows можно только на MS VC++. А вот на GCC или Watcom C++ каком-либо не выйдет. Так же как и на Delphi. Так что это не ограничения языка. Это БОЛЬШАЯ политика MS.
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 17.09.03 05:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Вот только шаблоны сводят ручную работу практически на нет. А если учесть что очень многим приложениям не нужно куча диалогов...

Насчет многим это ты погорячился. Я к примеру 90% своих программ пишу для конечного пользователя (весьма далекого от программирования и компьютеров). Поэтому хороший GUI ОБЯЗАТЕЛЕН.
WH>... и написать интерфейс при помощи WTL не состовляет большого труда...
Вот именно. НАПИСАТЬ. И ты не видишь в этом ничего дурного. А когда я говорю, что сортировку можно написать или использовать библиотеку — это почему-то неправильно. Двойные стандарты какие-то.

WH>>>>>Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.

FWP>>И он в некотрых случаях может принять неправильное решение.
FWP>>И следить за этим надо и обходить такие ситуации вручную. Да и надежности это не добавляет.
WH>Конкретно пожалуйста. Ни разу не встречал.
Посмотри весь топик. Я приводил цитату вашего любимого папочки Страуструпа. Повторять лень.
Re: Спор бесполезен!
От: WolfHound  
Дата: 17.09.03 05:39
Оценка:
Здравствуйте, Miem, Вы писали:

M> Этот Человек одержим! Это положительно его характеризует!

M>Давно слежу за топиком. Все ответы четкие, все в тему, но с уклоном в одно.. Однобокий взгляд...
M>Попробуйте поспорить с истинным православным. У вас ничего не получится... Когда человек ВЕРИТ в то, что говорит его не переубедить, он живет этим. Поставить под сомнение веру такого человека — значит посягнуть на самое дорогое, обречь на гибель. Коперника сожгли такие люди! Опомнитесь!
Ты на остальных посмотри... Они верят в то что отсутствие сторогой типизации благо... Что шаблоны в .НЕТ круче чем в С++ ...

M>PS Не в обиду WolfHound'у

Да я не обидчивый.
И вобще как только появится инструмент превосходящий по возможностям С++ я перейду на него. А пока...
Если у .НЕТ есть коекакие преймущества перед С++ но у дельфи ...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: DOOM Россия  
Дата: 17.09.03 05:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:


WH>>>Ах да я же забыл в дельфе нет инлайнов и дробление сказывается на производительности...

DOO>>Они есть! Просто их не надо описывать ручками, а это сделает за нас компилятор.
WH>А ты с С++ не путаешь? Если мне не изменяет скалероз дельфя вобще ни чего не подставляет.

Посмотри асмовский код... Может просто юзал доисторические Дельфи.
Re[5]: Некоторые итоги:
От: DOOM Россия  
Дата: 17.09.03 05:53
Оценка:
Здравствуйте, centurn, Вы писали:


C> А каким-нибудь Deplhi 3.0 по политическим соображениям не заставляют пользоваться для сравнения?


Если и сравнивать, то 6-м тогда уж. В крайнем случае с 5-м. Они намного круче 6-й VS
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 17.09.03 06:44
Оценка:
Здравствуйте, FWP, Вы писали:

WH>>Вот только шаблоны сводят ручную работу практически на нет. А если учесть что очень многим приложениям не нужно куча диалогов...

FWP>Насчет многим это ты погорячился. Я к примеру 90% своих программ пишу для конечного пользователя (весьма далекого от программирования и компьютеров). Поэтому хороший GUI ОБЯЗАТЕЛЕН.
А слабо на дельфях нарисовать ГУЙ в ХР стиле?

WH>>... и написать интерфейс при помощи WTL не состовляет большого труда...

FWP>Вот именно. НАПИСАТЬ. И ты не видишь в этом ничего дурного. А когда я говорю, что сортировку можно написать или использовать библиотеку — это почему-то неправильно. Двойные стандарты какие-то.
Та видел как на WTL пишут ГУИ? Думаю что нет. вот я видел как на дельфе пишут обобщенные сортировки

WH>>Конкретно пожалуйста. Ни разу не встречал.

FWP>Посмотри весь топик. Я приводил цитату вашего любимого папочки Страуструпа. Повторять лень.
Это про забытый сопиконструктор чтоли? Дык они нужны только помошникам. Классы логики в 99.99% случаев имеют правильный.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Спор бесполезен!
От: Miem Россия  
Дата: 17.09.03 06:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Ты на остальных посмотри... Они верят в то что отсутствие сторогой типизации благо... Что шаблоны в .НЕТ круче чем в С++ ...


M>>PS Не в обиду WolfHound'у

WH>Да я не обидчивый.
WH>И вобще как только появится инструмент превосходящий по возможностям С++ я перейду на него. А пока...
WH>Если у .НЕТ есть коекакие преймущества перед С++ но у дельфи ...

Просто нужно всегда понимать что язык — инструмент, шаблоны,строгая типизация — это тоже инструменты. Это то, с помощью чего решают задачи. Дык вот правильным набор инструментов будет тот, который по возможностям максимально сверху приближен к достаточным условиям задачи. И цитата в твоей подписи об этом говорит:

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

... << RSDN@Home 1.1 beta 2 >>
ICQ: 446240
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 17.09.03 06:59
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>>>Они есть! Просто их не надо описывать ручками, а это сделает за нас компилятор.

WH>>А ты с С++ не путаешь? Если мне не изменяет скалероз дельфя вобще ни чего не подставляет.
DOO>Посмотри асмовский код... Может просто юзал доисторические Дельфи.
VC++7.1
int add1(int x, int y)
{
    return x+y;
}
int add2(int x, int y)
{
    return add1(x, y)+add1(x, y);
}
int main()
{
    return add2(5, 6);
}


PUBLIC    _main
; Function compile flags: /Ogty
;    COMDAT _main
_TEXT    SEGMENT
_main    PROC NEAR                    ; COMDAT

; 186  :     return add2(5, 6);

    mov    eax, 22                    ; 00000016H

; 187  : }

    ret    0
_main    ENDP

Немного усложним
int main()
{
    return add2(GetTickCount(), 6);
}


_main    PROC NEAR                    ; COMDAT

; 186  :     return add2(GetTickCount(), 6);

    call    DWORD PTR __imp__GetTickCount@0
    lea    eax, DWORD PTR [eax+eax+12]

; 187  : }

    ret    0
_main    ENDP


Ну как? А какие результаты даст дельфя? Причем это очень простые примеры.
Но практака показывает что запутать компилятор практически не возможно.

ЗЫ на номера строк в асмовом коде не смотрем у меня там еще куча всего.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Спор бесполезен!
От: WolfHound  
Дата: 17.09.03 07:06
Оценка:
Здравствуйте, Miem, Вы писали:

M>Просто нужно всегда понимать что язык — инструмент, шаблоны,строгая типизация — это тоже инструменты. Это то, с помощью чего решают задачи. Дык вот правильным набор инструментов будет тот, который по возможностям максимально сверху приближен к достаточным условиям задачи. И цитата в твоей подписи об этом говорит:

По мне так чем меньше РУЧНОЙ работы тем лучше. В С++ ручками надо работать один раз при написании шаблона, а потом в сотне мест с различными типами использую.

M>

M>Пусть это будет просто:
M>просто, как только можно,
M>но не проще.
M>(C) А. Эйнштейн

Вот именно нельзя делать проще чем можно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Спор бесполезен!
От: Аноним  
Дата: 17.09.03 07:08
Оценка:
Здравствуйте, centurn, Вы писали:

C> Ага. Осторожно, WolfHound, а то эти Delphi-поклонники и сжечь могут.


Идельфопоклонники!
Re[32]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 17.09.03 07:22
Оценка:
WH>Мне нужен типизированый, автоматический массив созданный КОМовским аллокатором с возможностью вернуть его из функции.
WH>А тепер скажи какой такой базовый класс может быть у массива?

Ага, ну тогда понял.

function CreateMyStructArray(count : integer) : PMyStructArray;
begin
  Result := (PMyStructArray) КакТамПолучитьПамять( count*sizeof(TMyStruct) )
end;


Конечно, в отличие от шаблона тут придётся писать функцию CreateMyStructArray. Это, ясное дело, преимущество C++. Но считать такое мелкое преимущество чем-то гениальным и крутым — какой-то явный перекос.

M>>Бедные сишники! А как же они с WinAPI работают без try/finally? Сделали CreateFile, поковырялись, получили Exception — и файл остался висеть?


WH>Вот только жалеть нас не надо. Ибо с WinAPI без враперов работают только [censured]. А враперы уже и человеческий интерфейс предоставят и ресурс отдать не забудут.


Серьёзно? И что, на все тысячи функций WinAPI есть врапперы? И что, точно отражают семантику, не суживая способов применения? К примеру, есть такая утомительная область, как NT ACL. Наваляли на неё уже врапперы, или по старинке try/finally пишут?

Что-то не верится. Сдаётся мне, что подобные врапперы приходится писать самому программеру время от времени, когда оказывается, что поблизости нет готового.

А если вызвать-то нужно на всю программу два раза какой-нибудь "DeviceIOControlEx"? Тоже садишься и аккуратно пишешь враппер? О, это крутое преимущество C++. Избавление от ручного труда называется

Да, а ещё бывают сторонние библиотеки со своей дурацкой семантикой. На них что, тоже врапперы писать, если нужно некий try/finally — подход?
... << RSDN@Home 1.1 beta 1 >>
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 17.09.03 07:47
Оценка:
Здравствуйте, mihailik, Вы писали:


M>Ага. Компилятор Java написали. Интерпретатор и JIT'тер написали. А шаблоны — нет, тут сложность невероятно высока.


Вы когда-нибудь пробовали писать type checking и name analysis для кого-нибудь языка ?
Это само по себе не так просто, если язык поддерживает неявные преобразования и позволяет пользователю специфицировать дополнительные неявные преобразования. Добавление шаблонов увеличивает сложность реализации на порядок, а то и больше.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: ArtDenis Россия  
Дата: 17.09.03 07:48
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>> Разговорные языки по функциональности практически равноценны. Но С++ и

WH>> делфи... ой не смешите мои тапочки.

m> Мне кажется, твоя обувь слишком много на себя берёт.

m> По функциональности C++ опережает Дельфи только в возможности
m> компилировать драйвера.



2mihailik: большая просьба, обдумывать свои ответы собеседнику, иначе есть
вероятность того, что модератор перенесёт эту ветку в "Коллеги, улыбнитесь"


---------------------------------------------------------
СНП, Artyomov Denis. E-mail: artyomov <at> inbox.ru
Posted via RSDN NNTP Server 1.7 beta
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[4]: Спор бесполезен!
От: Miem Россия  
Дата: 17.09.03 07:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

M>>Просто нужно всегда понимать что язык — инструмент, шаблоны,строгая типизация — это тоже инструменты. Это то, с помощью чего решают задачи. Дык вот правильным набор инструментов будет тот, который по возможностям максимально сверху приближен к достаточным условиям задачи. И цитата в твоей подписи об этом говорит:


WH>По мне так чем меньше РУЧНОЙ работы тем лучше.

Всегда приветствуется!

WH> В С++ ручками надо работать один раз при написании шаблона, а потом в сотне мест с различными типами использую.

согласен, но это только если задача подразумевает эту "сотню мест".

WH>Вот именно нельзя делать проще чем можно.

А про проще чем можно никто и не говорил.

Вот видишь, однобокий взгляд Я тебе про набор инструментов для решении задачи, а ты про шаблоны и про ручную работу. Согласен с тем, что все вот эти вещи: язык, шаблоны, строгая типизация, RTTI(Reflection), макросы и тд. — это иструменты? Так я о том, что без необходимости все мешать не надо. Задачу можно решить разными способами в контексте разных инструментов. Именно в контексте, поэтому нужно четко представлять пути решения с помощью разных наборов инструментов, и не пытаться применить методы из одного набора к другому! Решения могут быть совершенно разные, но итог — удовлетворение конечным требованиям, готовый продукт одинаковым по функционалу. Вот где творчество!
... << RSDN@Home 1.1 beta 2 >>
ICQ: 446240
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 17.09.03 07:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, akasoft, Вы писали:


A>>Нет, ну как же тебе не понятно, с помощью буста можно C++ назвать другим языком, потому что он легко самостоятельно превращается во что ... нужно? ... угодно? ... в Дельфи? ... другой С++. Во что он САМ превращается, кстати?

WH>Во что хотим в то и превращаем хотим EBNF грамматики пишим, хотим FSM задаем...
WH>
WH> ...
WH>

WH>Причем используя туже систему FSM может быть задан динамически. Ну это я так для развлечения писал.


Ужас! FSM надо генерить из чего-нибудь более наглядного, например из UML statechart диаграмм.
В данном случае можно не заботиться о том, как оно все будет выглядить в генеренном коде, а сосредоточиться на эффективности сего генеренного кода.
Если необходима возможность reuse-а (например отнаследоваться от конкретной FSM), то можно предусмотреть возможность генерации FSM в ОО-виде, где transition суть виртуальная функция. (В UML 2.0 transition-ы могут быть виртуальными и переопределяться в наследниках FSM-а).
Если возможность reuse-а не нужна, то генерим простой double-switch (по state-ам и incoming events), такой подход даст максимальную эффективность.

Писать реализацию FSM-а ручками — это не правильно.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 17.09.03 08:09
Оценка:
FWP>>Насчет многим это ты погорячился. Я к примеру 90% своих программ пишу для конечного пользователя (весьма далекого от программирования и компьютеров). Поэтому хороший GUI ОБЯЗАТЕЛЕН.
WH>А слабо на дельфях нарисовать ГУЙ в ХР стиле?

Ты чего? Вообще без проблем делается.

В стиле Office XP, правда есть неурядицы. Borland'овское меню в из Delphi7 стиле Office XP глючит иногда.

WH>>>Конкретно пожалуйста. Ни разу не встречал.

FWP>>Посмотри весь топик. Я приводил цитату вашего любимого папочки Страуструпа. Повторять лень.
WH>Это про забытый сопиконструктор чтоли? Дык они нужны только помошникам. Классы логики в 99.99% случаев имеют правильный.

Чего-то я не пойму. Такое впечатление, что для тебя просто не существует процесса написания помощников и связанных с этим трудозатрат.
... << RSDN@Home 1.1 beta 1 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 17.09.03 08:09
Оценка:
WH>>>Именно. Оно реально бывает нужно раз в два года.

M>>Что вообще стоит писать на C++, если не низкоуровневый код, с использованием WinAPI и т.п.? А во всех этих WinAPI union'ы кругом торчат.


WH>КОМ серверы например. И вобще все что нужно. С++ дает неизмеримо больше возможностей и контроля чем дельфи.


Ага. А Delphi, Java и C# избавляют программиста от необходимости контроля. Контроль берёт на себя среда.

Возможностей и мощностей в C++, конечно, много. Но в метро и общественном транспорте не нужны альпинистские крючья и верёвки. Они там мешают.
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 17.09.03 08:09
Оценка:
M>>Мне кажется, твоя обувь слишком много на себя берёт.
WH>Нда?
M>>По функциональности C++ опережает Дельфи только в возможности компилировать драйвера.
WH> Ржут даже мои носки у которых вобще нет чувства юмора.
WH>Хотя что еще можно ждать от человека который не понимает зачем нужны и чем отличяются классы помошники от базовых классов. Но это и не удивительно в дельфе нет помошников.

Ага. Значит ты готов конкретно и чётко сравнить функциональность C++ и Дельфи? Без отвлечённых рассуждений?

Если ты считаешь, что шаблоны или множественное наследование — функциональностью языка, то я с тобой не соглашусь. Функция — это то, что можно применить наружу, а не внутриязыковые приколы.

Чем C++ может уделать Дельфи с позиций внешнего наблюдателя?

WH>>>А ну-ну. Напиши boost::spirit на дельфе. Можешь даже не пытаться. Не выдет.

M>>Какой-то дыбильный boost::spirit. На Дельфи он попросту не нужен никому. Ты бы ещё попросил на C# Hashtable написать.
WH>Вот когда тебе будет нужен парсер низкой или средней сложности я посмотрю как ты на дельфе будешь корячиться...

Чисто умозрительные утверждения. В интернете куча парсеров, написанных на Паскале. Дельфи-компилятор, насколько я помню, тоже на Паскале.

M>>А ты вот напиши на C++ доступ к COM-объектам по позднему связыванию. Хоть поприкалываемся над небывалой простотой C++


WH>Чаво?


Есть COM-объект. Необходимо вызывать какие-то его методы, использовать свойства при помощи позднего связывания, т.е. методов IDispatch. В скриптовых языках, в VB, в Дельфи это очень просто.

var Excel : Variant;

begin
  Excel := CreateOleObject('Excel.Application');
  Excel.OpenFile('sdfsdfsdfsd.xls');
  Excel.Range("A1").Value=294;
end.
... << RSDN@Home 1.1 beta 1 >>
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 17.09.03 08:09
Оценка:
WH>>>Ну знаю я по using жутко не удобно.
M>>Ну мало ли. Главное, что всем удобно. Ради одного человека менять не будут.
WH>ОДНОГО? Да все мои знакомые С++ники плюются на этот изврат.

Ёжики плакали, кололись, но продолжали есть кактус. Чего вам на C++ не пишется?

WH>>>К томуже Dispose может бросать исключения

M>>В отличие от деструкторов C++, как я понимаю?
WH>Да. Или хочешь сказать не понимаешь по чему это плохо?

Да не понимаю. Если возникла ошибочная ситуация, почему не выбрасывается исключение?

WH>>>Что ты тут нагнал вобще не понятно. Если ты про хранение потомков какого либо класса в одном контейнере то в С++ это делается на раз. Вот только генерацию такого контейнера берут на себя шаблоны.

M>>В Delphi есть готовый контейнер для потомков какого-либо класса. TObjectList.
WH>А в STL их 7 штук с разными свойствами. Массив, список...

Круто! Семь штук! Кстати, а при чём здесь Дельфи vs C++?

Ну напишу я на Дельфи не 7, а 97 таких контейнеров — Дельфи станет от этого круче?
... << RSDN@Home 1.1 beta 1 >>
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 17.09.03 08:09
Оценка:
S> а учитывая кроме всего прочего что SQL еще и интерпретатор то....

В MS SQL точно компилятор, а не интерпретатор.

Думаю, и в других "больших" серверах то же самое.
... << RSDN@Home 1.1 beta 1 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: Miem Россия  
Дата: 17.09.03 08:19
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Гм. У нас на нем (C++/C) написан CASE тул, который включает: GUI, внутренние представление для модели, парсеры, кодогенераторы, Debugger, run-time библиотеки, импорт из других языков, storage в XML и все остальное. И все это хозяйство работает и под Win и под Solaris и под Linux. Помимо всего прочего, мы имеем COM Api, просто Api и Tcl Api. Все немеряно расширяемо.


Как называеться? Можно посмотреть?
... << RSDN@Home 1.1 beta 2 >>
ICQ: 446240
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 17.09.03 08:30
Оценка:
Здравствуйте, Miem, Вы писали:

M>Здравствуйте, _Obelisk_, Вы писали:



M>Как называеться? Можно посмотреть?


http://www.taug2.com. Называется Tau/Developer, стоит $20 000, на сайте вроде бы была демо-версия, но она малость старая (версия 2.0, а сейчас уже выпустили 2.2.20 ) и сильно урезанная.

http://www.telelogic.com/campaigns/2003/americas/sd_taug2/index.cfm?source=homepage
мнение SD Magazine-а о версии 2.0 .



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[42]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 17.09.03 08:32
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

WH>>Причем используя туже систему FSM может быть задан динамически. Ну это я так для развлечения писал.

хъ
_O_>Писать реализацию FSM-а ручками — это не правильно.
Ы?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 17.09.03 08:37
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>>>Конкретно пожалуйста. Ни разу не встречал.

FWP>>>Посмотри весь топик. Я приводил цитату вашего любимого папочки Страуструпа. Повторять лень.
WH>>Это про забытый сопиконструктор чтоли? Дык они нужны только помошникам. Классы логики в 99.99% случаев имеют правильный.

M>Чего-то я не пойму. Такое впечатление, что для тебя просто не существует процесса написания помощников и связанных с этим трудозатрат.

Один раз забить все необходимое в помошник и пользоваться не задумываясь об освобождении ресурсов или постоянно писать try/finally для освобождения ресурсов.
Как ты думаешь в каком случае трудозатраты больше?
Причем практика показывает что написать помошник выгодней даже если используешь его один раз ибо логика работы с ресурсом не смешивается с основной логикой программы.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 17.09.03 08:43
Оценка:
Здравствуйте, mihailik, Вы писали:

>На теже грабли в другом языке я сознательно об этих вопросах беспокоюсь. А в C++ мне Wolfhound, авторитетно сказал, что о времени жизни беспокоиться не нужно.


M>Или всё-таки нужно?

Если тебя волнует будет ли освобожден ресурс до выхода из функции то не нужно. Но если есть какято очень хитрая логика которая случается раз в год...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 17.09.03 08:45
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>КОМ серверы например. И вобще все что нужно. С++ дает неизмеримо больше возможностей и контроля чем дельфи.

M>Ага. А Delphi, Java и C# избавляют программиста от необходимости контроля. Контроль берёт на себя среда.
Где ты среду в дельфе нашол? Дельфи это unmanaged компилятор с произвольным доступом к памяти. Ни какого контроля.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 17.09.03 08:53
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Ага. Значит ты готов конкретно и чётко сравнить функциональность C++ и Дельфи? Без отвлечённых рассуждений?

Да.

M>Если ты считаешь, что шаблоны или множественное наследование — функциональностью языка, то я с тобой не соглашусь.

M>Функция — это то, что можно применить наружу, а не внутриязыковые приколы.

M>Чем C++ может уделать Дельфи с позиций внешнего наблюдателя?
Ни чем. С точки зрения пользователя пофигу как написано приложение на дельфе, С++, асме или в машинных кодах.
А вот с точки зрения ПРОГРАММИСТА не первый план выходят "внутриязыковые приколы".
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 17.09.03 09:10
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Ёжики плакали, кололись, но продолжали есть кактус. Чего вам на C++ не пишется?

Еще как пишется. Просто надо же посмотреть новомодный технологии.

M>Да не понимаю. Если возникла ошибочная ситуация, почему не выбрасывается исключение?

В С++ существует раскрутка стека исключением при это вызываются деструкторы автоматических объектов и что ты будешь делать с двумя исключениями сразу?

M>Круто! Семь штук! Кстати, а при чём здесь Дельфи vs C++?

При том что STL это часть С++.

M>Ну напишу я на Дельфи не 7, а 97 таких контейнеров — Дельфи станет от этого круче?

Это 7 базовых контейнеров на их основе можно сделать что угодно.
И вобще попробуй придумать 97 различных структур данных
std::list — двухсвязный список
std::vector — массив
std::set — множество(любых объектов)на основа КЧ дерева
std::map — ассациотивный массив на основа КЧ дерева
std::deque — структура данных с произвольным доступом оптимизирована на вставку/удаление с конца или начала
std::stack — стек
std::queue — очередь
еще 90 структур данных пожалуйста
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 17.09.03 09:20
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Ага, ну тогда понял.

M>
M>function CreateMyStructArray(count : integer) : PMyStructArray;
M>begin
M>  Result := (PMyStructArray) КакТамПолучитьПамять( count*sizeof(TMyStruct) )
M>end;
M>

M>Конечно, в отличие от шаблона тут придётся писать функцию CreateMyStructArray. Это, ясное дело, преимущество C++. Но считать такое мелкое преимущество чем-то гениальным и крутым — какой-то явный перекос.
Да ни хрена ты не понял. Посошник САМ совободит память и вызовет деструкторы у объектов если в процессе заполнения произойдет сбой.

M>Серьёзно? И что, на все тысячи функций WinAPI есть врапперы? И что, точно отражают семантику, не суживая способов применения? К примеру, есть такая утомительная область, как NT ACL. Наваляли на неё уже врапперы, или по старинке try/finally пишут?

хъ

try/finally это РУЧНОЕ освобождение ресурсов. В С++ освобождать ресурсы руками это дурной тон, а в дельфе без альтернатив.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[43]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 17.09.03 09:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, _Obelisk_, Вы писали:


_O_>>Писать реализацию FSM-а ручками — это не правильно.

WH>Ы?


Угу, любой универсальный язык программирования для этого плохо подходит.
Тут нужно нечто иное, скажем у нас это выглядит так

signal ok;
statemachine S {
   start {
      outupt self.ok(); // сами себе посылаем, иная запись   ^self.ok();
      nextstate st1;
   }
   state st1;
      input ok {
         nextstate st2;
      }
   state st2;
      input * { // реагирования на любой сигнал
         stop;
      }
}



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 17.09.03 10:19
Оценка:
Тоже подведу итоги.
Если смотреть на влияние Языков на дальнейшее развитие средств программирования, то идеи Вирта и Хэйлсберга воплощенные в востребованных языках оказали намного больше влияния, чем идеи воплощенные в С и С++.
Некоторые размышления высказаны в http://www.rsdn.ru/Forum/Message.aspx?mid=383611&amp;only=1
Автор: Serginio1
Дата: 15.09.03

И немного дополню от себя. Т.К. дальнейшее развитие связано с Net или аналогичной системы у меня лично сомнений не вызывает.
Структурированность кода и строгая типизация воплощенная Виртом в Паскале на данный момент воплощена во всех языках. Помню как еще во времена ДВК-2 после Фортрана и Васика просто наслаждался Else, Case,Record,Set, рекурсией, связными списками, вложенными процедурами итд.
Хэйлсберг еще в TP 6 ввел объекты имеющие одного общего предка а в Delphi развил идею компонентности которая сразу завоевала популярность. Кроме всего прочего в Delphi изначально встроена поддержка Строк и интерфейсов в том числе и посчет ссылок и в базовом классе TObject function GetInterface(const IID: TGUID; out Obj): Boolean;
Встроенная поддержка Вариантов в Delphi имеет отображение в Net через более продуманное функциональность базового класса Object. Свойства, события, Procedure of Object или TMetod тоже воплощены в делегатах (правда еще больше расширены и с поддержкой асинхронного вызова).
Кроме всего из-за одного общего разработчика целостность Delphi не вызывает сомнений.
Что же я вижу в Net из С++.
1. Структуры с поддержкой методов.
2. Перегрузка операторов, которую поддерживает только С#.
3. Перегрузка методов (Хотя она и существут в Delphi c 4 версии).
И все?????
Линию шаблонов которую так упорно гнет WolfHound легко реализуетс через интерфейсы, но это ООП в отличие от шаблонов. Кроме всего прочего не составляет труда написать программу для генерации исходников со всеми возможностями наблонов С++.
Хотя моему разгильдяйскому характеру и очень нравится С++ за его гибкость, но считаю выбрал правильный путь выбрав Delphi и Net.
и солнце б утром не вставало, когда бы не было меня
Re[3]: Некоторые итоги:
От: _Obelisk_ Россия http://www.ibm.com
Дата: 17.09.03 11:28
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Тоже подведу итоги.


S> Линию шаблонов которую так упорно гнет WolfHound легко реализуетс через интерфейсы, но это ООП в отличие от шаблонов.



ООП и шаблоны могут сосуществовать, шаблоны есть в UML 2.0, причем они даже мощнее чем в С++.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[6]: Некоторые итоги:
От: AndrewJD США  
Дата: 17.09.03 11:54
Оценка:
Здравствуйте, DOOM, Вы писали:


DOO>Если и сравнивать, то 6-м тогда уж. В крайнем случае с 5-м. Они намного круче 6-й VS


Незабываем добовлять ИМХО. Кому как. Вот раньше мне нравился Delphi IDE. Но если заниматься не только рисованием форм, то связка VS6 + VisualAssist — THE BEST (ИМХО ). Студия 7.1 тоже хороша, но почемуто MS обидела С++. Там редактор гораздо слабее чем для C#
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 17.09.03 12:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А слабо на дельфях нарисовать ГУЙ в ХР стиле?

Насколько я знаю в Delphi7 это возможно.

WH>>>... и написать интерфейс при помощи WTL не состовляет большого труда...

FWP>>Вот именно. НАПИСАТЬ. И ты не видишь в этом ничего дурного. А когда я говорю, что сортировку можно написать или использовать библиотеку — это почему-то неправильно. Двойные стандарты какие-то.
WH>Та видел как на WTL пишут ГУИ? Думаю что нет.
Да какая разница как? Главное РУЧКАМИ.

WH>>>Конкретно пожалуйста. Ни разу не встречал.

FWP>>Посмотри весь топик. Я приводил цитату вашего любимого папочки Страуструпа. Повторять лень.
WH>Это про забытый сопиконструктор чтоли? Дык они нужны только помошникам. Классы логики в 99.99% случаев имеют правильный.
Согласен. При определенных опыте и самодисциплине обойти опасные ситуации несложно. Но и опыт и самодисциплина понятия субъективные и к языку никакого отношения не имеют.
Re[3]: Некоторые итоги:
От: WolfHound  
Дата: 17.09.03 12:34
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Линию шаблонов которую так упорно гнет WolfHound легко реализуетс через интерфейсы, но это ООП в отличие от шаблонов.


S>Кроме всего прочего не составляет труда написать программу для генерации исходников со всеми возможностями наблонов С++.
А это вобще сильно сказано Ты ее пол года писать будешь и еще два года отлаживать.(Если в коммандн то немного поменьше)
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 17.09.03 12:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>> Линию шаблонов которую так упорно гнет WolfHound легко реализуетс через интерфейсы, но это ООП в отличие от шаблонов.

WH>
S>>Кроме всего прочего не составляет труда написать программу для генерации исходников со всеми возможностями наблонов С++.
WH>А это вобще сильно сказано Ты ее пол года писать будешь и еще два года отлаживать.(Если в коммандн то немного поменьше)
Я не собираюсь писАть из-за невостребованности, да и уже появляются другие средства. Все зависит от ручек. Спасибо за твое мнение о моих возможностях.
и солнце б утром не вставало, когда бы не было меня
Re[5]: Некоторые итоги:
От: WolfHound  
Дата: 17.09.03 12:59
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Кроме всего прочего не составляет труда написать программу для генерации исходников со всеми возможностями наблонов С++.

WH>>А это вобще сильно сказано Ты ее пол года писать будешь и еще два года отлаживать.(Если в коммандн то немного поменьше)
S> Я не собираюсь писАть из-за невостребованности, да и уже появляются другие средства. Все зависит от ручек. Спасибо за твое мнение о моих возможностях.
Я не о твоих спасобностях я о сложносте задачи. Ты ее не дооцениваешь и сильно.
А вот о других средствах которые могут заменить шаблоны по подробней.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
от модератора
От: _MarlboroMan_ Россия  
Дата: 17.09.03 13:34
Оценка:
Здравствуйте, ArtDenis, Вы писали:

AD>2mihailik: большая просьба, обдумывать свои ответы собеседнику, иначе есть

AD>вероятность того, что модератор перенесёт эту ветку в "Коллеги, улыбнитесь"
AD>

пока еще не унесет, но "по шапке надавать" может. обоим есть за что...
... << RSDN@Home 1.1 beta 2 >>

— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Re[6]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 17.09.03 13:57
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А вот о других средствах которые могут заменить шаблоны по подробней.

http://www.osp.ru/news/soft/2003/09/15_01_print.htm
http://www.wn.ru/computers/16.09.2003/6.html
и солнце б утром не вставало, когда бы не было меня
Re[6]: Некоторые итоги:
От: centurn Россия  
Дата: 17.09.03 14:51
Оценка:
Здравствуйте, DOOM, Вы писали:

C>> А каким-нибудь Deplhi 3.0 по политическим соображениям не заставляют пользоваться для сравнения?

DOO>Если и сравнивать, то 6-м тогда уж. В крайнем случае с 5-м.

Ага, помнится, мне, для того, чтобы поработать в 5-м Delphi, приходилось переключать экран в какой-то жуткий режим, иначе уже Splash screen этой делфи мне намертво комп вешал. Так что для меня субъективно 4-й Делфи лучше 5-го. А 6-й студии афайк хронологически как раз 5-я делфя соответствует.
Кстати, кривая работа при нестандартных настройках видео (Large fonts, например) — классическая болезнь дельфийских прог, а иногда вот и самой делфийской IDE...

DOO>Они намного круче 6-й VS


Не забывай про "имхо"...
По моим представлениям, главный недостаток VS6 — плохая работа с шаблонами, что явно не тянет на аргумент в пользу Делфей.
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 17.09.03 15:44
Оценка:
FWP>>>>А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов.
WH>>>Ибо реализовать их нАмного сложнее чем кажется.
M>>Ага. Компилятор Java написали. Интерпретатор и JIT'тер написали. А шаблоны — нет, тут сложность невероятно высока.
WH>Ты просто не представляешь возможности шаблонов.

Ты считаешь, что реализовать шаблоны сложнее, чем написать хороший оптимизирующий компилятор?
... << RSDN@Home 1.1 beta 1 >>
Re[13]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 17.09.03 15:44
Оценка:
WH>Ну что за бред ты тут несешь. MSDN ни кто не отменял. А вот слушать все что говорит братва из MS

Если я тебя правильно понял, ты считаешь, что драйвера нужно писать на продвинутом C++ с STL и прочими наворотами?
... << RSDN@Home 1.1 beta 1 >>
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 04:24
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Ты считаешь, что реализовать шаблоны сложнее, чем написать хороший оптимизирующий компилятор?

Я считаю что эти задачи сопастовимы по сложности. Особенно если учесть что придется писать оптимизатор так чтобы он мог оптимизировать шаблоны...
А теперь представь что на разработка жабы или .НЕТ пришлось бы потратить примерно в двое больше ресурсов
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Некоторые итоги:
От: FWP Россия  
Дата: 18.09.03 04:25
Оценка:
Здравствуйте, centurn, Вы писали:

C> Ага, помнится, мне, для того, чтобы поработать в 5-м Delphi, приходилось переключать экран в какой-то жуткий режим, иначе уже Splash screen этой делфи мне намертво комп вешал. Так что для меня субъективно 4-й Делфи лучше 5-го.

4-я дельфя — это уродец эпохи Inprise. Глюк на глюке. А вот с пятой никаких проблем не было. Мы на 6ю перешли то всего с год назад.
C>А 6-й студии афайк хронологически как раз 5-я делфя соответствует.
Нет. VS6 <-> Delphi6.
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 07:21
Оценка:
Здравствуйте, mihailik, Вы писали:

M>А, так ты Flush в try/finally делаешь?

M>А шуму-то было, мол, в C++ try/finally не нужен никогда.
Что такое исключение? Это ФАТАЛЬНЫЙ сбой в алгоритме. Следовательно алгоритм не отработал.
Вопрос нафига записывать мусор если надо просто сообщить о провале и подчистить ресурсы?

M>А при чём здесь объём памяти? В C# всё прозрачно расписано, когда и в каких случаях стоит вызывать Dispose. Если не следуешь советам, сам виноват.

А при том что когда памяти мало GC убивает объекты до того как будут сожраны ВСЕ ресурсы, а когда много...
Вся проблема в том что вызов РЕКОМЕНДАТЕЛЕН те если ты его забыл сделать то ни кто тебе ни чего не скажет. А как показывает практика 90% ошибок происходит именно из-за забывчивости.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 07:21
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Если я тебя правильно понял, ты считаешь, что драйвера нужно писать на продвинутом C++ с STL и прочими наворотами?

А почему нет?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 07:22
Оценка:
WH>Да ни хрена ты не понял. Посошник САМ совободит память и вызовет деструкторы у объектов если в процессе заполнения произойдет сбой.

В Дельфи объекты нельзя распределить в какой-то особенной памяти, кроме как в стандартной куче. Да я и не вижу необходимости.

А стандартные типы не имеют никакой деструктивной логики, которую нужно было бы вызывать.

WH>try/finally это РУЧНОЕ освобождение ресурсов. В С++ освобождать ресурсы руками это дурной тон, а в дельфе без альтернатив.


Дурной тон? Понимаю.

Если нужно из чужой dll'ки вызвать пару-трёшку функций в определённом порядке, на C++ принято тратить полчаса на враппер? Даже если известно наверняка, что никогда и никому больше этот враппер не понадобится?

Слава богу, что в Дельфи с тоном посвободнее.
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 07:22
Оценка:
M>>Чего-то я не пойму. Такое впечатление, что для тебя просто не существует процесса написания помощников и связанных с этим трудозатрат.

WH>Один раз забить все необходимое в помошник и пользоваться не задумываясь об освобождении ресурсов или постоянно писать try/finally для освобождения ресурсов.

WH>Как ты думаешь в каком случае трудозатраты больше?

Это зависит от цифр.

WH>Причем практика показывает что написать помошник выгодней даже если используешь его один раз ибо логика работы с ресурсом не смешивается с основной логикой программы.


Ну вот. А то кто-то говорит, что в C++ мало ручной работы. Пишете там всякие помощники по поводу и без повода, и нас, бедных Дельфистов агитируете. Доколе!
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 07:22
Оценка:
>>На теже грабли в другом языке я сознательно об этих вопросах беспокоюсь. А в C++ мне Wolfhound, авторитетно сказал, что о времени жизни беспокоиться не нужно.

M>>Или всё-таки нужно?


WH>Если тебя волнует будет ли освобожден ресурс до выхода из функции то не нужно.


Если я должен думать, есть опастность или нет — значит я просто всегда ожидаю опасность. Где же тут C++ даёт послабление относительно Дельфи? Думать-то всё равно нужно столько же.

WH>Но если есть какято очень хитрая логика которая случается раз в год...


Чтобы засечь этот "раз в год", я должен думать об этой возможности каждую секунду. Где же экономия?
... << RSDN@Home 1.1 beta 1 >>
Re[34]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 07:22
Оценка:
_O_>Гм. У нас на нем (C++/C) написан CASE тул, который включает

Ну мало ли, что на нём можно написать. На VB тоже всякие невероятные дела делают. Но реально-то C++ лучше всего выстреливает в системном и низкоуровневом программировании. В создании прикладных систем у него есть мощная конкуренция.

_O_>С Delphi-ями мы бы зависли на реализации эффективного и удобного внутреннего представления по причине отсутствия множественного наследования и шаблонов.


У каждого свой уровень в Дельфи. Ничего зазорного нет, если кто-то не умеет на нём нормально продуктивно работать. Зато вы в C++ специалисты.
... << RSDN@Home 1.1 beta 1 >>
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 07:22
Оценка:
WH>>>КОМ серверы например. И вобще все что нужно. С++ дает неизмеримо больше возможностей и контроля чем дельфи.

M>>Ага. А Delphi, Java и C# избавляют программиста от необходимости контроля. Контроль берёт на себя среда.


WH>Где ты среду в дельфе нашол? Дельфи это unmanaged компилятор с произвольным доступом к памяти. Ни какого контроля.


Средой я назвал окружение. Все вот эти "примочки" и "магию" компилятора. Свойства, RTTI. Семантику самого языка в конце концов.

Прямой доступ, конечно, разрешён. Но всё-таки не так явно и беззастенчиво, как в C++. Никакой явной адресной арифметики, обращения к указателям в стиле массивов и пр. В C++ это ещё в наследство от обычного C осталось. А в Дельфи наоборот, палки в колёса суют, если хочешь с укзателями работать.

Кроме того, все объекты сугубо by ref. Никаких объектов на стеке или ещё где ни попало. Операторы, слава богу, не перегружаются. Никаких конструкторов копирования, неявных преобразований и множественного наследования. Шаблоны тоже разум не затмевают. Короче говоря, возможности поурезаны, но нам-то это и нужно.

А кому нужен мощный инструмент, налагающий большой груз ответственности, инструмент, требующий серьёзного и длительного обучения — вперёд. Тому на C++ работать самая дорога. Там и платят больше.
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 07:22
Оценка:
WH>>> Разговорные языки по функциональности практически равноценны. Но С++ и
WH>>> делфи... ой не смешите мои тапочки.

m>> Мне кажется, твоя обувь слишком много на себя берёт.

m>> По функциональности C++ опережает Дельфи только в возможности
m>> компилировать драйвера.

AD>


AD>2mihailik: большая просьба, обдумывать свои ответы собеседнику, иначе есть

AD>вероятность того, что модератор перенесёт эту ветку в "Коллеги, улыбнитесь"
AD>

Если мои рассуждения народ задолбали, я могу и заткнуться. Делов-то

Кстати, а почему ты переводишь стрелу на модератора. Я считаю, у каждого должен быть свой внутренний модератор. Так что давай конструктивно. Что конкретно тебе не понравилось в моём сообщении?
... << RSDN@Home 1.1 beta 1 >>
Re: от модератора
От: mihailik Украина  
Дата: 18.09.03 07:22
Оценка:
_MM_>пока еще не унесет, но "по шапке надавать" может. обоим есть за что...

Один из этих обоих, кажется, я. А кто второй? С кем мне на скамье сидеть?

P.S. Если есть за что, я готов прислушаться к мнению уважаемого модератора. Какие замечены недостатки?
... << RSDN@Home 1.1 beta 1 >>
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 07:22
Оценка:
M>>Есть COM-объект. Необходимо вызывать какие-то его методы, использовать свойства при помощи позднего связывания, т.е. методов IDispatch. В скриптовых языках, в VB, в Дельфи это очень просто.

ГВ>Ну вот же ж блин. Ну нельзя на C++ наезжать по таким направлениям — не для того он предназначен.


Ну так я о том же. Гнобят бедный Дельфи и в хвост и в гриву. В гриву я ещё согласен, но в хвост — это зря.

ГВ>Конечно, если накатать набор врапперов, то можно сделать и "по позднему связыванию". В результате код пользователя будет примерно таким:


Ну да, на Дельфи тоже можно TLB импортировать. Только это куча лишних действий. Если нужно всего-то открыть Excel и бросить значения в пару ячеек, тут враппер как помеха какая-то.

Кроме того, работа по позднему связыванию отличается от работы по интерфейсам тем, что освобождает от привязки к версиям. Если на C++ импортировать Office XP TLB, то с Office 2000 вполне полезут проблемы.

ГВ>Ну и наконец, если в твоей программе логики помимо подключения COM-объектов мало, то кой чёрт тогда тебе C++ использовать? Бери тот же VB и полный вперёд!


Ага. Согласен. Для OLE Automation лучше использовать более соответствующий язык.
... << RSDN@Home 1.1 beta 1 >>
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 07:22
Оценка:
M>>Чем C++ может уделать Дельфи с позиций внешнего наблюдателя?

WH>Ни чем. С точки зрения пользователя пофигу как написано приложение на дельфе, С++, асме или в машинных кодах.

WH>А вот с точки зрения ПРОГРАММИСТА не первый план выходят "внутриязыковые приколы".

Пожалуй что так. Но тогда я и не знаю, как прийти к объективности.

Программисту-Дельфисту вряд ли понравятся монстровитый функции C++. А Сишнику в рамках Дельфи будет всё время тесновато.

Предлагается по этому поводу поздравить друг друга и всех окружающих с чем-нибудь там..
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 07:23
Оценка:
M>>Ну напишу я на Дельфи не 7, а 97 таких контейнеров — Дельфи станет от этого круче?
WH>Это 7 базовых контейнеров на их основе можно сделать что угодно.
WH>И вобще попробуй придумать 97 различных структур данных

Ладно, ладно, семь — магическое число. Согласен. Тут C++ переплюнул, у него число более знатное.
... << RSDN@Home 1.1 beta 1 >>
Re[7]: Некоторые итоги:
От: WolfHound  
Дата: 18.09.03 07:27
Оценка:
Здравствуйте, Serginio1, Вы писали:

WH>>А вот о других средствах которые могут заменить шаблоны по подробней.

S>http://www.osp.ru/news/soft/2003/09/15_01_print.htm
copy-paste-replace. Еще раз повторю шаблоны С++ значительно мощьнее чем copy-paste-replace.
S>http://www.wn.ru/computers/16.09.2003/6.html
Вот только очередного С++глюка от багландов мне и не хватало...
Я очень сильно удивлюсь если это будет нормальный компилятор.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 07:36
Оценка:
Здравствуйте, alexkro, Вы писали:

WH>>Ну как? А какие результаты даст дельфя? Причем это очень простые примеры.

WH>>Но практака показывает что запутать компилятор практически не возможно.

A>Оптимизация, говоришь... You ain't seen nothing yet! Небольшой этюд на тему (ручной) оптимизации виртуальных методов (испольнитель (компилятор) все тот же):


Это я то ни чего не видел Мои реальные программы намного сильнее морочат компилятор. И ни чего. Вся навороченая compile-time логика летит в трубу.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: Lloyd Россия  
Дата: 18.09.03 07:40
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Если мои рассуждения народ задолбали, я могу и заткнуться. Делов-то


M>Кстати, а почему ты переводишь стрелу на модератора. Я считаю, у каждого должен быть свой внутренний модератор. Так что давай конструктивно. Что конкретно тебе не понравилось в моём сообщении?


Внутренний прокурор. (с) Пелевин.
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 09:12
Оценка:
Здравствуйте, mihailik, Вы писали:

M>В Дельфи объекты нельзя распределить в какой-то особенной памяти, кроме как в стандартной куче. Да я и не вижу необходимости.

Ты нет а вот те кто придумывал COM почемуто видят.

M>А стандартные типы не имеют никакой деструктивной логики, которую нужно было бы вызывать.

А варианты? А строки их к стати тоже нужно в COM аллокатором размещать если вернуть хочешь.

M>Дурной тон? Понимаю.

А в дельфе try/create/finally/free, try/create/finally/free, try/create/finally/free,....
В то время как в С++ new, new, new, new,...
Разницу замечаем или еще нет?

M>Если нужно из чужой dll'ки вызвать пару-трёшку функций в определённом порядке, на C++ принято тратить полчаса на враппер? Даже если известно наверняка, что никогда и никому больше этот враппер не понадобится?

Вот мне недавно надо было просканить папку и вернуть файлы удвалетворяющие маске. Я не задумываясь написал врапер над FindFirst/FindNext и не жалею ибо логика работы с ресурсом и логика работы программы были разделены что прибавило читабельности и сильно. К томуже затраты на написание врапера сравними с затратами на одно использование этих функций. А если учесть что работа с ресурсом как правило осуществляется в нескольких местах...

M>Слава богу, что в Дельфи с тоном посвободнее.

Ага вот только народ (из другой конторы) который писал OPC сервер на дельфе потратил много больше времени на разработку ибо за меня работал компилятор, а они все делали ручками.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 09:12
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Один раз забить все необходимое в помошник и пользоваться не задумываясь об освобождении ресурсов или постоянно писать try/finally для освобождения ресурсов.

WH>>Как ты думаешь в каком случае трудозатраты больше?
M>Это зависит от цифр.
Даже при одиночном использовании логика программы разделяется, а это уже стоит многого.

WH>>Причем практика показывает что написать помошник выгодней даже если используешь его один раз ибо логика работы с ресурсом не смешивается с основной логикой программы.

M>Ну вот. А то кто-то говорит, что в C++ мало ручной работы. Пишете там всякие помощники по поводу и без повода, и нас, бедных Дельфистов агитируете. Доколе!
Именно по этому и мало ручной работы ибо я пишу логику один раз, а ты каждый раз при использовании.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 09:12
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Если тебя волнует будет ли освобожден ресурс до выхода из функции то не нужно.

M>Если я должен думать, есть опастность или нет — значит я просто всегда ожидаю опасность. Где же тут C++ даёт послабление относительно Дельфи? Думать-то всё равно нужно столько же.

WH>>Но если есть какято очень хитрая логика которая случается раз в год...

M>Чтобы засечь этот "раз в год", я должен думать об этой возможности каждую секунду. Где же экономия?
Тебе знакомо такое слово "проектирование"? То о чем ты сейчас говоришь относится именно туда. Если архитектура хреновая то отгребещь по полной в любом случае, а когда нормальная то на С++ работы много меньше.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 09:12
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Где ты среду в дельфе нашол? Дельфи это unmanaged компилятор с произвольным доступом к памяти. Ни какого контроля.

M>Средой я назвал окружение. Все вот эти "примочки" и "магию" компилятора. Свойства, RTTI. Семантику самого языка в конце концов.

M>Прямой доступ, конечно, разрешён.

Вот и закончилась безопасность.
M>Но всё-таки не так явно и беззастенчиво, как в C++.
Но есть следовательно в один рад с жабой и .НЕТ ставить нельзя.
M>Никакой явной адресной арифметики, обращения к указателям в стиле массивов и пр. В C++ это ещё в наследство от обычного C осталось. А в Дельфи наоборот, палки в колёса суют, если хочешь с укзателями работать.
Если кому захочется он всеравно сделает...

M>Кроме того, все объекты сугубо by ref.

Ну и нахрена это надо?
M>Никаких объектов на стеке или ещё где ни попало.
Вот и приходится городить try/finally постоянно.
M>Операторы, слава богу, не перегружаются.
Это еще почему?
M>Никаких конструкторов копирования, неявных преобразований и множественного наследования.
В том то и засада что не всегда объект можно просто скопировать.
M>Шаблоны тоже разум не затмевают.
Ага. И использование полиморвных контейнеров ведет к чистоте, простоте и надежности
M>Короче говоря, возможности поурезаны, но нам-то это и нужно.
При написании ГУИ к БД согласен, а вот на счет всего остального.

M>А кому нужен мощный инструмент, налагающий большой груз ответственности, инструмент, требующий серьёзного и длительного обучения — вперёд. Тому на C++ работать самая дорога. Там и платят больше.

А кому нужен инструмент налогающий кучу ответственности и не дающий ни каких инструментов контроля тому примая дорога на дельфе работать.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: ArtDenis Россия  
Дата: 18.09.03 09:12
Оценка:
Здравствуйте, mihailik, Вы писали:
AD>>
AD>> 2mihailik: большая просьба, обдумывать свои ответы собеседнику, иначе
AD>> есть вероятность того, что модератор перенесёт эту ветку в "Коллеги,
AD>> улыбнитесь"
m> Если мои рассуждения народ задолбали, я могу и заткнуться. Делов-то
m> Кстати, а почему ты переводишь стрелу на модератора. Я считаю, у каждого
m> должен быть свой внутренний модератор. Так что давай конструктивно. Что
m> конкретно тебе не понравилось в моём сообщении?

Ещё раз повторюсь: — это привет от моего внутреннего модератора.

Теперь конструктивно:

m> По функциональности C++ опережает Дельфи только в возможности

m> компилировать драйвера.

Так вот, если заглянуть в стандарт С++, то не найдёшь ни одной строчки о
компиляции драйверов. Это первое. Теперь, задумаемся, а что такое
функциональность языка. На мой взгляд, — это возможности (и связанные с ними
особенности), предоставляемые программисту в переводе формально поставленной
задачи в программный код. Т.е. с этой точки зрения, в С++ есть какая-то
"изюминка", которая позволила после компиляции превратить программный код в
драйвер ?

А теперь сравним функциональности языков (звёздочкой помечены, на мой
взгляд, наиболее используемые вещи)

Функциональность дельфи:
1. Переменные *
2. Типы *
3. Процедуры, функции (в т.ч. вложенные)
4. Классы
5. Абстакция, наследование, полиморфизм *
6. Тип "Ссылка на класс"
7. Виртуальные конструкторы
8. Глобальная фабрика объектов.
9. Довольно богатое RTTI *
10. Указатель на функцию в классе
11. VCL
12. Что-то ещё...

Функциональность С++:
1. Переменные *
2. Типы *
3. функции *
4. Классы *
5. Абстакция, наследование, полиморфизм *
6. Перегрузка операторов *
7. Нормальная(!) перегрузка функций *
8. Множественное наследование *
9. Понятие "объект класса" *
10. Поименованные области *
11. Шаблоны и STL:
— типизированные контейнеры и массивы *
— итераторы и типонезависимые алгоритмы *
— "умные" указатели и массивы *
— функторы и связыватели *
— ANSI/UNICODE строки *
— Указатели на функцию в классе
— фабрики объектов *
... ещё куча того, что реализуется за счёт шаблонов.
12. RTTI
13. Может кто ещё чего добавит, а то я забыл

Информация предоставлена, можешь сравнивать.

---------------------------------------------------------
СНП, Artyomov Denis. E-mail: artyomov <at> inbox.ru
Posted via RSDN NNTP Server 1.7 beta
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: Lloyd Россия  
Дата: 18.09.03 10:01
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Кроме того, все объекты сугубо by ref. Никаких объектов на стеке или ещё где ни попало.


А как по твоему передаются параметры? По воздуху?
Re[8]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 10:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>>>А вот о других средствах которые могут заменить шаблоны по подробней.

S>>http://www.osp.ru/news/soft/2003/09/15_01_print.htm
WH> copy-paste-replace. Еще раз повторю шаблоны С++ значительно мощьнее чем copy-paste-replace.
Ну я и не спорю. И ведутся поиски альтернативных аналогов шаблонов С++ , в том числе присоединения на этапе выполнения программы, а не только компиляции. В Net как как они планируют будет так. И не думаю, что нечто подобное не изыскивает и Борланд в С++ Builder они есть и не составляет труда все перенести и в Delphi + перегрузку операторов и Inline. При всей твоей рекламе шаблонов, лично я совершенно безболзненно обхожусь без них, но от возможности их применения не отказался бы. Еще раз давай совсем немного подождем,а на данном этапе Delphi уже исчерпал себя.
S>>http://www.wn.ru/computers/16.09.2003/6.html
WH> Вот только очередного С++глюка от багландов мне и не хватало...
WH>Я очень сильно удивлюсь если это будет нормальный компилятор.
"Каждому Свое". А я очень сильно удивлюсь если ты когда нибудь вообще удивишься продуктам Борланда, в том числе и J Builder
и солнце б утром не вставало, когда бы не было меня
Re[9]: Некоторые итоги:
От: WolfHound  
Дата: 18.09.03 11:17
Оценка:
Здравствуйте, Serginio1, Вы писали:

WH>> copy-paste-replace. Еще раз повторю шаблоны С++ значительно мощьнее чем copy-paste-replace.

S> Ну я и не спорю. И ведутся поиски альтернативных аналогов шаблонов С++ , в том числе присоединения на этапе выполнения программы, а не только компиляции. В Net как как они планируют будет так.
В .НЕТ это простой copy-paste-replace. Там даже шаблонных функций нет

S>И не думаю, что нечто подобное не изыскивает и Борланд в С++ Builder они есть и не составляет труда все перенести и в Delphi + перегрузку операторов и Inline.

BCB это глюкалово страшное. Если все это перенести в дельфи то точно хана дельфе.
S>При всей твоей рекламе шаблонов, лично я совершенно безболзненно обхожусь без них,
Ну некоторые и на С безболезненно пишут, а некоторые и на асме.
S>но от возможности их применения не отказался бы. Еще раз давай совсем немного подождем,а на данном этапе Delphi уже исчерпал себя.
Вот я и говоряю что .НЕТ2 ждать надо.

WH>> Вот только очередного С++глюка от багландов мне и не хватало...

WH>>Я очень сильно удивлюсь если это будет нормальный компилятор.
S> "Каждому Свое". А я очень сильно удивлюсь если ты когда нибудь вообще удивишься продуктам Борланда, в том числе и J Builder
Я не знаю про J Builder но С++билдер это глюкалово сплошное.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 11:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>>> copy-paste-replace. Еще раз повторю шаблоны С++ значительно мощьнее чем copy-paste-replace.

S>> Ну я и не спорю. И ведутся поиски альтернативных аналогов шаблонов С++ , в том числе присоединения на этапе выполнения программы, а не только компиляции. В Net как как они планируют будет так.
WH>В .НЕТ это простой copy-paste-replace. Там даже шаблонных функций нет
Еще раз http://www.dotsite.ru/Publications/PublicationDetails.aspx?ID=115

"Когда шаблонный класс откомпилирован, между ним и обычным классом фактически нет никакой разницы. На самом деле, результатом компиляции является не что иное как метаданные и промежуточный язык (IL). IL, конечно же, параметризован, чтобы принимать поставляемые пользователем типы где-то в коде. Отличие в использовании IL для шаблонного типа основано на том, является ли поставляемый параметр типа типом значения или ссылочным типом."

Различия между C# шаблонами и другими реализациями

"Шаблоны С++ существенно отличаются от C# шаблонов. Там где C# шаблоны компилируются в IL, что приводит к тому, что для каждого типа значения специализация разумно происходит во время выполнения и однажды только для ссылочных типов, шаблоны С++ являются по существу макросом расширения кода, которые генерируют специализированный тип для каждого параметра типа, поставляемого в шаблон. Кроме того, когда компилятор С++ сталкивается с шаблоном, таким как Stack целых, он расширяет код шаблона в класс Stack, содержащий целые как собственный тип. В зависимости от того, является ли параметр типа типом значения или ссылочным типом, за исключением компоновщика, специально разработанного для уменьшения количества кода, каждый раз компилятор С++ создает специализированный класс, в результате чего возникает существенное увеличение размера кода в сравнении C# шаблонами.

Более того, шаблоны С++ не могут определять ограничения. Они могут только неявно задать ограничения, просто используя член, который должен или не должен принадлежать параметру типа. Если в параметре типа, который в итоге передается в шаблонный класс, этот член существует, программа будет работать правильно. Если член не существует, программа даст сбой и, возможно, будет возвращено непонятное сообщение об ошибке. Поскольку C# шаблоны могут объявлять ограничения и строго типизированы, таких потенциальных ошибок нет.

Между тем, компания Sun Microsystems® предложила дополнение к шаблонам в следующей версии языка программирования Java под кодовым названием "Tiger". Компания Sun выбрала реализацию, которая не требует изменения Виртуальной машины Java.

S>>И не думаю, что нечто подобное не изыскивает и Борланд в С++ Builder они есть и не составляет труда все перенести и в Delphi + перегрузку операторов и Inline.

WH>BCB это глюкалово страшное. Если все это перенести в дельфи то точно хана дельфе.


S>>При всей твоей рекламе шаблонов, лично я совершенно безболзненно обхожусь без них,

WH>Ну некоторые и на С безболезненно пишут, а некоторые и на асме.
Еще на 1С и С++. Шутка, но многое писалось о других универсальных способах правда с потерей типизации и скорости но один на все.
S>>но от возможности их применения не отказался бы. Еще раз давай совсем немного подождем,а на данном этапе Delphi уже исчерпал себя.
WH>Вот я и говоряю что .НЕТ2 ждать надо.
А зачем ее ждать, кроме шаблонов, там копать неперекопать, а там и твои шаблоны подойдут.
WH>>> Вот только очередного С++глюка от багландов мне и не хватало...
WH>>>Я очень сильно удивлюсь если это будет нормальный компилятор.
S>> "Каждому Свое". А я очень сильно удивлюсь если ты когда нибудь вообще удивишься продуктам Борланда, в том числе и J Builder
WH>Я не знаю про J Builder но С++билдер это глюкалово сплошное.
и солнце б утром не вставало, когда бы не было меня
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 11:47
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Да ни хрена ты не понял. Посошник САМ совободит память и вызовет деструкторы у объектов если в процессе заполнения произойдет сбой.


M>В Дельфи объекты нельзя распределить в какой-то особенной памяти, кроме как в стандартной куче. Да я и не вижу необходимости.


Небольшая поправочка в менеджере памяти, так как от обычного Heap имеют большое различие и скорость удаления в 10 раз выше чем при удалении из хиппа за счет не возврата памяти а вторичного использования. Хорошо продуманная индексация и объединения неиспользуемых блоков памяти. Почти идеал.
и солнце б утром не вставало, когда бы не было меня
Re[11]: Некоторые итоги:
От: Sergey Россия  
Дата: 18.09.03 11:55
Оценка:
Hello, Serginio1!
You wrote on Thu, 18 Sep 2003 11:37:33 GMT:

S> "Шаблоны С++ существенно отличаются от C# шаблонов. Там где C# шаблоны

S> компилируются в IL, что приводит к тому, что для каждого типа значения
S> специализация разумно происходит во время выполнения и однажды только
S> для ссылочных типов, шаблоны С++ являются по существу макросом
S> расширения кода, которые генерируют специализированный тип для каждого
S> параметра типа, поставляемого в шаблон.

Ага, только вот совершенно забыли про template template parameters и non-type template parameters в С++ И про то, что шаблоны С++ умеют рекурсивные функции во время компиляции считать

S> Кроме того, когда компилятор С++

S> сталкивается с шаблоном, таким как Stack целых, он расширяет код шаблона
S> в класс Stack, содержащий целые как собственный тип. В зависимости от
S> того, является ли параметр типа типом значения или ссылочным типом, за
S> исключением компоновщика, специально разработанного для уменьшения
S> количества кода, каждый раз компилятор С++ создает специализированный
S> класс, в результате чего возникает существенное увеличение размера кода
S> в сравнении C# шаблонами.

Цирк... Где такой убогий компоновщик взять? Даже VC 6.0 понимает, что std::vector<long> и std::vector<int*> — одно и то же.

S> Более того, шаблоны С++ не могут определять ограничения.


Щаз.

S> Они могут

S> только неявно задать ограничения, просто используя член, который должен
S> или не должен принадлежать параметру типа. Если в параметре типа,
S> который в итоге передается в шаблонный класс, этот член существует,
S> программа будет работать правильно. Если член не существует, программа
S> даст сбой и, возможно, будет возвращено непонятное сообщение об ошибке.

Вот этот абзац применительно к C++ — полный бред. Если член не существует, программа просто не скомпилируется — о каких сбоях может идти речь?

Best regards,
Sergey.
Posted via RSDN NNTP Server 1.7 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 18.09.03 11:55
Оценка:
Здравствуйте, Serginio1, Вы писали:

M>>В Дельфи объекты нельзя распределить в какой-то особенной памяти, кроме как в стандартной куче. Да я и не вижу необходимости.

S> Небольшая поправочка в менеджере памяти, так как от обычного Heap имеют большое различие и скорость удаления в 10 раз выше чем при удалении из хиппа за счет не возврата памяти а вторичного использования. Хорошо продуманная индексация и объединения неиспользуемых блоков памяти. Почти идеал.

А разве есть другой серьезный компилятор, скажем, C++, в котором нет аналогичного менеджера? sbheap.c из VC, например, весит больше ста килобайт. И в любом случае выделение в стеке дешевле.
Re[11]: Некоторые итоги:
От: AlexK Украина  
Дата: 18.09.03 12:00
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, WolfHound, Вы писали:


WH>>Здравствуйте, Serginio1, Вы писали:


WH>>>> copy-paste-replace. Еще раз повторю шаблоны С++ значительно мощьнее чем copy-paste-replace.

S>>> Ну я и не спорю. И ведутся поиски альтернативных аналогов шаблонов С++ , в том числе присоединения на этапе выполнения программы, а не только компиляции. В Net как как они планируют будет так.
WH>>В .НЕТ это простой copy-paste-replace. Там даже шаблонных функций нет
S> Еще раз http://www.dotsite.ru/Publications/PublicationDetails.aspx?ID=115

... skipped ...

S>Более того, шаблоны С++ не могут определять ограничения. Они могут только неявно задать ограничения, просто используя член, который должен или не должен принадлежать параметру типа. Если в параметре типа, который в итоге передается в шаблонный класс, этот член существует, программа будет работать правильно. Если член не существует, программа даст сбой и, возможно, будет возвращено непонятное сообщение об ошибке. Поскольку C# шаблоны могут объявлять ограничения и строго типизированы, таких потенциальных ошибок нет.


... skipped ...

не стоит приписывать ограничения там где их быть не должно.
Если вникнуть в проблему, то все ограничения которые наложит на код c# будут следствием RTTI или методанных, которые НЕТом сгенерились для себя самого... так что тут С++ на порядок позволяет поднять гибкость и скорость по сравнению с c# — не нужны тебе ограничения ты о них и забыл... нужны прикрутил... а то что c# на порядок надежнее будет, так это скажеться на производительности... надо же куда-то Гигагерцы девать, а то застоялись без дела то...

скоро это будет выглядить приблизительно так: надо тормоза — пиши на НЕТ... увольте... не хочу так жить...
они своей надежностью воспитают еще одно поколение псведо-программеров, который будет считать что умение кинуть на формочку кнопку — делает его прогарммером...

на счет непонятных ошибок так ты ее и в НЕТ получиш... не смотрел как дебугер показывает часть кода от макрософта?

с++ — путь к силе духа! и ясности ума!
отредактировано модератором. _MM_
Re[42]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 12:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


AD>>>8. Глобальная фабрика объектов.

S>> Если это касается СОМ, то наследоваников от TComObjectFactory великое множество.
WH>Ну и нафига этот геморой? В С++ все ATL делает. Ни разу фабрику ручками не писал.
S>> Set (очень удобно с побитовыми операциями)
WH>Ну и нафига это на уровне языка надо?
Очень удобно и просто. На ассемблере тоже BitBlt существует, но только на регистр.
S>> Встроенная поддержка Строк (в том числе и WideString),Интерфейсов,Вариантов**
WH>Ну интерфейсы еще куда ни шло, а вот строки и темболие варианты на уровне языка
Тоже очень удобно особенно с IDispatch итд.
S>> Классы поддерживающие интерфейсы c автоматическим подсчетом ссылок и приведение к интерфейсу через As

WH>Ну и нафига во все интерфейсы подсчет ссылок запихивать? В С++ это делается на раз, а для привидения типов служит dynamic_cast.

В классы а не в интерфейсы. И работа с приведением через интерфейсы как в Net очень удобна.

S>> Динамические массивы (умные)

WH>И чтоже в них такого умного чего не может std::vector?
S>> Единая иерархия классов а также Is и As *
WH>Вот уж нафиг не упало все классы от одного наследовать. И dynamic_cast никто не отменял.
Аналог dynamic_cast Is плиз ???
Единая информация об объекте. Не прав.
А вот структуры объекты действительно нужны, но с возможность боксинга в объект как в Net

S>> Явное разделение структур и объектов ( хотя записи с методами и не помешали)+-

WH>А смысл?
Смысл в организации хранения данных. Если в С++ практически нет различия, то в Delphi все объекты ссылочные. Ну не знал, что реализованное в Net разграничение между объектами и структурами, а так же единая иерархия классов подвергаются сомнению. Глупые они там наверное, забыли WolfHound спросить. Не в обиду, может действительно правда.
и солнце б утром не вставало, когда бы не было меня
Re[43]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 12:22
Оценка:
Здравствуйте, Serginio1, Вы писали:

WH>>Ну и нафига во все интерфейсы подсчет ссылок запихивать? В С++ это делается на раз, а для привидения типов служит dynamic_cast.

S> В классы а не в интерфейсы. И работа с приведением через интерфейсы как в Net очень удобна.
А чем чисто абстрактный класс без данных отличается от интерфейса?

WH>>Вот уж нафиг не упало все классы от одного наследовать. И dynamic_cast никто не отменял.

S>Аналог dynamic_cast Is плиз ???
typeid
S> Единая информация об объекте. Не прав.
S> А вот структуры объекты действительно нужны, но с возможность боксинга в объект как в Net
НАФИГА? Создал в стеке пусть лежит в стеке, создал в хипе пусть будет в хипе. Нафига это разделение?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 12:25
Оценка:
Здравствуйте, Serginio1, Вы писали:

WH>>>Да ни хрена ты не понял. Посошник САМ совободит память и вызовет деструкторы у объектов если в процессе заполнения произойдет сбой.

M>>В Дельфи объекты нельзя распределить в какой-то особенной памяти, кроме как в стандартной куче. Да я и не вижу необходимости.
S> Небольшая поправочка в менеджере памяти, так как от обычного Heap имеют большое различие и скорость удаления в 10 раз выше чем при удалении из хиппа за счет не возврата памяти а вторичного использования. Хорошо продуманная индексация и объединения неиспользуемых блоков памяти. Почти идеал.
Пишем аллокатор на пуле и он что хочешь уделает. Вот только всегда ли оно надо?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Некоторые итоги:
От: AlexK Украина  
Дата: 18.09.03 12:54
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, AlexK, Вы писали:


AK>>скоро это будет выглядить приблизительно так: надо тормоза — пиши на НЕТ... увольте... не хочу так жить...

S> Ну да Native компиляторы доживают свой век или уйдут в Linux, т.к. там уже на конкретной машине под камень и операционку компилируют, а не толко программы.
S> Живи по старому....

Опять промащечка... Линуха в основном то и живут на языках интерпретаторах: Perl, PHP ... че та там еще было...
пол оски на скриптах написано. а вторая половина пережиток прошлого, которое все бояться трогать... Линух мертв — в нем только остатки былой силы. Пока не будет крупной корпорации, которая не начнет постоянно поддержиать Линух, разгребет все его тоны мусора, то смысла в такой оске нету. Линух — "отстойник" мыслей. А вот приживуться ли...

А то что НЕТ под каждый проц свой код генерит, так это вранье все... не успели они эту фичу в полном объеме сделать. Только на мемори менедмент их и хватило... один для сервера, другой для клиента... Native compiler стране нужен!, но в связи с дифицитом рук которые будут писать софт, появляються языки на освоение которых требует все меньше времени и понимания основ... Вот и получаеться что программинг пытаються свести до уровня домо-хозяйки... Но программист это же гордое название человека!, который не спит ночами и стараеться все сделать для клиента...
Делфи как раз и была попытка сделать упрощенный вариант программинга в целом... согласен оно заняло достойную нишу и туда перекачивало не мало толковых людей... подстегнуло отросль компайлеров и языков програмирования к развитию... только теперь приходит очередь нового поколения — НЕТ фреймворка. а что вот делать с программерами старой закалки?
Только макрософты их переплюнули на много больше, мало того что написали либу отдаленно напоминающую vcl, но и дали возможность старым программерам не меняя языка делать свое дело... вот только реализация подкачала... пока там больше багов чем может себе позволить комерческий софт.
Вот и пытаються заткнуть недостаток качества автоматами затыкания дыр... постоянные проверки... метаданные... ексепшены... проверка типов... но это же порождает торомоза с которыми тяжело смириться; это же раждает "программеров" без понимания того что оно делат внутри...

Хочу жить по старому, да уже не смогу... вот так и рождаються сказки про злолотой век программинга и т.п. чушь.

AK>>они своей надежностью воспитают еще одно поколение псведо-программеров, который будет считать что умение кинуть на формочку кнопку — делает его прогарммером...

S> Хехе уже давно воспитаны на Васиках и 1С.

основное слово еще одно

AK>>с++ — путь к силе духа! и ясности ума!

S> Программирование это не профессия, а Смысл Жизни!!!!
Да прибудет с тобой сила...

точно в джидаи записываться надо...
Re[14]: Некоторые итоги:
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 18.09.03 13:03
Оценка:
Здравствуйте, AlexK, Вы писали:

AK>А то что НЕТ под каждый проц свой код генерит, так это вранье все... не успели они эту фичу в полном объеме сделать.


Для ARM, MIPS и SH3/SH4 под Windows CE уже сделали. Просто у них приоритеты другие.
Re[15]: Некоторые итоги:
От: AlexK Украина  
Дата: 18.09.03 13:10
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, AlexK, Вы писали:


AK>>А то что НЕТ под каждый проц свой код генерит, так это вранье все... не успели они эту фичу в полном объеме сделать.


_>Для ARM, MIPS и SH3/SH4 под Windows CE уже сделали. Просто у них приоритеты другие.


так по ихним рекламам тебя в зависимости от проца на машине (где Винды стоят) по разному натив код генериться должен... а то что они начали на другие процы все перегонять — опять спасибо надо сказать с++ за кросплатформенность... (почти полную)
Re[16]: Некоторые итоги:
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 18.09.03 13:25
Оценка:
Здравствуйте, AlexK, Вы писали:

AK>так по ихним рекламам тебя в зависимости от проца на машине (где Винды стоят) по разному натив код генериться должен...


Кстати, у VC++ есть ключи, указывающие, под какой процессор генерить. Сильно ли они меняют код для типового исходника на С++ (меньше Pentium-1 не рассматриваем)?

AK>а то что они начали на другие процы все перегонять — опять спасибо надо сказать с++ за кросплатформенность... (почти полную)


Для раскрутки, естественно, кроссплатформенные плюсы очень даже помогают. Только вот в .net compact framework native-бинарников (которые не все и переносятся, часть — кодогенератор под конкретный процессор) — 300-550K (в зависимости от платформы) mscoree и 80-150K какой-то переходник к AGL. Остальные полтора мега на разных платформах совпадают с точностью до бита.
Re[17]: Некоторые итоги:
От: AlexK Украина  
Дата: 18.09.03 13:47
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:

_>Здравствуйте, AlexK, Вы писали:


AK>>так по ихним рекламам тебя в зависимости от проца на машине (где Винды стоят) по разному натив код генериться должен...


_>Кстати, у VC++ есть ключи, указывающие, под какой процессор генерить. Сильно ли они меняют код для типового исходника на С++ (меньше Pentium-1 не рассматриваем)?


а тут и мерять нечего... а вот если от Интела компайлер взять то там разница чувствуеться...

AK>>а то что они начали на другие процы все перегонять — опять спасибо надо сказать с++ за кросплатформенность... (почти полную)


_>Для раскрутки, естественно, кроссплатформенные плюсы очень даже помогают. Только вот в .net compact framework native-бинарников (которые не все и переносятся, часть — кодогенератор под конкретный процессор) — 300-550K (в зависимости от платформы) mscoree и 80-150K какой-то переходник к AGL. Остальные полтора мега на разных платформах совпадают с точностью до бита.


а кто спорит... но замечу от кросплатформенности софт круче не становился.. .а только наоборот терял пару пунктов в скорости и возможностях.. а сделать что-то стандартное на всех желание хорошое, но толку мало... нахрена калькулятору Windows CE? (но это грубая анология...) хотя приблизительно так дело и будет обстоять... переносимость NET пока что точно такой же миф как и переносимость Java в начале своего пути. мы получим мощное по возможностям средство для всех платформ, но оно будет одинаково тормозить на всех платформах. или как у Sun получиться что работает Java на машинах только собственного производства...

да кстатит смотрел я тот код что макрасофты юзают, так вот ни каким там оптимайзом на платформу и не пахнет... сначало ядро компайлиться которое c# компайлить могет, а потом на осное с# исходников генеряться остальные либы... довольно мрачно выглядит...потому как оптимизационный алгоритм компилятора с# связан по рукам и ногам, как раз изи крос-проц-платформенности... могут юзаться только общии команды для всех процов... в результате код практически не оптимизирован, а дальше все ложиться на проц... конечно основные части кода макрософт не паблишила, но я сомневаюсь что в не опубликованных исходниках один гиниальный код и остался...

вот наконец-то разработки конвееров пентуимовых и пашут по полной... прогноз переходов... и т.д. и т.п. Кто читал обзоры на Петиуму, тот должен помнить что там как раз и была основная фича — расчет на исполнение не оптимизированного кода старых процесоров.. вот там то пентиум на все 100 и вкалывал...
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 13:57
Оценка:
Здравствуйте, desperado_gmbh, Вы писали:


_>А разве есть другой серьезный компилятор, скажем, C++, в котором нет аналогичного менеджера? sbheap.c из VC, например, весит больше ста килобайт. И в любом случае выделение в стеке дешевле.

Ну кто же с этим спорит. Но не зря же в Net GC внедрили, но оставили структуры — объекты, для полного использования стека. sbheap.c посмотрю, спасибо.
и солнце б утром не вставало, когда бы не было меня
Re[18]: Некоторые итоги:
От: desperado_gmbh http://www.livejournal.com/users/tolstopuz
Дата: 18.09.03 14:05
Оценка:
Здравствуйте, AlexK, Вы писали:

AK>нахрена калькулятору Windows CE? (но это грубая анология...)


Ты видел навороченные калькуляторы типа HP49? Язык там напоминал аналитик с "Мир-2", программы (включая игрушки) писались как на нем, так и в машинных кодах. Сейчас его на сайте нет, видимо, хэндхелды убили этот рынок. Даже на телефоне .NET Compact Framework или J2ME дают удобство и гибкость, захотел — скачал новый калькулятор или icq-клиента.

AK>потому как оптимизационный алгоритм компилятора с# связан по рукам и ногам, как раз изи крос-проц-платформенности... могут юзаться только общии команды для всех процов... в результате код практически не оптимизирован, а дальше все ложиться на проц...


После компилятора c# получается код на IL, ассебмлере для виртуальной объектно-ориентированной стековой машины, не похожей ни на один из target-процессоров. Его оптимизация — задача джита. Даже с учетом его невылизанности результаты неплохие, я уже кидал ссылку на managed Q2. 85% от чисто сишного кода и 70% от сишного кода с ассемблерными вставками (это в software rendering, с акселерацией разница еще меньше) — неплохой результат для версии 1.1.
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 18.09.03 14:36
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, mihailik, Вы писали:


M>>Кроме того, все объекты сугубо by ref. Никаких объектов на стеке или ещё где ни попало.


L>А как по твоему передаются параметры? По воздуху?


(Вот, из курса ВМКашных лекций по ЯП)

Вообще говоря, существует пять способов передачи параметров:
1) По значению (IN);
2) По результату (OUT);
3) По значению результата;
4) По ссылке;
5) По имени;

Механизм передачи параметра по значению достаточно прост — для подпрограммы выделяется некоторая область памяти (стек), в который копируется значение фактического параметра, которое в свою очередь и используется процедурой.
По результату — также выделяется область памяти для формального параметра, который копируется в фактический параметр после завершения процедуры.
По значению результата, не сложно догадаться, — перед началом выполнения подпрограммы происходит копирование фактического параметра в формальный, а при выходе -из формального в фактический.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 14:54
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, mihailik, Вы писали:


M>>Кроме того, все объекты сугубо by ref. Никаких объектов на стеке или ещё где ни попало.


L>А как по твоему передаются параметры? По воздуху?

Часть через Регистры. А вот с FPU Борланд подкачал. А объектов на стеке действительно нет, только ссылки на них.
и солнце б утром не вставало, когда бы не было меня
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 16:15
Оценка:
M>>В Дельфи объекты нельзя распределить в какой-то особенной памяти, кроме как в стандартной куче. Да я и не вижу необходимости.

WH>Ты нет а вот те кто придумывал COM почемуто видят.


Те, кто придумывал COM, сейчас стараются его как можно скорее забыть.

M>>А стандартные типы не имеют никакой деструктивной логики, которую нужно было бы вызывать.

WH>А варианты? А строки их к стати тоже нужно в COM аллокатором размещать если вернуть хочешь.

Ну, разве что строки. O.K., напишем отдельный классик для строк. Пока ничего серьёзного.

M>>Дурной тон? Понимаю.

WH>А в дельфе try/create/finally/free, try/create/finally/free, try/create/finally/free,....
WH>В то время как в С++ new, new, new, new,...
WH>Разницу замечаем или еще нет?

Замечаем разницу, но я пример приводил
В том же C++ не всегда можно забить на время жизни.

M>>Если нужно из чужой dll'ки вызвать пару-трёшку функций в определённом порядке, на C++ принято тратить полчаса на враппер? Даже если известно наверняка, что никогда и никому больше этот враппер не понадобится?


WH>Вот мне недавно надо было просканить папку и вернуть файлы удвалетворяющие маске.


Это всё хорошо. Ручной труд — он ведь облагораживает

M>>Слава богу, что в Дельфи с тоном посвободнее.


WH>Ага вот только народ (из другой конторы) который писал OPC сервер на дельфе потратил много больше времени на разработку ибо за меня работал компилятор, а они все делали ручками.


Ну что я тебе могу сказать про этот народ и этот сервер. Я ни того ни другого не знаю
... << RSDN@Home 1.1 beta 1 >>
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 16:16
Оценка:
M>>Ну вот. А то кто-то говорит, что в C++ мало ручной работы. Пишете там всякие помощники по поводу и без повода, и нас, бедных Дельфистов агитируете. Доколе!

WH>Именно по этому и мало ручной работы ибо я пишу логику один раз, а ты каждый раз при использовании.


Иногда этот "каждый раз" означает в точности "один раз".

Но в остальном тенденция, конечно, полезная. Если меру знать
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 16:16
Оценка:
M>>Кроме того, все объекты сугубо by ref. Никаких объектов на стеке или ещё где ни попало.

L>А как по твоему передаются параметры? По воздуху?


Все ОБЪЕКТЫ by ref. В C++ объекты (экземпляры классов) могут располагаться как в стеке, так и по адресу в памяти.

А в Дельфи переменная типа TObject — на самом деле указатель.
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 16:16
Оценка:
M>>Прямой доступ, конечно, разрешён.
WH>Вот и закончилась безопасность.

В .NET тоже разрешён прямой доступ.

M>>Но всё-таки не так явно и беззастенчиво, как в C++.

WH>Но есть следовательно в один рад с жабой и .НЕТ ставить нельзя.

Да ладно. В один ряд нельзя, в другой можно. Я ж не говорю, что Дельфи — это Java. Но нахожу много общих черт.

M>>Никакой явной адресной арифметики, обращения к указателям в стиле массивов и пр. В C++ это ещё в наследство от обычного C осталось. А в Дельфи наоборот, палки в колёса суют, если хочешь с укзателями работать.

WH>Если кому захочется он всеравно сделает...

Точно так же, как и в .NET. Да и даже в Java — никто не мешает написать внешний объект, который будет обращаться к памяти напрямую. А в классах Java его использовать.

M>>Кроме того, все объекты сугубо by ref.

WH>Ну и нахрена это надо?

Для однообразности и простоты. Все объекты ведут себя с памятью одинаково. Мозги не парятся.

M>>Никаких объектов на стеке или ещё где ни попало.

WH>Вот и приходится городить try/finally постоянно.

Не постоянно. В Дельфи тоже есть способ уйти от ручного вызова деструкторов к подсчёту ссылок. Интерфейсы всегда работают по учёту ссылок.

M>>Операторы, слава богу, не перегружаются.

WH>Это еще почему?

А вот чтобы приколисты вроде Страуструпа не выдумывали разных новых значений оператора сдвига. Сдвиг — он в Дельфи всегда сдвиг.

M>>Никаких конструкторов копирования, неявных преобразований и множественного наследования.

WH>В том то и засада что не всегда объект можно просто скопировать.

А все объекты byref, то есть ничего и не копируется. Чтобы сделать копию, нужно как и в .NET вызвать какой-нибудь Clone.

M>>Шаблоны тоже разум не затмевают.

WH>Ага. И использование полиморвных контейнеров ведет к чистоте, простоте и надежности

Тут ты прав. Действительно удобно.

M>>Короче говоря, возможности поурезаны, но нам-то это и нужно.

WH>При написании ГУИ к БД согласен, а вот на счет всего остального.

Ты что, предлагаешь и в браузерах скрипты на C++ писать? Или ты какое-то конкретное "остальное" имеешь ввиду?

WH>А кому нужен инструмент налогающий кучу ответственности и не дающий ни каких инструментов контроля тому примая дорога на дельфе работать.


Тебе, как большому знатоку Дельфи, это виднее. Где уж мне неучу с тобой спорить.
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 16:16
Оценка:
WH>А теперь представь что на разработка жабы или .НЕТ пришлось бы потратить примерно в двое больше ресурсов

А причём здесь .NET? На .NET шаблоны себя не заставили ждать.

А вот Java давно написана, а о шаблонах всё разговоры да разговоры.
... << RSDN@Home 1.1 beta 1 >>
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 16:16
Оценка:
M>>RTTI (aka Reflection)
WH>Рефлекшен в дельфе... Бедные мои тапочки... Ну не надо сравнивать бумажный самолетик с истребителем пятого поколения.

Почему не надо сравнивать?

RTTI решает те же проблемы, что и Reflection. Сериализация и ремотинг. Конечно, RTTI похилее Reflection'а, ну и что? Работает, функции выполняет.

M>>Свойства

WH>О да это величайшая АРХИТЕКТУРНАЯ особенность. К стати VC++ поддерживает свойства в качестве расширения.

Свойства — это важная архитектурная особенность. Языки, в которых поддерживаются свойства являются компонент-ориентированными. Ну вот не могу сказать почему так выходит, а реальность такова.

M>>Упор на простоту синтаксиса

WH>Или убогость? Так чтобы [censured] поняли?

А я не вижу ничего хорошего в том, что C++ не понимают люди без образования.

M>>Значительная часть преимуществ как Делфи, так и C# коренится в этих трёх пунктах.

WH>Особенно два последних.... величайшие преймущества.

Если тебе непонятны эти преимущества, возможно они тебе и не нужны. Мало ли у кого какая отрасль работы. А мне вот нужно, чтобы мой код был понятен [censured]'ам, и свойство-ориентированность тоже удобна.
... << RSDN@Home 1.1 beta 1 >>
Re[12]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 16:16
Оценка:
M>>А, так ты Flush в try/finally делаешь?
M>>А шуму-то было, мол, в C++ try/finally не нужен никогда.

WH>Что такое исключение? Это ФАТАЛЬНЫЙ сбой в алгоритме. Следовательно алгоритм не отработал.

WH>Вопрос нафига записывать мусор если надо просто сообщить о провале и подчистить ресурсы?

А вот надо. Лог вести, или ещё какие предсмертные действия совершить.

M>>А при чём здесь объём памяти? В C# всё прозрачно расписано, когда и в каких случаях стоит вызывать Dispose. Если не следуешь советам, сам виноват.

WH>А при том что когда памяти мало GC убивает объекты до того как будут сожраны ВСЕ ресурсы, а когда много...

WH>Вся проблема в том что вызов РЕКОМЕНДАТЕЛЕН те если ты его забыл сделать то ни кто тебе ни чего не скажет. А как показывает практика 90% ошибок происходит именно из-за забывчивости.


Ну и кто по твоему должен что сказать? Или для всех локальных объектов Dispose делать?

FileStream CreateFileStream(string filename)
{
    return new FileStream(filename, bla, bla, bla);
}
... << RSDN@Home 1.1 beta 1 >>
Re[15]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 18.09.03 16:20
Оценка:
M>>Если я тебя правильно понял, ты считаешь, что драйвера нужно писать на продвинутом C++ с STL и прочими наворотами?

WH>А почему нет?


Потому, что рантайм-библиотеки не писались для этого применения. Мало ли, каким образом там память выделяется, какие дополнительные функции вызываются.

В некоторых местах в драйвере нельзя никакой лишней работы делать. Чтобы не дай бог ни подкачки, ни задержки никакой не было. Ну, закрепишь ты свой собственный код в памяти от свопирования. Но служебные библиотеки мало ли как там закреплять — это отдельно тестировать нужно.
... << RSDN@Home 1.1 beta 1 >>
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.09.03 16:31
Оценка:
Здравствуйте, mihailik, Вы писали:

S>> а учитывая кроме всего прочего что SQL еще и интерпретатор то....


M>В MS SQL точно компилятор, а не интерпретатор.


M>Думаю, и в других "больших" серверах то же самое.

http://www.rsdn.ru/Forum/Message.aspx?mid=370720&amp;only=1
Автор: Serginio1
Дата: 01.09.03
и солнце б утром не вставало, когда бы не было меня
Re[37]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 18:14
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Ты нет а вот те кто придумывал COM почемуто видят.

M>Те, кто придумывал COM, сейчас стараются его как можно скорее забыть.
Да. Но он еще живее всех живых.

WH>>А варианты? А строки их к стати тоже нужно в COM аллокатором размещать если вернуть хочешь.

M>Ну, разве что строки. O.K., напишем отдельный классик для строк. Пока ничего серьёзного.
Да еще нужна типизированые массивы...

M>Замечаем разницу, но я пример приводил

M>В том же C++ не всегда можно забить на время жизни.
В 99.999999% случаев. В то время как в дельфе надо в 100% случаев ручками.

WH>>Вот мне недавно надо было просканить папку и вернуть файлы удвалетворяющие маске.

M>Это всё хорошо. Ручной труд — он ведь облагораживает
Мое решение разгрузило алгоритм а это многого стоит.

M>Ну что я тебе могу сказать про этот народ и этот сервер. Я ни того ни другого не знаю

Ну народ там нормальный, а вто OPC протокол хорошо что я на С++ пишу.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 18:14
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Именно по этому и мало ручной работы ибо я пишу логику один раз, а ты каждый раз при использовании.

M>Иногда этот "каждый раз" означает в точности "один раз".
Даже если и так то как правило основная логики становится прозрачней ибо не замусорена логикой работы с ресурсом, а работы практически столькоже но учитывая что алгоритм получился болие прозрачный с поддержкой будет меньше проблем. Факт.
M>Но в остальном тенденция, конечно, полезная. Если меру знать
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 18:14
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>А теперь представь что на разработка жабы или .НЕТ пришлось бы потратить примерно в двое больше ресурсов

M>А причём здесь .NET? На .NET шаблоны себя не заставили ждать.

M>>Ага. Компилятор Java написали. Интерпретатор и JIT'тер написали. А шаблоны — нет, тут сложность невероятно высока.

M>А вот Java давно написана, а о шаблонах всё разговоры да разговоры.
Вот по тому и разговоры что задаче не тривиальная.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 18:14
Оценка:
Здравствуйте, mihailik, Вы писали:

M>>>RTTI (aka Reflection)

WH>>Рефлекшен в дельфе... Бедные мои тапочки... Ну не надо сравнивать бумажный самолетик с истребителем пятого поколения.
M>Почему не надо сравнивать?

M>RTTI решает те же проблемы, что и Reflection. Сериализация и ремотинг. Конечно, RTTI похилее Reflection'а, ну и что? Работает, функции выполняет.

см разговор с Синклером на счет сериализыции.

M>Свойства — это важная архитектурная особенность.


M>Языки, в которых поддерживаются свойства являются компонент-ориентированными. Ну вот не могу сказать почему так выходит, а реальность такова.
Это ни как не связано. В С++ я могу эмулировать свойства, а некоторые компиляторы поддерживают их в качестве расширения.

M>А я не вижу ничего хорошего в том, что C++ не понимают люди без образования.

А я не вижу ни чего хорошего в том что людей без образования допускать к работе ибо всеравно глаз да глаз за ними нужен.
Ну не дело это домохозяйкам программы писать.

M>Если тебе непонятны эти преимущества, возможно они тебе и не нужны.

Преймущества .НЕТ это Reflection и Reflection.Emit это сильно, а все остальное фигня.

M>Мало ли у кого какая отрасль работы. А мне вот нужно, чтобы мой код был понятен [censured]'ам, и свойство-ориентированность тоже удобна.

Вот это действительно круто.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 18:14
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Что такое исключение? Это ФАТАЛЬНЫЙ сбой в алгоритме. Следовательно алгоритм не отработал.

WH>>Вопрос нафига записывать мусор если надо просто сообщить о провале и подчистить ресурсы?
M>А вот надо. Лог вести, или ещё какие предсмертные действия совершить.
Лог кидающий исключения. Гениально.

M>Ну и кто по твоему должен что сказать? Или для всех локальных объектов Dispose делать?

M>
M>FileStream CreateFileStream(string filename)
M>{
M>    return new FileStream(filename, bla, bla, bla);
M>}
M>

Вот и я о томже. На С++ это будет так
boost::shared_ptr<FileStream> CreateFileStream(string filename)
{
    return boost::shared_ptr<FileStream>(new FileStream(filename, bla, bla, bla));
}

Таким образом мы получаем гарнтию детерминированого освобождения ресурса, а не когда GC на горе свиснет.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 18.09.03 18:14
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>А почему нет?

M>Потому, что рантайм-библиотеки не писались для этого применения. Мало ли, каким образом там память выделяется, какие дополнительные функции вызываются.
STL и CRT это немного разные вещи не находишь?
M>В некоторых местах в драйвере нельзя никакой лишней работы делать. Чтобы не дай бог ни подкачки, ни задержки никакой не было. Ну, закрепишь ты свой собственный код в памяти от свопирования. Но служебные библиотеки мало ли как там закреплять — это отдельно тестировать нужно.
Слова человека не знающего о существовании такого понятия в STL как allocator.
Но даже если забить на STL то ни что не мешает просто пользоваться всеми благами шаблонов.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 19.09.03 01:29
Оценка:
Здравствуйте, mihailik, Вы писали:

M>А причём здесь .NET? На .NET шаблоны себя не заставили ждать.

M>А вот Java давно написана, а о шаблонах всё разговоры да разговоры.

Судя по тому компилятору, который они сейчас попробовать дают, в Java будут на редкость отстойные шаблоны .
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 19.09.03 05:07
Оценка:
M>>В том же C++ не всегда можно забить на время жизни.
WH>В 99.999999% случаев. В то время как в дельфе надо в 100% случаев ручками.
Ошибаешься слегка!

WH>Ага это мне для каждого объекта придется писать интерфейсы... и всегда через них таскать

Ну да, все время забываю, что ты знаток Delphi !
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: ArtDenis Россия  
Дата: 19.09.03 06:46
Оценка:
Здравствуйте, mihailik, Вы писали:

AD>>3. функции *

M>Почему в Дельфи Процедуры и функции, причём даже "в т.ч. вложенные" не удостоились звезды, а в C++ простые функции удостоились?
Каюсь, забыл.

AD>>4. Классы *

M>Почему в Дельфи Классы не удостоились звезды, а в C++ удостоились?
Ещё раз извиняюсь

AD>>7. Нормальная(!) перегрузка функций *

M>В Дельфи, значит, ненормальная?
Да.

AD>>9. Понятие "объект класса" *

M>Что такое за понятие?
Это значит, что объявляя переменную с типом класса, вот так:
ClassName variable;

мы сразу получаем объект класса (как только программный поток попадает в область видимости этой переменной). В OP мы получим лишь ссылку на объект класса, после чего класс нужно вручную создавать. Вследствие чего в OP невозможны "умные" указатели (если только на уровне языка)

AD>>10. Поименованные области *

AD>>11. Шаблоны и STL:

M>Ну да, а для Дельфи есть VirtualTreeView — очень удобный компонент. Если уж пошли библиотеки сравнивать.



AD>> — типизированные контейнеры и массивы *

Какую-то я фигню написал про массивы. Любой массив типизирован, т.к. все его элементы имеют один и тот же тип. Сорри, видимо торопился. Но это к делу не относится.

M>В Дельфи, вроде бы отстутсвуют. В Дельфи все массивы, кажется, нетипизированные



Ага, значит, если мы объявляем массив
  arr : array[1..200] of Integer;

то получаем массив неизвестно чего Ты бы, сначала, паскаль подучил, прежде чем спорить.

Да кстати, о шаблонах, забыл добавить в список одну замечательную вещь — стратегии, которые позволяют конструировать объекты с желанным типом поведения. Короче, Александреску рулит!
... << RSDN@Home 1.1 beta 1 >>
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[36]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 19.09.03 07:52
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А слабо на дельфях нарисовать ГУЙ в ХР стиле?


Нет, не слабо. Даже задумываться не надо.
... << RSDN@Home 1.1 beta 2 >>
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 19.09.03 07:53
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Если архитектура нормальная для C++, то на C++ работы меньше. Если архитектура нормальная для Дельфи — соотвественно.


Просто разные "архитектурные" подходы.
... << RSDN@Home 1.1 beta 2 >>
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 19.09.03 07:53
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Ладно, ладно, семь — магическое число. Согласен. Тут C++ переплюнул, у него число более знатное.


Да нет же. Это вопрос библиотеки хорошей. Вот я буду на каждое заявление говорить: VCL. И уверять, что там зашибастые визуальные контролы на все случаи. Их дофигаста. Компоненты пишет всякий, кому не лень. Дофигаста бесплатных компонентов. И это ну очень круто удобно. Кто будет спорить...

А если я скажу: SysUtils/Math/Classes/System — то перекроет это функционал STL? Я сомневаюсь... Но ведь эти 4 модуля никто не обозвал Delphi STL, а ведь могли бы.

И, например, уже написанной библиотеки с подобным функционалом невизуальным и для Дельфи я пока не вспомню. Вот и гнёт он нас этим STL.

А вот раньше помню приходилось делать свои PInteger, IntegerArray и др. В D6/D7 эти вещи завраппены, и можно пользоваться "стандартными" типами...
... << RSDN@Home 1.1 beta 2 >>
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 19.09.03 08:05
Оценка:
Здравствуйте, akasoft, Вы писали:

A>И, например, уже написанной библиотеки с подобным функционалом невизуальным и для Дельфи я пока не вспомню. Вот и гнёт он нас этим STL.

И не вспомнишь. Ибо не возможно.

A>А вот раньше помню приходилось делать свои PInteger, IntegerArray и др. В D6/D7 эти вещи завраппены, и можно пользоваться "стандартными" типами...

В том то и дело что в дельфе на каждый тип приходится писать враперы в то время как в С++ один раз шаблон.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
от модератора
От: _MarlboroMan_ Россия  
Дата: 19.09.03 08:08
Оценка:
Здравствуйте, ArtDenis, Вы писали:

AD> Ты бы, сначала, паскаль подучил, прежде чем спорить.


а я бы на твоем месте таких заяв не делал... бо чревато боком.
... << RSDN@Home 1.1 beta 2 >>

— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 19.09.03 12:17
Оценка:
Здравствуйте, mihailik, Вы писали:

M>>>Есть COM-объект. Необходимо вызывать какие-то его методы, использовать свойства при помощи позднего связывания, т.е. методов IDispatch. В скриптовых языках, в VB, в Дельфи это очень просто.

ГВ>>Ну вот же ж блин. Ну нельзя на C++ наезжать по таким направлениям — не для того он предназначен.
M>Ну так я о том же. Гнобят бедный Дельфи и в хвост и в гриву. В гриву я ещё согласен, но в хвост — это зря.

Ну дык. Сабжект топика такой.

ГВ>>Конечно, если накатать набор врапперов, то можно сделать и "по позднему связыванию". В результате код пользователя будет примерно таким:

M>Ну да, на Дельфи тоже можно TLB импортировать. Только это куча лишних действий. Если нужно всего-то открыть Excel и бросить значения в пару ячеек, тут враппер как помеха какая-то.

Если относительно таких задач рассуждать, то для них и вовсе никакого враппера не нужно. Что ты будешь на каждом вызове HRESULT обрабатывать, что свой обработчик сделаешь; что напрямую через VMT-интерфейс, что через IDispatch — монопенисуально.

M>Кроме того, работа по позднему связыванию отличается от работы по интерфейсам тем, что освобождает от привязки к версиям. Если на C++ импортировать Office XP TLB, то с Office 2000 вполне полезут проблемы.


Проблемы и на VB иногда лезут. А с другой стороны, никто не мешает внутри С++ — врапперов сделать вызовы через IDispatch и вообще навернуть всё что угодно, хоть динамическое построение vmt, благо она там не ахти какая сложная — без множественного наследования-то.

ГВ>>Ну и наконец, если в твоей программе логики помимо подключения COM-объектов мало, то кой чёрт тогда тебе C++ использовать? Бери тот же VB и полный вперёд!

M>Ага. Согласен. Для OLE Automation лучше использовать более соответствующий язык.

Правильно, только обрати внимание — для использования COM/OLE-объектов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 19.09.03 14:05
Оценка:
Здравствуйте, mihailik, Вы писали:

M>>>Кроме того, все объекты сугубо by ref. Никаких объектов на стеке или ещё где ни попало.


L>>А как по твоему передаются параметры? По воздуху?


M>Все ОБЪЕКТЫ by ref. В C++ объекты (экземпляры классов) могут располагаться как в стеке, так и по адресу в памяти.


M>А в Дельфи переменная типа TObject — на самом деле указатель.

Спасибо. А причем тут Я???? А вот с FPU действительно Борланд покачал.
и солнце б утром не вставало, когда бы не было меня
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: jhfrek Россия  
Дата: 19.09.03 15:44
Оценка:
Здравствуйте, DOOM, Вы писали:

J>>А это вообще засада... Напишешь obj.FValue := ... вместо obj.Value := ... и кирдык всему тому что должно происходить внутри SetValue. А компилятор, зараза, не обругает...


DOO>warning скажет! Сделай warnings as errors раз так жить проще.


Чего он скажет???

Сейчас только сделал


TClass1 = class
private
  FValue: single
public
  property Value: single read FValue write SetValue
...

TClass2 = class
private
 Class1: TClass1; 
public
 constructor Create;
...

constructor TClass2.Create;
begin
  Class1 := TClass1.Create;

  Class1.Value := 10.0;
  Class1.FValue := 20.0;
end;


никакого warning
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: jhfrek Россия  
Дата: 19.09.03 15:48
Оценка:
Здравствуйте, mihailik, Вы писали:

J>>А... Сэмулируй мне, плеазе, друзей на Дельфях. Страдаю без них жутко...


M>Френдов-то? Да там все, кто внутри одного файла — френды.


Да я знаю. А если мне нужна фабрика сложного класса??? Получается файл неведренных размеров... А если хочется фабрику запихнуть в dll? Вообще фиг чего получится, ну или надо класс в инклюды пихать...
Re[45]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 19.09.03 15:57
Оценка:
Здравствуйте, Serginio1, Вы писали:

WH>>А чем чисто абстрактный класс без данных отличается от интерфейса?

S> Чем ??? Посмотри на реализацию придуманную M$.
Еще раз: ФИЗИЧЕСКОЕ устройчтво меня не волнует. А ЛОГИЧЕСКИ это тоже самое.
S>Дла каждого объекта (не класса) генерятся в памяти функции заглушки, которые генерят вызов методов класса с передачей данных объекта (Self) в методы класса.
Ты сам понял что сказал?
На всякий случай скажу как дело обстоит на самом деле.
Для каждого класса(не объекта)компилятор генерирует таблицу виртуальных функций при вызове просто берем указатель из таблици и вывываем this передается через ECX.
S> Вот и поймешь в чем причина. Не прав.

S> Гхы-Гхы. WolfHound хоть ты и RSDN но рассыждаешь как зеленоротый птенец.

НА ЛИЧНОСТИ ПЕРЕХОДИТЬ ЗАПРЕЩЕНО ПРАВИЛАМИ ФОРУМА.
S>По сути объекты 1С++ схожи со структурами.
Не понял.
S>Но виртуальность накладывает на обязательное поле
Какое поле?
S>ссылки на VMT,
S>в Delphi с отрицательным смещение хранится куча информации о типе , интерфейсах итд.
Я не копался в дельфе но что-то мне подсказавает что там лежит только указатель. Но если они в каждай объект запихали всю метоинформацию то...
S>Кроме всего прочего вариантный подход, тоже требует определенных методов по преобразованию.
Какой подход? Ах да. Я же забыл что дельфя с типами не дружит. И временами под скрипт пытается косить.
S>Я лично ну ни как не пойму какие проблемы у С++ с БД.
Я тоже.
S> А как насчет InheritedForm,,,,
А как на чсет типизированых контейнеров, адаптивных алгоритмов, смартпоинтеров,... А ведь это нужно на много чаще чем RTTI.

WH>>НАФИГА? Создал в стеке пусть лежит в стеке, создал в хипе пусть будет в хипе. Нафига это разделение?

S> Создал структуру как в Net и пусть себе лежит.
Почему один и тотже класс нельзя разместить в стеке, в хипе, как часть другого?
S>Какие проблемы. Неотвечаешь на предыдущие вопросы.
Какие именно? Ссылки пожалуйста.
S>Единственный аргумент Шаблоны. И все???
А что мало? Ах да. Я все время забываю что ты не имеешь представления о возможностях С++ шаблонов.
S> Честно говоря, как оппонент Вы WolfHound, очень не интересны.
А чтож тогда разговариваешь?
S>Абсолютно нет никакого конструктивизма и анализа.
Что анализировать? Нетипизированые контейнеры или варианты в языке? Им самое место в библиотеке.
S>Уперся рогом и все.
А ты чтоли нет?
S>Но в Net Я нашел, то что искал и ищу.
Плюсы есть но и минусов не мало. Хотя после дельфей их не видно ибо не знаешь куда смотреть.
S> С++ умрет, а Виртовский Паскаль останется.
И это еще мне говорят что я рогом уперся
S>И уже доказал свою состоятельнось, не взирая на свой возраст. Главное фундамент.
И чтоже в паскале такаго чего нет в С++?
S> Если Ты в Москве готов в личном поединке обсудить общеязыковые проблемы за кружечкой Водки.
Я не в Москве и водку не пью.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Страуструпа зовут ...?
От: akasoft Россия  
Дата: 19.09.03 19:06
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Короче, хотите программировать под Windows — читайте Страуструпа...


Пожалуйста, Страуструп случайно не Бьерн?
... << RSDN@Home 1.1 beta 2 >>
Re[39]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 19.09.03 20:03
Оценка:
Здравствуйте, mihailik, Вы писали:

M>>>Свойства

WH>>О да это величайшая АРХИТЕКТУРНАЯ особенность. К стати VC++ поддерживает свойства в качестве расширения.

M>Свойства — это важная архитектурная особенность. Языки, в которых поддерживаются свойства являются компонент-ориентированными. Ну вот не могу сказать почему так выходит, а реальность такова.


Постойте-постойте!!! Как, в С++ нет свойств? Тех, что есть даже в самом распоследнем Дельфи? Да не может этого быть! Я просто не могу поверить...
... << RSDN@Home 1.1 beta 2 >>
Re: Страуструпа зовут ...?
От: alexkro  
Дата: 20.09.03 08:47
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, mihailik, Вы писали:


M>>Короче, хотите программировать под Windows — читайте Страуструпа...


A>Пожалуйста, Страуструп случайно не Бьерн?


На русско-язычных книжках написано Бьерн. А, вообще, — это Bjarne, что произносится как Бьярнэ. http://www.research.att.com/~bs/bs_faq.html#pronounce
Re[47]: По просьбам трудящихся: Delphi vs C++(VS)
От: AlexK Украина  
Дата: 20.09.03 09:56
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, WolfHound, Вы писали:


WH>>Здравствуйте, Serginio1, Вы писали:



WH>>И чтоже в паскале такаго чего нет в С++?

S> Посмотри и сравни с Net. Зачем толочь одно и тоже.
S>>> Если Ты в Москве готов в личном поединке обсудить общеязыковые проблемы за кружечкой Водки.
WH>>Я не в Москве и водку не пью.
S> Ну вот они какие Сишники. А у нас народный русский (Российский) напиток Водка.
S> Срочно нужно новый Язык изобретать МежНациональный.
S> И пойми если бы в С++ было то, что мне хотелось сразу перешел бы на него.
S> А вот Net действительно берет своей мощью. И если мои посты только в защиту Delphi, то твои претендуют на абсолютную истинность. Такая небольшая разница.
S> ПРошу простить меня Модератор. Пятница однако.

"...Незнанае законов от ответсвенности не спасают..." (c) уголовное право

а тут просто надо руками пощупать, пописать на с++ с пол годика...
и поймеш круче языка еще не было...

А НЕТ не мощью берет, а тем что альтернативы ему нету... и мне слабо вериться что кто-то смогет макрософтов переплюнуть... задавят... делфи или помрет или вольеться в НЕТ как подмножество языков... что в принципе ничего не поменяет... и вот заметь с++ получил новое развитие в НЕТ... он так и остался стандартом для разработки топ перформанс апликаций... чего для Delphi на просторах макросовтовской оски небыло и не будет... делфи язык бизнес-апликаций, с++ язык системного уровня — но при этом он совершенно свободно может быть использован для наисания все-чего угодно...
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: AlexK Украина  
Дата: 20.09.03 10:01
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, mihailik, Вы писали:


M>>>>Свойства

WH>>>О да это величайшая АРХИТЕКТУРНАЯ особенность. К стати VC++ поддерживает свойства в качестве расширения.

M>>Свойства — это важная архитектурная особенность. Языки, в которых поддерживаются свойства являются компонент-ориентированными. Ну вот не могу сказать почему так выходит, а реальность такова.


A>Постойте-постойте!!! Как, в С++ нет свойств? Тех, что есть даже в самом распоследнем Дельфи? Да не может этого быть! Я просто не могу поверить...


НЕту.. но при этом простым классов-шаблоном-врапером можно это сделать... полная гибкость!
вобще понятия проперти/ивентов появилось только когда придумали и внедрили COM... идея может и до этого в воздухе летала, но достойной реализации небыло до COM... если не очень ошибаюсь в библиотке boost есть наработка на эту тему — создание пропертей и создание ивентов. И заметьте язык позволяет достаточно легко выкрутиться и расшириться собственными средствами, что для Делфи почти не реально...
Re[42]: По просьбам трудящихся: Delphi vs C++(VS)
От: AlexK Украина  
Дата: 20.09.03 10:28
Оценка:
Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, AlexK, Вы писали:


AK>>НЕту.. но при этом простым классов-шаблоном-врапером можно это сделать... полная гибкость!

AK>>вобще понятия проперти/ивентов появилось только когда придумали и внедрили COM... идея может и до этого в воздухе летала, но достойной реализации небыло до COM... если не очень ошибаюсь в библиотке boost есть наработка на эту тему — создание пропертей и создание ивентов. И заметьте язык позволяет достаточно легко выкрутиться и расшириться собственными средствами

AJD>Только этими свойствами очень неудобно пользоваться. На rsdn даже есть статья посвященная реализации свойств на плюсах. Нормального так ничего и не придумали...


Так лень думать стало — COM это все на себя перетянул...
Re[42]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 20.09.03 13:04
Оценка:
Здравствуйте, AndrewJD, Вы писали:

AJD>Только этими свойствами очень неудобно пользоваться. На rsdn даже есть статья посвященная реализации свойств на плюсах. Нормального так ничего и не придумали...


Почему? Вполне нормально. Их еще пооптимизировать можно. Можно указатели на getter/setter-ы параметрами шаблона передавать. Тогда все, что нужно хранить в свойстве — адрес объемлющего класса. В принципе, его можно отсчитывать от объектв-свойства. Но вот как шаблонами/препроцессором получить смещение от объекта-свойства до объекта, его содержащего, я не знаю. Похоже, никак. Поскольку при компиляции полей класса определение класса еще не полно и смещения до поля-свойства не известно . Но это уже технические детали.

А насчет синтаксиса — тоже не очень навороченно, описание поля, да в конструкторе свойству адрес внешнего класса дать. И все. В C++ бывают ситуации с гораздо более тяжелым синтаксисом. Так что они не сильно-то и нужны.
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 22.09.03 04:33
Оценка:
Здравствуйте, AlexK, Вы писали:

M>>>>>Свойства

WH>>>>О да это величайшая АРХИТЕКТУРНАЯ особенность. К стати VC++ поддерживает свойства в качестве расширения.

M>>>Свойства — это важная архитектурная особенность. Языки, в которых поддерживаются свойства являются компонент-ориентированными. Ну вот не могу сказать почему так выходит, а реальность такова.


AK>НЕту.. но при этом простым классов-шаблоном-врапером можно это сделать... полная гибкость!

AK>вобще понятия проперти/ивентов появилось только когда придумали и внедрили COM...
Точно, точно! Особенно мне нравился СОМ под Win3.11. А под DOS еще больше
Re[43]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 22.09.03 04:37
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, AndrewJD, Вы писали:


AJD>>Только этими свойствами очень неудобно пользоваться. На rsdn даже есть статья посвященная реализации свойств на плюсах. Нормального так ничего и не придумали...


WF>Почему? Вполне нормально. Их еще пооптимизировать можно. Можно указатели на getter/setter-ы параметрами шаблона передавать. Тогда все, что нужно хранить в свойстве — адрес объемлющего класса. В принципе, его можно отсчитывать от объектв-свойства. Но вот как шаблонами/препроцессором получить смещение от объекта-свойства до объекта, его содержащего, я не знаю. Похоже, никак. Поскольку при компиляции полей класса определение класса еще не полно и смещения до поля-свойства не известно . Но это уже технические детали.


WF>А насчет синтаксиса — тоже не очень навороченно, описание поля, да в конструкторе свойству адрес внешнего класса дать. И все. В C++ бывают ситуации с гораздо более тяжелым синтаксисом. Так что они не сильно-то и нужны.

Вот именно. Нафига в С++ свойства? В Delphi они несут большую функциональную нагрузку, а в С++?
Re[44]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 22.09.03 11:42
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>Вот именно. Нафига в С++ свойства? В Delphi они несут большую функциональную нагрузку, а в С++?


Я считаю, что свойства лишь более удобный вариант записи get_something(), set_something() (если не заморачиваться с RTTI/Reflection-ом, все равно полноценного в C++ нет). И следовательно в C++ они не нужны, поскольку синтаксис это сильно не упростит (C++ все равно останется языком с очень тяжелым синтаксисом). В языках типа Дельфи, С# — да очень нужны, для более легкого понимания. В C++ — нет.
Re[45]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 22.09.03 12:31
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, FWP, Вы писали:


FWP>>Вот именно. Нафига в С++ свойства? В Delphi они несут большую функциональную нагрузку, а в С++?


WF>Я считаю, что свойства лишь более удобный вариант записи get_something(), set_something() (если не заморачиваться с RTTI/Reflection-ом, все равно полноценного в C++ нет). И следовательно в C++ они не нужны, поскольку синтаксис это сильно не упростит (C++ все равно останется языком с очень тяжелым синтаксисом). В языках типа Дельфи, С# — да очень нужны, для более легкого понимания. В C++ — нет.

Так и я про то же. Свойства — это атрибут компонентно-ориетированного языка. Компоненты в Delphi, а теперь и в C#?, позволяют затачивать IDE под себя. Т.е. в идеале программрование должно свестись к киданию компонент на форму и настройке их СВОЙСТВ. В действительности это, конечно, не так . А в С++ это просто дань моде.
На мой взгляд один из самых неприятных недостатков Delphi вытекает из этого его достоинства. Многие начинающие программисты умирают на уровне компонентокидательства. А потом считают, что этим Delphi и заканчивается. Так скоро начнут искать компоненты для поиска максимума в массиве. Кстати, STL косвенно тоже ведет к деградации программистского сообщества.
Конечно GENERIC PROGRAMMING позволяет облегчить некоторые проблемы. И введение его в Delphi и в C# не помешает. Но и не является такой панацеей какой ее пытается представить WH.
Re[43]: По просьбам трудящихся: Delphi vs C++(VS)
От: AndrewJD США  
Дата: 22.09.03 14:02
Оценка:
Здравствуйте, WFrag, Вы писали:


WF>А насчет синтаксиса — тоже не очень навороченно, описание поля, да в конструкторе свойству адрес внешнего класса дать. И все. В C++ бывают ситуации с гораздо более тяжелым синтаксисом. Так что они не сильно-то и нужны.


Бывают ситуации... Вот поэтому они никому нафиг не нужны. Зачем заморачиваться с свойствами, если они вместо облегчения жизни, делают ее еще сложнее...
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[44]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 22.09.03 14:11
Оценка:
Здравствуйте, AndrewJD, Вы писали:

AJD> Бывают ситуации... Вот поэтому они никому нафиг не нужны. Зачем заморачиваться с свойствами, если они вместо облегчения жизни, делают ее еще сложнее...


Да нет, в использовании вне класса — как в C#. В использовани в классе — тоже ничего сложного. Просто не так логично, как в C#, не get/set, а два метода, переменная и в конструкторе немного буковок.
Re[44]: Свойства
От: VuDZ Россия  
Дата: 22.09.03 18:17
Оценка:
Здрасте...
Канэшна, на С# property понавороченнее, но мне хватает и того, что можно сделать на С++ за 3 минуты...
Конечно, имногда хотелось бы писать some_class.foo++, но, это не так часто бывает нужно...
Re[38]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 23.09.03 11:05
Оценка:
M>>Операторы, слава богу, не перегружаются.
S>Уже. Custom Variant Types начиная с 6 позволяют реализовать нечто похожее на перегрузку операторов.

Ну как с адресной арифметикой: если очень хочется, то можно. Только неудобно.
... << RSDN@Home 1.1 beta 1 >>
Re[40]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 23.09.03 11:05
Оценка:
WF>Судя по тому компилятору, который они сейчас попробовать дают, в Java будут на редкость отстойные шаблоны .

Хе-хе. Мелочь, а приятно.
... << RSDN@Home 1.1 beta 1 >>
Re[43]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 23.09.03 11:05
Оценка:
WF>А насчет синтаксиса — тоже не очень навороченно, описание поля, да в конструкторе свойству адрес внешнего класса дать. И все. В C++ бывают ситуации с гораздо более тяжелым синтаксисом. Так что они не сильно-то и нужны.

Вот он, булыжник в огород сишников!
... << RSDN@Home 1.1 beta 1 >>
Re[7]: По просьбам трудящихся: Delphi vs C++(VS)
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.03 11:59
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Очень даже правда и любой Дельфист это скажет перешедший или изучающий Net. Подождем Delphi.Net и тогда уж сравним с C# ( уже по анонсам много интересного и много отличного от C#) Хотя это два языка Брата и родитель у них один Андреас Хейлсберг. Прошу не обижаться поклонников Вирта (я сам его поклонник).


Да уж братья. И уж совсем не ясно каким боком Вирт к Шарпу?
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.09.03 13:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Serginio1, Вы писали:


S>> Очень даже правда и любой Дельфист это скажет перешедший или изучающий Net. Подождем Delphi.Net и тогда уж сравним с C# ( уже по анонсам много интересного и много отличного от C#) Хотя это два языка Брата и родитель у них один Андреас Хейлсберг. Прошу не обижаться поклонников Вирта (я сам его поклонник).


VD>Да уж братья. И уж совсем не ясно каким боком Вирт к Шарпу?

Вирт-Паскаль-Хейлсберг-Turbo Pascal-Delphi-Net-C#. (Типизация, иерархия классов, сериализация, компонентность)
и солнце б утром не вставало, когда бы не было меня
Re[14]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 23.09.03 14:38
Оценка:
WH>Таким образом мы получаем гарнтию детерминированого освобождения ресурса, а не когда GC на горе свиснет.

И как это работает? Посдчёт ссылок, как я понимаю.

Это старьё, и алгоритм типа AddRef/Release давно признан архитектурно убогим. На цикличных ссылках не пашет.
... << RSDN@Home 1.1 beta 1 >>
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.09.03 17:32
Оценка:
Здравствуйте, Serginio1, Вы писали:

VD>>Да уж братья. И уж совсем не ясно каким боком Вирт к Шарпу?

S> Вирт-Паскаль-Хейлсберг-Turbo Pascal-Delphi-Net-C#. (Типизация, иерархия классов, сериализация, компонентность)

Вирт создал обычный Паскаль. А на Дельфи вроде как даже плевался. Он тут точно не причем.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.09.03 17:46
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Serginio1, Вы писали:


VD>>>Да уж братья. И уж совсем не ясно каким боком Вирт к Шарпу?

S>> Вирт-Паскаль-Хейлсберг-Turbo Pascal-Delphi-Net-C#. (Типизация, иерархия классов, сериализация, компонентность)

VD>Вирт создал обычный Паскаль. А на Дельфи вроде как даже плевался. Он тут точно не причем.

Были еще Модула и (уже забыл Обтерон вроде) тоже ООП. Главное идеи и их преемственность. А так как я вырос еще из Виртовского Паскаля, то эти переходы для меня очень просты.
и солнце б утром не вставало, когда бы не было меня
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 23.09.03 18:53
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>>>При написании ГУИ к БД согласен, а вот на счет всего остального.

M>>>Ты что, предлагаешь и в браузерах скрипты на C++ писать? Или ты какое-то конкретное "остальное" имеешь ввиду?
WH>>Ты дурочку не валяй. Прекрасно понял о чем речь.

M>Прекрасно понял. Когда ты говоришь "всё остальное", это означает "узкий круг задач, которыми я сейчас занимаюсь"


Вот это, кстати, в точку. Этим, кстати, многое определяется в высказываниях.
... << RSDN@Home 1.1 beta 2 >>
Re[15]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 24.09.03 01:54
Оценка:
Здравствуйте, mihailik, Вы писали:

M>И как это работает? Посдчёт ссылок, как я понимаю.

M>Это старьё, и алгоритм типа AddRef/Release давно признан архитектурно убогим. На цикличных ссылках не пашет.

Зато быстро, эффективно и детерминировано. К тому же есть механизм слабых ссылок, для разрешения проблемы циклических ссылок.
P.S. А у тебя есть другой вариант? Более новый, чем циклические ссылки, с детерминированным освобождением? Интересно было бы послушать.
P.P.S. Кстати, кем признан ? Мировым сообществом Java/.NET программистов?
Re[10]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 24.09.03 04:13
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Вирт создал обычный Паскаль. А на Дельфи вроде как даже плевался. Он тут точно не причем.

Вирт создал не только Pascal. Были еще Modula, Modula-2, Modula-3. TurboPascal и Delphi много чего почерпнули из них. Создатели Delphi привнесли в язык много модных, но потенциально опасных вещей. Поэтому он и "плевался". И если Modula-2 и TurboPascal — близняшки, то Oberon-2 и Delphi7 — троюродные братья
Re[17]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 24.09.03 16:32
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Ага. И это "продают" под видом простоты и надёжности.


Ну да, согласен, простой домохозяйке это не доступно. С++ — это не язык для домохозяек, как это уже не раз отмечалось. Он дико сложен, но и чрезвычайно гибок. В принципе, циклические ссылки — не так страшны, как тебе кажется.

WF>>P.S. А у тебя есть другой вариант? Более новый, чем циклические ссылки, с детерминированным освобождением? Интересно было бы послушать.


M>А что такое детерминированное освобождение? Ты можешь описать это другим образом кроме как "также, как AddRef/Release"?


Когда на объект нет ссылок, он сразу умирает. Все просто . Или если использовать scoped_ptr, когда указазатель выходит из области видимости. Или, например, автоматическое отписывание от события. На C++ реализуется чрезвычайно просто. В конструкторе, например, подписываемся, а в деструкторе — автоматически отписываемся.

WF>>P.P.S. Кстати, кем признан ? Мировым сообществом Java/.NET программистов?


M>А ты сам разве не согласен с мировым сообществом?


Не совсем. Где-то GC лучше, где-то C++-ый подход.


Я не понимаю, что все к этим циклическим ссылкам привязались . Не так уж часто они встречаются. Гораздо чаще встречаются повисшие на событиях делегаты в .NET-е, и насколько мне известно, эта проблема красиво не решается. Все эти решения через WeakDelegates — удаление гланд через задний проход. А все из-за отсутствия автоматического вызова деструкторов. Приходится два раза думать об одном и том же. И если подписывание — это часть логики, которую за тебя, разумеется, никто не сделает, то отписывание часто — всего лишь освобождение ресурсов. Которое, опять таки, довольно часто может быть автоматизировано.
Re[18]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 24.09.03 17:05
Оценка:
M>>Ага. И это "продают" под видом простоты и надёжности.

WF>Ну да, согласен, простой домохозяйке это не доступно. С++ — это не язык для домохозяек, как это уже не раз отмечалось. Он дико сложен, но и чрезвычайно гибок.


Согласен.

WF>В принципе, циклические ссылки — не так страшны, как тебе кажется.


Это как так "не так страшны"? Зависнет в памяти целый граф, типа там большая структура бизнес-объектов — это не страшно? Хм...

WF>>>P.S. А у тебя есть другой вариант? Более новый, чем циклические ссылки, с детерминированным освобождением? Интересно было бы послушать.


M>>А что такое детерминированное освобождение? Ты можешь описать это другим образом кроме как "также, как AddRef/Release"?


WF>Когда на объект нет ссылок, он сразу умирает. Все просто .


Куда там! Следуя этому определению ты от циклических ссылок никак не уйдёшь.

WF>Или если использовать scoped_ptr, когда указазатель выходит из области видимости.


А без C++ можно определение дать? А то получается, детерминированное осовобождение — чисто внутренне понятие C++.

WF>Я не понимаю, что все к этим циклическим ссылкам привязались . Не так уж часто они встречаются.


Если важный сервер в банке будет падать "не так уж часто", ребята будут очень недовольны. Так что категории "часто/нечасто" тут не совсем правильны.

WF>Гораздо чаще встречаются повисшие на событиях делегаты в .NET-е, и насколько мне известно, эта проблема красиво не решается.


А в чём, собственно, проблема-то? Ну да, делегаты создают жёсткую ссылку на объект и не дают его выбросить. Ну оно так и задумывалось, под это и написано.

WF>Все эти решения через WeakDelegates — удаление гланд через задний проход.


Естественно.

WF>А все из-за отсутствия автоматического вызова деструкторов. Приходится два раза думать об одном и том же. И если подписывание — это часть логики, которую за тебя, разумеется, никто не сделает, то отписывание часто — всего лишь освобождение ресурсов. Которое, опять таки, довольно часто может быть автоматизировано.


Проблема автоматического вызова деструкторов — та же архитектурная проблема циклических ссылок.
... << RSDN@Home 1.1 beta 1 >>
Re[21]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 25.09.03 15:33
Оценка:
Здравствуйте, mihailik, Вы писали:

WF>>Детерминированное == определенное. Т.е когда точно известен момент (и им можно управлять), например, смерти объекта.


M>Определённое? Кем определённое?


Семантикой умных указателей, например. Т.е известно, последовательность каких действий с интерфейсом умного указателя приводит к смерти объекта. Или областью видимости, если это переменная на стеке.

M>В .NET объекты освобождаются тоже строго в определённый срок. Этот срок определяет GC.


Нет. Неизвестно точно, какие действия с интерфейсом GC в конечном итоге приведут к смерти данного объекта.

Пояснение: Интерфейс GC — это выделение объекта. Вызов GC.Collect() по очевидным причинам не рассматриваем в данной ситуации. Он, конечно, дает некоторую определенность, но слишком большой ценой .

M>Конечно, ты скажешь, что определять время освобождения должен программист. Но тогда встаёт вопрос, какой программист? Если один компонент использует другой, то на ком должна лежать ответственность за освобождение?


M>С одной стороны, это дело автора компонента, с другой — только пользователь компонента знает, когда он уже перестал его использовать.


Мне все равно, кто как и зачем кого использует. Я использую некий компонент. Как он мне становится не нужен, я неявным образом (посредством области видимости, например) освобождаю его.

M>Циклические ссылки внутри одной библиотеки можно (со скрипом) разешить. Но как быть с циклическими ссылками между компонентами разных библиотек? Кто тут будет определять время жизни?


Тут, конечно, сложнее. Надо подумать. Хотя действительно, в этой ситуации стоимость решения существенно возрастает.

WF>>По аналогии. Если важный сервер в банке будет падать "не так уж часто" (от нехватки памяти), ребята будут очень недовольны.


M>Ну тут не .NET виноват, а программисты. Нечего делегаты использовать не по назначению.


.NET не может быть виноватым. И C++ тоже. Виноват всегда программист. Стоит лишь вопрос цены. Правда, тут .NET наверняка выигрывает (если не стоит вопрос производительности). Хм, надо тогда подумать, в чем все же может быть преимущество C++

Кстати, меня как-то забавная мысль посетила, насчет удешевления процесса разработки за счет использования всяких "управляемых" рантаймов и дополнительных проверках. Проги стали меньше падать, зато гораздо чаще глючить .

M>Как тенденция это хорошо. Но дело-то происходит на реальной земле. А тут автоматически не всё можно сделать.


Ну и что. Это ведь не повод отказываться от автоматизации вообще.
Re[22]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 25.09.03 15:52
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, mihailik, Вы писали:


WF>>>Детерминированное == определенное. Т.е когда точно известен момент (и им можно управлять), например, смерти объекта.


M>>Определённое? Кем определённое?


WF>Семантикой умных указателей, например. Т.е известно, последовательность каких действий с интерфейсом умного указателя приводит к смерти объекта. Или областью видимости, если это переменная на стеке.


Время на ослеживание. С таким же успехом, можно выделять память и в куче а и передвигать указатель конца использумой памяти. А дефрагментация памяти. Оссобенно при реаллоках когда памяти куча и Оут Оф Память. И в общем зачем тратить ресурсы если эта память не нужна. Другое дело системные ресурсы. Но об этом должен заботится программист ди не так их уж и много. Да и отслеживание мертвых объектов может происходить в момент простоя. Для многопроцессорных серверов вообще не проблема. Я думаю они провели немало времени за тестами и GC еще молод и будет развиваться. Идея правильная!!!!
и солнце б утром не вставало, когда бы не было меня
Re[20]: По просьбам трудящихся: Delphi vs C++(VS)
От: akasoft Россия  
Дата: 25.09.03 17:10
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Проблема в том, что когда я подписываю на событие (например, в конструкторе, да еще и на статическое событие) — это часть логики. Если я забуду подписаться, это, скорее всего, легко обнаружится. А вот отписывание — уже не часть логики, я могу с легкостью забыть отписаться и получу утечку. Вот почему "умные" указатели существенно облегчают работу — нужно лишь захватить ресурс, а освободится он сам, причем управляемо.


Расслабляют они умные мозги, заставляют их думать, что кто-то за них всё сделает, да ещё и как надо.

Странная какая-то проблема. Я вот о чём подумал — что проблема эта связана с определённымим стереотипами, накладываемыми основным (часто используемым) языком программирования. Вот Сишники привыкли, что освобождение ресурсов за них делает компилятор и всякие сборщики, переменные по коду объявляют, где хотят, опять же чувствительность к регистру. Те же, кто OP использует привыкли в конструкторах захватывать, а в деструкторах освобождать. Ну или там захватывать, когда понадобилось, но освобождать всегда ручками в деструкторах.

Т.е. в голове крутится — если подписался на событие, значит надо и отписаться. Как-то переложить это на (какой-то там) компилятор и в голову не приходит...

За это мне этот C# Коллектор так не нравится . Чё хочет делает, не управляемый в пень какой-то.

Вот ещё вспомнил, раньше, во времена DOS, в Борланд Паскале была такая возможность запомнить процедурой Mark (по моему) текущий указатель кучи, потом дико распределять её как угодно, до дыр, что называется. А потом одним махом по заверщении действий приказать всё освободить вызовом Release (кажется). Так было удобно, не надо тебе о дырах и щелях в памяти заботиться, и памятью можно было управлять явно. А это всёже какой-никакой элемент оптимизации работы программы.
... << RSDN@Home 1.1 beta 2 >>
Re[11]: Некоторые итоги:
От: WolfHound  
Дата: 25.09.03 19:57
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Применение Маккросов и Шаблонов наложили отпечаток и на сам язык, так перегрузки операций и функций прекрасно вписываются в Шаблонную систему и неявное приведение типов, но их переизбыток иногда ведет к непониманию кода, особенно когда перегруженная функция имеет совсем другой смысл, но написание ее будет темже. Перегрузка операторов для элементарных типов тоже может вести к неправильному восприятию (например сложение указателей и неявное приведение к LongWord).

Супер аргумент этим же мотивировали отсутствие перегрузки операторов в жабе.
S> Отсутствие шаблонов в Delphi, заставляет мыслить Виртуально, а не Шаблонно.
Ага типа я в С++ не могу мыслить виртуально. Вся разница в том что в С++ у меня есть выбор и очень часто шаблон оказывается оптимальным решением, но иногда и виртуальность нужна.
S> Вернемся к сортировке. Для элементарных типов шаблоны впереди планеты всей, но со сложными структурами, когда нужно сортировать по любому сочетанию полей и во время выполнения программы шаблоны бессмыслены, если вспомнить комбинаторику и посчитать все сочетания.
S> Решение выглядит приблизительно так.
хъ
Какой кошмар
В С++ существует такое понятие "функтор" это объект который ведет себя как функция.
struct some
{
//...
};
struct some_dynamic_cmp
{
    bool operator()(const some& lhs, const some& rhs)
    {
    //Тут сравниваем
    }
};
void main()
{
    std::vector<some> some_vec;
    //Заполняем
    some_dynamic_cmp cmp;
    //Устанавлеваем правила сравнения
    std::sort(some_vec.begin(), some_vec.end(), cmp);
}

Все.
S> И в отличие от шаблонов, скорость падает, но я имею универсальность, а при выборе оптимальных алгоритмов в прктических диапозонах вычислений ловит тысячные секунды не имеет смысла. Все зависит от задачи.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 25.09.03 19:57
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Именно. Всё должно быть как можно проще.

Вот именно все должно быть проще. Вот скажи мне какого черта я должен прописать создание десятка объектов (конструктор по умолчению которых мне прекрасно подходит) в конструкторе и удаление всех в деструкторе если я могу их лишь одан раз описать?

M>Именно, что слабо. Никому не нужная экзотика.

Ну ладно не int а класс написаный неизвесно кем не извесно когда и менять его ты не можешь. Ы?

M>В некоторых случаях ограничения выбора — благо. К примеру, на мосту через Днепр перильца есть.

Я бы сказал по другому. Нахрена пользоваться одной и тойже отверткой для заворачивания винтов и шурупов разного размера и с разными шляпами когда можно взять разные. Вспоминаем про шурупы на которых висят двери и ту винтики что в наручных часах...

M>Прекрасно понял. Когда ты говоришь "всё остальное", это означает "узкий круг задач, которыми я сейчас занимаюсь"

Узкий круг задачь это тонны ГУИ к БД который надо быстро нарисовать. А С++ решает очень широкий круг задач от СОМ серверов до игр. Можно и на дельфе я не спорю но какой ценой.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[42]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 25.09.03 19:57
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Вот это, кстати, в точку. Этим, кстати, многое определяется в высказываниях.


Ты что, предлагаешь и в браузерах скрипты на C++ писать? Или ты какое-то конкретное "остальное" имеешь ввиду?

... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 25.09.03 19:57
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Хе-хе. Мелочь, а приятно.

Ну и нахрена нужны отмазки в место инструментов?
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 25.09.03 19:57
Оценка:
Здравствуйте, mihailik, Вы писали:

WF>>А насчет синтаксиса — тоже не очень навороченно, описание поля, да в конструкторе свойству адрес внешнего класса дать. И все. В C++ бывают ситуации с гораздо более тяжелым синтаксисом. Так что они не сильно-то и нужны.


M>Вот он, булыжник в огород сишников!

Ага ты посмотри посты Serginio1 где он пытается реализовать элементарные вещи.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[45]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 25.09.03 19:57
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Да нет, в использовании вне класса — как в C#. В использовани в классе — тоже ничего сложного. Просто не так логично, как в C#, не get/set, а два метода, переменная и в конструкторе немного буковок.

Либо не парится и использовать расширения ибо всеравно большинство программ не будут портироваться.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[41]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 25.09.03 19:57
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Ну, в Дельфи тоже можно много чего эмулировать. Те же шаблоны можно эмулировать.

Это как? Уж не про ту ли ты фиговину с королевства?

M>Ага. А в начале прошлого века говорили: не дело это, домохозяек за руль пускать. Но когда машины стали удобны, надёжны и просты в управлении, домохозяйки сели за руль.

А ты сядешь за автомобиль собранный домохозяйкой?

M>С языками/компьютерами/программированием будет точно то же самое.

А ну-ну.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 25.09.03 19:57
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Расслабляют они умные мозги, заставляют их думать, что кто-то за них всё сделает, да ещё и как надо.

Вот именно нахрена делать то что очень хорошо может сделать компилятор.

A>Странная какая-то проблема. Я вот о чём подумал — что проблема эта связана с определённымим стереотипами, накладываемыми основным (часто используемым) языком программирования. Вот Сишники привыкли, что освобождение ресурсов за них делает компилятор и всякие сборщики, переменные по коду объявляют, где хотят, опять же чувствительность к регистру. Те же, кто OP использует привыкли в конструкторах захватывать, а в деструкторах освобождать. Ну или там захватывать, когда понадобилось, но освобождать всегда ручками в деструкторах.

Вот скажи мне зачем отпускать ресурс ручками? Ведь логика работы с ресурсом обычно весьма громоздка дык зачем захламлять код? Зачем думать об исключениях?

A>Т.е. в голове крутится — если подписался на событие, значит надо и отписаться. Как-то переложить это на (какой-то там) компилятор и в голову не приходит...

Вот именно потомушто нельзя по нормальному это сделать, а вот еслибы было мохно то я уверен что ты бы этим пользовался.

A>За это мне этот C# Коллектор так не нравится . Чё хочет делает, не управляемый в пень какой-то.

Мне тоже очень не нравится, а вот смартпоинтеры это совсем другое дело. Всегда знаешь кого и главное когда они пристрелят.

A>Вот ещё вспомнил, раньше, во времена DOS, в Борланд Паскале была такая возможность запомнить процедурой Mark (по моему) текущий указатель кучи, потом дико распределять её как угодно, до дыр, что называется. А потом одним махом по заверщении действий приказать всё освободить вызовом Release (кажется). Так было удобно, не надо тебе о дырах и щелях в памяти заботиться, и памятью можно было управлять явно. А это всёже какой-никакой элемент оптимизации работы программы.

Какой ужас.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 25.09.03 19:57
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Время на ослеживание. С таким же успехом, можно выделять память и в куче а и передвигать указатель конца использумой памяти. А дефрагментация памяти. Оссобенно при реаллоках когда памяти куча и Оут Оф Память. И в общем зачем тратить ресурсы если эта память не нужна. Другое дело системные ресурсы. Но об этом должен заботится программист ди не так их уж и много. Да и отслеживание мертвых объектов может происходить в момент простоя. Для многопроцессорных серверов вообще не проблема. Я думаю они провели немало времени за тестами и GC еще молод и будет развиваться. Идея правильная!!!!

У мнея такое ощущение что кто-то чего-то сильно не понимает.
Допустим у нас есть некий объект который держит ресурс. Этот объект использовало куча других и через некоторое время он перестал быть нужен. Вопрос как узнать когда именно нужно освободить ресурс, а если легика была довольно сложной? В конце концов после долгих мучений выяснится что оптимальным решением будет именно подсчет ссылок. А вот как его реализовать в .НЕТ чтобы не было мучительно больно при использовании это уже придется хорошо подумать.
Хотя некоторые объекты (строки,...) лучше на GC.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 25.09.03 19:57
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Я не знаю, насколько STL зависит от платформы.

STL от платформы не зависит вобще.

WH>>Слова человека не знающего о существовании такого понятия в STL как allocator.

M>Для профессионального программиста на C++ ты делаешь удивительно тривиальные выводы. Да, я не знаю, что такое STL allocator. И именно поэтому, я не понимаю твоего аргумента
Это такая дурь скармливается последним аргументом шаблона(обычно используется аллокатор по умолчанию) Короче можно заставить контейнер использовать тот распределитель памяти который тебе нужен.

WH>>Но даже если забить на STL то ни что не мешает просто пользоваться всеми благами шаблонов.

M>Думаю, без хороших библиотек шаблоны среднеполезны.
Думаю без шаблонов хороших библиотек не напишешь.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 26.09.03 01:05
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Время на ослеживание. С таким же успехом, можно выделять память и в куче а и передвигать указатель конца использумой памяти. А дефрагментация памяти. Оссобенно при реаллоках когда памяти куча и Оут Оф Память. И в общем зачем тратить ресурсы если эта память не нужна. Другое дело системные ресурсы. Но об этом должен заботится программист ди не так их уж и много. Да и отслеживание мертвых объектов может происходить в момент простоя. Для многопроцессорных серверов вообще не проблема. Я думаю они провели немало времени за тестами и GC еще молод и будет развиваться. Идея правильная!!!!


Я не думаю, что стоит от GC ожидать существенного прироста производительности. По-моему, он принципиально медленный. Ведь когда убираем мусор по крайней мере объекты в окрестнсти (в графе) исследуемой на предмет мертвых объектов области должны быть заблокированы. Я так понимаю. Хотя в теории построения GC я не особо силен.
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.09.03 05:41
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Вот только однажды ктото долго матерился когда на слабой машине софтина на любых стресстестах работала как часы, а на серваке падала в месте с системой.
Ну у нас софтина под java работала как часы под очень жесткой нагрузкой. Ну, это не так важно. Хотя я вообще не очень понимаю, как Java или .NET может вообще положить систему. Надо бы изучить эту тему.
WH>Чесно говоря не могу себе представить случай когда могут возникнуть циклические ссылки. Особенно в объектах которые используют внешние ресурсы.
Ну, вообще представить себе такой случай особой фантазии не надо. Практически любое отношение в бизнес-системе позволяет двустороннюю навигацию. Его можно, конечно, искусственно разорвать, но это не всегда удобно. Ну там накладная->клиент->список накладных->накладная. пипец.
Согласен насчет внешнересурсных ссылок. Но они как-то не очень часто имеют неопределенный scope. Из моего опыта все сценарии ровно такие: захватили-трай-попользовали-финалли-отпустили. Тут неважно, GC или еще кто.
WH>Проблема GC в том что ему не надо циклов для того чтобы держать ресурсы. К томуже он не риагирует на нехватку внешних ресурсов, а только на нехватку памяти.
WH>Проблема какраз в том чтобы узнать когда именно вызвать Dispose особенно если однозначно не возможно определить хозяина, а вот если использовать подсчет ссылок и GC одновременно(для того чтобы рано или позно но убить цикл)то это может дать очень не плохие результаты.
А! вот одновременно — неплохая идея. Поверх GC можно реализовать подсчет ссылок. Очень даже вполне.
WH>Да просто строки и компания используют ТОЛЬКО память, а именно не ее нехватку реагирует GC а вот колличество открытых файлов в системе ограничено и GC на это не риагирует. Тоже самое касается других ресурсов.
Ну я бы так пессимистично не относился. Если у нас есть в одном домене потоки двух типов, один из которых не требует ресурсов типа А и все время работает, тогда да — у GC не будет стимула проснуться и убрать для потоков типа B. Но по-моему, такие потоки проще разнести по разным доменам. А для симметричных потоков GC неизбежно проснется, когда будут исчерпаны любые ресурсы, т.к. пользовательским потокам просто нечего без них делать.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 09:11
Оценка:
WF>>>Детерминированное == определенное. Т.е когда точно известен момент (и им можно управлять), например, смерти объекта.

M>>Определённое? Кем определённое?


WF>Семантикой умных указателей, например. Т.е известно, последовательность каких действий с интерфейсом умного указателя приводит к смерти объекта. Или областью видимости, если это переменная на стеке.


Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.

M>>В .NET объекты освобождаются тоже строго в определённый срок. Этот срок определяет GC.


WF>Нет. Неизвестно точно, какие действия с интерфейсом GC в конечном итоге приведут к смерти данного объекта.


WF>Пояснение: Интерфейс GC — это выделение объекта. Вызов GC.Collect() по очевидным причинам не рассматриваем в данной ситуации. Он, конечно, дает некоторую определенность, но слишком большой ценой .


В том то и дело, что нестрогие определения как раз и приводят к таким вот доопределениям "на ходу". Чтобы объяснить, что такое "детерменированное освобождение" тебе пришлось и от умных указателей отталкиваться, и от GC, и от цены. Как будто этот детерминизм — не реальное понятие, а что-то из области гуманитарных наук. Что нельзя понять, только сердцем почувствовать

M>>Конечно, ты скажешь, что определять время освобождения должен программист. Но тогда встаёт вопрос, какой программист? Если один компонент использует другой, то на ком должна лежать ответственность за освобождение?


M>>С одной стороны, это дело автора компонента, с другой — только пользователь компонента знает, когда он уже перестал его использовать.


WF>Мне все равно, кто как и зачем кого использует. Я использую некий компонент. Как он мне становится не нужен, я неявным образом (посредством области видимости, например) освобождаю его.


Ага. А если кто-то другой тоже его использует — сам виноват. Мы объект уже убили. Нечего было на одной дорожке пересекаться.
... << RSDN@Home 1.1 beta 1 >>
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 09:11
Оценка:
WH>Проблема какраз в том чтобы узнать когда именно вызвать Dispose особенно если однозначно не возможно определить хозяина, а вот если использовать подсчет ссылок и GC одновременно(для того чтобы рано или позно но убить цикл)то это может дать очень не плохие результаты.

Одновременно? Попахивает извращением. Хотя, возможно, какое-то зерно в этом есть.
... << RSDN@Home 1.1 beta 1 >>
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 26.09.03 09:44
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.


Слово "например" видел?

M>В том то и дело, что нестрогие определения как раз и приводят к таким вот доопределениям "на ходу". Чтобы объяснить, что такое "детерменированное освобождение" тебе пришлось и от умных указателей отталкиваться, и от GC, и от цены. Как будто этот детерминизм — не реальное понятие, а что-то из области гуманитарных наук. Что нельзя понять, только сердцем почувствовать


Ну, если подходить совсем формально, в случае с GC он бесспорно тоже определен в каком-то смысле. Можно ведь после каждого присваивания ссылки делать GC.Collect(), только ведь это абсурд.

Попробуем определить так: детерминированность — это когда событие не зависит от внешних к системе факторов.
Re[26]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 26.09.03 09:57
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Sinclair, Вы писали:


WH>>>Допустим у нас есть некий объект который держит ресурс. Этот объект использовало куча других и через некоторое время он перестал быть нужен. Вопрос как узнать когда именно нужно освободить ресурс, а если легика была довольно сложной? В конце концов после долгих мучений выяснится что оптимальным решением будет именно подсчет ссылок.


То оче ты говоришь называется MarshalByRefObject и для него существуют определенные интерфейсы для определения его времени жизни. Хотя и пользоваться им не стоит часто. Очень сомнительно, использовать объект с подключенным к нему кучей других из одного потока , вместо того чтобы прямо его использовать. Значит, что то с логикой программы.
и солнце б утром не вставало, когда бы не было меня
Re[27]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 26.09.03 10:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>Вот только однажды ктото долго матерился когда на слабой машине софтина на любых стресстестах работала как часы, а на серваке падала в месте с системой.

S>Ну у нас софтина под java работала как часы под очень жесткой нагрузкой. Ну, это не так важно. Хотя я вообще не очень понимаю, как Java или .NET может вообще положить систему. Надо бы изучить эту тему.
Ну на счет операционки это я скорей всего погорячился (хотя если в callback'е поставить открытие файла то система будет чувствовать себя очень хреново) но сама себя программа может свалить легко
using System;
using System.Threading;
namespace SystemCrush
{
    class Class1
    {
        static object sync=new object();
        static void callback()
        {
            lock(sync)
                Thread.Sleep(0);
        }
        [STAThread]
        static void Main(string[] args)
        {
            while(true)
                new Thread(new ThreadStart(callback)).Start();
        }
    }
}

В место Thread.Sleep может быть любая операция прерывающая поток.
В реальной жизни на сервак который обрабатывает пользователей в отдельных потоках пришла бешеная нагрузка.

S>Ну, вообще представить себе такой случай особой фантазии не надо. Практически любое отношение в бизнес-системе позволяет двустороннюю навигацию. Его можно, конечно, искусственно разорвать, но это не всегда удобно. Ну там накладная->клиент->список накладных->накладная. пипец.

И кто из них работает с системными ресурсами?

S>А! вот одновременно — неплохая идея. Поверх GC можно реализовать подсчет ссылок. Очень даже вполне.

Для этого надо хоть какието средства со стороны среды. Хотя и сейчас можно но на это смотреть будет страшно. Нужны смартпоинтеры.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 26.09.03 10:13
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.

Это значит что объект умрет тогда и только тогда когда в нем уже не будет необходимости не раньше и не позже.
Что не понятно?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[42]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 15:11
Оценка:
M>>Именно. Всё должно быть как можно проще.

WH>Вот именно все должно быть проще. Вот скажи мне какого черта я должен прописать создание десятка объектов (конструктор по умолчению которых мне прекрасно подходит) в конструкторе и удаление всех в деструкторе если я могу их лишь одан раз описать?


В конечном счёте для того, чтобы не нужно было заботится о циклических ссылках.

WH>А слабо integer by ref сделать?

M>>Именно, что слабо. Никому не нужная экзотика.
WH>Ну ладно не int а класс написаный неизвесно кем не извесно когда и менять его ты не можешь. Ы?

Тут и делать ничего не надо. Все классы в Дельфи byref.
... << RSDN@Home 1.1 beta 1 >>
Re[48]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 15:11
Оценка:
AK> делфи язык бизнес-апликаций, с++ язык системного уровня — но при этом он совершенно свободно может быть использован для наисания все-чего угодно...

Это "чего угодно" меня просто веселит. Вы, товарищи крутые программисты, bat-файлы тоже на C++ пишете? Или зашоренность до таких размеров ещё не разрослась?
... << RSDN@Home 1.1 beta 1 >>
Re[42]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 15:11
Оценка:
WF>>Судя по тому компилятору, который они сейчас попробовать дают, в Java будут на редкость отстойные шаблоны .

M>>Хе-хе. Мелочь, а приятно.


WH>Ну и нахрена нужны отмазки в место инструментов?


Ты не понял. Это я радуюсь, что злопакостным явщикам неприятности сыпятся. Микрософт, как это говорят, форева!
... << RSDN@Home 1.1 beta 1 >>
Re[42]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 15:11
Оценка:
M>>Ну, в Дельфи тоже можно много чего эмулировать. Те же шаблоны можно эмулировать.
WH> Это как?

Препроцессор написать. Object Pascal, кстати, очень легко поддаётся синтаксическому разбору. Есть бесплатные реализации.
... << RSDN@Home 1.1 beta 1 >>
Re[19]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 15:11
Оценка:
M>>Я не знаю, насколько STL зависит от платформы.
WH>STL от платформы не зависит вобще.

Это хорошо, если так. Видимо, ребята из Микрософта не были так в этом уверены.

WH>>>Слова человека не знающего о существовании такого понятия в STL как allocator.

M>>Для профессионального программиста на C++ ты делаешь удивительно тривиальные выводы. Да, я не знаю, что такое STL allocator. И именно поэтому, я не понимаю твоего аргумента
WH>Это такая дурь скармливается последним аргументом шаблона(обычно используется аллокатор по умолчанию) Короче можно заставить контейнер использовать тот распределитель памяти который тебе нужен.

Ага. Удобно.

WH>>>Но даже если забить на STL то ни что не мешает просто пользоваться всеми благами шаблонов.

M>>Думаю, без хороших библиотек шаблоны среднеполезны.
WH>Думаю без шаблонов хороших библиотек не напишешь.

Напоминаю, вопрос в том, стоит ли в драйверах использовать C++.
... << RSDN@Home 1.1 beta 1 >>
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 15:11
Оценка:
FWP> И если Modula-2 и TurboPascal — близняшки

Не может быть! Вроде, в Модуле какие-то существенные вещи были добавлены
... << RSDN@Home 1.1 beta 1 >>
Re[24]: По просьбам трудящихся: Delphi vs C++(VS)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 26.09.03 15:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>У мнея такое ощущение что кто-то чего-то сильно не понимает.

WH>Допустим у нас есть некий объект который держит ресурс. Этот объект использовало куча других и через некоторое время он перестал быть нужен. Вопрос как узнать когда именно нужно освободить ресурс, а если легика была довольно сложной? В конце концов после долгих мучений выяснится что оптимальным решением будет именно подсчет ссылок. А вот как его реализовать в .НЕТ чтобы не было мучительно больно при использовании это уже придется хорошо подумать.
WH>Хотя некоторые объекты (строки,...) лучше на GC.

Для этого существуют Синглетоны, Синглкалы и активированные клиентом объекты. Правда через MarshalByRefObject. При этом подсчет ссылок совершенно не нужен, особенно когда клиент отвалился. То, что следить за системными ресурсам стало сложнее это накладывает более продуманный подход к программированию. А выбор есть, только не тот к чему ты привык.
и солнце б утром не вставало, когда бы не было меня
Re[24]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 26.09.03 15:42
Оценка:
M>>Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.

WH>Это значит что объект умрет тогда и только тогда когда в нем уже не будет необходимости не раньше и не позже.

WH>Что не понятно?

Непонятно слово "необходимость".
... << RSDN@Home 1.1 beta 1 >>
Re[25]: По просьбам трудящихся: Delphi vs C++(VS)
От: _wqwa США  
Дата: 26.09.03 21:50
Оценка:
Здравствуйте, mihailik, Вы писали:

M>>>Какие-такие умные указатели? Мы опять скатываемся к тому, чтобы считать "детерменированное освобождение" сугубо Сишной конструкцией, не имеющей никакого смысла в других языках.


WH>>Это значит что объект умрет тогда и только тогда когда в нем уже не будет необходимости не раньше и не позже.

WH>>Что не понятно?

M>Непонятно слово "необходимость".

Ссылок не осталось. Необходимость есть, пока существуют ссылки. Ну хорошо, если тебе так нравится, пускай будет так: пока существуют сильные ссылки (strong references), которыми определяется семантика владения объектом.
Если ссылок на объект не осталось (ушли из поля видимости исполняемого в данный момент кода), он СРАЗУ ЖЕ будет прибит.

Пример:
0. Начало функции.
1. Создаем на куче объект0.
2. Заворачиваем его в смарт-поинтер.
3. Передаем смарт-поинтер объекту1,
4. передаем смарт-поинтер объекту2.
5. некие действия
6. конец функции.

Объект0 умрет в случае когда оба объекта 1 и 2 наиграются им, и выбросят.
В случае, если они наигрались им до завершения нашей функции, то он будет прибит при ее завершении.
Кто здесь?!
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.03 22:34
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Были еще Модула и (уже забыл Обтерон вроде) тоже ООП. Главное идеи и их преемственность. А так как я вырос еще из Виртовского Паскаля, то эти переходы для меня очень просты.


Оберон2. Жаль ты не видел это "объектной-ориентированнсоти".
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: По просьбам трудящихся: Delphi vs C++(VS)
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.09.03 22:34
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>Вирт создал не только Pascal. Были еще Modula, Modula-2, Modula-3. TurboPascal и Delphi много чего почерпнули из них.


Врд ли можно что-то почерпнуть из продуктов вышедших позже. Да и слава богу что не почепрнули. Уж очень своеобразное видение ОО у Вирта.

FWP> Создатели Delphi привнесли в язык много модных, но потенциально опасных вещей. Поэтому он и "плевался". И если Modula-2 и TurboPascal — близняшки, то Oberon-2 и Delphi7 — троюродные братья


Да как две капили воды и пластмассы.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: По просьбам трудящихся: Delphi vs C++(VS)
От: WFrag США  
Дата: 27.09.03 01:41
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Через примеры можно только описать, но нельзя определить.


Вообще-то примеры нужны для лучшего понимания... Чтобы разговор не превратился в совершенно оторванный флейм (правда, он уже превратился ). Собственно, для этого я их и пытался дать. Т.е на вопрос я давал конкретный пример и попытку определения.

M>Освобождение ДОЛЖНО зависеть от внешних к системе факторов. У объекта может быть несколько систем-"пользователей".


Хорошо, давай определимся, что я считаю системой и внешними факторами.

Весь программный комплекс — внутренняя система. Все библиотеки, все классы, объекты с которыми программа работает. Поэтому возможность смерти объекта не зависит от внешних факторов. GC — это внешний фактор, программа про него ничего не знает. И про память она ничего не знает.

Грубо говоря: Живут себе объекты, рождаются как-то, посылают сообщения друг другу. Иногда, когда про объект забывают, он через некоторое время загадочным образом умирает. Повлиять, когда он реально умрет другие объекты не могут. А вот в C++ жизнь объекта не зависит от внешних факторов, объекты как-то общаются друг с другом, и когда они договариваются о ненужности какого-либо объекта, они его убивают. Вот детерминированность в моем определении.
Re[12]: По просьбам трудящихся: Delphi vs C++(VS)
От: FWP Россия  
Дата: 29.09.03 04:41
Оценка:
Здравствуйте, VladD2, Вы писали:

FWP>>Вирт создал не только Pascal. Были еще Modula, Modula-2, Modula-3. TurboPascal и Delphi много чего почерпнули из них.

VD>Врд ли можно что-то почерпнуть из продуктов вышедших позже. Да и слава богу что не почепрнули. Уж очень своеобразное видение ОО у Вирта.
Понятие модулей появилось в TP4.5. Соответственно раздельная компиляция и смартлинкер. Открытые массивы, обрабoтчики исключений в Delphi.
А ООП по Вирту — это действительно своеобразная вещь. Но ведь Вирт, в отличие от WH не только декларирует афоризм Энштейна, но и старается воплощать его в жизнь.
К примеру, Oberon — это почти полностью его разработка. А вот Oberon-2 — делали сотрудники его лаборатории и вернули в язык многие вещи, которые Вирт выбраковал.
Re[12]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.09.03 10:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>Ага типа я в С++ не могу мыслить виртуально. Вся разница в том что в С++ у меня есть выбор и очень часто шаблон оказывается оптимальным решением, но иногда и виртуальность нужна.

А все твои примеры шаблонные. Кроме всего прочего, не слжно тойже M$ зделать генерилку исходников из шаблонов, и все нетовские проблемы исчезну. А так как мне приходится работать как с ранним так и споздним связыванием, смысла от шаблонов никакого.
WH>struct some
WH>{
WH>//...
WH>};
WH>struct some_dynamic_cmp
WH>{
WH> bool operator()(const some& lhs, const some& rhs)
WH> {
WH> //Тут сравниваем
WH> }
WH>};
WH>void main()
WH>{
WH> std::vector<some> some_vec;
WH> //Заполняем
WH> some_dynamic_cmp cmp;
WH> //Устанавлеваем правила сравнения
WH> std::sort(some_vec.begin(), some_vec.end(), cmp);
WH>}
WH>[/ccode]
WH>Все.
Твой пример из разряда раннего связывания, в отличие от моего. Приведи аналог моего примера с шаблонами.
и солнце б утром не вставало, когда бы не было меня
Re[13]: По просьбам трудящихся: Delphi vs C++(VS)
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.09.03 16:14
Оценка:
Здравствуйте, FWP, Вы писали:

FWP>К примеру, Oberon — это почти полностью его разработка. А вот Oberon-2 — делали сотрудники его лаборатории и вернули в язык многие вещи, которые Вирт выбраковал.


Но не все. При всей недоработанности Дельфий Обераон им в подметки не годится (когда нужно реальный код писать).
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[43]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 29.09.03 16:25
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Вот именно все должно быть проще. Вот скажи мне какого черта я должен прописать создание десятка объектов (конструктор по умолчению которых мне прекрасно подходит) в конструкторе и удаление всех в деструкторе если я могу их лишь одан раз описать?

M>В конечном счёте для того, чтобы не нужно было заботится о циклических ссылках.

Причем тут циклические ссылки если мне надо например пустой список строк создать?

modified by moderator. _MM_
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[49]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 29.09.03 16:25
Оценка:
Здравствуйте, mihailik, Вы писали:
M>Это "чего угодно" меня просто веселит. Вы, товарищи крутые программисты, bat-файлы тоже на C++ пишете? Или зашоренность до таких размеров ещё не разрослась?
Только если ты пишешь на дельфе
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 29.09.03 16:25
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>В место Thread.Sleep может быть любая операция прерывающая поток.

WH>>В реальной жизни на сервак который обрабатывает пользователей в отдельных потоках пришла бешеная нагрузка.
M>Ого, ты попробуй там while(true), тоже экстремальные ощущения.
ты чего постоянно дурочку валяешь? Это вполне нормальный код. В реальной жизни просто приперлись одновременно ~2000 клиентов и кирдык. Даже если поток будет отробатывать практически мнгновенно.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 29.09.03 16:25
Оценка:
Здравствуйте, mihailik, Вы писали:

M>Напоминаю, вопрос в том, стоит ли в драйверах использовать C++.

Напоминаю ответ: Почему бы и нет?
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Некоторые итоги:
От: WolfHound  
Дата: 30.09.03 07:21
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> А все твои примеры шаблонные. Кроме всего прочего, не слжно тойже M$ зделать генерилку исходников из шаблонов, и все нетовские проблемы исчезну. А так как мне приходится работать как с ранним так и споздним связыванием, смысла от шаблонов никакого.

Вот только если они будут только компаил тайм то толку от нх будет мало. Да и они уже есть МС++.

S>Твой пример из разряда раннего связывания, в отличие от моего. Приведи аналог моего примера с шаблонами.


#include "stdafx.h"
template<class T>
struct dynamic_cmp_t
{
private:
    struct member_ptr_cmp_t
    {
        typedef int T::* member_ptr_t;
        typedef int(*member_cmp_t)(const T&, const T&, member_ptr_t);
        template<class M>
        member_ptr_cmp_t(M T::* member)
            :ptr(reinterpret_cast<member_ptr_t>(member))
            ,cmp(&member_cmp<M>)
        {}
        template<class M>
        static int member_cmp(const T& lhs, const T& rhs, member_ptr_t ptr)
        {
            typedef M T::* member_t;
            member_t member=reinterpret_cast<member_t>(ptr);
            const M& l=lhs.*member;
            const M& r=rhs.*member;
            if(l<r)return -1;
            if(r<l)return 1;
            return 0;
        }
        int compare(const T& lhs, const T& rhs)const
        {
            return cmp(lhs, rhs, ptr);
        }
        member_ptr_t ptr;
        member_cmp_t cmp;
    };
    typedef std::vector<member_ptr_cmp_t>        vector_t;
    typedef typename vector_t::const_iterator    vector_iter_t;
    vector_t vector_;
public:
    void reset()
    {
        vector_.clear();
    }
    template<class M>
    void add(M T::* member)
    {
        vector_.push_back(member_ptr_cmp_t(member));
    }
    int operator()(const T& lhs, const T& rhs)const
    {
        for(vector_iter_t i=vector_.begin(), e=vector_.end();i!=e;++i)
            if(int res=i->compare(lhs, rhs))
                return res;
        return 0;
    }
#define DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(name, op)\
private:\
    struct name##_t\
    {\
        name##_t(const dynamic_cmp_t& cmp)\
            :cmp_(cmp)\
        {}\
        bool operator()(const T& lhs, const T& rhs)const\
        {\
            return cmp_(lhs, rhs) op 0;\
        }\
    private:\
        const dynamic_cmp_t& cmp_;\
    };\
public:\
    name##_t name()const\
    {\
        return name##_t(*this);\
    }\
    bool name(const T& lhs, const T& rhs)const\
    {\
        return name()(lhs, rhs);\
    }
DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(less, <)
DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(greater, >)
DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(less_equal, <=)
DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(greater_equal, >=)
DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(equal, ==)
DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(not_equal, !=)
#undef DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION
};
struct test
{
    test()
        :i1(rand())
        ,f1(rand())
        ,i2(rand())
    {}
    int i1;
    float f1;
    int i2;
};
int main()
{
    test test_arr[100];
    test_arr[2].f1=123;
    test_arr[3].f1=123;
    test_arr[4].f1=123;
    dynamic_cmp_t<test> cmp;
    cmp.reset();
    cmp.add(&test::f1);
    cmp.add(&test::i2);
    cmp.add(&test::i1);
    cmp.less(test_arr[1], test_arr[2]);
    cmp.greater(test_arr[1], test_arr[2]);
    cmp.less_equal(test_arr[1], test_arr[2]);
    cmp.greater_equal(test_arr[1], test_arr[2]);
    cmp.equal(test_arr[1], test_arr[2]);
    cmp.not_equal(test_arr[1], test_arr[2]);
    std::sort(test_arr, test_arr+100, cmp.less());
    std::sort(test_arr, test_arr+100, cmp.greater());
    return 0;
}

Ну и где тут ранние связование? Компатор собирается динамически.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 30.09.03 09:16
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>int main()

WH>{
WH> test test_arr[100];
WH> test_arr[2].f1=123;
WH> test_arr[3].f1=123;
WH> test_arr[4].f1=123;
WH> dynamic_cmp_t<test> cmp;
WH> cmp.reset();
WH> cmp.add(&test::f1);
WH> cmp.add(&test::i2);
WH> cmp.add(&test::i1);
WH> cmp.less(test_arr[1], test_arr[2]);
WH> cmp.greater(test_arr[1], test_arr[2]);
WH> cmp.less_equal(test_arr[1], test_arr[2]);
WH> cmp.greater_equal(test_arr[1], test_arr[2]);
WH> cmp.equal(test_arr[1], test_arr[2]);
WH> cmp.not_equal(test_arr[1], test_arr[2]);
WH> std::sort(test_arr, test_arr+100, cmp.less());
WH> std::sort(test_arr, test_arr+100, cmp.greater());
WH> return 0;
WH>}
WH>[/ccode]
WH>Ну и где тут ранние связование? Компатор собирается динамически.

Обрати внимание на мой код

TType = packed record
d:Integer;
b:Double;
end;
var a:array of Ttype;
ai:Array of integer;
fld:TFld;
Begin
Fld:=TUniversalMultiFld.CreateWithFldClass([TIntegerFld,TDoubleFld]);
Fld.SetCompareFields([Fld.Fields[1],Fld.Fields[0]]); // можно сделать только по индексам
SortArrayFld(a,Fld);

Fld.SetCompareFields([Fld.Fields[0]]); // можно сделать только по индексам
SortArrayFld(a,Fld);

fld.free;
fld:=TIntegerFld.Create;
SortArrayFld(ai,Fld);
Заполнение массивов опускаю.

итд итп.

Но нет китайских иероглифоф. А по писанине то же.
А если структура как в БД насчитывает 100 полей и нужно делать динамическую сортировку по 1, сразу по нескольким полям и нужно как в Ёкселе вывести массив динамически его отсортировать, произвести поиск итд.
и солнце б утром не вставало, когда бы не было меня
Re[16]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 30.09.03 12:09
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>К томуже std::sort работает с любым рандомакцесс итератором которыми также являются и указатели

S>> Но нет китайских иероглифоф. А по писанине то же.
WH>Ну и где ты нашол иероглифы?


WH>К томуже мне не надо следить за порядком полей в структуре, за типами полей, не надо писать TIntegerFld итп и для того чтобы поддерживалась сортировка по полю определенного типа надо чтобы для этого типа был определен оперетор < и все. А он определен для всех базовых типов, для std::string и в общем то для всех типов для которых имеет смысл сравнение.

S>> А если структура как в БД насчитывает 100 полей и нужно делать динамическую сортировку по 1, сразу по нескольким полям и нужно как в Ёкселе вывести массив динамически его отсортировать, произвести поиск итд.
WH>Какие проблемы?

Давай вспомним комбинаторику, сколько сочетаний возможно уже из 3. А из 4. И для всех них писать свои функции???? А если мне структура записи известна только на этапе выполнения, как с таблицами БД и зачем мне типизация в данном случае.
Честно говоря единственно, что мне в Delphi не хватает Это Inline. Все остальное так же как ит ты пишу заготовки и Copy-Paste-Replase или собственную генерилку объектов на худой конец.
и солнце б утром не вставало, когда бы не было меня
Re[18]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 01.10.03 09:41
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>> Давай вспомним комбинаторику, сколько сочетаний возможно уже из 3. А из 4.

WH>Давай вспомним программирование и подумаем причем тут комбинаторика?
Честно говоря давно не занимался комбинаторикой, но
из 2=2*1!+2! (количество одинарных и 2 х взаимодействий)=4
из 3=3*1!+3*2!+3!=15
из 4=4*1!+4*2!+4*3!+4!=75
итд.


S>>И для всех них писать свои функции????

WH>Зачем? Я компатор полностью динамичеки собрать могу.

S>>А если мне структура записи известна только на этапе выполнения,

WH>И что? Поставь конкретную задачу получишь конкретный ответ. Но ни каких проблем я не вижу.

из 2=2*1!+2! (количество одинарных и 2 х взаимодействий)=4
из 3=3*1!+3*2!+3!=15
из 4=4*1!+4*2!+4*3!+4!=75
итд.

Задача такая отобразить любую таблицу БД информация о которой известна только на этапе выполнения, отредактировать и отсортировать произвести поиск в любых комбинациях полей. Тоже относится и к любым массивам.
Через филды это лекго делается и шаблоны мне не нужны.
Да и применение очень легко для любого конечного пользователя.
см.
http://www.rsdn.ru/Forum/Message.aspx?mid=396688&amp;only=1
Автор: Serginio1
Дата: 30.09.03


оттуда
WH> std::sort(test_arr, test_arr+100, cmp.less()); /
WH> std::sort(test_arr, test_arr+100, cmp.greater());
WH> return 0;
WH>}
WH>[/ccode]
WH>Ну и где тут ранние связование? Компатор собирается динамически.
У тебя есть одно маленькое премущество, мое ну очень слабое знание шаблонов и C++. Но
Смотрим.
dynamic_cmp_t<test> cmp;

Откуда тебе известна структура Test, если вопрос стоял о позднем связывании?????

И интересно сравнить по скорости.
А как ты не крути с шаблонами, на нижнем уровне все происходит без типов и можно смотреть ассемблерный код. А как мне его добиться мои личные проблемы. А виртуалльные методы позволяют легко добиваться цели при получении типа записи в момент выполнения программы.
И уверяю тебя регулярные выражения, шаблоны, макросы,Редакторы компонентов, SQL к чистому программированию никакого отношения не имеют.
и солнце б утром не вставало, когда бы не было меня
Re[19]: Некоторые итоги:
От: WolfHound  
Дата: 01.10.03 11:11
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Давай вспомним комбинаторику, сколько сочетаний возможно уже из 3. А из 4.

WH>>Давай вспомним программирование и подумаем причем тут комбинаторика?
S> Честно говоря давно не занимался комбинаторикой, но
МЛИН да знаю я комбинаторику. В крайнем случае в справочнике уточню.
Ты на вопрос ответь: Кокого черта ты ее сюда вобще приплел?

S> Задача такая отобразить любую таблицу БД информация о которой известна только на этапе выполнения, отредактировать и отсортировать произвести поиск в любых комбинациях полей.

В чем проблема? В каком виде поступают данные? Как передается информация о типах?
S>Тоже относится и к любым массивам.
К каким еще массивам?
S> Через филды это лекго делается и шаблоны мне не нужны.
Вот только за меня все филды сгенерит компилятор а тебе придется действовать через задницу простите через CPR
S>Да и применение очень легко для любого конечного пользователя.
S>см.
S>http://www.rsdn.ru/Forum/Message.aspx?mid=396688&amp;only=1
Автор: Serginio1
Дата: 30.09.03

Тебе второй раз обьяснить почему для типов известных на стадии компиляции это хреновое решение? А в твоем примере все извено на стадии компиляции.

S> Откуда тебе известна структура Test, если вопрос стоял о позднем связывании?????

Если мне не изменяет память стояла задача динамически менять компатор для какойлибо структуры.

S> А как ты не крути с шаблонами, на нижнем уровне все происходит без типов и можно смотреть ассемблерный код. А как мне его добиться мои личные проблемы. А виртуалльные методы позволяют легко добиваться цели при получении типа записи в момент выполнения программы.

Я не понял мы вобще о чем разговариваем? О том как получить кучу асма? Или о том на коком языке писать проще?
S> И уверяю тебя регулярные выражения, шаблоны, макросы,Редакторы компонентов, SQL к чистому программированию никакого отношения не имеют.
Ну чегоже ты тогда в машинных кодах не пишешь?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 01.10.03 15:38
Оценка:
Здравствуйте, WolfHound, Вы писали:

Поясни несколько моментов, так как мои познания в С++ очень поверхностны.
WH>
WH>
WH>#include "stdafx.h"
WH>template<class T>
WH>struct dynamic_cmp_t
WH>{
WH>private:
WH>    struct member_ptr_cmp_t
WH>    {
WH>        typedef int T::* member_ptr_t;
                  Тоесть эту запись нужно воспринмать как ссылка на поле????
                  Почему int???? Или это смещение записи???? Или и тип и смещение вместе взятое.
                    

WH>        typedef int(*member_cmp_t)(const T&, const T&, member_ptr_t);
WH>        template<class M>
WH>        member_ptr_cmp_t(M T::* member)
WH>            :ptr(reinterpret_cast<member_ptr_t>(member))
WH>            ,cmp(&member_cmp<M>) Это ссылка на функцию сравнения???
                    WH>        {}
WH>        template<class M>
WH>        static int member_cmp(const T& lhs, const T& rhs, member_ptr_t ptr)
WH>        {
WH>            typedef M T::* member_t;
WH>            member_t member=reinterpret_cast<member_t>(ptr);
WH>            const M& l=lhs.*member;
WH>            const M& r=rhs.*member;
WH>            if(l<r)return -1;
WH>            if(r<l)return 1;
WH>            return 0;
WH>        }
WH>        int compare(const T& lhs, const T& rhs)const
WH>        {
WH>            return cmp(lhs, rhs, ptr);
WH>        }
WH>        member_ptr_t ptr;
WH>        member_cmp_t cmp;
WH>    };
WH>    typedef std::vector<member_ptr_cmp_t>        vector_t;
WH>    typedef typename vector_t::const_iterator    vector_iter_t;
WH>    vector_t vector_;
WH>public:
WH>    void reset()
WH>    {
WH>        vector_.clear();
WH>    }
WH>    template<class M>
WH>    void add(M T::* member)
WH>    {
WH>        vector_.push_back(member_ptr_cmp_t(member));
             Тобишь вызываем конструктор member_ptr_cmp_t с параметром member

WH>    }
WH>    int operator()(const T& lhs, const T& rhs)const
WH>    {
WH>        for(vector_iter_t i=vector_.begin(), e=vector_.end();i!=e;++i)
WH>            if(int res=i->compare(lhs, rhs))
WH>                return res;
WH>        return 0;
WH>    }
WH>#define DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(name, op)\
WH>private:\
WH>    struct name##_t\
WH>    {\
WH>        name##_t(const dynamic_cmp_t& cmp)\
WH>            :cmp_(cmp)\
WH>        {}\
WH>        bool operator()(const T& lhs, const T& rhs)const\
WH>        {\
WH>            return cmp_(lhs, rhs) op 0;\
WH>        }\
WH>    private:\
WH>        const dynamic_cmp_t& cmp_;\
WH>    };\
WH>public:\
WH>    name##_t name()const\
WH>    {\
WH>        return name##_t(*this);\
WH>    }\
WH>    bool name(const T& lhs, const T& rhs)const\
WH>    {\
WH>        return name()(lhs, rhs);\
WH>    }

 Все что выше для меня вообще поный лес.
WH>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(less, <)
WH>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(greater, >)
WH>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(less_equal, <=)
WH>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(greater_equal, >=)
WH>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(equal, ==)
WH>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(not_equal, !=)
WH>#undef DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION
WH>};
WH>struct test
WH>{
WH>    test()
WH>        :i1(rand())
WH>        ,f1(rand())
WH>        ,i2(rand())
WH>    {}
WH>    int i1;
WH>    float f1;
WH>    int i2;
WH>};
WH>int main()
WH>{
WH>    test test_arr[100];
WH>    test_arr[2].f1=123;
WH>    test_arr[3].f1=123;
WH>    test_arr[4].f1=123;
WH>    dynamic_cmp_t<test> cmp;
WH>    cmp.reset();
WH>    cmp.add(&test::f1);
WH>    cmp.add(&test::i2);
WH>    cmp.add(&test::i1);

 Создаешь спискок классов отвечающие за Поля???
WH>    cmp.less(test_arr[1], test_arr[2]);
WH>    cmp.greater(test_arr[1], test_arr[2]);
WH>    cmp.less_equal(test_arr[1], test_arr[2]);
WH>    cmp.greater_equal(test_arr[1], test_arr[2]);
WH>    cmp.equal(test_arr[1], test_arr[2]);
WH>    cmp.not_equal(test_arr[1], test_arr[2]);
   Не до конца понял.
 
WH>    std::sort(test_arr, test_arr+100, cmp.less());
WH>    std::sort(test_arr, test_arr+100, cmp.greater());
WH>    return 0;
WH>}
WH>

WH>Ну и где тут ранние связование? Компатор собирается динамически.
Если я все правильно понял, то разницы в моем коде и твоем никакой. Правда в твоем случае без виртуальных классов только за счет функции сравнения member_cmp_t. Кроме
cmp.add(&test::f1);
WH> cmp.add(&test::i2);
WH> cmp.add(&test::i1);
По сути ты записываешь описание полей?????
В паскале пришлось бы делать с твоей аналогией
cmp.add(@test.f1,TypeOf(test.f1)); Забыл как в RTTI TypeOf, но на C# прямо из типа я могу получить всю информацию о записи и соотвественно прописать все филды.

Но как быть если у тебя не известна структура test на этапе компиляции.
Конечно не разобрался но по сути твой и мой код индентичны.
Слишком много иероглифоф.
Врага надо знать в лицо (С++). Будь добр ответь на ламерские вопросы.
и солнце б утром не вставало, когда бы не было меня
Re[20]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 01.10.03 15:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

S>> Откуда тебе известна структура Test, если вопрос стоял о позднем связывании?????

WH>Если мне не изменяет память стояла задача динамически менять компатор для какойлибо структуры.
В том числе было понятие позднее связываие. Это когда данные о структуре получаешь во время выполнения программы.

S>> А как ты не крути с шаблонами, на нижнем уровне все происходит без типов и можно смотреть ассемблерный код. А как мне его добиться мои личные проблемы. А виртуалльные методы позволяют легко добиваться цели при получении типа записи в момент выполнения программы.

WH>Я не понял мы вобще о чем разговариваем? О том как получить кучу асма? Или о том на коком языке писать проще?
На Delphi проще при достижении тех же результатов. (Для меня лично)
S>> И уверяю тебя регулярные выражения, шаблоны, макросы,Редакторы компонентов, SQL к чистому программированию никакого отношения не имеют.
WH>Ну чегоже ты тогда в машинных кодах не пишешь?
Только на заре моей юности. Но мой код ближе к человеческому, а не аналог регулярных выражений.

Лучше ответь на другой вопрос, что бы не повторяться здесь. Немного поначалу не разобрался, поэтому и комбинаторику вспомнил. Поэтому большая просьба ответить.
и солнце б утром не вставало, когда бы не было меня
Re[20]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 01.10.03 16:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Тебе второй раз обьяснить почему для типов известных на стадии компиляции это хреновое решение? А в твоем примере все извено на стадии компиляции.


Но применять я могу как посчитаю нужным. Но при сортировке по полям ты по сути приходишь к тем же виртуальным методам. И твой код не отличается от моего.

S>> А как ты не крути с шаблонами, на нижнем уровне все происходит без типов и можно смотреть ассемблерный код. А как мне его добиться мои личные проблемы. А виртуалльные методы позволяют легко добиваться цели при получении типа записи в момент выполнения программы.

WH>Я не понял мы вобще о чем разговариваем? О том как получить кучу асма? Или о том на коком языке писать проще?
В итоге получить кучу асма. И в С++ ее (кучи) при активном применении шаблонов окажется намного больше. А Проще писать на Родном Языке.
На данном этапе я доказываю, что без шаблонов дышится очень легко, а ты обратное а в итоге приходим к одному и томуже. Ладно закрываю этот разговор. Ответь пожалуйста только на вопросы по синтаксису С++. Я даже книгу из-за тебя по С++ купил 900 стр. Правда за 2 дня прочитал, но информации мало.
и солнце б утром не вставало, когда бы не было меня
Re[20]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 01.10.03 16:27
Оценка:
Здравствуйте, WolfHound, Вы писали:


S>> Задача такая отобразить любую таблицу БД информация о которой известна только на этапе выполнения, отредактировать и отсортировать произвести поиск в любых комбинациях полей.

WH>В чем проблема? В каком виде поступают данные? Как передается информация о типах?

А ты ни разу даже с ДБФ файлами не работал???? Заголовочная часть в том числе включает информацию о записи. Или Ёксель сначала идет тип потом данные итд. Тот же Вариант.
А дальше идут последовательно данные по аналогии смассивом, и засасывая в память та же работа как с массивом.
S>>Тоже относится и к любым массивам.
WH>К каким еще массивам?
К последовательному набору записей, он же массив
S>> Через филды это лекго делается и шаблоны мне не нужны.
WH>Вот только за меня все филды сгенерит компилятор а тебе придется действовать через задницу простите через CPR

Один раз извини через задницу (В Net сразу позаботились). За то потом на всю жизнь.
и солнце б утром не вставало, когда бы не было меня
Re[15]: Некоторые итоги:
От: WolfHound  
Дата: 02.10.03 04:52
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, WolfHound, Вы писали:


S> Поясни несколько моментов, так как мои познания в С++ очень поверхностны.

WH>>
WH>>
WH>>#include "stdafx.h"
WH>>template<class T>
WH>>struct dynamic_cmp_t
WH>>{
WH>>private:
WH>>    struct member_ptr_cmp_t
WH>>    {
WH>>        typedef int T::* member_ptr_t;
S>                  Тоесть эту запись нужно воспринмать как ссылка на поле????
S>                  Почему int???? Или это смещение записи???? Или и тип и смещение вместе взятое.
WH>>

Это указатель на поле типа int. В данном случае пришлось прибегнуть к к небольшому хаку. В С++ размер указатель на поле одного типа всегда равен размеру указателя на поле любого другого типа. Можно было и без хака но тогда пришлось бы использовать динамическую память, а это лишние тормоза.
WH>>
WH>>        typedef int(*member_cmp_t)(const T&, const T&, member_ptr_t);
WH>>        template<class M>
WH>>        member_ptr_cmp_t(M T::* member)
WH>>            :ptr(reinterpret_cast<member_ptr_t>(member))
WH>>

Тут мы говорим компилятору что он должен считать указатель на поле какого либо типа указателем на поле типа int
WH>>
WH>>            ,cmp(&member_cmp<M>) Это ссылка на функцию сравнения???
                    WH>>        {}
WH>>

Да причем создаем функцию для сравнения полей определенного типа.
WH>>
WH>>        template<class M>
WH>>        static int member_cmp(const T& lhs, const T& rhs, member_ptr_t ptr)
WH>>        {
WH>>            typedef M T::* member_t;
WH>>            member_t member=reinterpret_cast<member_t>(ptr);
WH>>

Так как нам известен факлический тип поля возвращаем его указателю.
WH>>
WH>>            const M& l=lhs.*member;
WH>>            const M& r=rhs.*member;
WH>>

Получаем ссылки на конкретные поля(только для удобства компилятор все это выкинет)
WH>>
WH>>            if(l<r)return -1;
WH>>            if(r<l)return 1;
WH>>

Обрати внимание использован только оператор <
WH>>
WH>>            return 0;
WH>>        }
WH>>        int compare(const T& lhs, const T& rhs)const
WH>>        {
WH>>            return cmp(lhs, rhs, ptr);
WH>>        }
WH>>        member_ptr_t ptr;
WH>>        member_cmp_t cmp;
WH>>    };
WH>>    typedef std::vector<member_ptr_cmp_t>        vector_t;
WH>>    typedef typename vector_t::const_iterator    vector_iter_t;
WH>>    vector_t vector_;
WH>>public:
WH>>    void reset()
WH>>    {
WH>>        vector_.clear();
WH>>    }
WH>>    template<class M>
WH>>    void add(M T::* member)
WH>>    {
WH>>        vector_.push_back(member_ptr_cmp_t(member));
S>             Тобишь вызываем конструктор member_ptr_cmp_t с параметром member
WH>>

Да. Сторого говоря в данном случае member_ptr_cmp_t не нужен компилятор может найти его сам ибо контейнер строго типизированый просто я сначала хотел вызывать его с двумя параметрами но потом передумал, а стереть забыл.
WH>>
WH>>    }
WH>>    int operator()(const T& lhs, const T& rhs)const
WH>>    {
WH>>        for(vector_iter_t i=vector_.begin(), e=vector_.end();i!=e;++i)
WH>>            if(int res=i->compare(lhs, rhs))
WH>>                return res;
WH>>        return 0;
WH>>    }
WH>>#define DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(name, op)\
WH>>private:\
WH>>    struct name##_t\
WH>>    {\
WH>>        name##_t(const dynamic_cmp_t& cmp)\
WH>>            :cmp_(cmp)\
WH>>        {}\
WH>>        bool operator()(const T& lhs, const T& rhs)const\
WH>>        {\
WH>>            return cmp_(lhs, rhs) op 0;\
WH>>        }\
WH>>    private:\
WH>>        const dynamic_cmp_t& cmp_;\
WH>>    };\
WH>>public:\
WH>>    name##_t name()const\
WH>>    {\
WH>>        return name##_t(*this);\
WH>>    }\
WH>>    bool name(const T& lhs, const T& rhs)const\
WH>>    {\
WH>>        return name()(lhs, rhs);\
WH>>    }
S> Все что выше для меня вообще поный лес.
WH>>

Это макрос для генерации функций создания компатора и сравнения двух структур
WH>>
WH>>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(less, <)
WH>>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(greater, >)
WH>>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(less_equal, <=)
WH>>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(greater_equal, >=)
WH>>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(equal, ==)
WH>>DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION(not_equal, !=)
WH>>#undef DYNAMIC_CMP_T_DEFINE_CMP_FUNCTION
WH>>};
WH>>struct test
WH>>{
WH>>    test()
WH>>        :i1(rand())
WH>>        ,f1(rand())
WH>>        ,i2(rand())
WH>>    {}
WH>>    int i1;
WH>>    float f1;
WH>>    int i2;
WH>>};
WH>>int main()
WH>>{
WH>>    test test_arr[100];
WH>>    test_arr[2].f1=123;
WH>>    test_arr[3].f1=123;
WH>>    test_arr[4].f1=123;
WH>>    dynamic_cmp_t<test> cmp;
WH>>    cmp.reset();
WH>>    cmp.add(&test::f1);
WH>>    cmp.add(&test::i2);
WH>>    cmp.add(&test::i1);
S> Создаешь спискок классов отвечающие за Поля???
WH>>

Строго говоря ни какие классы тут не создаются. Но создаются функции сравнения для каждого типа поля те в данном случае компилятор создаст две функции сравнения для полей i1 и i2 будут использована одна функция.
WH>>
WH>>    cmp.less(test_arr[1], test_arr[2]);
WH>>    cmp.greater(test_arr[1], test_arr[2]);
WH>>    cmp.less_equal(test_arr[1], test_arr[2]);
WH>>    cmp.greater_equal(test_arr[1], test_arr[2]);
WH>>    cmp.equal(test_arr[1], test_arr[2]);
WH>>    cmp.not_equal(test_arr[1], test_arr[2]);
S>   Не до конца понял.
WH>>

Это так. Стереть забыл. Просто проверял работоспасобность функций сравнения для двух структур.
WH>>
WH>>    std::sort(test_arr, test_arr+100, cmp.less());
WH>>    std::sort(test_arr, test_arr+100, cmp.greater());
WH>>    return 0;
WH>>}
WH>>

WH>>Ну и где тут ранние связование? Компатор собирается динамически.
S> Если я все правильно понял, то разницы в моем коде и твоем никакой.
Ну да так по мелочи у меня весь фреймворк для поддержки любых типов меньше чем твой без поддержки типов вобще их еще отдельно прописывать надо.
S>Правда в твоем случае без виртуальных классов только за счет функции сравнения member_cmp_t. Кроме
Что дает некоторое преймущуство в скорости не находишь?
S> cmp.add(&test::f1);
WH>> cmp.add(&test::i2);
WH>> cmp.add(&test::i1);
S> По сути ты записываешь описание полей?????
Я записываю лишь смещения полей в структуре, а компилятор генерит всю инфраструктуру по мере необходимости.
S> В паскале пришлось бы делать с твоей аналогией
S>cmp.add(@test.f1,TypeOf(test.f1));
И все в рантайме, а если новый тип появится?
S>Забыл как в RTTI TypeOf, но на C# прямо из типа я могу получить всю информацию о записи и соотвественно прописать все филды.
.НЕТ это отдельная история там вобще все подругому а тут мы разговариваем не о нем, а о C++ и Delphi

S> Но как быть если у тебя не известна структура test на этапе компиляции.

Надо знать КОНКРТНЫЙ формат информации о типах полей. К томуже в реальной жизни в 99% случаев все извесно компилятору
S> Конечно не разобрался но по сути твой и мой код индентичны.
Ну если не считать то что твой код не типизирован, с ним больше гемороя при поддержке, он в несколько раз больше то можно сказать что да
S> Слишком много иероглифоф.
А у тебя слишком много извратов.
S> Врага надо знать в лицо (С++). Будь добр ответь на ламерские вопросы.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: По просьбам трудящихся: Delphi vs C++(VS)
От: _Obelisk_ Россия http://www.ibm.com
Дата: 02.10.03 07:54
Оценка:
Здравствуйте, mihailik, Вы писали:


M>Освобождение ДОЛЖНО зависеть от внешних к системе факторов. У объекта может быть несколько систем-"пользователей".


А что делать в случае активных объектов и асинхронного общения ?
У объекта может не быть пользователей, а он продолжает работать, работать и работать... и убивать его нельзя.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[16]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.10.03 11:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

Большое спасибо. Разобрался.
S>> Но как быть если у тебя не известна структура test на этапе компиляции.
WH>Надо знать КОНКРТНЫЙ формат информации о типах полей. К томуже в реальной жизни в 99% случаев все извесно компилятору.

Сразу видно не работал с БД и другими таблицами типа Ёкселя. А там твой подход с шаблонами не проходит.
Вернее если структура таблицы БД известна заранее, то проходит, но есть более сложные иерархические структуры и приходится писать единого нетипизированного предка, а над ним уже делать типизированные объекты, но предок практически реализует весь код, а надстроечные дают типизацию, и при этом код остается компактным.И надо отметить, виртуальные вызовы не так уж сильно и тормозят.
S>> Конечно не разобрался но по сути твой и мой код индентичны.
WH>Ну если не считать то что твой код не типизирован, с ним больше гемороя при поддержке, он в несколько раз больше то можно сказать что да
WH>А у тебя слишком много извратов.
Да Вроде обычный код, только ближе к действительному генерируемому коду компилятором.

Заметь я не против Шаблонов, но и без них можно преспокойно обходится. В Delphi они появятся в обязательном порядке, т.к. они внедряются в Net, но не такие как в С++.
и солнце б утром не вставало, когда бы не было меня
Re[17]: Некоторые итоги:
От: WolfHound  
Дата: 06.10.03 11:01
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Сразу видно не работал с БД и другими таблицами типа Ёкселя.

Давай не будем столь категоричны ладно. Я примо сейчас работаю с MSSQL через ADO
S>А там твой подход с шаблонами не проходит.
Еще как подходит. Немного в другой форме но прекрасно подходит.
S> Вернее если структура таблицы БД известна заранее, то проходит, но есть более сложные иерархические структуры и приходится писать единого нетипизированного предка, а над ним уже делать типизированные объекты, но предок практически реализует весь код, а надстроечные дают типизацию, и при этом код остается компактным.И надо отметить, виртуальные вызовы не так уж сильно и тормозят.
То есть всетаки изветна? А даже если и нет то шаблоны всеравно сократят работу и сильно.

S> Да Вроде обычный код, только ближе к действительному генерируемому коду компилятором.

Ну и нафига ручками генерить то что может сделать компилятор? Если уж до конца следовать этому принципу то тогда надо писать прямо в машинных кодах.

S> Заметь я не против Шаблонов, но и без них можно преспокойно обходится. В Delphi они появятся в обязательном порядке, т.к. они внедряются в Net, но не такие как в С++.

Это не шаболоны. Это отмазка для галочки.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 06.10.03 12:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


S>> Сразу видно не работал с БД и другими таблицами типа Ёкселя.

WH>Давай не будем столь категоричны ладно. Я примо сейчас работаю с MSSQL через ADO
Во во Ado и прочие посредники. Иногда и слокальными таблицами не грех поработать.
S>>А там твой подход с шаблонами не проходит.
WH>Еще как подходит. Немного в другой форме но прекрасно подходит.
Проходит только на полвину. Все равно придешь к виртуальным методам.
S>> Вернее если структура таблицы БД известна заранее, то проходит, но есть более сложные иерархические структуры и приходится писать единого нетипизированного предка, а над ним уже делать типизированные объекты, но предок практически реализует весь код, а надстроечные дают типизацию, и при этом код остается компактным.И надо отметить, виртуальные вызовы не так уж сильно и тормозят.
WH>То есть всетаки изветна? А даже если и нет то шаблоны всеравно сократят работу и сильно.
Один раз создав по шаблонному методу CPR прекрасно сокращают работу.
И не всегда известна заранее информация. Но даже когда и известна, все равно лучше выстроить иерархию над базовыми нетипизированными объектами, для компактности кода и более простого переопределения за счет наследования.

S>> Да Вроде обычный код, только ближе к действительному генерируемому коду компилятором.

WH>Ну и нафига ручками генерить то что может сделать компилятор? Если уж до конца следовать этому принципу то тогда надо писать прямо в машинных кодах.
Тоже не грех оптимизируя под определенные команды. Как не расхваливай компилятор С++ а ассемблерных вставок там тоже предостаточно.
S>> Заметь я не против Шаблонов, но и без них можно преспокойно обходится. В Delphi они появятся в обязательном порядке, т.к. они внедряются в Net, но не такие как в С++.
WH>Это не шаболоны. Это отмазка для галочки.
Это твоя точка зрения, но она одна из многих. Шаблоны могут приносить больше вреда в ситуациях где предпочтительней наследование с переопределением виртуальныз методов. Шаблоны подменяют чистое ООП, но очень полезны для создания быстрых типизированных объектов на основе заготовок. Но на мышление сильно влияют применяемые инструменты.
и солнце б утром не вставало, когда бы не было меня
Re[19]: Некоторые итоги:
От: WolfHound  
Дата: 07.10.03 05:16
Оценка:
Здравствуйте, Serginio1, Вы писали:

WH>>Давай не будем столь категоричны ладно. Я примо сейчас работаю с MSSQL через ADO

S> Во во Ado и прочие посредники. Иногда и слокальными таблицами не грех поработать.
Ты хочешь сказать что ручками читаешь xls файлы?

WH>>То есть всетаки изветна? А даже если и нет то шаблоны всеравно сократят работу и сильно.

S> Один раз создав по шаблонному методу CPR прекрасно сокращают работу.
А потом понадобилась еще функциональность, а потом нашлась ошибка,....
S>И не всегда известна заранее информация. Но даже когда и известна, все равно лучше выстроить иерархию над базовыми нетипизированными объектами, для компактности кода и более простого переопределения за счет наследования.
Одно другого не отменяет.

S> Тоже не грех оптимизируя под определенные команды. Как не расхваливай компилятор С++ а ассемблерных вставок там тоже предостаточно.

Где? В моих программах даже критичных к производительности нет ни одной асмовой вставки. Оптимизатор зверь.

S> Это твоя точка зрения, но она одна из многих. Шаблоны могут приносить больше вреда в ситуациях где предпочтительней наследование с переопределением виртуальныз методов. Шаблоны подменяют чистое ООП, но очень полезны для создания быстрых типизированных объектов на основе заготовок. Но на мышление сильно влияют применяемые инструменты.

Ну и зачем их тогда вобще вводить если от них вреда больше чем пользы? А зачем нужна перегрузко операторов если можно для класса студент определить оператор сложения? А зачем нужен while если можно поставить неверное условие и цикл будет выполнятся вечно? А зачем.....
И вобще пишите на брейнфаке ибо там каждый значит ровно то что он значит и ни чего больше.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.10.03 11:29
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:


WH>>>Давай не будем столь категоричны ладно. Я примо сейчас работаю с MSSQL через ADO

S>> Во во Ado и прочие посредники. Иногда и слокальными таблицами не грех поработать.
WH>Ты хочешь сказать что ручками читаешь xls файлы?

C MSSQL, не работаю а c DBF очень часто, т.к. основное мое занятие 1С (дбф версии).

WH>>>То есть всетаки изветна? А даже если и нет то шаблоны всеравно сократят работу и сильно.

S>> Один раз создав по шаблонному методу CPR прекрасно сокращают работу.
WH>А потом понадобилась еще функциональность, а потом нашлась ошибка,....
Ну TFild и их наследники в Delphi очень давно. Тоже можно сказать и об ADO.

S>>И не всегда известна заранее информация. Но даже когда и известна, все равно лучше выстроить иерархию над базовыми нетипизированными объектами, для компактности кода и более простого переопределения за счет наследования.

WH>Одно другого не отменяет.

S>> Тоже не грех оптимизируя под определенные команды. Как не расхваливай компилятор С++ а ассемблерных вставок там тоже предостаточно.

WH>Где? В моих программах даже критичных к производительности нет ни одной асмовой вставки. Оптимизатор зверь.
А какже memcopy. Она на чистом С++ написана. Огромное количество низкоуровневых функций на асме.

WH>И вобще пишите на брейнфаке ибо там каждый значит ровно то что он значит и ни чего больше.

Все убедил. Ухожу обогащать. У меня диплом специалиста по ОБОГАЩЕНИЮ руд цветных металлов.
А что такое брейнфак не знаю.
Но уверяю тебя ты слишком переоцениваешь роль шаблонов. Все закрываю тему.
и солнце б утром не вставало, когда бы не было меня
Re[21]: Некоторые итоги:
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 07.10.03 12:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

на последок
http://info.borland.ru/events/open_letter/index.html
http://www.osp.ru/os/2003/09/004_5.htm
и солнце б утром не вставало, когда бы не было меня
Re[30]: По просьбам трудящихся: Delphi vs C++(VS)
От: vvs86 Великобритания  
Дата: 08.10.03 11:10
Оценка:
WH>>>Слабо на дельфях написить такого помошника?
A>>Может и нет, если постановку задачи сделать словами, или хотя бы на C#. А то слова вроде знакомые, а вместе — чехарда в голове.
WH>Ни на дельфе ни на шарпе не реализуемо.

A zachem ono v .NET nado — u nas reflection i GC
Re[17]: По просьбам трудящихся: Delphi vs C++(VS)
От: vvs86 Великобритания  
Дата: 08.10.03 11:18
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>Нука изобрази аналог на дельфях.

WH>>
WH>>    std::sort(int_arr, int_arr+N);
WH>>    std::sort(float_arr, float_arr+N);
WH>>    std::sort(double_arr, double_arr+N);
WH>>    std::sort(string_arr, string_arr+N);
WH>>    return 0;
WH>>}
WH>>


M>Я вот не знаком с std::sort. Что такое этот код?


M>Сортировка и в Дельфи есть. Если нужно сортировать объекты некоторого типа, пишем функцию сравнения — и передаём задачу в функции стандартной библиотеки.


M>Если ты имеешь ввиду именно простую форму записи, тогда да. В этом случае запись на C++ действительно компактнее и проще. Но это частный случай, в реальных программах сишный код наоборот очень забористый.


WH>>Заметь объекты разного размера и природы. А тагже мы не получаем никакого оверхеда.


M>В Дельфе тоже никакого оверхеда. Разве что, возможно, лишний уровень indirection, который в случае с шаблонами, возможно, компилятор исключит.


M>Ну, это оверхед просто гигантский. Особенно будет заметно на реальных задачах.


WH>>Ну окошки на дельфе рисовать это нормально но писать логику


M>Да уж, логику-то точно в сях писать хреново. Кто потом её читать будет, эту вот логику?


M>На сях нужно системные примочки делать, всякие критичные места. А логику нужно делать на таком языке, чтоб любой чужой человек прочитал с листа. К примеру, C#, Дельфи. На худой конец, VB.


U C# pljusovoj sintaksis
Re[18]: По просьбам трудящихся: Delphi vs C++(VS)
От: ArtDenis Россия  
Дата: 08.10.03 11:58
Оценка:
Здравствуйте, vvs86, Вы писали:

V>U C# pljusovoj sintaksis


С каких это пор ??? Больше похоже на яву
... << RSDN@Home 1.1 beta 1 >>
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[31]: По просьбам трудящихся: Delphi vs C++(VS)
От: WolfHound  
Дата: 08.10.03 16:10
Оценка:
Здравствуйте, vvs86, Вы писали:

WH>>Ни на дельфе ни на шарпе не реализуемо.

V> A zachem ono v .NET nado — u nas reflection i GC
Ну рефлекшен тут вобще ни какой пяткой и если мне не изменяет скалероз то ГЦ не контролирует этот аллокатор.
... << RSDN@Home 1.1 beta 2 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: По просьбам трудящихся: Delphi vs C++(VS)
От: Viktor Denk Германия  
Дата: 03.12.03 16:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:


DOO>>И современные разработки продолжают вести на C. И вообще все unix'оиды не признают C++, нас препод долго обсмеивал за то, что на парах по Linux'у мы пытались писать программки с использованием new и т.п. И утверждал при этом, что лишь С достоин существования. Вот так.

WH>Давай его сюда. Сначала я ему обьясню почему С++ круче чем С, а потом Влад и AVK почему надо все бросать и писать на C#.

Smeshno, esli by ne bylo tak grustno. Nu ljudi dobrye — eto zhe ne religioznye voprosy: verish' kontra ne verish', ili kishki vyrezhu. C/C++ ne luchshe Delphi, no i Delphi ne luchshe C/C++. Eto raznye jazyki u nix raznye oblasti i dlja raznyx zadach. Da i dlja raznyx ljudej tozhe. I ja soglasen tol'ko s odnim vyskazyvaniem ( prosti uzhe ne pomnju kto, a iskat' vlom): VC++ luchshe uzhe tem, chto tam bol'she platjat. No obratnoe neverno: esli bol'she platjat — to jazyk luchshe. My zhe vse ljudi s vysshim obrazovaniem i neploxim matematicheskim i znaem, chto v zhizni v otlichii ot matematiki vyzhivajut ne luchshie, a bolee prisposoblennye. Vse znajut, chto Windows ne samaja luchshaja iz vozmozhnyx sistem, no ee prodano bol'she vsego. I ne potomu, chto ona luchshaja, a potomu, chto Djadja Bill genij v marketinge, on delaet ne samoe luchshee, no zato vsegda VOVREMJA. ak i VC++, otstoj na samom dele, kak po gljukavosti, po IDE, po ... ( kazhdyj mozhet sam dobavit'). No, moj znakomyj ispol'zuet dlja programmirovanij vorovannyj Editor ( zabyl kakoj) i "makefile" i dovolen, a proektiki ( etak na 300-500 kilostrok) delaet na C/C++ dlja Windows / Linux, xotja priznaet lish' BSD.

I vot na eto "davaj ego sjuda..." xotelos' by rasskazat' takuju istoriju: dva, net uzhe 3 goda nazad ja iskal rabotu ( proekt delal odin, na Delphi, inache prosto po srokam ne popadal, zhena shefa ne imeja programmy uzhe prodala okolo 20 ekzempljarov. Eto byla sistema upravlenija urokom v shkolax. Dolzna begat' v seti. Proekt potjanul bol'she 200 kilostrok. No shef chto — to ne povyshal oklad, a pri 10 — 12 chasovoj rabote bez vyxodnyx eto bylo by edinstvennym stimulom, nu i ezdit' kazhdyj den' 60 km v odnu storonu po proselochnym dorogam, dazhe v Germanii ne saxar. Oni do six por prodajut etu programmu, lish' teper' moja doch' razvivaet ee dal'she). I vot v odnoj firme posle razgovorov stal ja delat' nechto vrode praktiki. Kak — to Chef razotkrovennichalsja. I vot chto on skazal, bukval'no: "Sushchestvuet lish' odin zhivoj jazyk — C, C++ — gljuchnyj i davno umer. Vo vsem mire programmirujut vse bol'shie firmy, zasluzhivajushchie uvazhenija, lish' na C. Vse drugie, kotorye pytalis' sdelat' chto libo na drugix jazykax, libo razorilis', libo razorjajutsja.( TOCHKA)" Ja snachala byl nemnogo osharashen, a potom ponjal, na samom dele on prav. U nego tol'ko Quellcoda ( ne binary — QUELLCOD) za 10 let nakopilos' 1,5 GByte ( poltora gigabajta). I on ne mozhet eto vybrosit'. A ljubaja peredelka v koncepcii stoit vsego dorozhe. I esli kakaja — to sobaka ili volk, a uzh tem bolee Vlad ili AVK budut chto — to imet' protiv, on chelovek vezhlivyj — rugat'sja ne budet, prosto ne voz'met na rabotu. A v opredelennyx situacijax eshche kak budesh' po volch'i vyt', bud' ty samaja rasprekrasnaja sobaka.
Vot tak dorogoj Sobaka-Chelovek!
A sam ja programmiruju i na VC, i na VC++, i na Delphi. Esli vremja est', ili zakazchik xochet ( esli xochet, to i na VB, C++Builde, JScript...). Kogda nado bystro to na Delphi. Pri etom kachestvo ne stradaet. Tut kto — to vse pytalsja uvedet' kak s shablonami privedennyj kod budet' vygljadet' na Delphi. Ja dumaju, chto kazhdyj Delphiec, dazhe programmirujushchij begin...end mozhet privesti analogichnye primery, no v druguju storonu. Poet skazal: "Zhivem my ne dolgo, davajte ljubit' i radovat' druzhboj drug druga. Nam nezachem bol'she serdca xolodit' i tak uzh za oknami v'juga. Davajte drug drugu dolgi vozvrashchat', shchadit' BEZZASHCHITNUJU strannost', davajte spokojnoj dushoju proshchat' talantlivost' i bestallannost'... Chto delat' — zemlja nash PREKRASNYJ udel, ishchi sredi nas vinovatyx..."
Takaja diskussija MOGLA by stat' i konstruktivnoj, esli by iskali obshchee, luchshee — kak eto luchshee iz odnogo jazyka ispol'zovat' v drugom.
Da i ne KODERY my, a programmisty, ili PROGRAMMISTY, po vsjakomu. A dlja normal'nogo programmera lish' odin vopros: KOGDA?
Moj e-mail: viktor_denk@web.de
Re[14]: По просьбам трудящихся: Delphi vs C++(VS)
От: _silent Россия http://www.bezhetsk.ru
Дата: 04.12.03 05:21
Оценка:
Здравствуйте, Viktor Denk, Вы писали:

VD>Здравствуйте, WolfHound, Вы писали:


WH>>Здравствуйте, DOOM, Вы писали:


DOO>>>И современные разработки продолжают вести на C. И вообще все unix'оиды не признают C++, нас препод долго обсмеивал за то, что на парах по Linux'у мы пытались писать программки с использованием new и т.п. И утверждал при этом, что лишь С достоин существования. Вот так.

WH>>Давай его сюда. Сначала я ему обьясню почему С++ круче чем С, а потом Влад и AVK почему надо все бросать и писать на C#.

VD>Smeshno, esli by ne bylo tak grustno. Nu ljudi dobrye — eto zhe ne religioznye voprosy: verish' kontra ne verish', ili kishki vyrezhu. C/C++ ne luchshe Delphi, no i Delphi ne luchshe C/C++. Eto raznye jazyki u nix raznye oblasti i dlja raznyx zadach. Da i dlja raznyx ljudej tozhe. I ja soglasen tol'ko s odnim vyskazyvaniem ( prosti uzhe ne pomnju kto, a iskat' vlom): VC++ luchshe uzhe tem, chto tam bol'she platjat. No obratnoe neverno: esli bol'she platjat — to jazyk luchshe. My zhe vse ljudi s vysshim obrazovaniem i neploxim matematicheskim i ...

[skipped]

Нда, было бы намного интереснее читать статью на русском и даже на английском, но не на транслите... На транслите читать даже и не буду...
С уважением, _silent << RSDN@Home >>
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: Lipatov  
Дата: 08.12.03 22:17
Оценка:
Здравствуйте, Jenyay, Вы писали:

J>Насчет STL не знаю — как то не приходилось от них ничего наследовать (хотя, вроде бы можно), но никто не мешает сувать шаблоны в свои классы и наследовать от них.


О да, STL это глыба! И совершенн верно, что макросы — это не есть inline! inline такие возможности и не снились! Я видел наполнение огромного массива на этапе компиляции сделанное с помощью переопределения макроса и #include. Не помню точно как это было сделано, но 5-ю строками написали целую программу!
Насчет STL, наследовать можно и нужно. У меня был случай, что пришлось переставлять
элементы списка list местами с сохранением ссылок на них, т.е. все созданные итераторы должны продолжать указывать на свои элементы. Я просто создал насдедника от
list и добавил функуию длиной в 10 строк. Где еще так можно! (хотя не спорю, в кишках STL без ста грамм не разберешся!)
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: Lipatov  
Дата: 09.12.03 11:43
Оценка:
Здравствуйте, Oxy, Вы писали:

Oxy>Интересно, а где модератор? Спит что ли.

Oxy>Такие религиозные войны надо прекращать в зародыше. Они, ИМХО, не несут никакой смысловой нагрузки и только засоряют форум. Ну поумнчают здесь любители этого дела, померцают гранями, а толку? Никто никого не убедит и не переубедит.
Да, совершенно согласен. Каждый язык хорошь там для чего придуман. Попробуй на MSVC сделать разветвленный интерфейс какой нибудь АС, с ума сойдешь! А сделать парсер файлов Word на Pascal? Тоже не сахар...
Все эти споры совершенно ни к чему. Работать надо, а не болтать.
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 12.12.03 10:47
Оценка:
Oxy>Интересно, а где модератор? Спит что ли.
Oxy>Такие религиозные войны надо прекращать в зародыше. Они, ИМХО, не несут никакой смысловой нагрузки

Так вроде не противоречит правилам.
... << RSDN@Home 1.1.0 stable >>
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: Oxy  
Дата: 12.12.03 10:51
Оценка:
Здравствуйте, mihailik, Вы писали:
M>Так вроде не противоречит правилам.

Правила не мешало бы дополнить...
Re[4]: По просьбам трудящихся: Delphi vs C++(VS)
От: mihailik Украина  
Дата: 12.12.03 10:56
Оценка:
M>>Так вроде не противоречит правилам.
Oxy>Правила не мешало бы дополнить...

Может и не мешало бы. Смотря чем дополнять.
... << RSDN@Home 1.1.0 stable >>
от модератора.
От: _MarlboroMan_ Россия  
Дата: 15.12.03 03:17
Оценка:
Здравствуйте, Oxy, Вы писали:

Oxy>Интересно, а где модератор? Спит что ли.


да в командировке он. т.е. считай в отпуске, бо связи практически нет.

Oxy>Такие религиозные войны надо прекращать в зародыше. Они, ИМХО, не несут никакой смысловой нагрузки и только засоряют форум. Ну поумнчают здесь любители этого дела, померцают гранями, а толку? Никто никого не убедит и не переубедит.


для этого форум специательный сделали. голосуйте и переносите.
... << RSDN@Home 1.1.2 beta 2 >>

— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Re[16]: Некоторые итоги:
От: Hacker_Delphi Россия  
Дата: 17.12.03 06:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

S>> В паскале пришлось бы делать с твоей аналогией

S>>cmp.add(@test.f1,TypeOf(test.f1));
WH>И все в рантайме, а если новый тип появится?
а все будет нормально... RTTI автоматом подгрузится..
S>>Забыл как в RTTI TypeOf, но на C# прямо из типа я могу получить всю информацию о записи и соотвественно прописать все филды.
WH>.НЕТ это отдельная история там вобще все подругому а тут мы разговариваем не о нем, а о C++ и Delphi
Ну... заметим, что как было верно замечено — очень много идей в .Net взято из Delphi.
к тому же появился Delphi .Net... все, конец C++ пришел

S>> Но как быть если у тебя не известна структура test на этапе компиляции.

WH>Надо знать КОНКРТНЫЙ формат информации о типах полей. К томуже в реальной жизни в 99% случаев все извесно компилятору
А вот нифига... возьми саму среду Delphi... при ее компиляции не было известно про всякие "3rd party components" но они нормально инсталлируются и работают... и написать такую оболочку на Delphi не составляет никакого особого труда. А вот написание компонентно ориентированых приложений на C++ — это геморой... даже на C++ Builder, который поддерживается лишь для того, чтобы фанаты C++ имели-таки возможность работать с нормальной компонентно ориентированой средой разработки...
а глючит.... глючит потому, что и так невозможную вешь сделали...
... << RSDN@Home 1.1.2 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Re[7]: Некоторые итоги:
От: Hacker_Delphi Россия  
Дата: 17.12.03 06:34
Оценка:
Здравствуйте, centurn, Вы писали:

C> Кстати, кривая работа при нестандартных настройках видео (Large fonts, например) — классическая болезнь дельфийских прог, а иногда вот и самой делфийской IDE...

Ага... ты еще скажи, что MS'ные проги ей не болеют.... запусти хоть Office 2000 в крупных шрифтах и зайди в какой-нить диалог — куча удовольчтвия гарантирована...
... << RSDN@Home 1.1.2 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: Hacker_Delphi Россия  
Дата: 17.12.03 06:54
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, DOOM, Вы писали:

DOO>>Ну конечно. А в VS я ее жду секунд 6-8. За это время успеваешь расслабиться
WH>ЧАВО???? Она мнгновенно выскакивает.
ну не знаю... у меня в Delphi оно взлетает за 0 секунд...
... << RSDN@Home 1.1.2 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Re[9]: По просьбам трудящихся: Delphi vs C++(VS)
От: The Lex Украина  
Дата: 14.01.04 11:53
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, Дарней, Вы писали:


Д>>Какой другой смысл?


DOO>(char *)name — указатель на байт Занимает 4-ре байта...


Да ну?! А если не 4, тогда что делать? А если вообще категорически все равно, сколько там занимает указатель, как и то, что он вообще из себя представляет, а просто нужно привести name к такому-то другому типу — при передаче его в качестве параметра, например?
Голь на выдумку хитра, однако...
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: Stoune  
Дата: 19.01.04 03:43
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>....Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов, но это все очень, на мой взгляд, сомнительные вещи без которых вполне можно обойтись(макрос меняется inline функцией и результат одинаковый, шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).


Не совсем в поддержку плюсов. Хотел обратить ваше внимание на недостаток вашего подхода, ведь хорошие програмисты в первую очередь пытаются избавится от дублирования кода, метод "Ctrl+Ins" плох не только тем что код сильно разбухает, а в значительной мере ещё тем что становится плохо управляемым, сложно контролировать и синхронизировать измененим, а то что шаблоны вещь хорошая и нужная признают сейчас многие, в .NET и Java их собираются ввести. Другое дело, то что шаблоны в плюсах реализированы достаточно сложно и их освоить не каждому под силу, а отсюда растут ноги у мифов о том что щаблоны это вредно.
... << RSDN@Home 1.1.2 beta 1 >>
Re[17]: Некоторые итоги:
От: Stoune  
Дата: 19.01.04 03:43
Оценка:
Здравствуйте, Hacker_Delphi, Вы писали:

H_D>а глючит.... глючит потому, что и так невозможную вешь сделали...


А помоему глючит потому что не смогли нормально скрестить ядро VCL написаное на паскале с плюсами, шаг вправо, шаг
влево и приходится лезть в паскалевый код, плюс поппытались привить идеологию работы Паскаля в плюсы, ну и на последок выпуск откровенно сырых релизов, ну чтоб BCB6 на ровном месте с пустой формой вылетал по AV ето вы меня уж извините за это надо бить по рукам линейкой менеджеров которые выпустили на рынок такой продукт.
... << RSDN@Home 1.1.2 beta 1 >>
Re[21]: Некоторые итоги:
От: Stoune  
Дата: 19.01.04 03:43
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> А какже memcopy. Она на чистом С++ написана. Огромное количество низкоуровневых функций на асме.


memcopy входит в рантайм, эта и ей подобные функции используются в основном для совместимости с програмами на С, и если посмотриш на код генерируемый Делфами то думаю ты получиш код почти аналогичный коду что даёт ета функция, и его судя по копирайтам писала Intel, а их учить как затачивать код под свои камни думаю никто не будет.
Для ООП всё же лучше использовать std::copy, если ты конечно не пишеш драйвера, std::copy будет сторого типизированой и даже если внутри она и будет реализована на базе memcopy тебя это не должно волновать, так как это библиотечная функция, ты ведь не часто лезеш и правиш VCL надеюсь, на той же Делфи тоже предостаточно будет низкоуровневого и legacy кода(Graph,Dos), В VCL внутри тоже есть вызовы низкоуровневых функций.
Ну и наконец если тебе нужна скорость, то ни в Делфе ни в плюсах без асмовых вставок не обойтись, а для других целей их и не применяют почти, разве что драйвера писать и с железом работать.
... << RSDN@Home 1.1.2 beta 1 >>
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: Stoune  
Дата: 19.01.04 03:43
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, mihailik, Вы писали:



M>>Конечно, есть люди, которым по долгу службы приходится на ассемблере писать. Слава богу, я к таким не принадлежу.


DOO>Повреь мне зря... Самый красивый и понятный язык(когда макросами не перегружен по самое нехочу).


Ну вот попрограмируй под современные DSP или микроконтролеры, и раскажеш про красивый и понятный,то ета команда за этой идти не может изза особенностей реализации конвеера, то код не помещается в сегмент кода, а всё изза того что дурацкий компилер сравнение делает 3-юмя камандами, когда можна одной, а ещё производители имеют привычку каждых два года менять номенклатуру и выпускать сырые камни, а потом выпускают кучу еррат, ой извините у нас такой глюк, а посему обходной манёвр продерните нитку через задний проход и втыкните в иголку, хорошо если ещё еррату выпустят, а то могут умолчать и признаться только в частном розговоре да у нас есть проблемы, и о плюсах я пока только мечтаю, да что там говорить дайте мне нормальный ANSI C99, а документацию писали дэбилы с образованием в 6-ть класов и менеджэры по продажам изза чего выяснить технические поробности можно только методом или научного втыка, что иногда опасно кристал сожжёш, или контактируя с разработчиками и такими же как ты нещасными.
... << RSDN@Home 1.1.2 beta 1 >>
Re[23]: Еще итогов
От: Hacker_Delphi Россия  
Дата: 19.01.04 05:41
Оценка:
Здравствуйте, Glоbus, Вы писали:

G>Так что, как говорил товарищ Сталин: "Факты — вещь упрямая". То есть оказывается не нужны людям свойства, не нужны им быстрые кнопочки на формах, не нужны им самопальные реализации контейнеров через наследование и код через Копи/Паст. А нужны им шаблоны, нужен им монстроидальный синтаксис, нужна им, гадам, перегрузка операторов. И готовы они потерпеть лишнее время, так как как ни крути, а на сях прожект сложнее разработать и реализовать (может потому что задачи сложнее). И готовы эти гады (работодатели всмысле) в 2 раза больше денег платить за все эти сишные неудобства, и хотят они их почти в 5 раза больше и сильнее чем все TContainer"ы и ТПрограммер компоненты вместе взятые. Так что королевство дельфей может сушить сухари. Где то я там видел фразу типа "С++ и дельфи — умирающие направления". Ага, жестко они умирают. А лохи эти, из котор программерских — они ж лапти, у них денег куры не клюют — вот и платят специалистам по тупиковым направлениеям по 3000 уе.

G>Вот такие дела
Ну ты несколько не прав... есть еще набор стереотипов типа: C++ — круто, Pascal — отстой... Java — круто... .Net — да так... лабудень... Oracle — супер рулез! MSSQL — поделка наколеночная для неудачников.... и так далее...
стереотипов море... и стереотипы рулят мышлением большинства из неас...
... << RSDN@Home 1.1.2 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: Сметанин Россия  
Дата: 06.02.04 12:05
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>[...] Причем видел я и такой идиолтизм как написание достаточного громоздского интерфейса средствами чистого API. Больно было смотреть как маятся люди, делая тривиальные вещи, стоит только начать использовать VCL.


Я видел ещё веселее — написание на API контролов (типа тулбаров, менюшек, гридов etc) на VB6!!! Блин, до этого мне даже в голову не приходило, что на VB можно вешать хуки, обрабатывать сообытия типа всяких WM_INITMENUPOPUP, WM_MEASUREITEM, WM_DRAWITEM etc. Я вам скажу — вот это всем извратам изврат!
С уважением,
Юрий Сметанин.
Re[5]: По просьбам трудящихся: Delphi vs C++(VS)
От: Аноним  
Дата: 09.02.04 23:11
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>>>В одной книжке я встретил правильную фразу, дословно не помню, что-то вроде, что существует объектно ориентированное пргораммирование и шаблонное программирование.

DOO>>>Очень разные вещи, поскольку в STL нет никакого наследования, например.
Настоятельно рекомендую посмотреть на ATL и WTL... В действительности шаблоны и наследование никак абсолютно друг дружке не мешают.

DOO>
DOO>template <class T>
DOO>class CTemplateClass
DOO>{
DOO>  T member;
DOO>}
DOO>class CSon1 : public CTemplateClass<class1>
DOO>{
DOO>}
DOO>class CSon2 : public CTemplateClass<class2>
DOO>

DOO>И что в итоге получается? CSon1 и CSon2 сложно называть детьми CTemplateClass.
А вот уже от незнания языка...


J>>Так со смартпоинтерами можно не бояться, что забудешь освободить память.

DOO>Волков бояться в лес не ходить
Береженого Бог бережет.

DOO>Мне на работе сказали WTL — хорошо, но MS не поддерживает. Поэтому пиши на MFC.

MFC, вообщем-то, уже тоже не будет развиваться. Теперь только .NET
Re[6]: По просьбам трудящихся: Delphi vs C++(VS)
От: Аноним  
Дата: 09.02.04 23:19
Оценка:
Здравствуйте, centurn, Вы писали:

C> А забыть вызвать деструктор в случае "ветвистого" кода, например?

Это еще что... А вот ежели исключение где сгенерируется... расширения вроде __finally не всегда ведь спасут да и забыть проще простого плюс код растет непомерно от всех этих __finally... А вот интеллектуальные указатели помогут... К тому же они еще и о владении позаботятся — ссылки подсчитают... Короче, ни один нормальный проект сейчас без таких патернов на C++ не пишется...
Re: По просьбам трудящихся: Delphi vs C++(VS)
От: Аноним  
Дата: 12.02.04 15:31
Оценка:
Здравствуйте, DOOM, Вы писали:

DOO>Сразу некоторые ответы на вопросы, возникшие в этом
Автор: DOOM
Дата: 26.08.03
топике.


DOO>Дельфи действительно швыряет EAbstractError при попытке создания экземпляра абстрактного класса, и это правильно, что в именно в run-time, поскольку пусть у меня следующая иерархия классов:

DOO>TAbstractClass = class ....
DOO>TClass1 = class(TAbstractClass)...
DOO>TClass2 = class(TAbstractClass)...
DOO>Я хочу создать массив, в котором будут и TClass1 и TClass2 — понятно, что надо создать массив TAbstractClass. В С это можно решить только используя указатели на класс, а в Дельфи есть только указатели на класс, просто это все неявно. И при их организации ООП это единственный способ. Поэтому-то мне и интересно как это сделано в С. К сожалению сейчас у меня нет времени покопаться в VS-ке и погладет как на asm'е все это выглядит.

DOO>По поводу того, что у Дельфи меньше возможностей... Приведите хоть один пример, который нельзя реализовать на Дельфи, но можно на C++. Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов, но это все очень, на мой взгляд, сомнительные вещи без которых вполне можно обойтись(макрос меняется inline функцией и результат одинаковый, шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).



DOO>По поводу IDE — тут по-моему вопросов нет. В дельфи оно факт удобнее.


DOO>По поводу библиотек — MFC vs VCL. VCL — действительно объектная библиотека, в которой обработка событий инкапсулированна в объект, а не реализуется посредством вставляемых куда-то макросов и т.п.


DOO>Теперь ваща очередь...



В Delphi очень не удобно то что не существует стековых объектов класса. Т. е для того чтобы использовать класс его нужно создать (.Create) а затем удалить (.Free. Объекты класса существуют как указатели. Очень много совершенно ненужных ключевых слов типа override, overload, reintroduce, (virtual, dinamic).Неудобно что нет перегрузки операторов и шаюлонов.

Однако есть удобная вещь — properties и то что можно очень быстро слепить среней сложности проекты
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: Oxy  
Дата: 12.02.04 15:49
Оценка:
Здравствуйте, Аноним, Вы писали:

А>В Delphi очень не удобно то что не существует стековых объектов класса. Т. е для того чтобы использовать класс его нужно создать (.Create) а затем удалить (.Free.


И это мне видится очень логично. Есть класс — это как некий шаблон. И есть экземпляр класса — объект построенный по этому шаблону. И да, его нужно создавать и уничтожать, что совершенно естественно. Создал объект — вот он, делай с ним что хочешь. Не нужен — уничтожай его и освобождай пямять. Все вполне логично, а главное ты имеешь полный контроль над кодом так как явно создаешь или уничтожаешь объекты. Иногда это очень даже помогает.

А>Объекты класса существуют как указатели.


Объекты класса существуют как объекты. И есть указатели на эти объекты. Доступ к объекту совершается через указатель. На один объект могут указывать множество указателей. Что тут непонятного, неудобного или нелогичного?

А>Очень много совершенно ненужных ключевых слов типа override, overload, reintroduce, (virtual, dinamic).


Ну это все субъективно. Мне, например, так не кажется. Как и многим другим программерам.
Если бы ты хорошо разобрался со всем этим, то, ИМХО, и тебе бы тоже так не казалось.

А>Неудобно что нет перегрузки операторов и шаюлонов.


Ну чего нет того нет. Полностью согласен. Но лично я от этого не страдаю.
Re[3]: По просьбам трудящихся: Delphi vs C++(VS)
От: Аноним  
Дата: 12.02.04 16:03
Оценка:
Здравствуйте, Oxy, Вы писали:

Oxy>Здравствуйте, Аноним, Вы писали:


А>>В Delphi очень не удобно то что не существует стековых объектов класса. Т. е для того чтобы использовать класс его нужно создать (.Create) а затем удалить (.Free.


Oxy>И это мне видится очень логично. Есть класс — это как некий шаблон. И есть экземпляр класса — объект построенный по этому шаблону. И да, его нужно создавать и уничтожать, что совершенно естественно. Создал объект — вот он, делай с ним что хочешь. Не нужен — уничтожай его и освобождай пямять. Все вполне логично, а главное ты имеешь полный контроль над кодом так как явно создаешь или уничтожаешь объекты. Иногда это очень даже помогает.


А>>Объекты класса существуют как указатели.


Oxy>Объекты класса существуют как объекты. И есть указатели на эти объекты. Доступ к объекту совершается через указатель. На один объект могут указывать множество указателей. Что тут непонятного, неудобного или нелогичного?


А>>Очень много совершенно ненужных ключевых слов типа override, overload, reintroduce, (virtual, dinamic).


Oxy>Ну это все субъективно. Мне, например, так не кажется. Как и многим другим программерам.

Oxy>Если бы ты хорошо разобрался со всем этим, то, ИМХО, и тебе бы тоже так не казалось.

А>>Неудобно что нет перегрузки операторов и шаюлонов.


Oxy>Ну чего нет того нет. Полностью согласен. Но лично я от этого не страдаю.


Стековые объекты испоьзуются в области видимости и уничтожаются при выходе из нее. Память выделяется гораздо быстрее чем при (.Create или new в С++). Тем более память может вообще не выделяться если это не нужно напрмер в условиях. Это конечно детали но мне в Delphi этот момент не нравится

Еще по поводу библиотеки типов в Delphi. Вроде визуально удобно но много глюков. Если знаешь IDL гораздо легче работать в текстовов редакторе. Это мое мнение. не зняю может я ошибаюсь
Re[8]: По просьбам трудящихся: Delphi vs C++(VS)
От: Аноним  
Дата: 13.02.04 06:43
Оценка:
Здравствуйте, Аноним, Вы писали:


A>>Как я с тобой согласен! И в C# подобная дребедень. using немного спасает ситуацию, но только в самых простых случаях. Особенно меня прикалывает тот факт, что IDispose.Dispose() может выбросить исключение. После этого я не могу понять как на C# можно писать надежные программы.


А>Вот-вот. Тут народ что-то рассказывает про отсутствие в C# шаблонов, перегрузки некоторых операторов и прочей лабудени. В то время как (на мой взгляд) самый реальный шаг назад — отсутствие надёжного механизма детерминированного освобождения ресурсов. using нифига ситуацию не спасает, т. к.:

Во-первых, rtfm unsafe. Во-вторых, детерминированное освобождение ресурсов требуется крайне редко, а вот сборщик муссора фактически исключаяет вероятность появления утечек памяти. А using — это всего-лишь конструкция try-finally с вызовом dispose
А>1) Каждый раз при создании объекта надо проверять поддержку IDisposable = лезть в MSDN. (Все классы не запомнишь.)
Не каждый раз. Ну что за дурная привычка? using нужен только для классов, использующих какой-либо системный ресурс отличный от памяти (например, файл). В остальных случаях сборщик муссора сам позаботится об уничтожении объектов.
А>2) Попытки систематически использовать using приводят к конструкциям вида:
А>using(....) {
А> using(...) {
А> using(...) {
А вот это уже от незнания языка. RTFM using, а именно возможность использовать using для множества объектов.
А>3) Dispose() может выбрасывать исключения
Деструктор и.у. тоже не застрахован от исключений.
А>4) Рекомендательный характер вызова Dispose(). Поубивал бы за это . Dispose() в половине случаев оставляется самой FCL на попечение Finalize, который, разумеется, вызывается, когда мало памяти, а не того ресурса, которого не хватает.
RTFM, о работе сборщика муссора, например, в книге Рихтера.
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: migel  
Дата: 30.09.04 07:11
Оценка:
Здравствуйте, pidolas, Вы писали:
P>Уж сколько раз твердили миру...

Блин ну что за мания к архивным раскопкам????
... << RSDN@Home 1.1.4 beta 2 rev. 172>>
Re[2]: По просьбам трудящихся: Delphi vs C++(VS)
От: Сантехник Беларусь  
Дата: 30.09.04 07:18
Оценка:
P>Уж сколько раз твердили миру...


Родной, в Janus есть пунктик меню "Скачать тему", оч полезен таким товарисчам как ты.
Головой надо думать. Не у всех Инет сильно толстый, чтобы тянуть 5 килопостов давно покрытых
пылью топиков...
А если это способ обратить на себя внимание, то тебе поможет Клеарасил.
... << RSDN@Home 1.1.4 beta 2 rev. 0>>
Re[35]: По просьбам трудящихся: Delphi vs C++(VS)
От: Shtirliz Россия  
Дата: 30.09.04 09:59
Оценка:
Здравствуйте, mihailik, Вы писали:

WH>>куда это ты ее приложить собрался? Уж не к задаче ли где 90% ГУИ? И всеравно против шарпа не тянет. Ну ни как.


M>Против шарпа?


M>В C# на редкость унылая и скромная библиотека визуальных компонентов. За какой аспект ни возьмись — практически всё хуже Дельфёвого.


M>Сдаётся мне, что ты по GUI просто мало работаешь. Мне для одной сложной формы пришлось даже импортировать Delphi-компонент как COM-объект.


Согласен. Таже беда была. Но для С++.
Ну тяжело с ГУИ в С++ работать. Все приходится делать ручками...
Времени уходит только на интерфейс просто тьма, не говоря уже о логике.
Тем более Delphi — среда быстрой разработки приложений.
Возможно оффтоп, но мне кажется что...

Работа программы ИМХО больше всего зависит от логики которая в нее заложена.
А на чем писать, по-моему не принципиально.
В плане надежности ПО, что студия что делфи без разницы.
Все зависит от радиуса кривизны рук создателя программы.
И если увидев кривую программу на делфи сразу кричать, что на делфи ничего серьезного написать нельзя, ИМХО не правильно.

P.S. Еще не встречал задачи которую можно написать на С++ и нельзя на делфи (исключения — драйвера).
... << RSDN@Home 1.1.4 >> << Windows 2000 Версия: 5.0.2195.0>>
Дункан Маклауд любил ходить в лес и издеваться над кукушками.
138385660
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.