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

VD>>Сказки расказываем в милиции. Первая дельфи ошбки по одной отплевывала.
FWP>М.б. Теперь 95й год трудно вспомнить. Но отложилось в памяти,что Delphi ошибки вываливала не так как TP/BP. Вот они точно по одной.

16-битный компилятор первой дельфи был развитием bp7. Посмотри глазами bpc.exe и dcc.exe — они очень похожи.

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

_O_>Есть задачи, где С — оптимален. (например decode/encode для ASN.1)

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

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

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

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

WH>Дык конибудь покажите мне уневерсальную сортировку на паскакале. Пусть жаде придеться писать коматоры. Слабо?
Ну почему ты такой упертый! Ну хорошо я повторю:
В Delphi шаблонов нет. Поэтому это сделать нельзя приемлемым для практического использования способом. Но всегда можно найти соответствующую ПРАКТИЧЕСКИМ НУЖДАМ библиотеку!

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.

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


D>> 2-е Почему в объекте сыне я могу вызвать конструктор
D>> родителя только перед выполнением своего конструктора.

S>Потому что кое-кто решил, что от этого бывает меньше всего проблем. И правильно.

И почему же это правильно? Не сложно придумать ситуацию, когда это как раз таки не верно.
S>Best regards,
S> Sergey.

Hello, DOOM!
You wrote on Fri, 05 Sep 2003 10:58:59 GMT:

D>>> 2-е Почему в объекте сыне я могу вызвать конструктор
D>>> родителя только перед выполнением своего конструктора.

S>> Потому что кое-кто решил, что от этого бывает меньше всего проблем. И
S>> правильно.

D> И почему же это правильно?

Потому что не следует поперек батьки в пекло лезть

D> Не сложно придумать ситуацию, когда это как раз таки не верно.

Ты придумай, а я постараюсь тебе показать, где ты неправ


Best regards,
Sergey.

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

DOO>2-е Почему в объекте сыне я могу вызвать конструктор родителя только перед выполнением своего конструктора.

Родитель (а их, кстати, бывает и несколько) почти ничем не отличается от членов сына, у которых тоже надо вызвать конструкторы. В следующей серии захочется и их вызывать когда вздумается?

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

_>Здравствуйте, _Obelisk_, Вы писали:
_O_>>Есть задачи, где С — оптимален. (например decode/encode для ASN.1)
_>Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.
В отпуске немного поковырялся с Linux. Посмотрел тектсты ядра, а там, какой ужас , ни шаблонов, ни классов. Значит жив курилка! В смысле голенький С. Хотя, конечно это не тот С, который был в 1972 году.

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

DOO>1-е Какого черта пости для каждого объекта я должен писать такую тучу конструкторов.
Не для каждого, а только для тех в которых ты мудришь с ресурсами. А их поверь очень мало.
Ибо нужно только один раз написать класс хозин какого либо ресурса и дальше пользоваться им.
В 99% случаев компилятор генерирует правильные конструктор копирования и копирующие присваивания.
DOO>2-е Почему в объекте сыне я могу вызвать конструктор родителя только перед выполнением своего конструктора.
Потомучно в дельфе нет конструкторов. Те то что там называется конструктором в самом деле является лиш процедурой которая вызывается после создания объекта.
DOO>3-е (к другому вопросу) Универсальная сортировка это TList.Sort.
Еще раз отсортируй мне массив.
Ы?

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

FWP>Да в том и дело, что по всей книге таких "предостережений" десятки, если не сотни.
FWP>Почему лично я предпочитаю виртовские языки заместо Сиплюхплюха, так это потому, что мне не надо помнить сотни всяких исключений из правил. В этом смысле даже С более безопасен, чем С++. Если конечно не извращаться с адресной арифметикой.
Нука приведи мне хотябы десяток

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

_>>Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.
FWP>В отпуске немного поковырялся с Linux. Посмотрел тектсты ядра, а там, какой ужас , ни шаблонов, ни классов. Значит жив курилка! В смысле голенький С. Хотя, конечно это не тот С, который был в 1972 году.

Кобол тоже жив. Но я все равно не понимаю, ради какой великой цели (кроме поддержки старого продукта) надо описывать переменные в начале функции, а не при первом использовании, много раз писать typedef struct structtag structname, закрывать однострочные комментарии, делать #define вместо inline и кучу других устаревших глупостей? И зачем заводить кусты функций, берущих первым параметром указатель на структуру, если синтаксис obj.fn(...) удобнее, чем fn(obj, ...) и сокращает код этой самой fn за счет избавления от кучи "this->"?

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

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

WH>>Дык конибудь покажите мне уневерсальную сортировку на паскакале. Пусть жаде придеться писать коматоры. Слабо?
FWP>Ну почему ты такой упертый! Ну хорошо я повторю:
FWP>В Delphi шаблонов нет. Поэтому это сделать нельзя приемлемым для практического использования способом. Но всегда можно найти соответствующую ПРАКТИЧЕСКИМ НУЖДАМ библиотеку!
Вот только приходится использовать какойнибудь изварат типа TList либо писать ручками...

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

FWP>>В отпуске немного поковырялся с Linux. Посмотрел тектсты ядра, а там, какой ужас , ни шаблонов, ни классов. Значит жив курилка! В смысле голенький С. Хотя, конечно это не тот С, который был в 1972 году.

_>Кобол тоже жив. Но я все равно не понимаю, ради какой великой цели (кроме поддержки старого продукта) надо описывать переменные в начале функции, а не при первом использовании, много раз писать typedef struct structtag structname, закрывать однострочные комментарии, делать #define вместо inline и кучу других устаревших глупостей? И зачем заводить кусты функций, берущих первым параметром указатель на структуру, если синтаксис obj.fn(...) удобнее, чем fn(obj, ...) и сокращает код этой самой fn за счет избавления от кучи "this->"?
Вы видимо плохо представляете современный ANSI C. Ничего такого писать не надо. Да и Linux назвать устаревшим продуктом — это, пожалуй слишком черезчур.

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

WH>Вот только приходится использовать какойнибудь изварат типа TList либо писать ручками...
Да уж приходится. Не все ж мышкой программить . Ну и в VC тож кое-что ручками писать приходится. То что в Delphi уже есть.
Я ж согласился, что шаблонов нет и это можно с натягом считать недостатком. Но ведь как-то обходятся без них миллионы программеров на VB, Java, C#, Oberon, Ada и т.д. И мы как-нибудь

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

_>>описывать переменные в начале функции, а не при первом использовании,
_>>много раз писать typedef struct structtag structname,
_>>закрывать однострочные комментарии,
_>>делать #define вместо inline
FWP>Вы видимо плохо представляете современный ANSI C. Ничего такого писать не надо.

Пожалуйста, по пунктам, по возможности ссылаясь на стандарт. И ни слова о C99 — под "голеньким C" понимается вовсе не он, а C89.

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

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

_>Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.

Иногда не нужны ни виртуальные функции, ни RTTI ни даже динамическая память.

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


_>Пожалуйста, по пунктам, по возможности ссылаясь на стандарт. И ни слова о C99 — под "голеньким C" понимается вовсе не он, а C89.

Вы не сталкивались просто с разработкой под DSP, RTOS-ы и Embedded платформы.

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

_>>Не могу представить себе задачу, для которой C++ с отключенными exceptions и RTTI будет хуже, чем чистый C.
_O_>Иногда не нужны ни виртуальные функции, ни RTTI ни даже динамическая память.

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

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

_>>Пожалуйста, по пунктам, по возможности ссылаясь на стандарт. И ни слова о C99 — под "голеньким C" понимается вовсе не он, а C89.
_O_>Вы не сталкивались просто с разработкой под DSP, RTOS-ы и Embedded платформы.

Разве? Пять лет мучался с ТКМ-51, где архитектура не очень-то заточена под C, даже push кладет два байта в стек в неправильном порядке. Кстати, приходилось использовать на тамошнем C структуры указателей на функции, чтобы эмулировать VMT. Или это уже на МФК...