Собственно у меня такой вопрос: на чем счас делается юзер интерфейс в серьезных с/с++ проектах?
вообще вопрос вызван тем что я не понимаю одну вещь:
почему ушел с++ билдер / делфи?
насколько я знаю они счас оч непопулярны
почему?
они позволяю оч быстро и просто делать юзер интерфейс
в чем их проблема?
могу предположить что они хорошо подходят только для каких-то оч шаблонных задач, а как только нужно сделать что-нить необычное возникают проблемы (это только предположение, потому что у оч многих навороченных либ которые много берут на себя по-моему есть такая проблемв)
еще могу предположить что дело в его непереносимости на другие оси типо юниксов
так ли это? еще какие-нить причины?
Здравствуйте, 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 интерфейсами?
Всё там есть, учите матчасть.
Posted via RSDN NNTP Server 2.1 beta
Re: почему ушел C++ Builder / Delphi?
От:
Аноним
Дата:
22.11.07 11:04
Оценка:
Почему ушел 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 — очень хорошая библиотека. Только больно уж дорогая.
Re[3]: почему ушел C++ Builder / Delphi?
От:
Аноним
Дата:
22.11.07 11:56
Оценка:
Здравствуйте, Сергей, Вы писали:
С>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.
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 там есть. Причем да же не по ссылке. И > это показательно. Просто неотемлимая часть языка.
Отъемлимая.
> Создание простого, лаконичного и > понятного кода, вместо разведения зоопарка классов — проффнепригодность > ?
Если ты можешь писать "бизнес логику" в стиле буста (а не используя
его) то ты наверное гений. Однако большенство написанного кода в мире
к такому не относится.
> _>Ты должен будешь отказаться чтобы получить читабельную и легко > _>сопровождаемую программу. А вот это уже проффнепригодность с вашей > стороны, раз вы не можете читать хорошо откомментированный, хорошо > структурированный шаблонный код. Этот код может получиться значительно > локаничнее, чем не шаблонные аналоги, без потери читабельности, и > понятности(при условии конечно если вы с шаблонами занкомы. А если нет, > очевидно вы не знаете с++)
Ситуаций в реальных задачах где бы сплошной шаблонный код дейтствительно
будет лаконичным, легко читаемым и поддерживаемым встречается очень мало.
Здравствуйте, avp_, Вы писали: _>shvonder wrote:
_>Мда... Деградация научной мысли. Без шаблонной матричной библиотеки _>уже ничего и не посчитать. _>Ну я занимался вычислениями, качество компилятора было как то побоку _>т.к. ключевые места пишутся на асме (если нужна скорость).
Судя по этому абзацу ваши занятия ограничились взятием одномерного БПФ. Причём здесь скорость ан асме ? Мой бородаты коллега может на фортране написать J.tx J для перемножения трансп. матрицы на себя, а мне нужно с double[] ? Или например, перемножение блочной матрицы можно так организовать, чтобы хранить и перемножать только блоки. И тут, поверте, без концепции срезов(slice) прсто вешалка. Без библиотеки в вычислениях делат нечего.
_>Опять же если заниматься адскими вычислениями то зачем выбирать борланд?
Согласен, фортран удобнее. Но ещё более удобен Matlab (кроме шуток). Вейвлет-фильтрация матрицы в 10 строчках + рисуночек — это вам не асме оптимайзить.
>> А все такие библиотеки >> используют шаблоны. _>Основная масса шаблонов работает на билдере.
Да, но основная масса библиотек на билдере не компилируется. Хоть, раз (благо это не сложно) но используют такое, что билдер не переварит.
_>Нет, скорее BCB5.
Эх, золотое было время ..
Бесплатная — она по GPL, что для коммерческой разработки не годится.
А>В любом случае это разовая инвестиция (на мой взгляд не такая уж и большая) А>Если фирма не может себе ее позволить, то зачем она вообще в бизнес пошла? А>Т.е. если бизнес не может покрыть даже затраты на покупку средств разработки, А>то это и не бизнес, а просто хобби.
Я несколько другое имел ввиду.
Учитывая, например, доступность wxWidgets совсем забесплатно, мне кажется, что таки дороговато.
ИМХО, нет в Qt таких значимых преимуществ перед wxWidgets, чтобы платить за это указанную цену.
Хотя, если учесть, что Trolltech живет и здравствует, много и тех, кто считает иначе.
Здравствуйте, avp_, Вы писали:
_>Не понимаешь разницы между языком и библиотекой? _>printf по твоему тоже часть языка?
А вы очевидно не понимаете разницы между словом библиотека, и словосочетанием библиотека входящая в стандарт языка.
_>Ну если для тебя C++ минус STL = C тогда ой... Я умываю руки.
Минус шаблоны. с++ без шаблонов. а все остальное.... все это можно и на С. Вобщем холивар.
_>Отъемлимая.
см выше
_>Если ты можешь писать "бизнес логику" в стиле буста (а не используя _>его) то ты наверное гений. Однако большенство написанного кода в мире _>к такому не относится.
Вы знаете, общественное мнение говорит, и я сним во многом согласен что написание бизнес логике на с++ вещь не очень благодарная.
И вы переходите к язвительности. Не стоит. Оно того не стоит.
_>Ситуаций в реальных задачах где бы сплошной шаблонный код дейтствительно _>будет лаконичным, легко читаемым и поддерживаемым встречается очень мало.
Ну да. Люди предпочитают С с классами и считают что это и есть вся мощь и богатство с++.
Не нужно всех под одну гребенку.
Вобщем спасибо вам за дисскуссию, но с моей стороны я считаю ее завершенной. Тк она все больше превращается в холивар, и выяснение проффпригодности друг друга. А тема совсем не об этом. Я высказал свое мнение по теме, вот и все. Если Билдер не умрет как С++ компилятор года через 3, я буду только рад. Но пока все идет к этому.
shvonder wrote:
> _>Пользовался. Работало в случаях когда мне было нужно. Может на > последних версиях ? Нужно проверить.
Да нет, не на последних. Конструкции типа
template <class T*> struct{};
работают.
> И > вообще, попробуйте отнять от 2008/01/01 00:00:00 микросекунду, учтя, что > ,видимо, год високосный (и выборный ).
Если такая ответственная задача, то наверняка надёжнее всё сделать самому.
Создать класс
class datetime
{ int date; // целое число дней
int time; // количество наносекунд
};
Реализовать для него арифметические операции, конструкторы.
Декодировать просто через TDateTime(date).DecodeDate
Написать оператор приведения к TDateTime и т.д.
> Вы пользовались TeeChart Pro ? Единственная достойная рисовалка,
А причём тут BCB? Радуйтесь что исходники доступны.
> Что > дальше ? Открываем Delphi, правим, тестируем, собираем, открываем > Билдер, работаем.
Почему править и компилировать нельзя из среды билдера?
shvonder wrote:
> (если нужна скорость). Судя по этому абзацу ваши занятия ограничились > взятием одномерного БПФ. Причём здесь скорость ан асме ? Мой бородаты > коллега может на фортране написать J.tx J для перемножения трансп. > матрицы на себя, а мне нужно с double[] ? Или например, перемножение > блочной матрицы можно так организовать, чтобы хранить и перемножать > только блоки. И тут, поверте, без концепции срезов(slice) прсто вешалка. > Без библиотеки в вычислениях делат нечего.
Это разные вещи. Скорость вычислений и удобство кодирования математических
конструкций. Когда дело доходит до C++ до обычно уже вопрос стоит о
создании эффективной числодробилки.
> _>Опять же если заниматься адскими вычислениями то зачем выбирать > борланд? Согласен, фортран удобнее. Но ещё более удобен Matlab (кроме > шуток). Вейвлет-фильтрация матрицы в 10 строчках + рисуночек — это вам > не асме оптимайзить.
Вот именно, для исследований лучше юзать спец средство. А лучше вообще
на листе бумаги
Здравствуйте, avp_, Вы писали: _>shvonder wrote:
_>Это разные вещи. Скорость вычислений и удобство кодирования математических _>конструкций. Когда дело доходит до C++ до обычно уже вопрос стоит о _>создании эффективной числодробилки. _>Вот именно, для исследований лучше юзать спец средство. А лучше вообще _>на листе бумаги
Я тоже так думал раньше. Но бородатый фортранщик, о котором идёт речь, пишет dll-ки для промышленного обрабатывающего софта. Не надо думать, что на каждого человека с большой головой и гусиным пером приходиться штат C++ и асм кодеров (и тестеров ). Тот же цейнот, отсутствие готовых библиотек и людей.
На C++ можно и окошки красиво нарисовать, и алгоритм закодировать. Только библиотеки нужны хорошие и компилятор адекватный. А не Borland, упокой господи его грешную душу,Builder
Там есть лицензии для образовательных целей.
Но они естественно для коммерческой разработки тоже не годятся
С>Я несколько другое имел ввиду. С>Учитывая, например, доступность wxWidgets совсем забесплатно, мне кажется, что таки дороговато. С>ИМХО, нет в Qt таких значимых преимуществ перед wxWidgets, чтобы платить за это указанную цену. С>Хотя, если учесть, что Trolltech живет и здравствует, много и тех, кто считает иначе.
Для личного пользования я бы тоже не стал себе покупать,
хотя я знаю парочку шароварщиков, которые все же купили.
Но у них дела идут хорошо и у них есть деньги для инвестиций в свой бизнес.
А если ты — фирма, приносящая доход, то почему бы и не сделать разовую инвестицию?
В общем не понимаю причин экономить на хороших библиотеках.
Qt — это все же не только GUI. С ним получаешь подержку потоков, Network Module,
OpenGL Module, SQL Module, SVG Module, XML Module, Script Module и пр...
Все это в одном флаконе с последовательным и логичным API.
В общем Qt стоит тех денег, что за него просят.
А для хобби достаточно и GPL версии.
Ладно... Прекращаю делать бесплатную рекламу trolltech'у
Кому надо, сами разберутся.
[skip]
S>Да кто ж спорит. Хорошая вещь. Но мне нужны матрицы библиотечные (Blitz), библиотеки надёжные (boost) и контейнеры стандартные. А формочки — что делать ? — придётся из wxWidgets брать.
Если Вас все в BCB не устраивает, то зачем Вы им пользовались?
Здравствуйте, Dym On, Вы писали:
DO>[skip]
S>>Да кто ж спорит. Хорошая вещь. Но мне нужны матрицы библиотечные (Blitz), библиотеки надёжные (boost) и контейнеры стандартные. А формочки — что делать ? — придётся из wxWidgets брать. DO>Если Вас все в BCB не устраивает, то зачем Вы им пользовались?
Потому пришёл из Delphi (изначально из-за STL-контейнеров, да так и остался).
Здравствуйте, ArtDenis, Вы писали:
AD>lamer11 пишет: >> >> почему ушел с++ билдер / делфи?
AD>Откуда такие сведения?
4) Тут нет у меня подтверждения, но есть ощущение что Делфи был так популярен именно в ExUSSR А за его пределами он был популярен совсем не так сильно. Границы стираются, и мы приходим к тому же, что и весь мир.
два в одном: ответ на первый вопрос и подтверждение второго тезиса на одной странице.
S>Вы пользовались TeeChart Pro ? Единственная достойная рисовалка, которую можно купить для VCL (если я не прав — киньте ссылочку). На работе мы дружно правим сырцы.
On Thu, 22 Nov 2007 14:04:05 +0500, Аноним <0@users.rsdn.ru> wrote:
> С чем писать GUI на С++ на серьезных проектах? > Qt — самое то. > С Qt получаешь полноценный фреймворк для разработки качественных GUI > плюс кучу других вещей, которые реально нужны в реальной работе. > Плюс это все платформо-независимо.
On Thu, 22 Nov 2007 18:04:16 +0500, Аноним <0@users.rsdn.ru> wrote:
> Qt — это все же не только GUI. С ним получаешь подержку потоков, Network > Module, > OpenGL Module, SQL Module, SVG Module, XML Module, Script Module и пр... > Все это в одном флаконе с последовательным и логичным API.
ну и зачем для разработки ГУЯ покупать этот многокилометровый довесок?
"мне не нужна вечная игла для примуса — я не собираюсь жить вечно".
Здравствуйте, Аноним, Вы писали:
А>Qt — это все же не только GUI. С ним получаешь подержку потоков, Network Module, А>OpenGL Module, SQL Module, SVG Module, XML Module, Script Module и пр...
Так и VCL тоже не только GUI, там дополнительных модулей наверно побольше чем в Qt.
Да и в wxWidgets и даже в MFC/WTL они тоже есть.
Здравствуйте, lamer11, Вы писали:
L>Собственно у меня такой вопрос: на чем счас делается юзер интерфейс в серьезных с/с++ проектах? L>вообще вопрос вызван тем что я не понимаю одну вещь: L>почему ушел с++ билдер / делфи? L>насколько я знаю они счас оч непопулярны L>почему? L>они позволяю оч быстро и просто делать юзер интерфейс L>в чем их проблема?
ИМХО
1) Потому что более не разумно использовать неуправляемый код для больших работ по GUI.
2) Потому что на этот рынок пришла Микрософт. (Там судя по всему много чего было — и финансово Борланд зависели от МС, и людей МС переманила важных, да и вообще — жутковато с МС тягаться, особенно учитывая страшные сказки про смерть WinAPI в Vista)
L>могу предположить что они хорошо подходят только для каких-то оч шаблонных задач, а как только нужно сделать что-нить необычное возникают проблемы (это только предположение, потому что у оч многих навороченных либ которые много берут на себя по-моему есть такая проблемв)
Не соглашусь. Шаблонных задач что-ли меньше стало?
L>еще могу предположить что дело в его непереносимости на другие оси типо юниксов
Это оказало косвенное вляние. С появлением дотнета на C++ имело смысл делать GUI если хочешь переносимости, чего Борланд предложить не сумел, зато его конкуренты — QT и wxWidgets это умели всегда, а теперь эта фича стала относительно более весомой.
L>так ли это? еще какие-нить причины?
Задолбали обещания нормального компилятора !
Здравствуйте, Mazay, Вы писали:
M>ИМХО M>1) Потому что более не разумно использовать неуправляемый код для больших работ по GUI.
А можно поподробнее с этого места — почему неразумно? Delphi — очень мощная вещь для разработки GUI. При правильном подходе реализовать интерфейс, скажем, аналогичный интерфейсу Microsoft Office — это дело одного-двух рабочих дней.
Здравствуйте, Сергей, Вы писали:
С>А можно поподробнее с этого места — почему неразумно? Delphi — очень мощная вещь для разработки GUI. При правильном подходе реализовать интерфейс, скажем, аналогичный интерфейсу Microsoft Office — это дело одного-двух рабочих дней.
А можно ссылки на софт или хотя бы скриншоты софта написанного на Delphi с интерфейсом уровня Microsoft Office?
Только не Office 97, а хотя бы 2000-2003
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Сергей, Вы писали:
С>А можно поподробнее с этого места — почему неразумно? Delphi — очень мощная вещь для разработки GUI. При правильном подходе реализовать интерфейс, скажем, аналогичный интерфейсу Microsoft Office — это дело одного-двух рабочих дней.
Аналогичный не получится — у них всё на самопальных контролах построено (типа MsoCommandBar). Вряд ли за два дня удастся их воспроизвести.
Здравствуйте, shvonder, Вы писали:
_>>Опять же если заниматься адскими вычислениями то зачем выбирать борланд? S>Согласен, фортран удобнее. Но ещё более удобен Matlab (кроме шуток). Вейвлет-фильтрация матрицы в 10 строчках + рисуночек — это вам не асме оптимайзить.
а в чем проблема?
он вроде позволяет реализованную функцию в COM-объект запихнуть или в .dll
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, Mazay, Вы писали:
M>>ИМХО M>>1) Потому что более не разумно использовать неуправляемый код для больших работ по GUI.
С>А можно поподробнее с этого места — почему неразумно? Delphi — очень мощная вещь для разработки GUI. При правильном подходе реализовать интерфейс, скажем, аналогичный интерфейсу Microsoft Office — это дело одного-двух рабочих дней.
В управляемой среде программировать гораздо приятнее благодаря:
1) Сплошной RTTI и вся информация о типах в рантайме + reflection. Напрямую в прикладном коде это, разумеется, не часто используется, но позволяет делать разные вкусности вроде аккуратного стэк-трэйса, оборачивания объектов, плюс то что перечисленно ниже:
2) Нет таких страшных вещей как расстрел стэка или "Access Violation". Есть, конечно, NullPointerException, но как правило локализует легко, даже без отладчика.
3) Неверное явное приведение типов ловится сразу же и так же лего локализуется.
3) Динамическая загрузка кода. Поясню — если половина классов в проекте на Яве не компилируется, это ещё не значит, что проект не сможет запуститься. И вообще манипулирование сборками/class-файлами гораздо проще чем динамичесая подгрузка DLL.
4) Не нужно думать о таких вещах как передача параметра по указателю или по значению, о владении объектом, о том делать или не делать метод виртуальным и т. п. Для всего этого есть неплохое решение по умолчанию, которое, по крайней мере, не позволит выстрелить себе в ногу.
В общем, то что на Дельфи делается "при правильно подходе", здесь могут делать "тупые индусы".
Разумеется, за эти преимущества приходится платить снижением гибкости и вычислительными ресурсами. В случае приложений, где важен GUI (аськи, плееры, почтовики, органайзеры) это может стать фатальным.
Главное гармония ...
Re[2]: почему ушел C++ Builder / Delphi?
От:
Аноним
Дата:
27.11.07 14:26
Оценка:
Здравствуйте, dip_2000, Вы писали:
_>Здравствуйте, lamer11, Вы писали:
_>4) Тут нет у меня подтверждения, но есть ощущение что Делфи был так популярен именно в ExUSSR А за его пределами он был популярен совсем не так сильно. Границы стираются, и мы приходим к тому же, что и весь мир. http://google.com/trends?q=delphi говорит что Вы правы.
M>1) Потому что более не разумно использовать неуправляемый код для больших работ по GUI.
чем ?
M>2) Потому что на этот рынок пришла Микрософт. (Там судя по всему много чего было — и финансово Борланд зависели от МС, и людей МС переманила важных, да и вообще — жутковато с МС тягаться, особенно учитывая страшные сказки про смерть WinAPI в Vista)
никуда винапи не делся, да и болбшая часть в ней самой на С++ родном и написано
M>Это оказало косвенное вляние. С появлением дотнета на C++ имело смысл делать GUI если хочешь переносимости, чего Борланд предложить не сумел, зато его конкуренты — QT и wxWidgets это умели всегда, а теперь эта фича стала относительно более весомой.
Вы что-то путаете что B2006 что B2007 работаеют с .NET а последняя и под Висту.
_>>1) Там давно нет с++ там уродливое наречие сильно напоминающее с++
проходит все ANSI тесты
_>>2) Продукт перестал развиваться самим родителем(Борландом)
Его развивает другая компания, не думаю что это минус
S> По-поводу BCB согласен с автором. Это и не C++, и не Delphi, ни рыба не мясо. Пользуясь им всё равно приходиться знать Deplhi.
ЗА 10 лет пользования ни разу не приходилось копаться в Delphi
S> Низкое качество C++ (собенно шаблонов) проявляется при попытке установить любую популярную библиотеку. Boost приходиться ковырять
Все версии boost включая самую последнюю компилятся удачно. Можте что-то другое ?
Здравствуйте, AndrewJD, Вы писали:
AJD>А можно ссылки на софт или хотя бы скриншоты софта написанного на Delphi с интерфейсом уровня Microsoft Office? AJD>Только не Office 97, а хотя бы 2000-2003
Мда, что-то не находится. На предыдущей работе приходилось иметь дело с некой средой разработки для микроконтроллеров — так вот она была построена на Jedi VCL, в ней самыми примечательными были компоненты для Dock-окошек, MSOffice-подобные тулбары/меню и компоненты для сохранения состояния всего этого дела в конфиг. Попробовал найти какие-нибудь скриншоты Jedi VCL — на офф. сайте не нашлось. Даже самому стало интересно, что там изменилось за полтора года.
С ходу нашлось только это: http://www.tmssoftware.com/advtoolbar.htm
Это демка набора компонентов, реализующих эелементы интерфейса Office-2007. Штука платная, но цена не кусается, так что если стоит задача делать подобный интерфейс — в любом случае дешевле купить, чем самому писать.
В принципе, можно еще привести в качестве примера саму среду Delphi.
Здравствуйте, Максим2006, Вы писали:
М>Здравствуйте, Сергей, Вы писали:
С>>А можно поподробнее с этого места — почему неразумно? Delphi — очень мощная вещь для разработки GUI. При правильном подходе реализовать интерфейс, скажем, аналогичный интерфейсу Microsoft Office — это дело одного-двух рабочих дней. М>Аналогичный не получится — у них всё на самопальных контролах построено (типа MsoCommandBar). Вряд ли за два дня удастся их воспроизвести.
Воспроизводить и не надо — такие компоненты существуют, как бесплатные, так и платные.
Здравствуйте, Mazay, Вы писали:
M>В управляемой среде программировать гораздо приятнее благодаря: M>1) Сплошной RTTI и вся информация о типах в рантайме + reflection.
RTTI в Delphi тоже весьма богат — если сравнивать с C++.
Рефлекшена в Delphi (нативном, разумеется — не Delphi.NET) нет. В чем полезность этой фичи в условиях наличия исходников?
M>Напрямую в прикладном коде это, разумеется, не часто используется, но позволяет делать разные вкусности вроде аккуратного стэк-трэйса, оборачивания объектов, плюс то что перечисленно ниже: M>2) Нет таких страшных вещей как расстрел стэка или "Access Violation". Есть, конечно, NullPointerException, но как правило локализует легко, даже без отладчика. M>3) Неверное явное приведение типов ловится сразу же и так же лего локализуется.
Всё это, бесспорно, удобно, но я акцентировал внимание именно на преимуществах управляемого кода для написания GUI.
M>3) Динамическая загрузка кода. Поясню — если половина классов в проекте на Яве не компилируется, это ещё не значит, что проект не сможет запуститься. И вообще манипулирование сборками/class-файлами гораздо проще чем динамичесая подгрузка DLL.
В Delphi есть понятие Runtime Package — это DLL с дополнительной информацией о содержимом, благодаря чему также намного удобнее Plain-C DLL.
M>4) Не нужно думать о таких вещах как передача параметра по указателю или по значению, о владении объектом, о том делать или не делать метод виртуальным и т. п. Для всего этого есть неплохое решение по умолчанию, которое, по крайней мере, не позволит выстрелить себе в ногу.
M>В общем, то что на Дельфи делается "при правильно подходе", здесь могут делать "тупые индусы".
С этим спорить не буду — "тупые индусы" на Delphi пишут всю логику в OnClick'ах.
M>Разумеется, за эти преимущества приходится платить снижением гибкости и вычислительными ресурсами. В случае приложений, где важен GUI (аськи, плееры, почтовики, органайзеры) это может стать фатальным.
Мне в Delphi сильно импонирует то, что результат не требует ничего, кроме стандартных системных DLL. Да и нативное приложение намного быстрее запускается.
Собственно, мой интерес к теме разработки GUI на управляемом коде был вызван вот чем: 2 года назад я работал Delphi-программистом, и собственно тогда и понял, что сила Delphi в наличии большого количества компонент, которые как правило очень просто встроить в своё приложение. Например, в JediVCL было много компонентов, повторяющих поведение оригинальных элементов управления других программ — например, Dock-окна a-la VS2005, Navigation Bar от Norton Antivirus. Весьма навороченный интерфейс можно было создать весьма просто. Сейчас, я смотрю, все в "мире Delphi" осталось примерно на том же уровне — похоже, умирает. Вот я и хотел узнать, как с этим делом (наличием сторонних компонент) в разработке на .Net/Java.
Здравствуйте, silart, Вы писали:
S>Тут был разговор про высокую цену Qt. S>Скажите пожалуйста, сколько же стоит коммерческая лицензия Qt под Windows, для MSVC2005?
Здравствуйте, Alex_Avr, Вы писали:
A_A>Здравствуйте, silart, Вы писали:
S>>Тут был разговор про высокую цену Qt. S>>Скажите пожалуйста, сколько же стоит коммерческая лицензия Qt под Windows, для MSVC2005?
A_A>здесь
Да заходил я уже по таким ссылкам. Точную цену никогда не говорят. Как-будто большой секрет. Там регистрироваться нужно. Вы мне можете назвать цифру? Хотя бы порядок цифр. 1000 баксов, 10000 баксов, 100000 баксов? Сколько примерно?
Здравствуйте, silart, Вы писали:
S>Здравствуйте, Alex_Avr, Вы писали:
A_A>>Здравствуйте, silart, Вы писали:
S>>>Тут был разговор про высокую цену Qt. S>>>Скажите пожалуйста, сколько же стоит коммерческая лицензия Qt под Windows, для MSVC2005?
A_A>>здесь
S>Да заходил я уже по таким ссылкам. Точную цену никогда не говорят. Как-будто большой секрет. Там регистрироваться нужно. Вы мне можете назвать цифру? Хотя бы порядок цифр. 1000 баксов, 10000 баксов, 100000 баксов? Сколько примерно?
Прошу прощения, Daevaorn.
Просто вчера торопился, не стал заходить по вашей ссылке. У меня инет медленный.
Спасибо за ссылку.
Что-то действительно дороговато.
$3300 за Qt Desktop для одной платформы.
Хотя, за хороший продукт, да если еще контора профессионально занимается разработкой, по-моему стоит приобрести.
Ни с какими Делфи, Билдером и MFC не сравнится. Все гораздо круче.
Здравствуйте, lamer11, Вы писали: L>так ли это? еще какие-нить причины?
Плохая оптимизация. Особенно вычисрений с плаваюшей запятой.
Ещё очень много глюков, причём не только компилятора ("сложные" шаблоны) но и рантайма.
Самое обидное, что большенство из этихглюков очень давно известны, но не исправляются...
Здравствуйте, Dym On, Вы писали:
DO>[skip]
S>>Да кто ж спорит. Хорошая вещь. Но мне нужны матрицы библиотечные (Blitz), библиотеки надёжные (boost) и контейнеры стандартные. А формочки — что делать ? — придётся из wxWidgets брать. DO>Если Вас все в BCB не устраивает, то зачем Вы им пользовались?
Ааааа, не надо по больному месту... Ну, не по своей воле. Старого кода туева хуча есть, вот и сидим на (де)билдере.
Что я могу сказать: проблем куча есть и отрицать их наличие фразами типа 'ха, пионэры, вы просто билдер готовить не умеете правильно' по меньшей мере странно. Причем большАя часть глюков-глючков-глючочков просто детские какие-то. То среда косячит, то память в ней утекает... То инлайн подстановки не выполняются (оказалось, IDE не передает параметр компилятору... детсад просто).
Но есть и куча косяков более фундаментальных, вроде поддержки стандарта С++. Конечно, полностью его никто не поддерживает, но так, как его не поддерживает Билдер... эх, блин.
S>Что-то действительно дороговато. S>$3300 за Qt Desktop для одной платформы.
Есть варианты: Qt Light Desktop Edition (только QtCore + QtGui)
или заполнить и отправить документы по спецпредложению для мелких контор,
получив скидку в 70%
Мы недавно докупали лицензии как раз с такой скидкой.
там уродливое наречие сильно напоминающее с++
), а приходится писать много и муторно.
А новые библиотеки, скажем рисования? Один TChart разрекламированный с безобразной структура классов! (а править сырцы всё равно на Deplhi ) А COM подцепить кроме как родными для Dephi интерфейсами? Хорошо хоть удалось (с усилиями) использовать два модуля из ATL 3.0.
, ибо это возможно только при компиляции примеров из хелпа.
)
— придётся из wxWidgets брать.
). Тот же цейнот, отсутствие готовых библиотек и людей. 
!
