C++ vs Delphi

[Apis.NET]

Да куплю я куплю, просто мне ещё 3 книги нужно вот и жду что б все вместе купить.

[mj]

С++ - это отстой...
Для сравнения если написать на C и Delphi написать программу выводящую параметры запуска с использованием одинаковых функций WinAPI, дык на C прога в 3 раза больше чем на Delphi получается...

Вот уж подумайте что лучше... :beer:

[Apis.NET]

:gigi:

test

(Отредактировал(а) ivank - 12:55 - 15 Дек., 2001)

[noname00.pas]

mj
Скомпиль пустую прогу на bp 7.0 и на TMT-Pascal... На ТМТ она будет весить больше 16к, а на бп меньше 2к. Так что же? БП круче что-ли? Судить надо по эффективности компиляции крупных и сложных программ...

[ivank]

mj

Ну что ж, пофлеймить хочем? :D

С++ - это отстой...Ну зачем же так безосновательно утверждать?
Для сравнения если написать на C и Delphi написать программу выводящую параметры запуска с использованием одинаковых функций WinAPI, дык на C прога в 3 раза больше чем на Delphi получается...
C++ это не C! Это раз!
Далее компиляторов плюсов море( есле не море, то уж вагон и маленькая тележка точно ) Так что выбирай какой по душе, это очень существенный плюс.
Я так понимаю, вы компилили Борландом или Микрософтом ( другие у нас в стране не в моде ) И я вас очень удивлю, но:
По дефолту( после создания проекта ) и тот и другой выставля дебаг -- ноль оптимизации
Старые Borland и MSVC < 6 по дефолту включают отладочную информацию внутрь экзешника, если её вырезать, то размер существенно уменьшится
ИМХО на Delphi серьёзный проект не напишешь! Тут очень много причин: Язык Object Pascal существенно беднее плюсов в плане ООП ( и не надо говорить что большие проекты можно без ООПа написать ):[list] Отсутствуют шаблоны Только интерфейсное и одиночное наследование. В плюсах есть ещё и множественное. Если хотите сказать, что Дельфи это полноценная среда разработки, то привидите хоть один пример успешного большого проекта выходящего за рамки гуя.

И вот 2 ссылочки по теме ( Васкецов может не ходить ;) )
Про различие C и C++: http://kalinin.ru/programming/cpp/09_07_01.shtml
Про Rad( уже постил в этом треде ) http://kalinin.ru/programming/cpp/26_07_00.shtml

(Отредактировал(а) ivank - 0:24 - 14 Дек., 2001)

[VuDZ]

вот же ш разашёлся злобный модер:
и так:
1. ИМХО на Delphi серьёзный проект не напишешь! Тут очень много причин:
безосновательное утвержение, замечание номер 1
делфи разрабатывался для рботы с БД, и не уж то ты думаешь, что в Борланде, ныне Ипрайс, такие идиоты сидят и не понимают, что SDK идёт на С, переносить это полностью под паскаль - долго и не благодарное это занятие

Язык Object Pascal существенно беднее плюсов в плане ООП ( и не надо говорить что большие проекты можно без ООПа написать ):[
Незнание сути предмета, замечание номер 2
В большенстве случаев, можно обойтись и без всей мощи ООП. Да и наш любимый С++ не полностью поддерживает ООП - неполное RTTI, отсутствие мета-классов. С помощью мета-классов можно сделать очень многие вещи, на этом базируется VCL. Если интерисует, достану ссылку на одну ветку, в которой было показано что можо сделать на ОП и нельзя с С++

Отсутствуют шаблоны
это не такой уж и большой недостаток. Да, с ними исходник меньше, но от этого страдает быстродествие софта.
Пример:


template <class T>
void BubleSort (T * array, size_t sz){
if ((!T) || (sz < 2))
*return;

for (int i = 0; i < sz; ++i)
*for (int j = 0; j < sz; ++j)
* if (array[[i]] <= array[j]){
* * T tmp = array[[i]];
* * array[[i]] = array[j];
* * array[j] = tmp;
* *}
}



тот же самый код, без шаблонов, работает на 30% быстрее.

В плюсах есть ещё и множественное.
Только не смешите мои тапочеи: в большнтсве прикладного софта это никому и не упало. С сиспрограммирование это очень мощная фишка, но в "обычном" - нет.

PS как RAD делфи не на много превосходит VC, а учитывая, что на создание интерфейса уходит максимум 10% всего времени от написания проекта, это копейки.

PPS если что, то проф. ориентацию я не менял, просто терпеть не могу религиозные войны и фанатизм

PPPS и по теме: лучше в начале выучить делфи, а потом приниматься за С, С++

<font size=dfontsize1 class=bgc1>Исправлено: <b>VuDZ</b>, 1:50 2-03-2002</font>

[ivank]

попытка отмазаться :>
вот же ш разашёлся злобный модер:
Ну... Я тогда ещё модером не был. Это раз. И два, с тех пор я уже персмотрел свою точку зрения.
что в Борланде, ныне ИпрайсОни обратно в борланд переименовались.
Да и наш любимый С++ не полностью поддерживает ООПЯ этого не утверждал. C++ далеко не самые ОО язык.

Да, с ними исходник меньше, но от этого страдает быстродествие софта.
Расскажи, почему это? В простейшем случаее шаблоны можно рассматривать как продвинутые макросы. И кстати твоя реализация так-себе, не сможет работать с вектором итп.

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

PS как RAD делфи не на много превосходит VC, а учитывая, что на создание интерфейса уходит максимум 10% всего времени от написания проекта, это копейки.
Читаем чуть выше:делфи разрабатывался для рботы с БД
В моём представлении работа с БД это просто SQL-запросы и их визуализация. Delphi сделана именно для этого -- для быстрого создания интерфейса к базам данных. Т.е. не что иное как RAD-средство. Почему-то MS VC для этих целей применяют реже.

PPPS и по теме: лучше в начале выучить делфи, а потом приниматься за С, С++Неверно, лучше сначала выучить алгоритмичесский язык, всё равно какой, хоть бэйсик (только в современном варианте) и научиться программировать, т.е. не просто знать синтаксис.

[VuDZ]

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

Расскажи, почему это? В простейшем случаее шаблоны можно рассматривать как продвинутые макросы. И кстати твоя реализация так-себе, не сможет работать с вектором итп.
про векторы - ну и .... ними, не в этом дело. Попробуй сам собрать такой пример, для второго - "читого" - кода, используй long double, И посмотри результаты. для достоверности, проделай это этак 1000-10000 раз, и всё буде ясно

Почему-то MS VC для этих целей применяют реже.
интересно, а почему две книги 70-015 и 70-016 на 3/4 состоят из описания как работать с БД? (это учебный курс для MCSD)

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

[ivank]

Времени отвечать про всё сейчас нет, но скажу, что с темплейтами MSVC и bcc5.5 оба провалились -- действительно худе. А вот у mingw всё было одинаково... Так что, плохая реализация темплейтов, это проблеммы создателей компилятора, а не языка.

[VuDZ]

я почти всегда юзаю ителовский компилер

[ivank]

vasketsov
Спор продолжать не хочу, но только одну вещь добавлю -- C++ есть везде, где есть C, т.к. существуют C++-frontend'ы -- компиляторы из C++ в C. Первые компилеры C++ (cfront в частности) компилировали всё в C, т.к. "это портабельный ассемблер". Сейчас наиболее популярный фронтенд это *Comeu. Его можно у них в onlin'е пощупать -- http://www.comeaucomputing.com .

[Daiv]

Ne pomnyu - gde to sprashival... no zabyl gde :)...
PO kakoi mukulature del'fei s samogo - 0 uchit' ?

[ivank]

Daiv
а тему новую создать не судьба?

[Daiv]

ivank
dumaesh stoit? nu sozdam, sozdam... :)

[Guest]

Какая на... Делфи. С++ быстрее, компактнее, мощнее. Билдер - вот то, что нужно.:up:

[Crew]

...Почему-то я себя почувствовал маленьким и *несчастным

ivank
Можно пример какого-нибудь применения множественного наследования, не код я имею ввиду, а просто идею.. кроме кнопочек с картинками и кроме потокового ввода-вывода, который соединяет в себе наследование от класса вывода и класса ввода (или может соединять)
И еще очень интересует вопрос переопределения имен при множественном наследовании. При достаточно больших классах не будут ли затраты.....слишком большими.


Исправлено: Crew, 0:05 11-02-2003

[vasketsov]

ivank
C++ есть везде, где есть C
Пока еще нет.
Ну вот не сделали еще компилятор, и все, руки, видать, не дошли руки. Даже компилятора с языка ассемблера там еще нет, на парситеках.

[Vaulter]

mj
смотря как писать. если руки кривые то хоть делфи суй в них, хоть си++

[ivank]

vasketsov
Не понял... Фронт-енды C++ -> C есть? Есть, соответственно для всего, для чего есть компилятор C можно откомпилять плюсовую программу (если ресурсов хватит). Где я не прав?

Crew
Множественное наследование можно применять где угодно, где приходится совмещать "два в одном".

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

[Crew]

ivank
Какие затраты, в смысле на что?
Проблема неоднозначности
Например: оба родителя используют метод add(int)
И предположим, что получившийся класс использует оба метода и ему они нужны для разных целей. После некоторго размышления оставляем оба метода например так
void CC::add(int n)
{
* *CA::add(n);
}
И вводим второй метод
void CC::add2(int n)
{
* CB::add(n);
}
Ура, проблема решена

А если двусмысленность более сложна?
Сейчас это было необходимо из-за пересечения понятий наследования и параметрической перегрузки. Когда в С++ используется перегруженное имя, то сперва вызывается механизм наследования для поиска контекста, в котором определена функция. Затем типы параметров анализируются для снятия двусмысленности в пределах данного контекста. Предположим, что есть два класса А и В, для каждого из которых определен метод display. но у методов разные аргументы (int и double). Мы считаем, что так как эти два метода различаются по списку параметров, дочерний класс может наследовать от двух родителей и иметь доступ к обоим методам. Счазззз. Когда мы вызываем метод display с целочисленным аргументом, компилятор не может приянять решение, использовать ли функцию из класса A(которая соответствует типу аргумента) или же из класса В (которая встречается первой при заложенном в С++ алгоритме поиска; для ее вызова аргумент будет приведен от типа int к типу double). Копмилятор ругнется, но ругнется только в точке вызова метода, а не при описании класса.
Звучит может угрожающе, но на самом деле это лечится, но только переопределением родительских классов, где методы необходимо объявить виртуальными (не чисто виртуальными), и компилятору станет ясно, что мы сделали это специально
Проблема на уровне дочерних классов, а решение на уровне родительских. Кде тут ООП?
Вот эти вот расходы на переопределение больших классов и кажутся мне слишком большими.

Исправлено: Crew, 0:15 12-02-2003