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

WH>Он наверно про ту байку что винду начинали писать на паскале.

Да нет, я про MAC OS

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

S> Для различного рода задач нужны свои инструменты. Шаблоны, Inline, сматрпоинтеры очень хорошая вещь которой мне не достает, но для различного рода задач можно абсолютно безболезненно без каких либо затруднений обходится без них.
Это где? В простеньком калькуляторе?
S>По поводу нетипизированой памяти то не вижу в этом криминала особенно при написании универсальных классов (функций) которые оперируют только размером записи, и писать шаблон нет никакого смысла.
А вот я вижу. Сырая память это потеря надежности, скорости,...
S> С другой стороны не вижу абсолютно никакого смысла на данном этапе сравнивать умирающие технологии.
Дельфя вимерает это факт, а вот на счет С++ это ты оочень зря.
S>Лучше смотреть на Net, особенно когда огромный набор процессоров в том числе и 64 разрядных.
Да смотрел я на него. Сырой.
S> А все лучшие идеи должны использоваться в новых технологиях, в том числе и поизвращаться с нетипизированой памятью и там придется, но с большими трудностями.
Вот только пока далеко не все лучшие идеи используются в шарпе.

Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, AlexK, Вы писали:
AK>>честно говря в первые слышу... просвети темного человека, т.е. меня... что же это на Паскале из ОС'ок писали?
AJD>MAC OS. Ранние версии были вообще полностю на паскале. Для версий 8.х-9.х конечно много кода написано на С, но API остался паскалевский.

не удивительно теперь почему Маки не в чести нынче...

по большому счету С, а не С++ единственный язык который портанут/написан под почти все платформы...
и он пока единственный вариант который дает приемлемое качество и скорости...

да вот еще один стандарт де факто:
— все операционки имеют в своем распоряжении CRT либу (набор минимальных функций, которые позволяют нормально програмить)
— паскаль такой либы не имеет и ссылаеться на системную... разумееться либа эта в основном написана на С или asm (QNX — пример)


а то что на паскале смогли написать — так это герои, которых желательно знать в лицо!
что лишний раз доказывает что не в языке дело, а в ДНК... или руках (смотря кому что роднее)

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

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

S>> Для различного рода задач нужны свои инструменты. Шаблоны, Inline, сматрпоинтеры очень хорошая вещь которой мне не достает, но для различного рода задач можно абсолютно безболезненно без каких либо затруднений обходится без них.
WH>Это где? В простеньком калькуляторе?

Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше. Да и API написан на Asme и С где типизацией если и пахнет то ...
Зачем огульно бросаться словами??? Не прав.
S>>По поводу нетипизированой памяти то не вижу в этом криминала особенно при написании универсальных классов (функций) которые оперируют только размером записи, и писать шаблон нет никакого смысла.
WH>А вот я вижу. Сырая память это потеря надежности, скорости,...

Все можно достаточно хорошо оптимизировать, для этого голова и дана, а не только пользоваться "шаблонами" в прямом смысле этого слова.
S>> С другой стороны не вижу абсолютно никакого смысла на данном этапе сравнивать умирающие технологии.

WH>Дельфя вимерает это факт, а вот на счет С++ это ты оочень зря.

Время рассудит, но Delphi найдет свою нишу в Net да и у Delphi с C# намного больше общего чем у C# с С++, да и M$ помоему не особо горит желанием развивать Native компиляторы.

S>>Лучше смотреть на Net, особенно когда огромный набор процессоров в том числе и 64 разрядных.
WH>Да смотрел я на него. Сырой.

S>> А все лучшие идеи должны использоваться в новых технологиях, в том числе и поизвращаться с нетипизированой памятью и там придется, но с большими трудностями.
WH>Вот только пока далеко не все лучшие идеи используются в шарпе.
Например???? Шаблоны будут, что еще???

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


AK>да вот еще один стандарт де факто:
AK>- все операционки имеют в своем распоряжении CRT либу (набор минимальных функций, которые позволяют нормально програмить)
AK>- паскаль такой либы не имеет и ссылаеться на системную... разумееться либа эта в основном написана на С или asm (QNX — пример)

ИМХО — это предрассудки. CRT либа может быть с успехом написана на паскале. Это просто зависит от реализации компилятора. То что паскаль от борланда юзает высокоуровневое API, еще не значит что паскаль _в_принципе_не_мевозможно писать низкоуровневый код (конечно это не так удобно, как на С).


AK>а то что на паскале смогли написать — так это герои, которых желательно знать в лицо!
AK>что лишний раз доказывает что не в языке дело, а в ДНК... или руках (смотря кому что роднее)

Эт верно

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

AK>...что лишний раз доказывает что не в языке дело, а в ДНК... или руках (смотря кому что роднее)

Да нет, дело в рынке.

Ну зачем писать 2 либы, делающие одно и тоже, но на двух языках. Представляете, ядро Windows, написанное на C, и то же самое, но на Fortran-е...

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

Отладка одна сколько сил отнимет...

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

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

AK>>...что лишний раз доказывает что не в языке дело, а в ДНК... или руках (смотря кому что роднее)

A>Да нет, дело в рынке.

A>Ну зачем писать 2 либы, делающие одно и тоже, но на двух языках. Представляете, ядро Windows, написанное на C, и то же самое, но на Fortran-е...

A>Буржуины началали первыми, а деньги они на ветер не бросают. Не прибыльно это дело. Куда проще сделать одну, а потом к ней описалово дать, ну или там заголовочные файлы для нескольких языков дать...

A>Отладка одна сколько сил отнимет...

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

Грубая аналогия: гаечный ключ... гайку можно и руками закрутить, но при помощи ключа это делать намного удобнее. продлим аналогии — у паскаля ручка чуть короче чем у с++. а по функционалу они равны... ( имелось ввиду что при помощи с++ можно намного сильнее закрутить гайки (рычаг больше), чем при помощи паскаля... усилия разные прикладывать просто надо )

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

по-этому спор какой из двух "ключей" круче надо прекращать. бред это!
кому как нравиться, тот так и живет. Мне вот очень с++ нравиться, но пишу я щас с#... а он мне не нравиться...

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

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

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

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

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

WH>Дельфя вимерает это факт...

"Какие ваши доказательства?!!"

Категорически не согласен. 10 лет работает OP. То, чем мы пользуемся сейчас, придумано когда?.. А... давно придумано. И инструментом для решения определённых задач быть не перестало.

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

Не развивается качественно — да, соглашусь. Одно количество прёт.

Мне кажется, Борланды средства распыляют: Дельфи, Билдер, Куликс, Болд, БДЕ, ИБ, ...

А если бы взяли направление, сделали, перевели средства на другое, опять сделали и т.п. С начала и до ума.

Ностальгия: какой BP7 был, "трёхплатформенный"... А BCPP...

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

WH>>Дельфя вимерает это факт...
A>"Какие ваши доказательства?!!"

Да очень просто. Дельфи занимала нишу приложений с оочень большим колличеством формочек. Грубо говоря ГУЙ к БД. Сейчас туда пришол C# который делает дельфю по всем параметрам. Он даже частично С++ потеснил.

А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.

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

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

WH>>>Дельфя вимерает это факт...
A>>"Какие ваши доказательства?!!"

WH>Да очень просто. Дельфи занимала нишу приложений с оочень большим колличеством формочек. Грубо говоря ГУЙ к БД. Сейчас туда пришол C# который делает дельфю по всем параметрам. Он даже частично С++ потеснил.

WH>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.

Уважаемый WolfHound, то что Delphi уступает в своем развитии C++ Вам уже много раз говорили. Но это еще не значит, что это уже мертвый Язык. В свое время когда появился первый Паскаль, еще помню писал на ДВК-2 типизация, различные конструкции были намного богаче чем в других языках в том числе и С. (правда в отличие от Васика уж очень долго проходила компиляция, но зато скорость выполнения покрывала все издержки). Но прошло время и тоже появилось и в других языках, но остались и Анахронизмы. Новый Виток новые языки, новые платформы. Если Delphi (в том числе и в Net) умрет, то не думаю, что это пойдет на пользу и Вне конкуренции M$ не особо будет шевелиться.
А может они решили все силы кинуть на Net, что бы не разбрассываться ??? Лучше совсем немного подождать, а потом обратно вернуться к данному разговору.

m>> Вот тебе тоже вопрос на тему как применить микроскоп для забивания
m>> гвоздей. Как в C++ отсортировать виндовый SafeArray, причём в режиме
m>> thread-safe?

S>Замечательный вопрос А как его вообще отсортировать, если часть объектов, что в нем лежат, могут оказаться многомерными массивами, часть — указателями на объекты (IDispatch), а остальные — типа currency

Ну так я о том же.

Шаблоны годятся для сортировки определённых входных данных. Что в C++, что в Delphi.

WH>А потом нам будет нужен бинарный поиск по отсортированому массиву, а потом удаление элементов при выполнение какого либо условия,...

А чем TList не устраивает? Религиозные причины?

M>>Или крутизна шаблонов как раз и заключается в работе со встроенными типами?
WH>Не со встроеными, а со всеми.

А какие проблемы применить TList ко всем типам?

M>>Игрушечки какие-то

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

Хм. Ты хочешь сказать, что размер C-плюснутого кода в разы меньше Дельфийского? Что-то сомневаюсь.

Возможно, смартпойнтеры действительно помогают в разы — но только по сравнению с тем же C++ без смартпойнтеров. А в Дельфи и без них всё уже легко, аккуратно и прозрачно.

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

WH>Да очень просто. Дельфи занимала нишу приложений с оочень большим колличеством формочек. Грубо говоря ГУЙ к БД. Сейчас туда пришол C# который делает дельфю по всем параметрам. Он даже частично С++ потеснил.

Ну чего же к БД только. Дельфи позиционируется, как средство разработки прикладных приложений. К БД его повело только потому, что разработчик (Борланд) кроме средств разработки продвигал ещё и СВБД свои.

Для прикладывания Дельфи очень даже ничего.

WH>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.

Речь об "...OP против C++..." или "Дельфи против Студии"?

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

S>А может они решили все силы кинуть на Net, что бы не разбрассываться ??? Лучше совсем немного подождать, а потом обратно вернуться к данному разговору.

Нет, это чистой воды сговор, статья ... не помню, какая.

Борланд да Майкрософт в очередной раз решили поделиться/помириться. Потому что, каким бы ты Гигантом не был, а силёнок на всех не хватит.

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

M>А чем TList не устраивает? Религиозные причины?
Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...
M>>>Или крутизна шаблонов как раз и заключается в работе со встроенными типами?
WH>>Не со встроеными, а со всеми.
M>А какие проблемы применить TList ко всем типам?
ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?

M>Хм. Ты хочешь сказать, что размер C-плюснутого кода в разы меньше Дельфийского? Что-то сомневаюсь.
Повторюсь

Например писал я OPC server там куча методов должны возвращать массивы созданные при помощи CoTaskMemAlloc. На С++ я за пять минут сотворил шаблон помошник который проверял былали выделена память, следил за выделеной памятью, инициализировал память и в случае чего вызывал деструкторы, а самое главное прикидывался массивом и уже когда все закончино и гарантировано не будет исключений я забирал заполненый массив и возвращал из функции.
Использование ваглядит примерно так

STDMETHODIMP COPCServer::GetItemProperties( 
/* [in] */                                LPWSTR szItemID,
/* [in] */                                DWORD dwCount,
/* [size_is][in] */                        DWORD *pdwPropertyIDs,
/* [size_is][size_is][out] */            VARIANT **ppvData,
/* [size_is][size_is][out] */            HRESULT **ppErrors
)
try
{
    ....
    CoArray<CComVariant> data(dwCount);
    CoArray<HRESULT> errors(dwCount);
    ....тут можно творить что угодно...
    *ppvData=data.Detach();
    *ppErrors=errors.Detach();
    return S_OK;
}
com_catch_all()//Ловит определенный типы исключений, достает из них HRESULT и возвращает. 
//Если прилетело не поймешь что просто возвращает E_FAIL

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

M>Возможно, смартпойнтеры действительно помогают в разы — но только по сравнению с тем же C++ без смартпойнтеров. А в Дельфи и без них всё уже легко, аккуратно и прозрачно.
Ой не надо на дельфе начинается try finaly hell.

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

S>>> Для различного рода задач нужны свои инструменты. Шаблоны, Inline, сматрпоинтеры очень хорошая вещь которой мне не достает, но для различного рода задач можно абсолютно безболезненно без каких либо затруднений обходится без них.
WH>>Это где? В простеньком калькуляторе?

S> Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше.
И в какой БД ты не типизированую пимять нашол?
S>Да и API написан на Asme и С где типизацией если и пахнет то ...
И очень на прасно. Хотя в те времена когда это все писалось выбора небыло. К томуже это язаки низкого и среднего уровня, а мы про ЯВУ разговариваем.
S> Зачем огульно бросаться словами??? Не прав.
Нда? Смотри выделеное и скажи что из этого не нужно в ЯВУ? Разве что смартпоинтеры там где есть GC и то иногда хочется детерминированого управления жизнью объекта.

WH>>А вот я вижу. Сырая память это потеря надежности, скорости,...
S> Все можно достаточно хорошо оптимизировать, для этого голова и дана, а не только пользоваться "шаблонами" в прямом смысле этого слова.
Нда? Взять хотябы сортировку сравнение через вызов функции по указателю, swap также и что ты тут оптимизировать собрался?
Или писать сортировку под каждый тип?

S> Время рассудит, но Delphi найдет свою нишу в Net да и у Delphi с C# намного больше общего чем у C# с С++, да и M$ помоему не особо горит желанием развивать Native компиляторы.
Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.

WH>>Вот только пока далеко не все лучшие идеи используются в шарпе.
S> Например???? Шаблоны будут, что еще???
Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
А сейчас все очень убого. Почти на уровне дельфи.

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

A>Ну чего же к БД только. Дельфи позиционируется, как средство разработки прикладных приложений. К БД его повело только потому, что разработчик (Борланд) кроме средств разработки продвигал ещё и СВБД свои.
A>Для прикладывания Дельфи очень даже ничего.
Во первых я сказал грубо. Во вторых куда это ты ее приложить собрался? Уж не к задаче ли где 90% ГУИ? И всеравно против шарпа не тянет. Ну ни как.

WH>>А на поле нативных высокопроизводительных ресурсожрущих приложений дельфя против С++ ой не смешите мои тапочки.
A>Речь об "...OP против C++..." или "Дельфи против Студии"?
Смотри сабж. Ну если так хочется можно ОП против С++. Ну и что изменится? В ОП от этого шаблоны не появится.

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

S> Уважаемый WolfHound,
Вот на вы переходить не надо выглядит так что драться собрался
S>то что Delphi уступает в своем развитии C++ Вам уже много раз говорили.
Я бы сказал безнадежно уступает. Если с этим ни кто не спорит то почему постоянно появляется какойнибудь "куул программер" который знает дельфю хуже меня(а я ее уже почти забыл и не желею)и начинает вопить С++ сакс?
S>Но это еще не значит, что это уже мертвый Язык.
И чтоже его может спасти? Добавят шаблоны, множественное наследование, приведут в порядок систему типов,...? И чем он тогда будет от С++ отличатся кроме небольшого различия в синтаксисе?
S>В свое время когда появился первый Паскаль, еще помню писал на ДВК-2 типизация, различные конструкции были намного богаче чем в других языках в том числе и С. (правда в отличие от Васика уж очень долго проходила компиляция, но зато скорость выполнения покрывала все издержки). Но прошло время и тоже появилось и в других языках, но остались и Анахронизмы. Новый Виток новые языки, новые платформы. Если Delphi (в том числе и в Net) умрет, то не думаю, что это пойдет на пользу и Вне конкуренции M$ не особо будет шевелиться.
С++ это язык для создания других языков. Причем при наличии определенных знаний и воображения это делается очень легко.
Например boost::sprit позволяет прямо на С++ записывать EBNF граматику.

A simple EBNF grammar snippet:

    group       ::= '(' expression ')'
    factor      ::= integer | group
    term        ::= factor (('*' factor) | ('/' factor))*
    expression  ::= term (('+' term) | ('-' term))*

is approximated using Spirit's facilities as seen in this code snippet:

    group       = '(' >> expression >> ')';
    factor      = integer | group;
    term        = factor >> *(('*' >> factor) | ('/' >> factor));
    expression  = term >> *(('+' >> term) | ('-' >> term));

Ну и естественно смартпоинтеры и прочие чернорабочие.
S>А может они решили все силы кинуть на Net, что бы не разбрассываться ??? Лучше совсем немного подождать, а потом обратно вернуться к данному разговору.
А какое отношение .NET имеет к сабжу?

Ну-ну...
Может MS ещё ещё WinAPI для Cobol, Logo, php и пр.?..

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

DOO>Кстати, а много ли люди видали драйверов написанных на С++, а не на С?
DOO>MS сами рекомендуют невыеживаться и писать не на асмах и С++ дрова, а на обычном С. Да и хороший пример ОС разработанной на языке высокого уровня это *nix — между прочим тоже С, а не C++.

Э... типа... опаньки...
Если Вы не видели критичного ко времени софта, написанного на С++, не надо говорить, что его нет :]
почитайте Страуструпта — Дизай и эволюция С++ — если найдёте, и тогда поймёте многое, а вот такие высказывания — это полная чушь.