Собственно у меня такой вопрос: на чем счас делается юзер интерфейс в серьезных с/с++ проектах?
вообще вопрос вызван тем что я не понимаю одну вещь:
почему ушел с++ билдер / делфи?
насколько я знаю они счас оч непопулярны
почему?
они позволяю оч быстро и просто делать юзер интерфейс
в чем их проблема?
могу предположить что они хорошо подходят только для каких-то оч шаблонных задач, а как только нужно сделать что-нить необычное возникают проблемы (это только предположение, потому что у оч многих навороченных либ которые много берут на себя по-моему есть такая проблемв)
еще могу предположить что дело в его непереносимости на другие оси типо юниксов
так ли это? еще какие-нить причины?

lamer11 пишет:
>
> почему ушел с++ билдер / делфи?

Откуда такие сведения?

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

L>Собственно у меня такой вопрос: на чем счас делается юзер интерфейс в серьезных с/с++ проектах?
L>вообще вопрос вызван тем что я не понимаю одну вещь:
L>почему ушел с++ билдер / делфи?
L>насколько я знаю они счас оч непопулярны
L>почему?
L>они позволяю оч быстро и просто делать юзер интерфейс
L>в чем их проблема?
L>могу предположить что они хорошо подходят только для каких-то оч шаблонных задач, а как только нужно сделать что-нить необычное возникают проблемы (это только предположение, потому что у оч многих навороченных либ которые много берут на себя по-моему есть такая проблемв)
L>еще могу предположить что дело в его непереносимости на другие оси типо юниксов
L>так ли это? еще какие-нить причины?

Лень расписывать долго, и по пунктам(тем более это потенциальный холивар), так что опишу свое мнение кратко(кроме описанного выше) :
C++ Builder ушел тк :
1) Там давно нет с++ там уродливое наречие сильно напоминающее с++
2) Продукт перестал развиваться самим родителем(Борландом)
3) Те же причины что у Делфи
Делфи ушел тк :
1) То для чего он применялся в первую очередь — быстрое и удобное написание GUI и удобная работа с базами, теперь гораздо проще выполняется на Java/.Net Фреймворках
2) Язык слабее чем Java/ c#. Неудобно. Хочется скать быстро и кратко(я имею ввиду — сказать в программе ), а приходится писать много и муторно.
3) Всеобщее отмирание "толстых" клиентов и переход в сторону веба.
4) Тут нет у меня подтверждения, но есть ощущение что Делфи был так популярен именно в ExUSSR А за его пределами он был популярен совсем не так сильно. Границы стираются, и мы приходим к тому же, что и весь мир.

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

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

_>Лень расписывать долго, и по пунктам(тем более это потенциальный холивар), так что опишу свое мнение кратко(кроме описанного выше) :
_>C++ Builder ушел тк :
_>1) Там давно нет с++ там уродливое наречие сильно напоминающее с++
_>2) Продукт перестал развиваться самим родителем(Борландом)
По-поводу BCB согласен с автором. Это и не C++, и не Delphi, ни рыба не мясо. Пользуясь им всё равно приходиться знать Deplhi.
Низкое качество C++ (собенно шаблонов) проявляется при попытке установить любую популярную библиотеку. Boost приходиться ковырять руками, собрать удаётся только малую часть. И работает половина средств. boost::date_time я неделю запускал. Матричную библиотеку мне так и не удалось найти, хотя тот же Blitz с полтычка становиться на VC. С другой стороны — это не Delphi, где всё под VCL заточено.Там хоть удобно с ним работать. А попробуй ты множественно отнаследовать форму от абстрактного класса: все операции нужно сделать абстрактными, и ни боже мой их реализацию(даже виртуальный деструктор нельзя!) А новые библиотеки, скажем рисования? Один TChart разрекламированный с безобразной структура классов! (а править сырцы всё равно на Deplhi ) А COM подцепить кроме как родными для Dephi интерфейсами? Хорошо хоть удалось (с усилиями) использовать два модуля из ATL 3.0.

dip_2000 wrote:

> 1) Там давно нет с++ там уродливое наречие сильно напоминающее с++

Там нормальный полноценный C++, stl. Глюки в основном только в сильно
навороченных шаблонах. Шаблоны уровня stl там работают на ура.

> 2) Продукт перестал развиваться самим родителем(Борландом)

Есть шансы что возродят. Вроде обещают доделать полную поддержку стандарта.

BCB хорош именно тем, что позволяет одновременно писать на полноценном
C++ и строгать гуй как на Дельфи. VCL вполне удобная библиотека.

shvonder wrote:

> Deplhi. Низкое качество C++ (собенно шаблонов) проявляется при попытке
> установить любую популярную библиотеку. Boost приходиться ковырять
> руками, собрать удаётся только малую часть. И работает половина средств.

Глючат только очень навороченные шаблоны, которые в прикладном коде
не возникают. Я успешно юзал boost::spirit версии 1.6

> boost::date_time я неделю запускал.

В VCL есть TDateTime

> С другой
> стороны — это не Delphi, где всё под VCL заточено.Там хоть удобно с ним
> работать.

Никакой разницы нет. Те же методы, тот же редактор форм.

> А попробуй ты множественно отнаследовать форму от абстрактного
> класса:

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

> классов! (а править сырцы всё равно на Deplhi ) А COM подцепить кроме
> как родными для Dephi интерфейсами?

Всё там есть, учите матчасть.

Почему ушел C++ Builder?
Потому что глючный он. Писать можно долго только смысла нету.

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

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

_>Там нормальный полноценный C++, stl. Глюки в основном только в сильно
_>навороченных шаблонах. Шаблоны уровня stl там работают на ура.

на надо их разделять c++ и stl — это одно целое(вернее одно — часть другого). А скоро добавиться еще и здоровый кусок Буста.
Почему кто-то за меня должен решать какой навороченности шаблоны мне использовать ? У меня есть стандарт, у меня есть код который собирается на нескольких других компиляторах, почему он не собирается на билдере, если код соответствует стандарту ?
Вобще для того что бу понять как многого не может билдер, достаточно открыть исходники буста и посмотреть, как много там кода сделано специально что бы сохранить поддержку этого компилятора(от которой в итоге отказались)

>> 2) Продукт перестал развиваться самим родителем(Борландом)
_>Есть шансы что возродят. Вроде обещают доделать полную поддержку стандарта.
Дай бог. Это будет как минимум не плохо

_>BCB хорош именно тем, что позволяет одновременно писать на полноценном
_>C++ и строгать гуй как на Дельфи. VCL вполне удобная библиотека.
C последним предложением согласен.

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

_>shvonder wrote:

_>Глючат только очень навороченные шаблоны, которые в прикладном коде
_>не возникают. Я успешно юзал boost::spirit версии 1.6
Да ну ? А потребность воспользоваться матрицами (Blitz, boost::ublas) в прикладном коде не возникает ? А operator<<(std::ofstream&, posix_time::ptime) вам никогда не был удобен? А вы не пробовали в BCB6 пользоваться std::bind2st ? И частичную специализацию никогда не пытались использовать ? И никогда boost::random вместо google/codesearch ? Не верю. , ибо это возможно только при компиляции примеров из хелпа.

>> boost::date_time я неделю запускал.
_>В VCL есть TDateTime
К сожалению. Время в формате double — это нонсенс, если вам понадобиться вычисления на времени с микросекундной точностью. Поверьте, не все задачи сводяться к выводу сегодняшней даты на форме )кстати, boost::date_time позволяет пробежаться, скажем, по каждому нечётному четвергу каждого второго високосного года )

_>Никакой разницы нет. Те же методы, тот же редактор форм.
Конечно. Но исходники то вы на чём будете править? Или писать свой компонент ? На Delphi конечно, там это удобно, хоть и пользоваться приходиться

array of MyType

вместо всяких разных

std::queue

. Да и вообще, весь механизм VCL не соответсвует C++ , и Билдер его реализует через всякие расширения вроде __closure. И от этого тоже постоянные проблемы, примеры уж не буду приводить.

Да и палитра компонентов всегда в Буилдере беднее была. А генерация хелпов из сырцов Pascal'я !? Народ, вон, стонет.

>> А попробуй ты множественно отнаследовать форму от абстрактного
>> класса:

_>Это запрещено с самого начала. Нельза применять множественное
_>наследование с классами VCL. С обычными C++ — можно.
_>Это несущественное ограничение.
Во первых можно: но на чистых абстрактных интерфейсах, которые компилятор реализует через делфяцкий interface. Во вторых вот такие ограничения всего и вся, что касаются VCL и убивают идею.
Постоянно приходиться думать на двух языкх.

_>Всё там есть, учите матчасть.
Да учу, учу. Вот скомпилирую только на VC + wxWidgets HelloWord — и сразу туда. Уж и Blitz у меня припасён

Здравствуйте, Аноним, Вы писали:

А>Почему ушел C++ Builder?
А>Потому что глючный он. Писать можно долго только смысла нету.

А>С чем писать GUI на С++ на серьезных проектах?
А>Qt — самое то.
А>С Qt получаешь полноценный фреймворк для разработки качественных GUI
А>плюс кучу других вещей, которые реально нужны в реальной работе.
А>Плюс это все платформо-независимо.

Qt — очень хорошая библиотека. Только больно уж дорогая.

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

С>Qt — очень хорошая библиотека. Только больно уж дорогая.

У них несколько разных лицензий:
http://trolltech.com/products/qt/licenses/licensing/licensingoverview
Есть и бесплатная.
В любом случае это разовая инвестиция (на мой взгляд не такая уж и большая)
Если фирма не может себе ее позволить, то зачем она вообще в бизнес пошла?
Т.е. если бизнес не может покрыть даже затраты на покупку средств разработки,
то это и не бизнес, а просто хобби.

dip_2000 wrote:

> на надо их разделять c++ и stl — это одно целое(вернее одно — часть
> другого).

Stl это отдельная вещь. Просто библиотека. Полно проектов на pure C++.

> А скоро добавиться еще и здоровый кусок Буста. Почему кто-то
> за меня должен решать какой навороченности шаблоны мне использовать ?

Использовать и разрабатывать это разные вещи. Во вменяемом прикладном коде
наличие таких шаблонных конструкций должно встречаться очень редко.

> У меня есть стандарт, у меня есть код который собирается на нескольких
> других компиляторах, почему он не собирается на билдере, если код
> соответствует стандарту ?

Не надо передёргивать. Если целенапраленно бить по багам конкретного
компилятора, то можно создать впечатление что всё ужастно. Основная масса
С++ кода компилируется нормально.

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

Потому что он остановился в развитии из за известных событий.
На момент выпуска он был вполне современным.

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

_>dip_2000 wrote:

_>Использовать и разрабатывать это разные вещи. Во вменяемом прикладном коде
_>наличие таких шаблонных конструкций должно встречаться очень редко.
Очень даже часто, учитывая библиотеки.
Любой, сколько-нибудь серьёзно занимающийся
вычислениями на C++ (мало таких, увы), скажет, что без матричной
библиотеки это хождение по мукам . А все такие библиотеки используют шаблоны. А это практически с гарантией отсекает билдер (если разработчики не приложили специальных усилий длч совместимости с ним).
Кстати не слишком ли резко называть использование в прикладном коде boost::file_system невменяемым ?

_>Не надо передёргивать. Если целенапраленно бить по багам конкретного
_>компилятора, то можно создать впечатление что всё ужастно. Основная масса
_>С++ кода компилируется нормально.
Правда в том, что билдер обычно сравнивают особняком, настолько он выделяется реализацией стандарта. Зато, говорят нам, на нём можно строгать GUI, как в Delph'ях. Мол, главное его достоинство — совместимость с VCL, а перейти на Delphi религия не позволяет.

_>Потому что он остановился в развитии из за известных событий.
_>На момент выпуска он был вполне современным.
Верно. Некоторые даже конкретизируют: на момент выпуска BCB4.

shvonder wrote:

> А
> потребность воспользоваться матрицами (Blitz, boost::ublas) в прикладном
> коде не возникает ?

Буст пионеры тащать в каждую дырку.
Я говорю не про библиотечный код, где авторы от большого ума лепять
мегаметаконструкции. А про прикладной код решающий кокретные задачи
который пишет программист при создании программы.

> А operator<<(std::ofstream&, posix_time::ptime) вам
> никогда не был удобен?

А в чём проблема?

> А вы не пробовали в BCB6 пользоваться
> std::bind2st

Не знаю, но тот же более навороченный boost::spirit::phoenix и всякие
лямбды работают замечательно на BCB5 с компилятором 2000 года.

> ? И частичную специализацию никогда не пытались
> использовать ?

Пользовался. Работало в случаях когда мне было нужно.

> Время в формате double — это
> нонсенс,

Это не нонсенс, это покрывает 99% задач.

> если вам понадобиться вычисления на времени с микросекундной
> точностью.

Если понадобятся, то вероятность операций над календарными датами
ничтожно мала. Поэтому __int64 и не надо никаких бустов. Либо
структура из даты и количества долей секунд.

> кстати, boost::date_time позволяет пробежаться, скажем, по
> каждому нечётному четвергу каждого второго високосного года )

Это хорошо. Но так ли жизненно необходим этот boost::date_time ?
Если есть функция декодирования даты в год, месяц, число, день недели,
то можно самому сделать в одну строчку всё что захочется.

> _>Никакой разницы нет. Те же методы, тот же редактор форм. Конечно. Но
> исходники то вы на чём будете править?

Исходники чего? VCL? Зачем такой экстремизим?
Но если хочется что компилятор паскаля входит в BCB.

> Или писать свой компонент ? На
> Delphi конечно, там это удобно, хоть и пользоваться приходиться
>

array of MyType

вместо всяких разных
>

std::queue

.

Все паскалевкие типа отмаплены в соответствующие конструкции билдера.
Свой код пишется на обычно c++ с использованием stl если надо.

> Да и вообще, весь механизм VCL не
> соответсвует C++ ,

Гениально! Ещё бы, портированная паскалевкая библиотека...
VCL никогда и не претендовал на портабельный с++ гуй.

> и Билдер его реализует через всякие расширения вроде
> __closure.

Расширений там ничтожно мало. TObject, __closure и
более широкая rtti. Всё остально в виде библиотеки
в system.pas

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

> И от этого тоже постоянные проблемы, примеры уж не буду
> приводить.

Раз пошла такая пьяко, то приводи.

> Да и палитра компонентов всегда в Буилдере беднее была.

Все компоненты для дельфи можно ставить в билдер.

> Во
> вторых вот такие ограничения всего и вся, что касаются VCL и убивают
> идею. Постоянно приходиться думать на двух языкх.

Ограничений там очень мало. Это раз.
Во вторых интерфэйс с юзером наверное нужно отделять от реализации?
В третьих, адское смешение VCL и OLE в одну кучу это плохо.

> _>Всё там есть, учите матчасть. Да учу, учу. Вот скомпилирую только на
> VC + wxWidgets HelloWord — и сразу туда. Уж и Blitz у меня припасён

Тем не менее когда нужно делать сложный гуй на многие десятки а то и
сотни форм,VCL с её IDE пока очень сильно рулит.

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

_>Stl это отдельная вещь. Просто библиотека. Полно проектов на pure C++.
:D Извините, не могу сдержать смех :D Вы стандарт с++ видели ?

_>Использовать и разрабатывать это разные вещи. Во вменяемом прикладном коде
_>наличие таких шаблонных конструкций должно встречаться очень редко.
Знаете, это не очень хорошая практика, вот так голословно ограничивать использование таких инструментов, как шаблоны. Я вам больше скажу — без шаблонов язык становится значительно беднее. Это раз.
Во вторых м/у редко и совсем не должны — пропасть. Если я хочу наклепать всю высокоуровневую логику проекта на шаблонах ? Да, там шаблонов, а тем более их частичной и полной специализации, дефолтных параметров в объявлении шаблона, перегруженных шаблонных функций и прочей радости будет процентов 5. Ну и что ? За то это будет лаконичный, эффективный и выполняющий свою задачу код. С какой стати я должен от этого отказываться ?

_>Не надо передёргивать. Если целенапраленно бить по багам конкретного
_>компилятора, то можно создать впечатление что всё ужастно. Основная масса
_>С++ кода компилируется нормально.
Да. так и есть. А как не скомпилируется что-то, так а ж зубы сводит от обиды :D Nr много приходится переделывать.

_>Потому что он остановился в развитии из за известных событий.
_>На момент выпуска он был вполне современным.
Ваз 2101 на момент выпуска то же был современным. Только сейчас на нем ездить не тянет.

shvonder wrote:

> Очень даже часто, учитывая библиотеки. Любой, сколько-нибудь
> серьёзно занимающийся вычислениями на C++ (мало таких, увы), скажет, что
> без матричной библиотеки это хождение по мукам.

Мда... Деградация научной мысли. Без шаблонной матричной библиотеки
уже ничего и не посчитать.
Опять же если заниматься адскими вычислениями то зачем выбирать борланд?
Ну я занимался вычислениями, качество компилятора было как то побоку
т.к. ключевые места пишутся на асме (если нужна скорость).

> А все такие библиотеки
> используют шаблоны.

Основная масса шаблонов работает на билдере.

> Правда в том, что билдер
> обычно сравнивают особняком, настолько он выделяется реализацией
> стандарта.

Выделяться он стал лишь недавно. Не будешь же ты переживать
насколько поддерживал стандарт тот же VC6 ?

> Зато, говорят нам, на нём можно строгать GUI, как в Delph'ях.
> Мол, главное его достоинство — совместимость с VCL, а перейти на Delphi
> религия не позволяет.

Билдер это C++ компилятор с возможностью использования всех
вкусностей дельфи по строганию гуя. Помимо гуя есть ещё и т.н.
"бизнес логика" которую надо кодировать.

> _>Потому что он остановился в развитии из за известных событий. _>На
> момент выпуска он был вполне современным. Верно. Некоторые даже
> конкретизируют: на момент выпуска BCB4.

Нет, скорее BCB5.

dip_2000 wrote:

> _>Stl это отдельная вещь. Просто библиотека. Полно проектов на pure C++.
> :D Извините, не могу сдержать смех :D Вы стандарт с++ видели ?

Тема неоднократно перетиралась. С++ возможен и без stl. Это факт.
Но что касается сабжа, то stl там есть.

> редко. Знаете, это не очень хорошая практика, вот так голословно
> ограничивать использование таких инструментов, как шаблоны. Я вам больше
> скажу — без шаблонов язык становится значительно беднее.

Шаблоны я не отрезал. Я просто сказал что если при кодировании
"бизнес логики" возникают шаблоны на которых начинает спотыкаться
борландовский компилятор, то что то не так в консерватории.
А тупо написать
template<class T>
class {};
никто не запрещает.

> Если я хочу наклепать
> всю высокоуровневую логику проекта на шаблонах ?

Тогда налицо профнепригодность

> Да, там шаблонов, а тем
> более их частичной и полной специализации, дефолтных параметров в
> объявлении шаблона, перегруженных шаблонных функций и прочей радости
> будет процентов 5. Ну и что ? За то это будет лаконичный, эффективный и
> выполняющий свою задачу код. С какой стати я должен от этого
> отказываться ?

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

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

>> _>Stl это отдельная вещь. Просто библиотека. Полно проектов на pure C++.
>> :D Извините, не могу сдержать смех :D Вы стандарт с++ видели ?

_>Тема неоднократно перетиралась. С++ возможен и без stl. Это факт.
Это будет совсем другой язык. Далеко не факт, что ему есть существенное место под солнцем.(особых преемущест перед чистым С он иметь не будет.) Можно еще долго "перетирать".

_>Но что касается сабжа, то stl там есть.
Причем да же не по ссылке. И это показательно. Просто неотемлимая часть языка.

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

>> Да, там шаблонов, а тем
>> более их частичной и полной специализации, дефолтных параметров в
>> объявлении шаблона, перегруженных шаблонных функций и прочей радости
>> будет процентов 5. Ну и что ? За то это будет лаконичный, эффективный и
>> выполняющий свою задачу код. С какой стати я должен от этого
>> отказываться ?
_>Ты должен будешь отказаться чтобы получить читабельную и легко
_>сопровождаемую программу.
А вот это уже проффнепригодность с вашей стороны, раз вы не можете читать хорошо откомментированный, хорошо структурированный шаблонный код. Этот код может получиться значительно локаничнее, чем не шаблонные аналоги, без потери читабельности, и понятности(при условии конечно если вы с шаблонами занкомы. А если нет, очевидно вы не знаете с++)

Здравствуйте, avp_, Вы писали:
>> ? И частичную специализацию никогда не пытались
>> использовать ?
_>Пользовался. Работало в случаях когда мне было нужно.
Может на последних версиях ? Нужно проверить.

>> Время в формате double — это
>> нонсенс,
_>Это не нонсенс, это покрывает 99% задач.
>> если вам понадобиться вычисления на времени с микросекундной
>> точностью.
_>Если понадобятся, то вероятность операций над календарными датами
_>ничтожно мала. Поэтому __int64 и не надо никаких бустов. Либо
_>структура из даты и количества долей секунд.
Может ваших 99% задач и покрывает. Но вот мне, например, приходится синхронизировать
данные с разных нескольких железок, которые пишут по несколько суток. В летнее и зимнее время, в разных часовых поясах, ну вы понимаете.. Где час прибавишь, а где микросекунду! И там, знаете, терять отсчёты на операциях округления double неприятно. И не надо мне про структуры из даты и кол-ва микросекунд, намучался я и с TDateTime и с t_time. И вообще, попробуйте отнять от 2008/01/01 00:00:00 микросекунду, учтя, что ,видимо, год високосный (и выборный ).
_>Это хорошо. Но так ли жизненно необходим этот boost::date_time ?
Внимательно изучив вопрос, приходиться признать, что жизненно необходим. Поскольку, с одной стороны, нам нужна микросекундная (бывают и наносекундные) точность, с другой огромный временной диапазон. Использую boost::date_time ежедневно, вот только Билдер подгаживает

_>Исходники чего? VCL? Зачем такой экстремизим?
_>Но если хочется что компилятор паскаля входит в BCB.
Умные, мля, все, как Ленин. Теоретики.
Вы пользовались TeeChart Pro ? Единственная достойная рисовалка, которую можно купить для VCL (если я не прав — киньте ссылочку). На работе мы дружно правим сырцы.
Например, хочу сделать зум на несколько каналов одновременно, нарисованых один под другим в разных Y-осях. А стандартный расчитан на одну Y-ось и работает неправильно. Структура классов плохая, и кроме как править исходники — нет вариантов. Что дальше ? Открываем Delphi, правим, тестируем, собираем, открываем Билдер, работаем.

_>Все паскалевкие типа отмаплены в соответствующие конструкции билдера.
_>Свой код пишется на обычно c++ с использованием stl если надо.
_>Гениально! Ещё бы, портированная паскалевкая библиотека...
_>VCL никогда и не претендовал на портабельный с++ гуй.
_>Расширений там ничтожно мало. TObject, __closure и
_>более широкая rtti. Всё остально в виде библиотеки
_>в system.pas
_>__closure замечательнейшая вещь. Всякие биндеры, функторы
_>и т.п. сразу идут лесом.
Вот человек: кто любит яблоки а кто свиной хрящик.

_>Во вторых интерфэйс с юзером наверное нужно отделять от реализации?
_>В третьих, адское смешение VCL и OLE в одну кучу это плохо.
Не понял.


_>Тем не менее когда нужно делать сложный гуй на многие десятки а то и
_>сотни форм,VCL с её IDE пока очень сильно рулит.

Да кто ж спорит. Хорошая вещь. Но мне нужны матрицы библиотечные (Blitz), библиотеки надёжные (boost) и контейнеры стандартные. А формочки — что делать ? — придётся из wxWidgets брать.

dip_2000 wrote:

> _>Тема неоднократно перетиралась. С++ возможен и без stl. Это факт. Это
> будет совсем другой язык.

Не понимаешь разницы между языком и библиотекой?
printf по твоему тоже часть языка?

> Далеко не факт, что ему есть существенное
> место под солнцем.(особых преемущест перед чистым С он иметь не будет.)
> Можно еще долго "перетирать".

Ну если для тебя C++ минус STL = C тогда ой... Я умываю руки.

> _>Но что касается сабжа, то stl там есть. Причем да же не по ссылке. И
> это показательно. Просто неотемлимая часть языка.

Отъемлимая.

> Создание простого, лаконичного и
> понятного кода, вместо разведения зоопарка классов — проффнепригодность
> ?

Если ты можешь писать "бизнес логику" в стиле буста (а не используя
его) то ты наверное гений. Однако большенство написанного кода в мире
к такому не относится.


> _>Ты должен будешь отказаться чтобы получить читабельную и легко
> _>сопровождаемую программу. А вот это уже проффнепригодность с вашей
> стороны, раз вы не можете читать хорошо откомментированный, хорошо
> структурированный шаблонный код. Этот код может получиться значительно
> локаничнее, чем не шаблонные аналоги, без потери читабельности, и
> понятности(при условии конечно если вы с шаблонами занкомы. А если нет,
> очевидно вы не знаете с++)

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