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

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

Наверное, шаблонами мало пользуетесь

Скорость ребилда не увеличится — линкер работает только последние пять минут из часа. А вот скорость билда после мелких изменений возрастет многократно. Только пока все это в мечтах...

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

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


_>>Вобщем делфи штука не плохая, но у C++ (VS) охватываемое поле деятельности куда шире, где-то они пересикаются где-то нет. Все что можно сделать на делфе можно повторить на C++, наоборот вряд ли...

DOO>Пример, пожалуйста.

Не видел ни одного промышленного CAD/CAM/CASE средства, ориентированного на разработку софта для real-time и embedded систем (и для разработки самих систем), которое бы было сделано на Delphi.

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

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

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

_>Наверное, шаблонами мало пользуетесь

Наоборот, очень часто пользуемся.

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

_O_>>>У нас проект как раз в три раза больше , а полный билд идет всего час.
_>>Наверное, шаблонами мало пользуетесь
_O_>Наоборот, очень часто пользуемся.

Тогда странно. Какие конструкции замедляют компиляцию больше всего, я пока не выяснял.

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

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

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

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

DOO>>>>У меня тоже вроде нет. Но VS вообще довольно глючная...
J>>>Не знаю как сейчас и Дельфи, но когда я писал на 4-м Билдере, глюков было до фига.
WH>>Я сейчас пишу на шестом. Сказать что он глючит это ничего не сказать.

DOO>Билдеры к делу не относятся, там по-моему даже компилятор сишный стоит доисторический, а весь VCL перегнан с паскаля(не руками).

Ну, VCL вообще никто не трогал. Просто под Cбилдером были написаны врапперы и только. А так при отладке ты заходишь в обычный код на Delphi(Pascal).

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

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

LVV>>1. Я дельфи последние совсем не знаю. Наверное стал такой же монстр, как и все остальное. Вполне возможно, что и компилирует медленно.
WH>Дельфи та она конечно всеравно быстрее. Это я к тому что мне по барабану сколько момпилится один фаил 0.5с или 0.05
WH>А пару тройку минут раз в день на полный ребилд я подождать могу.
LVV>>2. РСН — это как расшифровать? (Ну не понял я Вашу аббревиатуру )
WH>Pre Compiled Header

А мне вот на полный ребилд более 40 минут ждать надо.
Никакие РСН не помогут.
Без РСН я даже боюсь предположить, сколько уйдет времени

M>В Дельфи принято исправлять ошибки компиляции в таком режиме. Компилируем, IDE выбрасывает курсор на первую ошиюку. Исправляем — и опять компилируем. Курсор на следующей ошибке.
M>Это получается ровно столько же по времени, как и просто для перехода к следующей ошибке.
M>Такая вот скорость компиляции. Это тебе не полсекунды, это просто моментально.

А в С++ принято стараться не делать ошибки. Это и компиляцию ускоряет, и вообще.
А если серьезно, я в таких случаях компилирую только текущий файл, а это на любом проекте быстро. А большинство опечаток мне и VA без всякой компиляции показывает...

C> А в С++ принято стараться не делать ошибки. Это и компиляцию ускоряет, и вообще.

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

WH>>Во всех остальных областях дельфи проигрывает С++ с треском.
M>Кгм. В удобстве C++ проигрывает всем, кому только можно. Разве что ассемблеру не проигрывает.

Типа я никогда на дельфе не писал...
В дельфе надо следить за ресурсами ручками, а это так задалбывает...
А если писать с использованием исключений то код превращается в кучу try/finally что не добавляет ни читабельности ни скорости, а как оно задалбывает... В С++ все куда проще захватил ресурс в конструкторе, освободил в деструкторе и плевать хотел на исключения и ветвистую логику. И обрабатывать исключения буду там где удобно, а не там где ресурс захватил.
Еще очень часто есть куча рутинной работы которую в 99% случаев можно свалить на шаблоны.
STL контейнеры это вобще штука не заменимая. Если знаешь что тебе надо и свойства контейнеров то самопальные контейнеры не нужны в 99.999% случаев.
И многое другое...

_>>Вобщем делфи штука не плохая, но у C++ (VS) охватываемое поле деятельности куда шире, где-то они пересикаются где-то нет. Все что можно сделать на делфе можно повторить на C++, наоборот вряд ли...
DOO>Пример, пожалуйста.

Чтобы особо не фантазировать, спрошу, ты драйверов/операционок много на Делфах написанных видел? А 3D шутеров каких-нить? Знаю, что последнее можно, но какой ценой...

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

M>Что я себе действительно уяснил — что идеальных компиляторов и средств разработки не бывает

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

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


C>Чтобы особо не фантазировать, спрошу, ты драйверов/операционок много на Делфах написанных видел? А 3D шутеров каких-нить? Знаю, что последнее можно, но какой ценой...

На Дельфях не видел. Зато видел на паскале. MAC OS например...

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

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

J>>>Так тут другое дело, что память и выделяется и освобождается, когда надо, но сама. Хотя такими указателями я сам редко пользуюсь, но это не из-за глючности, а просто редко бывает запутанный код, что можно забыть освободить. Просто я стараюсь сразу после выделения памяти писать, где она освобождается.
WH>>А вто это очень зря. Для того чтобы я не использовал смартпоинтер нужна ооочень веская причина. Я даже с ходу придумать не могу.

J>Ну что ж, попробую пользоваться ими везде.

Только знай, что существует много вариаций классов смартпоинтеров, и что в разных случаях нужно использовать разные классы. Смотри, например, здесь и документацию по std::auto_ptr.

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

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

WH>>>Во всех остальных областях дельфи проигрывает С++ с треском.
M>>Кгм. В удобстве C++ проигрывает всем, кому только можно. Разве что ассемблеру не проигрывает.
WH>
WH>Типа я никогда на дельфе не писал...
WH>В дельфе надо следить за ресурсами ручками, а это так задалбывает...
WH>А если писать с использованием исключений то код превращается в кучу try/finally что не добавляет ни читабельности ни скорости, а как оно задалбывает...

Как я с тобой согласен! И в C# подобная дребедень. using немного спасает ситуацию, но только в самых простых случаях. Особенно меня прикалывает тот факт, что IDispose.Dispose() может выбросить исключение. После этого я не могу понять как на C# можно писать надежные программы.

WH> В С++ все куда проще захватил ресурс в конструкторе, освободил в деструкторе и плевать хотел на исключения и ветвистую логику. И обрабатывать исключения буду там где удобно, а не там где ресурс захватил.
WH>Еще очень часто есть куча рутинной работы которую в 99% случаев можно свалить на шаблоны.
WH>STL контейнеры это вобще штука не заменимая. Если знаешь что тебе надо и свойства контейнеров то самопальные контейнеры не нужны в 99.999% случаев.
WH>И многое другое...

Самый главный минус Дельфей, и их внебрачного урода Builderа, — это завязка всего под VCL. В Дельфях все обьекты автоматически наследуются от TObject, что в результирующий экзешник добавляет такое количество кода, что потом листинг функций в файле смотреть страшно.

Про TStringList и вообще любые списки, TListView и прочие Борландовские извращения говорить не буду. Например, почему TListItem::Data имеет тип данных TObject*? Я в эту самую дату загоняю свои типы дынных, и пользоваться огромадным кол-вом reinterpret_cast меня уже плющит.

Что еще нельзя делать в Delphi/Builder? Нельзя эффективно перехватывать оконные сообщения для создания кустомизированных контролов "на лету". Необходимо создавать свои собственные компоненты.

Код Дельфи не кроссплатформенный, как здесь кто-то утверждал, если не пользоваться CLX. Если пользовать, придется таскать n-мегабайтовые библиотеки. Правда, в случае Buildera, это и так приходится делать...

Нe спорю, Borland'овские продукты красивы и в общем удобны, но... Писать не-GUI и серьезные вещи IMHO надо на С++.

WH>В дельфе надо следить за ресурсами ручками, а это так задалбывает...

Эт смотря за какими. Например, при использовании интерфейсов всё за счёт "скрытых" AddRef/Release отлично освобождается.

procedure abc;
var s: IMyInterface;
begin
  s:=TMyObject.Create;
    s.DoSome;
    ...
    // и никаких забот — само освободится
end;

C++ вызывает деструкторы только для объектов в стеке. Если объект используется через указатель — точно так же заботится приходится самому. Просто в Дельфи все объекты — указатели.

WH>А если писать с использованием исключений то код превращается в кучу try/finally что не добавляет ни читабельности ни скорости, а как оно задалбывает...

Ну уж не знаю, как можно писать безопасный код без try/finally. Даже на C++. Разве что на WinAPI да ручками проверять каждый возврат на 0 или INVALID_FILE_HANDLE или что там ещё.

WH>Еще очень часто есть куча рутинной работы которую в 99% случаев можно свалить на шаблоны.

Хе-хе. Это кто же виноват, что в C++ столько рутины?

В Дельфи и без шаблонов рутинной работы практически нет.

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

WH>STL контейнеры это вобще штука не заменимая. Если знаешь что тебе надо и свойства контейнеров то самопальные контейнеры не нужны в 99.999% случаев.

Что, и типизированные коллекции для COM можно на одних шаблонах сбацать?

WH>И многое другое...

Ну, насчёт многого другого может быть ты и прав.

M>Самый главный минус Дельфей, и их внебрачного урода Builderа

А Билдер никто не любит. Те же самый плюсы, только глючные.

M>- это завязка всего под VCL. В Дельфях все обьекты автоматически наследуются от TObject, что в результирующий экзешник добавляет такое количество кода, что потом листинг функций в файле смотреть страшно.

Тю. Ты бы ещё на машкоды смотрел, как там всё неоптимально. Поменьше нужно заморачиваться такой ерундой. Главное — чтобы программа работала в соответствии с Т.З.

M>Про TStringList и вообще любые списки, TListView и прочие Борландовские извращения говорить не буду. Например, почему TListItem::Data имеет тип данных TObject*? Я в эту самую дату загоняю свои типы дынных, и пользоваться огромадным кол-вом reinterpret_cast меня уже плющит.

Это проблемы Билдера. На Дельфи никаких проблем нету.

M>Что еще нельзя делать в Delphi/Builder? Нельзя эффективно перехватывать оконные сообщения для создания кустомизированных контролов "на лету". Необходимо создавать свои собственные компоненты.

Бр-бр. Что это значит, "на лету перехватывать"?

M>Код Дельфи не кроссплатформенный, как здесь кто-то утверждал, если не пользоваться CLX. Если пользовать, придется таскать n-мегабайтовые библиотеки. Правда, в случае Buildera, это и так приходится делать...

Во, конечно! То ли дело C++ — это ж просто идеал многплатформенноси. Зачем только Яву изобрели не знаю. Писали бы всё на C++.

Вон Микрософт как поступает — берёт Word под Windows, перекомпилирует его для MacOS и продаёт. А за стыковкой с платформой сам дюже вумный компилятор C++ следит.

M>Нe спорю, Borland'овские продукты красивы

Красивы?

M>и в общем удобны, но... Писать не-GUI и серьезные вещи IMHO надо на С++.

Естественно, писать надо на C++. Пусть там неудобно, зато платят больше.

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

M>C++ вызывает деструкторы только для объектов в стеке. Если объект используется через указатель — точно так же заботится приходится самому. Просто в Дельфи все объекты — указатели.
А в С++ нормальные люди "голые указатели" вобще не используют. Ибо смартпоинтеры рулят.

M>Ну уж не знаю, как можно писать безопасный код без try/finally. Даже на C++. Разве что на WinAPI да ручками проверять каждый возврат на 0 или INVALID_FILE_HANDLE или что там ещё.
А вот так. Все ресурсы будут освобождены в деструкторах, а потом исключение ловится геднибудь на верху.

WH>>Еще очень часто есть куча рутинной работы которую в 99% случаев можно свалить на шаблоны.
M>Хе-хе. Это кто же виноват, что в C++ столько рутины?
Не в С++, а в проектах отличных от клиента к БД.

M>В Дельфи и без шаблонов рутинной работы практически нет.


M>Возьми вон сделай простейшую Dll с одним экспортом. На C++ это будет куча мелкий хидеров, файликов и всяких деклараторов. А на Дельфи — один скромный исходник.
Ой не смешите мои тапочки

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
extern "C"
__declspec(dllexport)
void __stdcall my_cool_export_function()
{
}
BOOL APIENTRY DllMain( HANDLE hModule, 
                       DWORD  ul_reason_for_call, 
                       LPVOID lpReserved
                     )
{
    return TRUE;
}

Все.

M>Что, и типизированные коллекции для COM можно на одних шаблонах сбацать?
Ты емеешь в виду IEnumXXX? Ну интерфейс в IDL по любому прописать придеться, а типовую реализацию легко.

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


WH>>Вот про MFC не надо. Этого динозавра давно пора пристрелить чтобы ни кто не мучался. Все прогрессивное человечество либо уже переползло на WTL либо собирается.

DOO>Видимо MS это не прогрессивное человечество . Все ведь говорят, что WTL больше не поддерживается и не документируется.

Неподдерживается????
Особенное если учесть планируемый в районе осени выход 7.1 версии.
Или это у меня неверые данные?