Здравствуйте, Anton Batenev, Вы писали:
В>>Да, среда заточена под VCL, которая заточена под паскаль, и использовать ее из плюсов не так удобно и органично как из дельфей. AB>Чем не удобно? Те же самые классы, те же самы методы... В чем неудобство? Да, не поддерживается множественное наследование... Да, есть еще ограничения пришедшие из Delphi...
1) Множественное наследование. Зафигачить нужную функциональность в готовый VCL класс "одним махом" — нереально. Хотя для С++ это естественно. Интерфейсы и те появились только в 6-м билдере.
2) Создание/удаление объектов. Только через неперегружаемые new/delete.
3) Виртуальные конструкторы/деструкторы. Помимо того, что они просто работают не так, как это принято в С++, они еще порождают массу глюков компилятора и самые неожиданные эффекты.
4) Мелочи типа __fastcall/__closure/__property и т.п. "расширения", которые или усложняют жизнь или просто не вписываются в С++ и мешают при использовании STL или других "нормальных" плюсовых библиотек.
Наверное еще есть, сейчас уже не помню, давно последний раз держал билдер в руках. Теперь вопрос: ради чего все страдания? Можно было предположить, что самые хитрые хотят клепать формы также легко как в дельфе, но хоть в какой-то мере задействовать мощь С++ (назло ограничениям VCL и глюкам компилятора). Однако выясняется, что "STL не нужна и хватает VCL". Именно такого подхода к использованию билдера я не понимаю. Перефразирую вопрос: в чем удобство использования только VCL из C++? Я вижу только недостатки, самый главный из которых — скорость компиляции. Никакой С++ не угонится за дельфей. Для RAD это актуально (положил на форму компонент, посмотрел что получилось, выставил свойство, опять посмотрел что получилось).
AB>Но, если очень хочется, то ведь можно! Более того, если не хватает функциональности BCB, если он не поддерживает некоторые стандарты, а очень хочется — ведь всегда есть альтернативы — VC++, например. Стыковка модулей из разных сред компиляции на уровне DLL / COM проблем не составляет ведь?
Проблем со стыковкой Borland C++ с VC ровно столько же, сколько и со стыковкой дельфи с VC. Несмортя на то, что язык один, просто так взять и подключить модуль скомпиленный одним компилятором (BC) к модулю, скомпилированному другим компилятором (VC) — нельзя.
[...] AB>Я не говорил, что его хватает на все случаи жизни. Я говорил о том, что не было надобности использовать STL. А всте остальные приемущества языка (именно языка, а не библиотек и языка в реализации от Inprise) от этого не страдают ведь?
STL — это одно из преимуществ языка. И сознательный отказ от него требует серьезных обоснований, а несознательный отказ ставит под сомнение само знание этих преимуществ. Надеюсь под преимуществами ты подразумеваешь что-то более интересное, нежели "{} vs begin/end"?
В>>Язык сложный, концепции другие, с паскалем стыкуется плохо... нафига? AB>А зачем его стыковать с паскалем?
Чтобы можно было использовать паскальную VCL из C++.
P.S. Кстати, билдер как продукт давно издох. О чем спорим?
P.S.S. Для меня это хоть уже и старая, но мозоль. Когда-то кучу времени потратил на "борьбу с VCL из С++".
Здравствуйте, Владик, Вы писали:
В>4) Мелочи типа __fastcall/__closure/__property и т.п. "расширения", которые или усложняют жизнь или просто не вписываются в С++ и мешают при использовании STL или других "нормальных" плюсовых библиотек.
Не знаю, как на счет __fastcall, но мне очень не хватает в VC __closure и __property (__property именно в реализации BCB).
В>Наверное еще есть, сейчас уже не помню, давно последний раз держал билдер в руках. Теперь вопрос: ради чего все страдания? Можно было предположить, что самые хитрые хотят клепать формы также легко как в дельфе, но хоть в какой-то мере задействовать мощь С++ (назло ограничениям VCL и глюкам компилятора).
Да, именно так в моем случае! Когда в проекте нету каких-либо особенных тонких мест, требовательных к скорости выполнения, размеру, etc. Почему бы не написать ее за неделю, получить деньги и остаток месяца провести в свое удовольствие, чем писать точно такую же функциональность на MFC в течении более длительного периода, получив в итоге то же самое (с точки зрения клиента)?
В>Однако выясняется, что "STL не нужна и хватает VCL".
Но ведь действительно хватает! (мне опять же). С другой стороны, если STL когда-нибудь мне потребуется — я без зазрений совести буду ее использовать.
В>Именно такого подхода к использованию билдера я не понимаю. Перефразирую вопрос: в чем удобство использования только VCL из C++?
Нет смешания сред, ИМХО. Для VCL, STL является чужеродной (опять же, ИМХО) — в итоге могут возникать различного рода труднообнаруживаемые ошибки и прочее. При использовании только VCL вероятность словить глюк при использовании STL равна нулю => остаются только "глюки" VCL, которые в большинстве случаев известны и легко обходятся => скорость разработки потенциально возрастает.
В>Я вижу только недостатки, самый главный из которых — скорость компиляции. Никакой С++ не угонится за дельфей. Для RAD это актуально (положил на форму компонент, посмотрел что получилось, выставил свойство, опять посмотрел что получилось).
Вне сомнения, скорость компиляции Delphi и BCB различны, но ведь и языки тоже разные. Давай посравниваем скорость компиляции VC и BCB VC проиграет в скорости за счет более сильной оптимизации.
AB>>Но, если очень хочется, то ведь можно! Более того, если не хватает функциональности BCB, если он не поддерживает некоторые стандарты, а очень хочется — ведь всегда есть альтернативы — VC++, например. Стыковка модулей из разных сред компиляции на уровне DLL / COM проблем не составляет ведь? В>Проблем со стыковкой Borland C++ с VC ровно столько же, сколько и со стыковкой дельфи с VC. Несмортя на то, что язык один, просто так взять и подключить модуль скомпиленный одним компилятором (BC) к модулю, скомпилированному другим компилятором (VC) — нельзя.
Я говорил про стыковку на уровне DLL / COM, а не на уровне исходного кода / obj / lib.
AB>>Я не говорил, что его хватает на все случаи жизни. Я говорил о том, что не было надобности использовать STL. А всте остальные приемущества языка (именно языка, а не библиотек и языка в реализации от Inprise) от этого не страдают ведь? В>STL — это одно из преимуществ языка.
STL — это библиотека и ничего более. То, что она "Standard" еще ни о чем не говорит — я не удивлюсь, когда таким же стандартом станет boost, например. А то, что шаблоны — приемущество языка — я с этим и не спорю — именно по этому я использую BCB, а не Delphi
В>И сознательный отказ от него требует серьезных обоснований, а несознательный отказ ставит под сомнение само знание этих преимуществ. Надеюсь под преимуществами ты подразумеваешь что-то более интересное, нежели "{} vs begin/end"?
Как ни парадоксально — и это тоже А если серьезно, то с учетом майнстрима в .NET, STL там не только не требуется, но и вредна с точки зрения идеологии (смешивание managed и unmanaged). Там же, где вредна .NET (скорость работы, например), то по моему опыту оказывается, что эффективнее (с точки зрения производительности) использовать собственные реализации. Однако, у STL есть одно огромное приемущество, которое может покрыть все вышеизложенное — написание кросс-платформенных приложений, но в этом случае, ни о каком классе AnsiString (и VCL вообще) и речи быть не должно
В>P.S. Кстати, билдер как продукт давно издох. О чем спорим?
Да, собственно, не знаю Наверное, о приемуществах и недостатках использования STL в BCB.
В>P.S.S. Для меня это хоть уже и старая, но мозоль. Когда-то кучу времени потратил на "борьбу с VCL из С++".
А для меня не мозоль, но старая... Так что предлагаю закончить с этим.
Здравствуйте, Anton Batenev, Вы писали:
В>>4) Мелочи типа __fastcall/__closure/__property и т.п. "расширения", которые или усложняют жизнь или просто не вписываются в С++ и мешают при использовании STL или других "нормальных" плюсовых библиотек. AB>Не знаю, как на счет __fastcall,
__fastcall портит жизнь там, где ожидается "обычные" сишные соглашения. Например в той же STL от борланда (хотя ее тожно было доточить, правки тривиальные, но борланд об этом не позаботился).
AB> но мне очень не хватает в VC __closure
Посмотри на boost::signals/function/bind — использовать после этого дельфийские расширения не захочется даже в BCB Не говоря уже о том, что реализовано это на страндартном С++ со всеми вытекающими рулезами.
AB> и __property (__property именно в реализации BCB).
Может ты про __published? Ибо сам по себе __property чужд языку и мешает при использовании STL, а толк от него — чисто косметический и на любителя.
[...] В>>Однако выясняется, что "STL не нужна и хватает VCL". AB>Но ведь действительно хватает! (мне опять же). С другой стороны, если STL когда-нибудь мне потребуется — я без зазрений совести буду ее использовать.
Ладно. Навскидку из самого популярного. Что ты используешь вместо STL'ых контейнеров std::lst, std::vector, std::map, вместо алгоритмов find/find_if и вместо std::auto_ptr? Потому что я себе не представляю программы на С++ сложнее "хелло ворд" без этих штук из STL или без собственных аналогичных велосипедов. Кстати, без boost (прежде всего как средства избавления от собственных велосипедов) уже тоже не представляю
В>>Именно такого подхода к использованию билдера я не понимаю. Перефразирую вопрос: в чем удобство использования только VCL из C++? AB>Нет смешания сред, ИМХО. Для VCL, STL является чужеродной (опять же, ИМХО)
Ну еще бы. Запихать TList или TComboBox->Items в std::for_each не получится. Хотя я когда-от писал такие обертки
В>>- в итоге могут возникать различного рода труднообнаруживаемые ошибки и прочее. При использовании только VCL вероятность словить глюк при использовании STL равна нулю => остаются только "глюки" VCL, которые в большинстве случаев известны и легко обходятся => скорость разработки потенциально возрастает.
На самом деле глюков непосредствено при использовании STL как таковой я сейчас не припомню (просто получаешь ошибку компиляции при поптыке засунуть TList в алгоритм или при попытке забайндить __fastcall). Глюки начинаются при попытке заиспользовать VCL-классы в плюсовом стиле (затемплейтизировать и т.д). Вот тут начинается...
[...] AB>Вне сомнения, скорость компиляции Delphi и BCB различны, но ведь и языки тоже разные. Давай посравниваем скорость компиляции VC и BCB VC проиграет в скорости за счет более сильной оптимизации.
Оптимизация включена только для релизных билдов. Но даже в дебаге BCB компилит быстрее (в пределах порядка, я точно не замерял). Пока дело не доходит до больших precompiled headers. А оно доходит в больших проектах. Вот тут BCB уже начинает сливать, а сама среда безбожно тормозит на каждый чих.
[...] AB>Как ни парадоксально — и это тоже А если серьезно, то с учетом майнстрима в .NET, STL там не только не требуется, но и вредна с точки зрения идеологии (смешивание managed и unmanaged).
Не понял. Я вообще не знаток .NET, но почему STL не может быть managed?
M> и при этом сохраниться возможность исользовать str в контейнерах STL ?
да. именно. Отчасти для этого предлагаемоер ешение и разрабатывалось.
M>Мне кажется что придется использовать приведение типов, а я бы не хотел этого. Считаю что использование двух строковых типов в одной программе является неправильным. Тем более, что проект только начинается и не хочется изначально вкладывать такую бяку (2 строковых типа).
Нет! Вы используете только 1 тип строк: MyStr. Всегда и везде. Приведение типов будет только при работе с VCL классами, и то достаточно условное,
ведь внутри MyStr — AnsiString.
M>Есть вариант вообще не использовать std::string и STL... M>А чем вас не устроил вариант использования AnsiString и контейнеров из VCL, что вам пришлось решать данную проблему?
проблема состоит в том, что в любом случае, желательно, чтобы завязки на данную конкретную платформу(Borland) были минимальны.
Наверное, о приемуществах и недостатках использования STL в BCB.
