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

M>Ёжики плакали, кололись, но продолжали есть кактус. Чего вам на C++ не пишется?
Еще как пишется. Просто надо же посмотреть новомодный технологии.

M>Да не понимаю. Если возникла ошибочная ситуация, почему не выбрасывается исключение?
В С++ существует раскрутка стека исключением при это вызываются деструкторы автоматических объектов и что ты будешь делать с двумя исключениями сразу?

M>Круто! Семь штук! Кстати, а при чём здесь Дельфи vs C++?
При том что STL это часть С++.

M>Ну напишу я на Дельфи не 7, а 97 таких контейнеров — Дельфи станет от этого круче?
Это 7 базовых контейнеров на их основе можно сделать что угодно.
И вобще попробуй придумать 97 различных структур данных
std::list — двухсвязный список
std::vector — массив
std::set — множество(любых объектов)на основа КЧ дерева
std::map — ассациотивный массив на основа КЧ дерева
std::deque — структура данных с произвольным доступом оптимизирована на вставку/удаление с конца или начала
std::stack — стек
std::queue — очередь
еще 90 структур данных пожалуйста

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

M>Ага, ну тогда понял.
M>

M>function CreateMyStructArray(count : integer) : PMyStructArray;
M>begin
M>  Result := (PMyStructArray) КакТамПолучитьПамять( count*sizeof(TMyStruct) )
M>end;
M>

M>Конечно, в отличие от шаблона тут придётся писать функцию CreateMyStructArray. Это, ясное дело, преимущество C++. Но считать такое мелкое преимущество чем-то гениальным и крутым — какой-то явный перекос.
Да ни хрена ты не понял. Посошник САМ совободит память и вызовет деструкторы у объектов если в процессе заполнения произойдет сбой.

M>Серьёзно? И что, на все тысячи функций WinAPI есть врапперы? И что, точно отражают семантику, не суживая способов применения? К примеру, есть такая утомительная область, как NT ACL. Наваляли на неё уже врапперы, или по старинке try/finally пишут?
хъ

try/finally это РУЧНОЕ освобождение ресурсов. В С++ освобождать ресурсы руками это дурной тон, а в дельфе без альтернатив.

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

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

S>> using в Net нужен только для освобождения системных ресурсов для их немедленного освобождения, во всех других объектах нет деструкторов в в обычном понимании, т.к. за освобождение памяти занятой объектом следит GC. Но через GC а так же через выделение памяти неподвласное GC итд можно многое, к сожалению еще не во все дебри Net залез.
WH>Все что GC попало уже не детерминировано. И using не всегда спасти может.
Есть области памяти неподвласные GC. Например когда using может не спасти если главная цель деструктора освобождение хэндлов системных ресурсов ????

S>>>>>> Например???? Шаблоны будут, что еще???
WH>>>>>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
S>>Насчет шаблонов в Net посмотри http://www.dotsite.ru/Publications/PublicationDetails.aspx?ID=115
S>> Почитай очень интересно, плю что предлагают SUN. Так что ты со своими шаблонами уже отстал от жизни.
WH> Ну прочитал. После С++ шаблонов каменный век. Конечно не на столько плохо как сейчас но всеравно близко нет той мощи.
WH>И ни слова о подключении реализации. Такое впечатление что ни кому не надо. Неполные типы это ИМХО штука безполезная особенно если сделать нормальное подключение реализации.

S>> Шаблоны,макросы по сути являются Copy-Paste-Replace и ни о каком ООП не идет и речи и легко реализуются без компиляторов путем генерации соответсвующих модулей на основании "Шаблона".
WH>Да ни фига подобного. Слова дилетанта. Это .НЕТ шаблоны можно генерить генератором, а С++ требуют информации о типах на много больше.

То есть ты утвержаешь что невозможно создать программу, которая генерит исходники из определенным образом написанных заготовок с конролем типов и выбора наилучшего алгоритма????

S>> А вот шаблоны в Net это действительно ООП.
WH>Обьясни мне пожалуйста кого волнует ФИЗИЧЕСКОЕ ООП. А что касается логической состовляющей то шаблоны в С++ очень объектно ориентированые.
Меня лично очень волнует.
WH>При помощи С++ шаблонов можно не только создавать обобщенные контейнеры но и выберать алгоритм наиболие подходящий типу.
WH>Например так Кто хотел определения наличия функции-члена?

Автор: MaximE
Дата: 13.09.03

WH>И много чего еще.

S>> Кроме всего прочего на данном этапе надежность кода встает на первый план (хотя мне это и не импонирует)
WH>Какие проблемы с надежностью С++ шаблонов мне ктонибудь обьяснит наконец?
Да втом, что шаблон он и в африке "Шаблон".

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

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

_O_>>Писать реализацию FSM-а ручками — это не правильно.
WH>Ы?


Угу, любой универсальный язык программирования для этого плохо подходит.
Тут нужно нечто иное, скажем у нас это выглядит так

signal ok;
statemachine S {
   start {
      outupt self.ok(); // сами себе посылаем, иная запись   ^self.ok();
      nextstate st1;
   }
   state st1;
      input ok {
         nextstate st2;
      }
   state st2;
      input * { // реагирования на любой сигнал
         stop;
      }
}

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

WH>>Все что GC попало уже не детерминировано. И using не всегда спасти может.
S> Есть области памяти неподвласные GC. Например когда using может не спасти если главная цель деструктора освобождение хэндлов системных ресурсов ????
Ну например если логика работы с ресурсов выходит за приделы одной функции.

WH>>Да ни фига подобного. Слова дилетанта. Это .НЕТ шаблоны можно генерить генератором, а С++ требуют информации о типах на много больше.
S> То есть ты утвержаешь что невозможно создать программу, которая генерит исходники из определенным образом написанных заготовок с конролем типов и выбора наилучшего алгоритма????
Я утверждаю что это на порядки болие сложная задача чем шаблон аля .НЕТ и в конце концов у тебя получится С++ компилятор.

WH>>Какие проблемы с надежностью С++ шаблонов мне ктонибудь обьяснит наконец?
S> Да втом, что шаблон он и в африке "Шаблон".
ГДЕ ПРОБЛЕМЫ С НАДЕЖНОСТЬЮ?

Тоже подведу итоги.
Если смотреть на влияние Языков на дальнейшее развитие средств программирования, то идеи Вирта и Хэйлсберга воплощенные в востребованных языках оказали намного больше влияния, чем идеи воплощенные в С и С++.
Некоторые размышления высказаны в http://www.rsdn.ru/Forum/Message.aspx?mid=383611&only=1

Автор: Serginio1
Дата: 15.09.03

И немного дополню от себя. Т.К. дальнейшее развитие связано с Net или аналогичной системы у меня лично сомнений не вызывает.
Структурированность кода и строгая типизация воплощенная Виртом в Паскале на данный момент воплощена во всех языках. Помню как еще во времена ДВК-2 после Фортрана и Васика просто наслаждался Else, Case,Record,Set, рекурсией, связными списками, вложенными процедурами итд.
Хэйлсберг еще в TP 6 ввел объекты имеющие одного общего предка а в Delphi развил идею компонентности которая сразу завоевала популярность. Кроме всего прочего в Delphi изначально встроена поддержка Строк и интерфейсов в том числе и посчет ссылок и в базовом классе TObject function GetInterface(const IID: TGUID; out Obj): Boolean;
Встроенная поддержка Вариантов в Delphi имеет отображение в Net через более продуманное функциональность базового класса Object. Свойства, события, Procedure of Object или TMetod тоже воплощены в делегатах (правда еще больше расширены и с поддержкой асинхронного вызова).
Кроме всего из-за одного общего разработчика целостность Delphi не вызывает сомнений.
Что же я вижу в Net из С++.
1. Структуры с поддержкой методов.
2. Перегрузка операторов, которую поддерживает только С#.
3. Перегрузка методов (Хотя она и существут в Delphi c 4 версии).
И все?????
Линию шаблонов которую так упорно гнет WolfHound легко реализуетс через интерфейсы, но это ООП в отличие от шаблонов. Кроме всего прочего не составляет труда написать программу для генерации исходников со всеми возможностями наблонов С++.
Хотя моему разгильдяйскому характеру и очень нравится С++ за его гибкость, но считаю выбрал правильный путь выбрав Delphi и Net.

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

M>Есть COM-объект. Необходимо вызывать какие-то его методы, использовать свойства при помощи позднего связывания, т.е. методов IDispatch. В скриптовых языках, в VB, в Дельфи это очень просто.

M>

M>var Excel : Variant;

M>begin
M>  Excel := CreateOleObject('Excel.Application');
M>  Excel.OpenFile('sdfsdfsdfsd.xls');
M>  Excel.Range("A1").Value=294;
M>end.
M>

Ну вот же ж блин. Ну нельзя на C++ наезжать по таким направлениям — не для того он предназначен.

Конечно, если накатать набор врапперов, то можно сделать и "по позднему связыванию". В результате код пользователя будет примерно таким:

ExcelWrapper excel(CREATE_BY_NAME); // Предположим, что CREATE_BY_NAME - константа,
                                    //определяющая способ создания объекта Excel.Application,
                                    // альтеннативой может быть передача конструктору GUID-а объекта.
excel.OpenFile("tra-la-la.xls");
excel.Range("A1") = 294; // Вот здесь избавимся от '.Value' за счёт перекрытия оператора присвоения значения

Лучше всего, конечно, сделать свою приблуду для импорта описаний .tlb а-ля директива #import.

Только это всё равно не решит глобальной проблемы COM, связанной с тем, что в реальности у тебя диспетчерский вызов может улететь в никуда, а QueryInterface на самом деле вернёт E_NOINTERFACE. Это — общая беда парадигмы позднего связывания. Кстати, Excel тоже тот ещё подарочек...

Ну и наконец, если в твоей программе логики помимо подключения COM-объектов мало, то кой чёрт тогда тебе C++ использовать? Бери тот же VB и полный вперёд!

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

S> Тоже подведу итоги.

S> Линию шаблонов которую так упорно гнет WolfHound легко реализуетс через интерфейсы, но это ООП в отличие от шаблонов.


ООП и шаблоны могут сосуществовать, шаблоны есть в UML 2.0, причем они даже мощнее чем в С++.

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


DOO>Если и сравнивать, то 6-м тогда уж. В крайнем случае с 5-м. Они намного круче 6-й VS

Незабываем добовлять ИМХО. Кому как. Вот раньше мне нравился Delphi IDE. Но если заниматься не только рисованием форм, то связка VS6 + VisualAssist — THE BEST (ИМХО ). Студия 7.1 тоже хороша, но почемуто MS обидела С++. Там редактор гораздо слабее чем для C#

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

WH>А слабо на дельфях нарисовать ГУЙ в ХР стиле?
Насколько я знаю в Delphi7 это возможно.

WH>>>... и написать интерфейс при помощи WTL не состовляет большого труда...
FWP>>Вот именно. НАПИСАТЬ. И ты не видишь в этом ничего дурного. А когда я говорю, что сортировку можно написать или использовать библиотеку — это почему-то неправильно. Двойные стандарты какие-то.
WH>Та видел как на WTL пишут ГУИ? Думаю что нет.
Да какая разница как? Главное РУЧКАМИ.

WH>>>Конкретно пожалуйста. Ни разу не встречал.
FWP>>Посмотри весь топик. Я приводил цитату вашего любимого папочки Страуструпа. Повторять лень.
WH>Это про забытый сопиконструктор чтоли? Дык они нужны только помошникам. Классы логики в 99.99% случаев имеют правильный.
Согласен. При определенных опыте и самодисциплине обойти опасные ситуации несложно. Но и опыт и самодисциплина понятия субъективные и к языку никакого отношения не имеют.

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

S> Линию шаблонов которую так упорно гнет WolfHound легко реализуетс через интерфейсы, но это ООП в отличие от шаблонов.

S>Кроме всего прочего не составляет труда написать программу для генерации исходников со всеми возможностями наблонов С++.
А это вобще сильно сказано Ты ее пол года писать будешь и еще два года отлаживать.(Если в коммандн то немного поменьше)

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

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

S>> Линию шаблонов которую так упорно гнет WolfHound легко реализуетс через интерфейсы, но это ООП в отличие от шаблонов.
WH>
S>>Кроме всего прочего не составляет труда написать программу для генерации исходников со всеми возможностями наблонов С++.
WH>А это вобще сильно сказано Ты ее пол года писать будешь и еще два года отлаживать.(Если в коммандн то немного поменьше)
Я не собираюсь писАть из-за невостребованности, да и уже появляются другие средства. Все зависит от ручек. Спасибо за твое мнение о моих возможностях.

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

S>>>Кроме всего прочего не составляет труда написать программу для генерации исходников со всеми возможностями наблонов С++.
WH>>А это вобще сильно сказано Ты ее пол года писать будешь и еще два года отлаживать.(Если в коммандн то немного поменьше)
S> Я не собираюсь писАть из-за невостребованности, да и уже появляются другие средства. Все зависит от ручек. Спасибо за твое мнение о моих возможностях.
Я не о твоих спасобностях я о сложносте задачи. Ты ее не дооцениваешь и сильно.
А вот о других средствах которые могут заменить шаблоны по подробней.

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

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

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

ну и к чему это всё нас приводит???

а к тому, что попытка сравнивать "мягкое" с "теплым" может привести только к одному выводу: "оно разное!", но вот оценить из в наминациях "хуже" и "лучше" уже не получится.

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

единственный светлый момент в этой дискуссии — это возможность новичкам удвидеть "+"-ы и "-"-ы инструментов в разного рода применениях, но здесь главное — "не пересолить", а то новичек это блюдо есть не будет и получится не дискуссия, а спор ради спора. оно нам надо?

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

AD>2mihailik: большая просьба, обдумывать свои ответы собеседнику, иначе есть
AD>вероятность того, что модератор перенесёт эту ветку в "Коллеги, улыбнитесь"
AD>

пока еще не унесет, но "по шапке надавать" может. обоим есть за что...

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

WH>А вот о других средствах которые могут заменить шаблоны по подробней.
http://www.osp.ru/news/soft/2003/09/15_01_print.htm
http://www.wn.ru/computers/16.09.2003/6.html

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

C>> А каким-нибудь Deplhi 3.0 по политическим соображениям не заставляют пользоваться для сравнения?
DOO>Если и сравнивать, то 6-м тогда уж. В крайнем случае с 5-м.

Ага, помнится, мне, для того, чтобы поработать в 5-м Delphi, приходилось переключать экран в какой-то жуткий режим, иначе уже Splash screen этой делфи мне намертво комп вешал. Так что для меня субъективно 4-й Делфи лучше 5-го. А 6-й студии афайк хронологически как раз 5-я делфя соответствует.
Кстати, кривая работа при нестандартных настройках видео (Large fonts, например) — классическая болезнь дельфийских прог, а иногда вот и самой делфийской IDE...

DOO>Они намного круче 6-й VS

Не забывай про "имхо"...
По моим представлениям, главный недостаток VS6 — плохая работа с шаблонами, что явно не тянет на аргумент в пользу Делфей.

FWP>>>>А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов.
WH>>>Ибо реализовать их нАмного сложнее чем кажется.
M>>Ага. Компилятор Java написали. Интерпретатор и JIT'тер написали. А шаблоны — нет, тут сложность невероятно высока.
WH>Ты просто не представляешь возможности шаблонов.

Ты считаешь, что реализовать шаблоны сложнее, чем написать хороший оптимизирующий компилятор?

M>>Правильно, а фиг ли что файл не сохранился. Нужно было почаще Backup делать
WH>flush в деструкторе... гениально.

А, так ты Flush в try/finally делаешь?

А шуму-то было, мол, в C++ try/finally не нужен никогда.

А>>>4) Рекомендательный характер вызова Dispose(). Поубивал бы за это
M>>Ага, не поняли они в Редмонде твоей таинственной русской души.
WH>Ага и потом народ долго думает почему на тачке с 256М программа работает прекрасно, а на серваке с двумя гигами вешается в месте с виндой.

А при чём здесь объём памяти? В C# всё прозрачно расписано, когда и в каких случаях стоит вызывать Dispose. Если не следуешь советам, сам виноват.

WH>Ну что за бред ты тут несешь. MSDN ни кто не отменял. А вот слушать все что говорит братва из MS

Если я тебя правильно понял, ты считаешь, что драйвера нужно писать на продвинутом C++ с STL и прочими наворотами?