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

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

_O_>>Не, никаких Фаров. Только

_O_>>

_O_>>copy con: MyCoolProg.exe
_O_>>

AE>Про это я как-то не подумал Это уже диагнох реального перца в квадрате

Уже такие перцы есть! Смотреть здесь

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

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


N>>положим захотелось нам искать среднее двух чисел и написали мы функцию:
N>>int kaka (int a, int b){return (a+b)/2;}

N>>и всё вроде тип-топ, но вот тут сунули нам два числа (вполне корректных):

N>>int a = 2113929216;
N>>int b = 2113929210;
_>Функциб kak можно переписать так:
_>int kaka(int a, int b){return ((a/2) + (b/2) + ((a%2) + (b%2))/2);}

_>Математика однако рулит не хуже Си с плюсами...и без плюсов тоже

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

S>Здравствуйте, Amidlokos, Вы писали:
A>>Математика в данном случае и правда рулит. Только при вычислении надо скастовать во float.
S>Это ты знатно придумал. Сможешь оценить просад производительности, не заглядывая в Intel Optimization Guide?

"А это уже второй вопрос" (С) Анекдот

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

(кстати, int-овую реализацию здесь

Автор: tinytjan
Дата: 25.05.05

уже предложили... что-то совсем голова до такого по жаре не допёрла)

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

Человеку скучно сделалось. Человек повоевать пришел.
А, собственно, повод к войне значения не имеет

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

K_O>Вот тут упоминали, что куча продуктов (Office, Adobe family, etc.) написана на С++. Написана, но в каждом
K_O>случае разработчикам приходилось писать свой framework конкретно под свой продукт (или семейство продуктов).

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

K_O>Вывод: для С++ нет нормальной (надежной и полнофункциональной) библиотеки для GUI.

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

Но потом оказалось, что всё-таки хочется от контролов большего, чем может дать библиотека, даже с расширениями.
В конце концов морду продукта (хотя там главное мозги) переписали на самописные контролы и оконную библиотеку. И не так уж дорого в масштабе всего изделия получилось. А лучше.

Просто у каждого прилодения есь свои особенности. Развитие опять же не стоит на месте. А библиотеки всё-таик зело статичны. Всегда предоставляют возможности нужные вчера.

У нас, кстати, рассматривалась идея перенсти оболочку на что-то дроугое с C++, (архитектура изделия в принципе это позволяет). Но оказалось, что не стоят яйца выделки. Всё-равно стандартные контроды хоть там хоть тут а всё же жмуть.
А уж если переписывать, то от чего бы и не переписать как нравится?

Ну а если надо быстро сработать приблуду какую-нибудь, то библиотека как раз и нужна.
В конце концов те самые приложения на C++ они не на VCL тоже написаны
Просто для такого большого монстра стандартная GUI библиотека невыгодной становится да и всё.

Кроме того вообще не ясна логика. Наверное в паскалеподобных языках есть что-то, что позволяет писать афигительные GUI библиотеки. Интересно что же это такое?

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

>> C>Есть. MFC, Stringray, и т.п.
>> Наша сказка хороша — начинай сначала. Только что подробно разобрали,
>> почему конкретно
>> MFC нельзя использовать для разработки, и тут на тебе опять.

C>Я услышал только один аргумент: не кроссплатформенная. Ну так оно
C>никогда таким и не планировалось.

1) MFC есть под Mac OS, но наверное лучше бы не было
2) Обычно portable GUI выглядят уродами всюду Запусти какоцй-нибудь ява-апплет. Например отсюда и насладись
И это понятно -- на разных платформах GUI приянто строить по-разному. Так что совсем-совсем переносимое GUI сделать "как родным" всюду очень трудно. Проще как-то иначе это всё запроектировать. MFC под Mac OS ужасна в первую очередь именно из-за того, что пытается совместить ужа с ежом и ведёт себя как принято на Mac OS, а приложению ажет вид что всё хорошо, всё как дома. Ну и лезут и лезут гадости.

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

A>Кроме того — ну, а где (повторю это любимое слово) ссылка-то на этот дельфовский суперкомпонент? Где пример программы с десятком тысяч node-ов?

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

Но мне опять же кажется, что обычно он таки не нужен

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

A>Я не говорю, что это будет быстрее. Я просто не понимаю (раз уж флейм пошёл) как от просада производительности спасёт контроль языком границ.
Очень просто. Язык либо станет статически ругаться на такую операцию (и тебе придется придумывать обходной вариант для подавления ворнинга), либо кинет ексепшн, не дав неверному результату прокрастся в программу.
A>Кастовать-то всё равно придётся,
С чего это вдруг?
A> а на проверку пойдут лишние такты.
Пойдут. Но флоат-вычисления, афаик, до сиж пор немеряно дороже целых.
A>(кстати, int-овую реализацию здесь

Автор: tinytjan
Дата: 25.05.05

уже предложили... что-то совсем голова до такого по жаре не допёрла)
Вообще-то, правильную реализацию предложили еше в феврале: Re[10]: Почему настоящие программисты избегают C++

Автор: screw_cms
Дата: 18.02.05

. И мне почему-то кажется, что она будет все-таки быстрее твоей

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

E>Кроме того вообще не ясна логика. Наверное в паскалеподобных языках есть что-то, что позволяет писать афигительные GUI библиотеки. Интересно что же это такое?

События, try...finally, информация о типах...

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

E>>Кроме того вообще не ясна логика. Наверное в паскалеподобных языках есть что-то, что позволяет писать афигительные GUI библиотеки. Интересно что же это такое?
K_O>События,

Ето не фича языка, это фича ОСи (если имеются в виду всякие WM_PAINT) или фича библиотеки (если имеются в виду всякие OnClick). Во всяком случае никто не помешал реализовать ту же идеологию в совершенно непаскалеподобном builder'е.

K_O>try...finally,

А гуи тут при чем?

K_O>информация о типах...

И что, таки только в паскалях есть?

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

П>Ето не фича языка, это фича ОСи (если имеются в виду всякие WM_PAINT) или фича библиотеки (если имеются в виду всякие OnClick). Во всяком случае никто не помешал реализовать ту же идеологию в совершенно непаскалеподобном builder'е.
Ну ты даешь. Непаскалеподобный билдер, между прочим, от С++ весьма и весьма отличается. Как ни странно, борланду пришлось изменить именно язык, а не библиотеки. Получилось что-то совершенно чудовищное. Как ты думаешь, удастся скомпилить билдерное приложение при помощи MSVC?
П>И что, таки только в паскалях есть?
Нет, есть еще и в билдере. См. выше. А также в управляемых средах.

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

E>>>Наверное в паскалеподобных языках есть что-то, что позволяет писать афигительные GUI библиотеки. Интересно что же это такое?
K_O>>События,

П>Ето не фича языка, это фича ОСи (если имеются в виду всякие WM_PAINT) или фича библиотеки (если имеются в виду всякие OnClick). Во всяком случае никто не помешал реализовать ту же идеологию в совершенно непаскалеподобном builder'е.

Ну, во-первых, не следует путать сообщения Windows и события. Во-вторых, события — это для Win32 именно фича языка, которую на С++ реализовать нормально невозможно. Чтобы С++Buildere реализовать события пришлось измененить язык. Тот С++, который там используется со стандартом несовместим.

K_O>>try...finally,
П>А гуи тут при чем?

try...finally обеспечивает гарантированный вызов finalization кода даже в тех случаях, когда в блоке try произошла исключительная ситуация. Причем в блоке finalization допускается возникновение еще одной исключительной ситуации, что недопустимо в С++ если использовать для этой цели scope guards. Причем здесь GUI? А притом, что нормальный GUI немыслим без многопоточности. Где многопоточность — там и объекты синхронизации. И вот тут finally очень помогает.

K_O>>информация о типах...

П>И что, таки только в паскалях есть?
Еще есть на платформах Java и .NET. Но для Win32 — только в Delphi.

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

S>Ну ты даешь. Непаскалеподобный билдер, между прочим, от С++ весьма и весьма отличается.

Но, согласись, от паскаля он отличается еще больше?

S>Как ни странно, борланду пришлось изменить именно язык, а не библиотеки.

Думается компилитор поменять было проще. Плюс опять же удобство разработки — не надо одни и те же либы по сорок раз переписывать.

S>Получилось что-то совершенно чудовищное.

Согласен. Но ведь получилось.

П>>И что, таки только в паскалях есть?
S>Нет, есть еще и в билдере. См. выше. А также в управляемых средах.

В скриптовых языках опять же (в питоне например). Так что рассматривать это как исключительное преимущество паскаля — вряд ли стоит ИМХО.

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

K_O>Ну, во-первых, не следует путать сообщения Windows и события.

Согласен, запутался слегка.

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

Если б вопрос стоял "что лучше для гуи — паскаль или с++" я бы, возможно не стал бы спорить. Но посмотри на тему, с++ там никаким боком, как, собственно и в исходном вопросе Егора:

E>Кроме того вообще не ясна логика. Наверное в паскалеподобных языках есть что-то, что позволяет писать афигительные GUI библиотеки. Интересно что же это такое?

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

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

Спорить не буду — не сталкивался настолько плотно.

K_O>>>информация о типах...
П>>И что, таки только в паскалях есть?
K_O>Еще есть на платформах Java и .NET. Но для Win32 — только в Delphi.

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

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

K_O>try...finally обеспечивает гарантированный вызов finalization кода даже в тех случаях, когда в блоке try произошла исключительная ситуация. Причем в блоке finalization допускается возникновение еще одной исключительной ситуации, что недопустимо в С++ если использовать для этой цели scope guards. Причем здесь GUI? А притом, что нормальный GUI немыслим без многопоточности. Где многопоточность — там и объекты синхронизации. И вот тут finally очень помогает.

Что насчет __try... __finally в с++ ? Хотя это и MS-specific но все же...
С другой стороны, мы на делфе реально пользуемся try..finally в 90% случаев для обеспечения эмуляции автоматических переменных...

K_O>>>информация о типах...
Что насчет RUNTIME_CLASS и проч.. ?

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

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

S>>Ну ты даешь. Непаскалеподобный билдер, между прочим, от С++ весьма и весьма отличается.

П>Но, согласись, от паскаля он отличается еще больше?

Я бы сказал так: паскаль — подмножество билдера, ввиду возможности последнего компилить пасовские юниты

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

K_O>События, try...finally, информация о типах...

уведомления (шаблон проектирования такой, вообще не language-specific практически), scope guard, rtti
Чем же они хуже для построения GUI библиотеки?

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

П>>Ето не фича языка, это фича ОСи (если имеются в виду всякие WM_PAINT) или фича библиотеки (если имеются в виду всякие OnClick). Во всяком случае никто не помешал реализовать ту же идеологию в совершенно непаскалеподобном builder'е.
S>Ну ты даешь. Непаскалеподобный билдер, между прочим, от С++ весьма и весьма отличается. Как ни странно, борланду пришлось изменить именно язык, а не библиотеки. Получилось что-то совершенно чудовищное. Как ты думаешь, удастся скомпилить билдерное приложение при помощи MSVC?
П>>И что, таки только в паскалях есть?
S>Нет, есть еще и в билдере. См. выше. А также в управляемых средах.

А что, там мега GUI библиотека?
Всё-таки хотелось бы понять что же нужно от языка для "действительно хорошей GUI библиотеке" такого, чего нет в C++.
Мне кажется, что однем из главных недостатков C++ является его гибкость. Но как раз этот недостаток позволяет промоделировать на C++ всё что угодно.

Бывают даже разработки, которые заставляют C++ прикинуться чем-то LISP-ообразным (или Prolog-оподобным)

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

K_O>>try...finally обеспечивает гарантированный вызов finalization кода даже в тех случаях, когда в блоке try произошла исключительная ситуация. Причем в блоке finalization допускается возникновение еще одной исключительной ситуации, что недопустимо в С++ если использовать для этой цели scope guards. Причем здесь GUI? А притом, что нормальный GUI немыслим без многопоточности. Где многопоточность — там и объекты синхронизации. И вот тут finally очень помогает.

AE>Что насчет __try... __finally в с++ ? Хотя это и MS-specific но все же...
Здесь MS-specific, в Builder'e — Borland specific, но все равно приходится менять язык С++. А что делать для Linux'a и прочих unix'ов?


K_O>>>>информация о типах...
AE>Что насчет RUNTIME_CLASS и проч.. ?
Это не только MS, это уже MFC-specific.

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

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

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

K_O>>События, try...finally, информация о типах...

E>уведомления (шаблон проектирования такой, вообще не language-specific практически), scope guard, rtti
E>Чем же они хуже для построения GUI библиотеки?
Про scope guards я уже сказал — они не допускают возникновения исключительной ситуации в finalization коде. Потому что в этом случае finalization код выполняется в деструкторе объекта, а в С++ исключение в деструкторе — это undefined behaviour.

rtti не является полноценнной заменой reflection'у, который есть в Java или .NET. Это очередная заплатка в языке.