Re[12]: По просьбам трудящихся: Delphi vs C++(VS) - Священные войны

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

WH>>Нет не так. ГУЙ это в большинстве задачь ничтожно малая часть работы.
FWP>Это в Delphi ничтожно малая часть. Потому ручная работа сведена к минимуму. А в C++ все ручками, да ручками

Вот только шаблоны сводят ручную работу практически на нет. А если учесть что очень многим приложениям не нужно куча диалогов... и написать интерфейс при помощи WTL не состовляет большого труда...

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

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

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

Какая-нибудь ОС всегда на машине стоит, а вот приходить и говорить, что надо бы вам еще оффис поставить к вашей винде — это дурной тон!

DOO>>Да и в чем Дельфи так не оптимально? Работает во многом даже быстрее.
WH>

Конкретней.

Ссылку на соответствующую статью я уже давал.

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

Ах да я же забыл в дельфе нет инлайнов и дробление сказывается на производительности...

Они есть! Просто их не надо описывать ручками, а это сделает за нас компилятор.

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

WH>>Ах да я же забыл в дельфе нет инлайнов и дробление сказывается на производительности...
DOO>Они есть! Просто их не надо описывать ручками, а это сделает за нас компилятор.
А ты с С++ не путаешь? Если мне не изменяет скалероз дельфя вобще ни чего не подставляет.

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

WH>Сам факт его существования достает. Зачем он нужен? Я не понимаю. (вернее зачем это надо в дельфе я знаю) В С++ этого нет вобще и никто не жалеет об этом.

ОПА!!! В сях нету finally!!!!!! Как я мог про это забыть... Не нужен говоришь... а если ты соединен с сервером, для которого лишнее повисшее соединение это непозволительная роскошь, а ты еще и отладку ведешь и вылетаешь с завидным постоянством? Как в такой ситуации встроенные в С++ механизмы помогут разорвать соединение? Или в STL есть какой-нибудь std::protocol, который сделает всю грязную работу?

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

WH>Нет типизированиесть нежна для повышения надежности, удобства и корости разработки.

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

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

FWP>Ну это ты зря. VS7 неплохой продукт.

Согласен. Но сейчас приходится пользоваться VS6.0 по политическим соображениям.

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

WH>>Сам факт его существования достает. Зачем он нужен? Я не понимаю. (вернее зачем это надо в дельфе я знаю) В С++ этого нет вобще и никто не жалеет об этом.

DOO>ОПА!!! В сях нету finally!!!!!! Как я мог про это забыть... Не нужен говоришь... а если ты соединен с сервером, для которого лишнее повисшее соединение это непозволительная роскошь, а ты еще и отладку ведешь и вылетаешь с завидным постоянством? Как в такой ситуации встроенные в С++ механизмы помогут разорвать соединение? Или в STL есть какой-нибудь std::protocol, который сделает всю грязную работу?

Ты вобще о чем? Что такого может finally чего не могут автоматические объекты? Приведи минимальный демонстрирующий код.

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

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

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

Любая таблица базы данных представляет из себя грубо говоя массив записей, но так как используется позднее связывание на основании описания записи (длины,определения полей) строятся для каждого поля объекты содержащие смещение поля и в зависимости от типа поля длину записи и соответственно происходит боксинг и дальнейшая обработка. Понятно, какое увеличение скорости приносит прямая работа с записью без посредников, а учитывая кроме всего прочего что SQL еще и интерпретатор то....
Кроме всего прочего существуют ООяБД которые могут хранить объекты, но так как объект можно представить как структуру или структуру связанных структур через ссылки то все же лучше сводить к табличному хранению или сериализации в зависимости от размера.

S>> И по поводу C# и Delphi.Net не рано ли говорить кто кого вытеснит????
WH>Ну мне так думается что те кто на дельфе не писал не будут и на Delphi.Net писать, а учитывая что он опаздывает относительно С# и сильно то многие дельфисты уже перешли на шарп, а начатый проект переписывать... И вернутся ли они после пары лет шарпа на дельфю очень большой вопрос.

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

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

WH>Я хоть слово сказал что рисовать ГУЙ это плохо?
WH>хъ
A>>Ну, не так?

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

В моей работе 90% времени клиенты рассматривают именно ГУИ. Им наплевать на функциональность, функциональность проверят тестеры.
Так что на рынке самое главное это получить деньги на создание продукта, которых завтра тебе их уже не дадут или поменяются интересы или ... или ...
Клиенту надо увидеть как это будет примерно работать, где будет находится какая кнопочка. Тогда начинает работать фантазия: "а сюда ещё это добавить, а сюда то"..
Мне не надо писать ни сервисов, ни драйверов, ни операционных систем. А работы, поверь мне, хватит и Delphi в этом плане идеальная система для быстрой реализации задуманного. Недостатки известны, достоинства тоже. А весь этот топик видится мне на 90% бессмысленным. Одни эмоции. Ведь главное цель, а средства надо выбирать отталкиваясь уже от бюджета.

Здравствуйте, 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. Специализированные шаблонные типы создаются единожды для каждого уникального типа значения, используемого в качестве параметра."
Кроме всего прочего на данном этапе надежность кода встает на первый план (хотя мне это и не импонирует)

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 уже сказал, хочу обратить внимание на выделенную строчку. Как ты думаешь, что значит эта "одна" строчка асмового кода? И еще что она будет значить, если хранимый тип не совпадает с тем, к чему ты приводишь.

Здравствуйте, 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&d_no=32&c_no=10

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>Соглашусь, что код стоит. Несомненно. В то же время есть абстракция, когда я скажу "лабел", у всех в мозгу возникнет почти одинаковый образ.

Это к чему?

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

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

... << RSDN@Home 1.1 beta 2 >>

FWP>>Ну это ты зря. VS7 неплохой продукт.
DOO>Согласен. Но сейчас приходится пользоваться VS6.0 по политическим соображениям.

А каким-нибудь Deplhi 3.0 по политическим соображениям не заставляют пользоваться для сравнения?

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

Старушки делятся на суеверных и нормальных.

M>>Типизированость? Не знаю такого слова. Знаю "надёжность". Знаю "удобство". Знаю "скорость разработки". А типизированность ради типизированности — это какие-то эстетские категории.
WH>Нет типизированиесть нежна для повышения надежности, удобства и корости разработки.

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

M>>Что-то сложное. Я в C++ не силён, ты бы словами кратко сказал.
WH>http://www.rsdn.ru/forum/Message.aspx?mid=383399&only=1

Чего?

M>>Видимо, этот помощник — это что-то универсальное и крутое. Только толку-то от всего этого хитроумия? Если мои классы должны действовать некоторым стандартным образом — я их в соответствующей иерархии и скомпоную. И сэкономлю вагон времени.
WH>ХА. Я же сказал это ПОМОШНИК он делает грязную работу.

ТЫ делаешь эту грязную работу, когда пишешь помощника. А в Дельфи я напишу базовый класс и грязную работа будет в базовом классе..

WH>>>Ой не надо на дельфе начинается try finaly hell.
M>>Не вижу в этой конструкции ничего инфернального. Можно, конечно, придумать случай, где try/finally будет доставать. Но я лично такого практически не встречал.

WH>Сам факт его существования достает. Зачем он нужен? Я не понимаю. (вернее зачем это надо в дельфе я знаю) В С++ этого нет вобще и никто не жалеет об этом.

Бедные сишники! А как же они с WinAPI работают без try/finally? Сделали CreateFile, поковырялись, получили Exception — и файл остался висеть?

Как говорил Карабас Барабас, это ж просто праздник какой-то!

... << RSDN@Home 1.1 beta 1 >>

DOO>>Видимо в основе у нас лежат диаметрально противоположные школы, поскольку, если Вас послушать то Сшный union это вообще ужас какой-то который надо убрать подальше. А я не представлаю себе нормальной работы без возможности смотреть на память так как это угодно мне, а не компилятору!

WH>Именно. Оно реально бывает нужно раз в два года.

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

... << RSDN@Home 1.1 beta 1 >>

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

A>>Правда?

Надо будет покопаться что-ли...

WH>Ну покопайся. А то мне дельфи ставить не охота.

Всё он ловит, нафиг он иначе нужен был

... << RSDN@Home 1.1 beta 1 >>

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 >>

	От:	WolfHound
	Дата:	16.09.03 05:09
	Оценка:

	От:	DOOM
	Дата:	16.09.03 07:35
	Оценка:

	От:	DOOM
	Дата:	16.09.03 07:41
	Оценка:

	От:	WolfHound
	Дата:	16.09.03 07:45
	Оценка:

	От:	DOOM
	Дата:	16.09.03 07:48
	Оценка:

	От:	Другой Аноним
	Дата:	16.09.03 07:48
	Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	16.09.03 08:17
Оценка: