Показать полную графическую версию : C++ vs Delphi
Хотелось бы услышать ваше мнение по этому вопросу.. Желательно с объяснениями почему одно, а не другое.......
noname00.pas
23-11-2001, 03:48
BigMac
C++ и Дельфи? Выбрать для разработки или для изучения? С++ эффективно компилирует, но в нём нет интерфейса для удобной и более эффективной разработки приложений под виндоус. В дельфи очень просто и удобно работать с API и создавать интерфейсы, но он не очень экономно компилит. При современных скоростях и темпах совершенствования железа я бы выбрал Дельфи.
noname00.pas
Выбрать для разработки или для изучения?
Для изучения, чтобы потом программить
noname00.pas
23-11-2001, 21:41
BigMac
Для изучения тем более Дельфи. Его учить проще на порядок :)
noname00.pas
Сенкс, а что другие скажут? :biggrin:
DiMka
А ты почему так думаешь?
Скорость разработки, скорость изучение, удобство элементарное :)
И я за Delphi! Я как-то начинал с C++ Builder-а, но упёрся в недостаток литературы и компонентов (т.е. компонентов много, но они написаны на Delphi и поэтому в C++ коряво ставяться...) После 2 недель мучения, перешёл на Delphi. Но у Delphi есть минус, на западе он считается "загнивающей системой... Там надо знать C++ Builder, Visual C++, либо Visual Basic. Конечно Delphi тоже чего-то стоит, но... И ё равно я за Delphi т.к. я лутше выучу то, что проще и удобней учить сдесь, а потом, по мере надобности, буду переходить. Не так уж сильно они отличаются.
Artem
А я, все-таки, решил на C++ подсесть....... просто в школе Си изучал....... :gigi:
Apis.NET
29-11-2001, 03:14
BigMacВ любом случае начни с С++!:lol:
Я только что зарегистрировался, так что ссори за поднятие старой темы.
Так вот, С++ одназначно рулит.
Что в нём есть чего нет в Delphi:
шаблоны -- как следствие удобные контейнеры и STL
множественное наследование -- оч удобно часть функциональности реализовать в предке.
относительная низкоуровневость -- создавался на базе Си как никак, в паскале( ObjectPascal ) это тоже есть, но это всё привнесено извне Борландом, в оригинале этого не было.
Выбор -- Если загнётся Борланд, то всё Дельфиисты останутся у разбитого корыта( врядли кто-нибудь из них перейдёт на gnu pascal ), в тоже время плюсовых компилеров море.
Чуть-чуть цитат теперь:
noname00.pas
С++ эффективно компилирует, но в нём нет интерфейса для удобной и более эффективной разработки приложений под виндоус. В дельфи очень просто и удобно работать с API
Существует такая штука как C++ Builder -- та же дельфи для плюсов, так что... WinAPI изначально создавался для Си, и пользоваться им соответственно удобнее на C ( C++ как ближайшем родственником ) Кстати гуй я рисую на VB
:biglaugh: -- а вся функциональность обычно в COM компонентах.
BigMac
А я, все-таки, решил на C++ подсесть....... просто в школе Си изучал....... :gigi:
ИМХО лучше изучать сразу C++ -- будет меньше соблазна попользовать всякие низкоуровневые штучки.
(Отредактировал(а) ivank - 12:14 - 7 Дек., 2001)
ivank
ИМХО лучше изучать сразу C++ -- будет меньше соблазна попользовать всякие низкоуровневые штучки.
Насколько мне друзья говорят, то они не особо и отличаются
Просто в Универ на СИ заставляют писать....:) Поэтому надо с СИ начать........
Я только что зарегистрировался, так что ссори за поднятие старой темы.
Это всегда приветствуется
Насколько мне друзья говорят, то они не особо и отличаются
Просто в Универ на СИ заставляют писать.... Поэтому надо с СИ начать........
Синтаксисом они вообще не отличаются, Си это просто подмножество C++, но принципы написания программ коренным образом отличаются.
Кстати C99 ( последний стандарт ) теперь ввёл ряд фич вообще несовместимых с C++! :down:
ivank
Блин.......... но все-таки с С начинать буду, для Универа надо, а потом на С++ перейду, я думаю это не так сложно будет :gigi:
vasketsov
07-12-2001, 19:41
Вот объясните мне, дауну, почему функцию WINAPI на дельфи вызвать сложнее, чем на С. Если не умеем ф-ции из библиотек подлинковывать - то тогда другое дело.
Проблема дельфи в отношении WINAPI заключается в двух вещах и только в двух вещах.
И это даже не имхо, это факт.
Во-первых, некоторые вызовы функций WINAPI в файлах *.pas (прежде всего windows.pas) реализованы некорректно, в частности, передача указателя заменена передачей параметра через var (сразу же параметр становится обязательным и тип его уже нужен тот, который описан) - это, бывает, вываливает всякие исключения. Перемуд(р)или создатели дельфей, с кем не бывает. Выход - писать правильное опрелеление и самому линковать. То же относится и к типам.
Во-вторых, борланд или кто там сейчас, явно отстает в создании файлов *.pas и примеров. Всякие "полулевые" библиотеки приходится описывать самому. А для С(++) есть MSVS, где заголовков просто на порядок больше, чем для дельфи. Правда, некоторые константы в MSVS не описаны, так я их беру из дельфи6 и DDK.
vasketsov
Вот объясните мне, дауну, почему функцию WINAPI на дельфи вызвать сложнее, чем на С.
Я этого не говорил, я сказал что WinAPI изначально для Си.
Правда, некоторые константы в MSVS не описаны, так я их беру из дельфи6 и DDK.
А последний Platform SDK поставить не судьба?
Немного в тему почему плохи Rad средства: http://www.kalinin.ru/programming/cpp/26_07_00.shtml
vasketsov
07-12-2001, 23:57
Ну, сходил по ссылке... вот оттуда пример:
>создание программ, которые в принципе не переносимы это просто издевательство над идеями C++.
Одной этой строчки достаточно, чтобы понять, что за человек это писал. Конечно, он мог иметь в виду ANSI C, но тогда все еще хуже, если автор не видит различия.
>VCL (Visual Component Library), целиком и полностью взятая из Delphi
У меня есть исходники VCL. Что то я не увидал такого.
>VCL-классы не могут участвовать во множественном наследовании
Опять же бред. Автор не знаком с основами ООП, или интерфейсное наследование за таковое не считает.
Ну и так далее.
Вывод: не давать ссылки на статьи с ошибками.
Мы люди умные, и сами понимаем, какая область применимости RAD.
>WinAPI изначально для Си
Обоснуй. Только сразу же, не надо писать, что WINAPI написано на С, поэтому оно для С Ж)). Win2000 подавляющей частью написано, насколько мне известно, на C++ и ASM. К тому же, я думаю, ясно, что спор о WINAPI не имеет ничего общего с разговорами о величине получающегося исполняемого файла.
vasketsov
Ну, сходил по ссылке... вот оттуда пример:
>создание программ, которые в принципе не переносимы это просто издевательство над идеями C++.
Одной этой строчки достаточно, чтобы понять, что за человек это писал. Конечно, он мог иметь в виду ANSI C, но тогда все еще хуже, если автор не видит различия.
Вы могли бы разъяснить поподробнее что вы хотели сказать.
>VCL (Visual Component Library), целиком и полностью взятая из Delphi
У меня есть исходники VCL. Что то я не увидал такого.
Я Билдер видел только одним глазом( да на нём ещё повязка была ), и насколько я понял на плюсах есть только интерфейсы к уже откомпиленым Дельфёвым компонентам. Хотя вот тут я ничего точно не знаю...
Автор не знаком с основами ООП, или интерфейсное наследование за таковое не считает.
Интерфейсное наследование это на множественное! Множественное это например если я порождаю обьект от кнопки и от картинки, переопределяю пару методоа и в результате получаю кнопку с картинкой. В случае интерфейсного мне придётся кнопку с картинкой делать мемберами, и иметь кучу гимороя с переопределением _всех_ методов.
>WinAPI изначально для Си
Обоснуй. Только сразу же, не надо писать, что WINAPI написано на С, поэтому оно для С Ж)).
В те давние времена когда закладывались основы современного WinAPI никакого Дельфи не существовало и впомине, соответственно единственный язык принимаемый во анимание был C, на котором к тому моменту писал весь Микрософт.
Win2000 подавляющей частью написано, насколько мне известно, на C++ и ASM.
Я конечно утверждать не берусь( исходников не видел =)), но я всегда считал что оно написаннон а Си и Асме.
К тому же, я думаю, ясно, что спор о WINAPI не имеет ничего общего с разговорами о величине получающегося исполняемого файла.
А разве такой разговор был?
зы ты(вы) Калинина не обижай(те), на самом деле у него много чего хорошего почитать можно.
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.