C++ vs Pascal: что роднее?

← →
a3m (2003-03-29 19:01) [0]

Что касается меня, то несомненно Паскаль. А вот что народ по этому поводу скажет очень даже интересно...

← →
Anatoly Podgoretsky (2003-03-29 19:14) [1]

Откуда народу знать, что тебе роднее.

← →
Cobalt (2003-03-29 20:09) [2]

Резать надо такие глупые ветки!!!
Вот моё мнение.

← →
DrPass (2003-03-29 20:33) [3]

А мне вот мама роднее...

← →
Плохой человек (2003-03-29 21:09) [4]

Не, конечно же C++ с объектно-ориентированными зачатками порвёт процедурный Pascal, но никак не дотянет до Object Pascal для Delphi, ИМХО.

← →
NetBreaker666 (2003-03-29 21:25) [5]

> Плохой человек (29.03.03 21:09)
> Не, конечно же C++ с объектно-ориентированными зачатками
> порвёт процедурный Pascal, но никак не дотянет до Object
> Pascal для Delphi, ИМХО.

это каким же он местом не дотянет до Object Pascаl интересно ? Что есть в ОП C++ чего нет в Delphi ? А в дельфи, например нет перегрухки операторов, namespace"ов, удобных операторов ++, --, +=, -=, возможности импортировать/экспортировать класыы в dll (кроме ActiveX)
Для меня роднее то, за что платят

← →
mike-d (2003-03-29 21:30) [6]

> NetBreaker666 © (29.03.03 21:25)

> Для меня роднее то, за что платят

Целиком поддерживаю. Даже если это будет VB или 1С.

← →
gek (2003-03-29 21:32) [7]

> NetBreaker666 © (29.03.03 21:25)

Ну а еще там есть и множественное наследование, в котором сам черт ногу сломит.
Ну а также есть страшной кривой класс String который по скорости
не идет ни в какое сравнение с String в Паскале.
namespace - это ерунда
удобных операторов ++, --, +=, -=, - тут можно согласиться

← →
vuk (2003-03-29 21:42) [8]

to NetBreaker666:
>А в дельфи, например нет перегрухки операторов
Перегрузка операторов нафиг не нужна. Кстати, для такой штуки как Custom Variant возможно некое подобие перегрузки операторов.

>namespace"ов
У каждого модуля своё пространство имён. Всё просто и понятно. И появилось это, пожалуй, пораньше, чем пространства имен в C++. Да и появились они там из-за отсутствия в языке понятия модульности, чтобы имена меньше конфликтовали. :o)

>удобных операторов ++, --, +=, -=,
inc, dec

>возможности импортировать/экспортировать класыы в dll
Есть, пакеты называется. :o)

to gek:
>Ну а еще там есть и множественное наследование, в котором сам
>черт ногу сломит.
Кстати, сама необходимость множественного наследования реализации под оооочень большим вопросом. А вот множественное наследование для интерфейсов в D8 обещают.

← →
NetBreaker666 (2003-03-29 22:03) [9]

> Ну а еще там есть и множественное наследование, в котором
> сам черт ногу сломит.

Ну, это откуда руки растут. Я тэк в полной мере этим пользуюсь.

> Ну а также есть страшной кривой класс String который по
> скорости
> не идет ни в какое сравнение с String в Паскале.

Во-первых на эту тему можно долго спорить (платформа, ОС, компилятор ?) Во-вторых:
Ну не используй. Зато *char куда быстрее String"a в паскале, и юзая его, понимешь почему не стоит использовать StringList1.Values[StringList2.Names[IntToStr(StringList3.Values["COUNT"])]] - что так любят участники форума :)

> >А в дельфи, например нет перегрухки операторов
> Перегрузка операторов нафиг не нужна. Кстати, для такой
> штуки как Custom Variant возможно некое подобие перегрузки
> операторов.

Иди ты нафиг со своим CustomVariant. А насчет того, что нафиг не нужна - ты наверное ни разу не пытался работать с 6-мерными вектроами в Delphi или хотя бы с комплексными числами. Я вот, ради одного этого удобства в свое время забил на проект в Delphi и перешел на TMT Pascal, потеряв при этом 2 месяца работы. (Тогда решил на C не переходить - с ASM"ом проблемы).

> >удобных операторов ++, --, +=, -=,
> inc, dec

??? char* uppercase(char* S) {while (S[++i]=upcase(s[i]));}
Нука, вставь сюда свой inc.

> >возможности импортировать/экспортировать класыы в dll
> Есть, пакеты называется. :o)

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

> Кстати, сама необходимость множественного наследования реализации
> под оооочень большим вопросом.

Ну здесь я с тобой отчасти согласен, хотя ты наверное с хардом не работал - там где много девайсов разных серий с разными параметрами, но в тоже время они имеют похожие интерфейсы и один и тот же принцип работы - а тебе надо сделать remote managing. (Ща вот с этим мужусь, хотя от сильных извращений я отказался )

← →
Тих (2003-03-29 22:16) [10]

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

← →
vuk (2003-03-29 22:19) [11]

to NetBreaker666:
>Нука, вставь сюда свой inc.
Ну, если Вам тах хочется, то легко. По сути один и тот же код. :o) Только про количество строк не надо. Языки разные.

procedure UpperCase(S : PChar);
begin
while s^ <> #0 do
begin
s^ := UpCase(s^);
inc(s);
end;
end;

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

>хотя ты наверное с хардом не работал
И при чём здесь множественное наследование?

← →
NetBreaker666 (2003-03-29 22:40) [12]

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

Спасибо, дорогой :) но не я спорить начал, а споры что лучше C или Delphi, кстати, уже давно считаются оффтопиком во всех крупных конференциях на тему ЯП.

> Ну, если Вам тах хочется, то легко. По сути один и тот же
> код. :o) Только про количество строк не надо. Языки разные.
>
> procedure UpperCase(S : PChar);
> begin
> while s^ <> #0 do
> begin
> s^ := UpCase(s^);
> inc(s);
> end;
> end;

Молодец, а теперь подумай, что удобней оптимизировать ? Понять, что цикл на C++ удобней реализовать через movsb гораздо легче, чем в цикле на Pascal. И вообще я сильно сомневаюсь, что в случае паскаля даже loopne будет использован. Вставит туда что-нибудь вроде or al,al; jz @OutLoop;

← →
vuk (2003-03-29 22:56) [13]

to NetBreaker666:
>а теперь подумай, что удобней оптимизировать ?
Я не спорю, оптимизатор в Delphi не фонтан. Но если уж хочется скорости, то чего уж там, прямо на ассемблере тогда и пишите.

Но мы вроде о языке говорили, а не об оптимизаторе.

← →
Anatoly Podgoretsky (2003-03-29 22:57) [14]

У тебя устаревшие сведения об оптимизации, movsb будет медленне, чем пара dec/jnz

← →
Anatoly Podgoretsky (2003-03-29 22:59) [15]

То же относится к LoopNE

← →
NetBreaker666 (2003-03-29 23:10) [16]

> to NetBreaker666:
> >а теперь подумай, что удобней оптимизировать ?
> Я не спорю, оптимизатор в Delphi не фонтан. Но если уж хочется
> скорости, то чего уж там, прямо на ассемблере тогда и пишите.
>
> Но мы вроде о языке говорили, а не об оптимизаторе.

Блин, тык качество оптимизации напрямую зависит от сложности анализа алгоритма. Я и говорю, что тот кусок на C++ легче поддается анализу чем тот на Pascal.

> Anatoly Podgoretsky © (29.03.03 22:57)
> У тебя устаревшие сведения об оптимизации, movsb будет медленне,
> чем пара dec/jnz
>
>
> Anatoly Podgoretsky © (29.03.03 22:59)
> То же относится к LoopNE

А откуда такие сведения ? Что-то я сильно сомневаюсь. Щас я уже на метро опаздываю - домой поеду, а завтра код в студию - сравним.

← →
Anatoly Podgoretsky (2003-03-29 23:19) [17]

Комплексные инструкции MOVS/SCAS/LODS/STOS/LOOP и многие другие на пентиумах, особенно на последних работают много медленнее комбинации простых, из за громадных пеналти.
Подробности можно получить из документации Интел по оптимизации процессоров Пентиум или на сайтах посвященных программированию и оптимизации на ассемблере, к конференции borland.BASM,
небольшое руговодство от Гуйдо Гайбелс есть на моем сайте.

Вот для 486 и ниже это было справедливо.

Я как то проверял, замена Loopnz, на пару инструкций dec, jnz ускорило обработку большого цикла в два раза.
Конечно это надо самостоятельно проверять, поскольку здравый смысл в это верить не хочет :-), я сам тоже не сразу поверил.

← →
VEG (2003-03-29 23:22) [18]

Object Pascal - роднее
Visual C++ - стильнее

← →
unreferenced (2003-03-29 23:27) [19]

C++ Rulezz

← →
NetBreaker666 (2003-03-29 23:28) [20]

> Комплексные инструкции MOVS/SCAS/LODS/STOS/LOOP и многие
> другие на пентиумах, особенно на последних работают много
> медленнее комбинации простых, из за громадных пеналти.

Нет, логика здесь кончено есть, но до Coppemine. А вот Coppermine, Tualatin и еже с ними - декодирование movsb - 2 такта, и dec jnz - два такта, но с точки зрения оптимизации "4 1 1" - использование movsb - рациональнее. Тем более при jnz возможны промахи системы предсказаний. Исправьте если что-то не так.

C++ vs Pascal: что роднее? Найти похожие ветки