Здравствуйте, Erop, Вы писали:
E>А что, там мега GUI библиотека?
Вообще-то одна из лучших. И это если считать только встроенную. А если учесть количество и качество бесплатных и коммерческих компонентов, которые бесшовно интегрируются с VCL (в частности, дизайнятся дизайнером и сериализуются стандартной подсистемой), то практически все остальные окажутся пылесосами.
E>Всё-таки хотелось бы понять что же нужно от языка для "действительно хорошей GUI библиотеке" такого, чего нет в C++.
Поддержки компонентной разработки. Я не буду расшифровывать — все это уже обсасывалось, и в том числе в этом форуме.

Sinclair wrote:

> Вообще-то одна из лучших. И это если считать только встроенную. А если
> учесть количество и качество бесплатных и коммерческих компонентов,
> которые /бесшовно/ интегрируются с VCL (в частности, дизайнятся
> дизайнером и сериализуются стандартной подсистемой), то практически
> все остальные окажутся пылесосами.

А в чем здесь заслуга *самого* VCL? Это заслуга среды и технологии
ActiveX. Сам VCL непосредственно — простенький враппер над WinAPI, не
сильно лучше WTL.

Лучшая GUI-либа, ИМХО, это QT.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Сам VCL непосредственно — простенький враппер над WinAPI, не
C>сильно лучше WTL.

Ну нет... Враппер над WinAPI это действительно WTL... MFC Тоже враппер своего рода,
тока с расширением функции.. VCL — это искажение WinAPI, местами добавлен функционал,
местами убран (скрыт) местами дико искажен для поддержки концепции VCL.. Чего стоит один
Handle ...

Когда юзал MFC — не мог и предположить что случайное использование хендла
в деструкторе окна приведет к таким диким последствиям как оказалось в VCL
А чего стоит TWinControl.SetFocus который кидается exception если контрол невидим
Так что не самый лучший вариант для построения ГУЯ... некоторые функции я использую апишные
принципиально, чтобы не писать лишние Try..finally.


Хотя с другой стороны надо отдать должное этой библиотеке ввиду наличия большого набора компонент и простоты
построения ГУЯ. Наверное этим она и прельщает многих разработчиков + удобно работать с БД...

C>Лучшая GUI-либа, ИМХО, это QT.
К сожалению не пробовал

AlexEagle wrote:

> Хотя с другой стороны надо отдать должное этой библиотеке ввиду
> наличия большого набора компонент и простоты
> построения ГУЯ. Наверное этим она и прельщает многих разработчиков +
> удобно работать с БД...

Работа с БД к самому VCL отношения не имеет, как и большой набор
компонент. Это заслуга среды, а VCL почти ничего существенного сам по
себе не добавляет по сравнению с WinAPI.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:
C>А в чем здесь заслуга *самого* VCL? Это заслуга среды
Что и требовалось доказать. Субж топика читал? ата не она, среда. Что и требовала
C>и технологии ActiveX.
АктивХэ к VCL имеет весьма косвенное отношение. Мой опыт использования внедренных активхэ контролов очень мал и чрезвычайно негативен. Все нормальные компоненты под VCL сделаны на VCL.
C>Лучшая GUI-либа, ИМХО, это QT.
Если учитывать стороннние компоненты, типа DevExpress, которые построены только благодаря языку и библиотеке Delphi, то, имхо, QT тихо умрет от зависти. Могу ошибаться.

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

K_O>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

Кривизна — это когда речь идет о руках программиста А так — самый гибкий язык, надо RTTI — получи с помощь RUNTIME_CLASS, надо обработчик завершения — тут уж доработала MS свой __try...__finally...

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

C>Работа с БД к самому VCL отношения не имеет, как и большой набор
C>компонент. Это заслуга среды, а VCL почти ничего существенного сам по
C>себе не добавляет по сравнению с WinAPI.

Я конечно понимаю что для тебя VCL просто три буквы, но для всех остальных
это Visual Components Library, поэтому свое "не причем" оставь при себе, хорошо ?

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

C>>Лучшая GUI-либа, ИМХО, это QT.
S>Если учитывать стороннние компоненты, типа DevExpress, которые построены только благодаря языку и библиотеке Delphi, то, имхо, QT тихо умрет от зависти. Могу ошибаться.

Имхо, DevExpress подавятся кросплатформенностью от QT

Здравствуйте, AlexEagle, Вы писали:
AE>Имхо, DevExpress подавятся кросплатформенностью от QT
Конечно. Но функциональность зачастую важнее кроссплатформенности.

Здравствуйте, Cyberax, Вы писали:
C>Работа с БД к самому VCL отношения не имеет, как и большой набор
C>компонент.
Правда что ли? Т.е. десятки тысяч строк VCL DB-компонентов — они для красоты написаны?
C>Это заслуга среды
А почему не пятницы?
C>, а VCL почти ничего существенного сам по
C>себе не добавляет по сравнению с WinAPI.
Ты точно видел VCL? Ну-ка, воспроизведи мне TClientDataSet заслугами среды или WinAPI.

Sinclair wrote:

> C>Работа с БД к самому VCL отношения не имеет, как и большой набор
> C>компонент.
> Правда что ли? Т.е. десятки тысяч строк VCL DB-компонентов — они для
> красоты написаны?

Есть ADO и ODBC, есть otl. Там те же десятки тысяч строк. А уж то что
они по какой-то причине попали в VCL — тупость Борланда.

> C>, а VCL почти ничего существенного сам по
> C>себе не добавляет по сравнению с WinAPI.
> Ты точно /видел/ VCL? Ну-ка, воспроизведи мне TClientDataSet заслугами
> среды или WinAPI.

ADO.Recordset. И я не понимаю почему оно входит в VCL, когда ему место в
отдельной либе.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Есть ADO и ODBC, есть otl. Там те же десятки тысяч строк. А уж то что
C>они по какой-то причине попали в VCL — тупость Борланда.

Чушь — это просто враперы сделанные по манере борланда упрощать до безобразия рутинные операции

>> C>, а VCL почти ничего существенного сам по
>> C>себе не добавляет по сравнению с WinAPI.
>> Ты точно /видел/ VCL? Ну-ка, воспроизведи мне TClientDataSet заслугами
>> среды или WinAPI.

C>ADO.Recordset. И я не понимаю почему оно входит в VCL, когда ему место в
C>отдельной либе.
Это и есть отдельная либа — ADOExpress Как и IBX в случае с TIBDatabase, TIBTable...

А тебе про TDatasource, TDataset и прочие базовые компоненты для доступа к БД говорят...
А также про TDBGgid, TDBEdit, TDBComboBox которые служат для ввода/редактирования данных из БД

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

K_O>>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

AE>Кривизна — это когда речь идет о руках программиста А так — самый гибкий язык, надо RTTI — получи с помощь RUNTIME_CLASS, надо обработчик завершения — тут уж доработала MS свой __try...__finally...

Только использование всех этих "гибкостей" обременено тысяей "если": если используешь только MSVC, если используешь именно MFC, и так далее...

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

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

C>>>Лучшая GUI-либа, ИМХО, это QT.
S>>Если учитывать стороннние компоненты, типа DevExpress, которые построены только благодаря языку и библиотеке Delphi, то, имхо, QT тихо умрет от зависти. Могу ошибаться.

AE>Имхо, DevExpress подавятся кросплатформенностью от QT

Пусть лучше мое приложение блестяще работает под одной ОС, чем коряво под десятью.

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

K_O>Во-вторых, события — это для Win32 именно фича языка, которую на С++ реализовать нормально невозможно.

Ну конечно boost::signal/function/bind дают такие "события", что дельфям и не снились.

K_O>Чтобы С++Buildere реализовать события пришлось измененить язык. Тот С++, который там используется со стандартом несовместим.

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

[...]
K_O>try...finally обеспечивает гарантированный вызов finalization кода даже в тех случаях, когда в блоке try произошла исключительная ситуация.

finally — это костыль, ведущий к copy-paste. В некоторых языках без него нельзя, в С++ — можно и нужно.

K_O>Причем в блоке finalization допускается возникновение еще одной исключительной ситуации, что недопустимо в С++ если использовать для этой цели scope guards.

А смысл? Я не вижу чем полезна возможность неявно потерять информацию об исключительной ситуации. Хоть для GUI, хоть не для GUI.

K_O>Причем здесь GUI? А притом, что нормальный GUI немыслим без многопоточности. Где многопоточность — там и объекты синхронизации. И вот тут finally очень помогает.

Для синхронизации scope-guards рулят как никогда. Их нельзя забыть написать.

[...]
K_O>Еще есть на платформах Java и .NET. Но для Win32 — только в Delphi.

Вот с информацией о типах в С++ туго, здесь нечено сказать. Хотя в дельфях не намного лучше.

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

K_O>finalization код выполняется в деструкторе объекта, а в С++ исключение в деструкторе — это undefined behaviour.

В С++ исключение в деструкторе — это вполне себе defined behaviour. Хотя и плохой тон. Проблемы начинаются в случае, когда деструктор вызывается уже как реакция на возбуждение исключения.

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

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

DB>1.Отсутствие модулей. Имитация понятия модуль в виде пары h-файл – cpp-файл приводит к многочасовым компиляциям системы.

Можно все в хэдере писать. Никто не запрещает.

DB>2.Использование целочисленных типов данных без знака (unsigned int) для номеров элементов и количественных значений в стандартной библиотеке stdc++. Приводит к следующим ошибкам:

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

DB>3.Отсутствие встроенной проверки на выход за диапазоны массива. Приводит к необходимости писать «обертки» для классов-контейнеров (в частности, для класса vector).

А кто мешает польховаться итераторами.

DB>4.Отсутствие встроенных средств инициализации динамической памяти нулями при конструировании объектов оператором new. Оборачивается не выигрышем, а проигрышем в производительности, поскольку приводит к необходимости писать код инициализации в конструкторах.

А почему например нет встроенных средств инициализации еденицами, мне например чаще еденицами надо инициализировать? Гибкость, однако.

DB>5.«Автоматизм» конструкторов и деструкторов для объектов, создаваемых динамически и имеющих виртуальные методы; работа виртуальных методов как не виртуальных при их вызове из конструкторов и деструкторов; отсутствие стандартного базового класса. Значительно затрудняет решение проблемы повторного входа в объекты (reentrance problem) при создании библиотек визуальных компонентов и систем GUI.

Ну тут согласен, просто С++ — язык довольно сразу, он рождался вместе с этими идеями, в Java и C# эти проблемы вроде решены.

DB>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

есть __try, __except, __finally, правда только у MS-совместимых.

DB>>6.Отсутствие оператора try {…} finally {…}. Приводит к созданию программ, неустойчивых к исключительным ситуациям. Попытка имитировать этот оператор с помощью оператора try {…} catch {…} приводит к большой избыточности кода.

UGN>Зачем он вообще нужен, этот finally? Делай все что нужно в деструкторах автоматических объектов

on ne nushen, no ochen' udoben... v ostal'nom polnostju s tonoj soglasen

D>Ну зачем же ставить заведомо нерешаемые задачи?
D>Над такими лучшие умы человечества бьются не один десяток лет, а Вы хотите чтоб Вам на каком-то инетрнет-форуме всё разрулили.

int kaka (int a, int b)
{
   return (a/2 + b/2);
}

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

K_O>Все эти изменения в языке или макросы в библиотеках — все это заплатки, свидетельствующие о кривизне языка С++.

Забавно, а вот приверженцы C++, обычно, возможность вводить в язык новые синтаксические кончтрукции при помощи макросов и хитрых шаблонов и перегруженных операторов, называют гибкостью и считают одним из огромных достоинств языка

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

Но я всё равно не понял при чём тут GUI