>>С учетом того что qt не используют stdlib, ваше замечание становится поразительно смешным.

QString QString::fromStdString ( const std::string & str )   [static]

Returns a copy of the str string. The given string is converted to Unicode
using the fromAscii() function.

This constructor is only available if Qt is configured with STL compatibility enabled.

>>Что препроцессор - это костыль (причем кривой)? Иил что Gtk вырастил нехилый набор костылей для поддержки ООП?

>Без препроцессора встроенного или внешнего не написана ни одна библиотека GUI на C++.

И это доказывает отсуствие этого костыля в Си? Си++ он хотя бы достался по наследству.

>>И в любом случае, то, что _тебе_ было проще писать COM-код на обычном Си, может говорить не только о том, что Си++ плох, но и о том, что ты плох, и о том, что COM плох.

>Поток сознания.

Ты просто не захотел понимать.

> STL, RTTI, Exceptions - любая из этих вещей тянет за собой весь CRT, который в COM фреймворк не интергирован абсолютно. И не мог быть интегрирован, так как с точки зрения Стандарта С++ у программы нет доступа к таким вещам как "монитор", "клавиатура", "сеть" и "ipc".

Ыыыы... Я правильно понял, STL, RTTI и exceptions не интегрированы в COM, потому что в стандартном Си++ нет доступа к монитору, клавиатуре, IPC и сети?

Кстати, ты удобно проигнорировал вопрос о том, какую "неявную бредятину С++ без спроса впердоливает".

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

Как это возможно, если ты C от С++ отличить не можешь?

> Я не об этом... в данном случае, "набить шишек" - это облажаться из-за самоуверенности и/или ограниченности.

> "1 - ничего не знает, не умеет, и всего боится; 2 - кое-что знает, умеет, и ничего не боится; 3 - знает и умеет всё, что нужно, и проявляет осторожность".

Ну я стараюсь аргументированно спорить :)

> Мне читать ваш пост смешно, а вот у вас я смайлика не вижу :)

Второй человек уже спрашивает, что такого инновационного придумал Троллтех.

>А эти 20% - как программировать?

На объектных языках, я не являюсь их противником. Просто, если писать на C, то как завещал великий^W^W^W как на C :)

>> А эти 20% - как программировать?

> На объектных языках

Вводить в проект еще один язык из-за 20% кода? Хаха.

>>Без препроцессора встроенного или внешнего не написана ни одна библиотека GUI на C++.

>И это доказывает отсуствие этого костыля в Си? Си++ он хотя бы достался по наследству.

Напиши GUI библиотеку на С++ без применения костыльного препроцессора.

>> STL, RTTI, Exceptions - любая из этих вещей тянет за собой весь CRT, который в COM фреймворк не интергирован абсолютно. И не мог быть интегрирован, так как с точки зрения Стандарта С++ у программы нет доступа к таким вещам как "монитор", "клавиатура", "сеть" и "ipc".

>Я правильно понял, STL, RTTI и exceptions не интегрированы в COM, потому что в стандартном Си++ нет доступа к монитору, клавиатуре, IPC и сети?

Да, авторы COM жили вне std::cin/std::cout/std::cerr/std::clog, и поэтому они вынуждены были сделать глобальное управление памятью, более-менее нормальный рефлекшен, RPC, компонентный фреймворк и пр. При этом С++ stdlib как ни странно не пригодился.

>Кстати, ты удобно проигнорировал вопрос о том, какую "неявную бредятину С++ без спроса впердоливает".

Exception handling prolog&epilog, неявные виртуальные функции, неявные преобразования типов и пр.

>Не перестают умилять каменты наиболее образованной фракции кдешнегов в духе "ООП=С++, Страуструп бох".

Читал когда-то прекрасный текст о том, что применять принципы ООП можно практически в любом языке, но другой момент, что есть приспособленные под это языки, а есть - нет. C++ затачивался специально. С - нет.

> Вводить в проект еще один язык из-за 20% кода? Хаха.

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

>>>Без препроцессора встроенного или внешнего не написана ни одна библиотека GUI на C++.

>>И это доказывает отсуствие этого костыля в Си? Си++ он хотя бы достался по наследству.

>Напиши GUI библиотеку на С++ без применения костыльного препроцессора.

Не напишу. И что. это доказывает некостыльность препроцессора в Си?

> авторы COM жили вне std::cin/std::cout/std::cerr/std::clog, и поэтому они вынуждены были сделать глобальное управление памятью, более-менее нормальный рефлекшен, RPC, компонентный фреймворк и пр. При этом С++ stdlib как ни странно не пригодился.

COM растет из разработок DEC (не Микрософт) самого начала 90-х, тогда C++ stdlib просто не было, распространенных компиляторов Си++ - тоже, и сам Си++ не был распространен :)

>>Кстати, ты удобно проигнорировал вопрос о том, какую "неявную бредятину С++ без спроса впердоливает".

>Exception handling prolog&epilog,

o_O они тебе мешали, а -fno-exceptions в компиляторе не было?

> неявные виртуальные функции,

wtf?

> неявные преобразования типов и пр.

Это преобразования, выполняемые конструктором? Просто не определять такие преобразования было нельзя?

> Если 80% кода - управление железом и сбор данных с него, а оставшиеся 20 - символьные вычисления

...то это 2 проекта :)

>>STL, RTTI, Exceptions - любая из этих вещей тянет за собой весь CRT

>4.2, учи матчасть и больше так не выставляй свое невежество

Чтобы собрать проект с опцией ATL_MIN_CRT надо отключить экзепшены, RTTI и не пользоваться STL(*), иначе будет несколько экранов unresolved external.

(*) Dinkumware вроде бы завязана только на ::operator new()/::operator new[]()/::operator delete()/::operator delete[](), не пробовал.

> ...то это 2 проекта :)

Тем интересней! :)

> "1 - ничего не знает, не умеет, и всего боится; 2 - кое-что знает, умеет, и ничего не боится; 3 - знает и умеет всё, что нужно, и проявляет осторожность".

И именно вторые являются источником бОльшей части никому не нужных проектов, но потенциально способных изменить мир. :)

Та ну его в пылюку этот флейм...

>>>И это доказывает отсуствие этого костыля в Си? Си++ он хотя бы достался по наследству.

>>Напиши GUI библиотеку на С++ без применения костыльного препроцессора.

>Не напишу. И что. это доказывает некостыльность препроцессора в Си?

Это доказывает что в C++ нету адекватной ему замены, хотя должна была бы быть.

>> авторы COM жили вне std::cin/std::cout/std::cerr/std::clog, и поэтому они вынуждены были сделать глобальное управление памятью, более-менее нормальный рефлекшен, RPC, компонентный фреймворк и пр. При этом С++ stdlib как ни странно не пригодился.

>COM растет из разработок DEC (не Микрософт) самого начала 90-х, тогда C++ stdlib просто не было, распространенных компиляторов Си++ - тоже, и сам Си++ не был распространен :)

Ну нифига себе. С++ отстал даже от технологий которые были до него.

>>>Кстати, ты удобно проигнорировал вопрос о том, какую "неявную бредятину С++ без спроса впердоливает".

>>Exception handling prolog&epilog,

>o_O они тебе мешали,

В COM исключения свои.

>а -fno-exceptions в компиляторе не было?

И пользоваться только Си API, которое без исключений? Спасибо за напоминание, я так и сделал. Только зачем мне тогда С++?

>> неявные виртуальные функции,

>wtf?

В ATL есть квалификаторы класса регламентирующие генерацию vTable, очевидно чтобы туда ничего лишнего не попало.

>> неявные преобразования типов и пр.

>Это преобразования, выполняемые конструктором? Просто не определять такие преобразования было нельзя?

Можно сразу все эти левые конструкторы и операторы= сразу поместить в private секцию класса, чтобы не мешались. Я так всегда и делаю.

>>>Exception handling prolog&epilog,

>>o_O они тебе мешали,

> В COM исключения свои.

В COM исключения как в CORBA - через возвращаемое значение. Чем этому мешали пролог с эпилогом?

>>а -fno-exceptions в компиляторе не было?

>И пользоваться только Си API, которое без исключений?

Ты так и не сказал, чем пролог/эпилог мешали. Кроме того, в Си++ есть еще много полезного, кроме исключений.

>>> неявные виртуальные функции,

>> wtf?

> В ATL есть квалификаторы класса регламентирующие генерацию vTable

И чем они мешали? В любом случае, это нестандартный Си++.

>>Это преобразования, выполняемые конструктором? Просто не определять такие преобразования было нельзя?

>Можно сразу все эти левые конструкторы и операторы= сразу поместить в private секцию класса, чтобы не мешались

Ну или так. И снова - проблема решена, не?

>На объектных языках

Чо, опять теплое с мягким?

http://www.helloworld.ru/texts/comp/other/oop/ch02.htm

Карделли и Вегнер говорят, что: "язык программирования является объектно-ориентированным тогда и только тогда, когда выполняются следующие условия:

* Поддерживаются объекты, то есть абстракции данных, имеющие интерфейс в виде именованных операций и собственные данные, с ограничением доступа к ним.
* Объекты относятся к соответствующим типам (классам).
* Типы (классы) могут наследовать атрибуты супертипов (суперклассов)" [34].

Поддержка наследования в таких языках означает возможность установления отношения "is-a" ("есть", "это есть", " - это"), например, красная роза - это цветок, а цветок - это растение. Языки, не имеющие таких механизмов, нельзя отнести к объектно-ориентированным. Карделли и Вегнер назвали такие языки _объектными_, но не _объектно-ориентированными_. Согласно этому определению объектно-ориентированными языками являются Smalltalk, Object Pascal, C++ и CLOS, a Ada - объектный язык.

> Карделли и Вегнер говорят, что: "язык программирования является объектно-ориентированным тогда и только тогда, когда выполняются следующие условия:

> * Поддерживаются объекты, то есть абстракции данных, имеющие интерфейс в виде именованных операций и собственные данные, с ограничением доступа к ним.

> Согласно этому определению объектно-ориентированными языками являются ... CLOS

В CLOS нет ограничения доступа к слотам класса. Сокрыть можно, но это реализуется другим механизмом в CommonLisp, не имеющим к CLOS никакого отношения. Карделли и Вегнер не в теме.

> Карделли и Вегнер не в теме.

Бгг.

> Латентность, заметная даже на глаз на оносительно старом железе

Так получилось, что этот пост я пишу на огнелисе под xubuntu на olpc. Железо очень хилое. Тулкит ведет себя вполне адекватно.

> Правильно, GNU is Not Unix!

"Советский, антисоветский - какая разница?.." (с) В данном вопросе разницы нет

Что "Бгг"? "Тогда и только тогда" и нарушение одного из "когда" как-то не вяжутся.

> C++ затачивался специально

Плохо его заточили. Испугались потерять С. В результате получилось фиговенькое ООП и монстроидальный язык. Вы бы смогли заточить специально _топор_ так, чтобы он хорошо работал как _колун_, но оставался топором?

> Что "Бгг"?

Что Карделли не в теме.

Ну я хз, кто в цепочке Карделли - анонимус-на-ЛОРе такую неточность допустил, но факт ошибки на лицо.

>>> А эти 20% - как программировать?

>> На объектных языках

> Вводить в проект еще один язык из-за 20% кода? Хаха.

Если ввести ещё один язык, то это может оказаться не 20% сишного кода, а 1% кода на tcl/tk :)

>STL, RTTI, Exceptions - любая из этих вещей тянет за собой весь CRT

>Чтобы собрать проект с опцией ATL_MIN_CRT надо отключить экзепшены, RTTI и не пользоваться STL(*), иначе будет несколько экранов unresolved external.

не вижу логической связи между "тянет" и "отключить", определись-ты наконец, с чего сам-то троллить будешь =)

>Второй человек уже спрашивает, что такого инновационного придумал Троллтех.

для дебилов, повторюсь: qt4.4

>Тулкит ведет себя вполне адекватно.

"Все познается в сравнении" - сделайте также

>И пользоваться только Си API, которое без исключений? Спасибо за напоминание, я так и сделал. Только зачем мне тогда С++?

Да, С++ это одни лишь исключения, rtti, шаблоны, etc. - как раз то, что тебе не нужно и жить мешает? Рекомендую расширить твой скудный кругозор =)

> Так получилось, что этот пост я пишу на огнелисе под xubuntu на olpc.

RMS, перелогиньтесь! :)

>Плохо его заточили. Испугались потерять С.

Смешно =)

>В результате получилось фиговенькое ООП и монстроидальный язык.

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

>Вы бы смогли заточить специально _топор_ так, чтобы он хорошо работал как _колун_, но оставался топором?

Мутная и совершенно неподходящая аналогия

Не для того я себя не пускал в РФ!

>Согласно этому определению объектно-ориентированными языками являются Smalltalk, Object Pascal, C++ и CLOS, a Ada - объектный язык.

Прочитай ещё раз внимательнее то, что я писал выше. Даже комментировать по существу не стану. Неинтересно, когда собеседник невнимательно слушает.

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

О чем и речь. Использовать С с парой синтаксических плюшек.

> Мутная и совершенно неподходящая аналогия

Специально для Вас extended edition: "за двумя зайцами погонишься, ни одного не поймаешь". И ООПв плюсах дурацкое, и с голым С совместимость потеряна в мелочах, после С99

> Правильно, GNU is Not Unix!

В этой фразе заключается юридическая сторона вопроса.

Linux - это UNIX тчк

> и с голым С совместимость потеряна в мелочах, после С99

это где это?

>> и с голым С совместимость потеряна в мелочах, после С99

> это где это?

Например, вот это C++ - ный компилятор не прожуёт.

static struct fuse_operations hello_oper = {
        .getattr        = hello_getattr,
        .readdir        = hello_readdir,
        .open           = hello_open,
        .read           = hello_read,
};

Это в гугле. На первой же странице поиска.

> "Правильный" тулкит должен легко биндиться на другие языки, чего за тулкитами, завязанными на С++, не наблюдается.

+1

> Тулкиты на С++ отлично связываются с языками, которые поддерживают ООП минимум на том уровне, какой необходим тулкиту, т.е. если какой-то язык связать с тулкитом нельзя - это лишь значит, что этот язык не поддерживает ООП в необходимой мере для использования тулкита.

Объектные модели в разных языках взаимонесовместимы, иначе зачем было бы делать разные языки? COM, UNO и другие решают эту проблему тем, что часть API выражается на наибольшем общем знаменателе языков, и это всех устраивает. Если делать API на C++, то на C++'ерам будет писать удобно, а остальные крутитесь как хотите, так?

Несложный пример: callbacks. В C это пара указатель-на-функцию+указатель-на-данные. У реализации callback последний параметр обычно void* (в WinAPI LPARAM), в него передаётся указатель-на-данные. В Ada жирным аналогом callback является нисходящее замыкание. В C++ — функтор. В Аде тоже можно функтор, но замыканием обычно удобнее. Если C++ либа требует функтор на вход, то придётся адское замыкание сначала обернуть в C'шный callback, а потом в C++'ный функтор. Если предоставить только чистый Адский интерфейс, плюсовики симметрично взвоют от языковых несовместимостей.

С этой точки зрения без разницы, привязываться ли к чужеродной системе типов C++ или к чужеродной системе типов GLib. Или к чужеродной системе типов ObjC. В GTK3 обещают IDL, а это уже интереснее.

> wxWidgets, gtkmm, они уродливы или свой изык придумали?

BEGIN_EVENT_TABLE ( MyFrame, wxFrame )

EVT_ACTIVATE_APP ( MyFrame::OnActivateApp )

EVT_CLOSE ( MyFrame::OnFrameClose )

EVT_KEY_DOWN ( MyFrame::OnKeyPressed )

EVT_MENU ( wxID_ABOUT, MyFrame::OnAbout )

EVT_MENU ( wxID_CLOSE, MyFrame::OnClose )

EVT_MENU ( wxID_CLOSE_ALL, MyFrame::OnCloseAll )

EVT_MENU ( wxID_CUT, MyFrame::OnCut )

EVT_MENU ( wxID_COPY, MyFrame::OnCopy )

EVT_MENU ( wxID_HELP, MyFrame::OnHelp )

EVT_MENU ( wxID_PASTE, MyFrame::OnPaste )

EVT_MENU ( ID_PASTE_NEW_DOCUMENT, MyFrame::OnPasteNewDocument )

EVT_MENU ( wxID_EXIT, MyFrame::OnQuit )

EVT_MENU ( wxID_NEW, MyFrame::OnNew )

EVT_MENU ( wxID_OPEN, MyFrame::OnOpen )

EVT_MENU ( wxID_SAVE, MyFrame::OnSave )

EVT_MENU ( wxID_SAVEAS, MyFrame::OnSaveAs )

EVT_MENU ( ID_RELOAD, MyFrame::OnReload )

...

EVT_UPDATE_UI ( ID_NEXT_DOCUMENT, MyFrame::OnUpdateNextDocument )

EVT_UPDATE_UI ( ID_HIDE_PANE, MyFrame::OnUpdateClosePane )

EVT_UPDATE_UI ( ID_RELOAD, MyFrame::OnUpdateReload )

EVT_IDLE ( MyFrame::OnIdle )

EVT_AUINOTEBOOK_PAGE_CLOSE ( wxID_ANY, MyFrame::OnPageClosing )

#ifdef __WXMSW__ EVT_DROP_FILES ( MyFrame::OnDropFiles ) #endif

END_EVENT_TABLE() IMPLEMENT_APP ( MyApp )

недостаточно уродливо? По-хорошему, event table должна быть инициализирована как-нибудь так:

EventTable evt_table (длинный список);

Сейчас, я вижу, всё сделано на макросах.

> Плюсы добавляют сложности во всех аспектах жизненного пути проекта

Жестоко, но справедливо

> Если резюмировать планы, то всё сводится к переписыванию ГТК заново. :)

We have all time in the universe. No worries and no guarantees. (c, FOSSD)

> Я - Страуструп. И, к сожалению, я вынужден признать, что С++ - говно.

БИС!

>>якой умный анонимуз. иди торвальдса унизь еще, он тоже с++ обложил как то.

>он еще и гном обложил, так что его мнение как неврастеника ничего не значит

И C++, и гном он более-менее по уму обкладывает, в отличие от всяких альтернативно зарегистрированных. Критики любому проекту нужны. Критики и эксперты как минус и плюс в элементе питания.

> Не подскажете, кто учит приделывать ООП к C?

Брэд Кокс

> Mono, единственного вменяемого фреймворка под все платформы

Mono не более всеплатформенная, чем GTK+.

> Как минимум: в настоящем ООП языке объектом является ВСЕ. Включая функции и классы.

Не в настоящем, а в "чистом" ООП языке. Чистый ОО язык -- это прокрустово ложе. Нет в ООП таких понятий, как классы-утилиты, равно как и классы-traits. Весь этот вонючий упор на ООП в буллшитных языках -- это надругательство над ОО принципами. Всё хорошо в меру. Не надо таких "настоящих" языков. Языковые элементы ООП должны быть только там, где они нужны.

>>>>IIRC, самая первая реализация Модулы3

>Брррр... А где оно живёт ? И живёт ли вообще ?

CVSup

> А то, что Си++ включает в себя весь Си89 - ты не знал?

Хватит уже повторять этот маркетинговый понос лемминг едишн

> объектно-ориентированными языками являются Smalltalk, Object Pascal, C++ и CLOS, a Ada - объектный язык

Сведения устарели лет на 13. Ada 95 -- это не просто объектно-ориентированный язык, это первый ОО язык, который стандартизировали.

>нормальная поддержка тем, а не той безвкусицы, что есть в GTK+, типа clearlooks, murrine, etc

Это Вы нереально "отожгли", да :D Сколько надежд я когда-то вкладывал в е17.. а до сих пор нет приличных приятных глазу тем..

> для дебилов, повторюсь: qt4.4

Сюрприз, IT-мир уже 50 лет выпускает новые версии софта.

> Сведения устарели лет на 13. Ada 95 -- это не просто объектно-ориентированный язык, это первый ОО язык, который стандартизировали.

Таки CLOS лет на десять до этого стандартом стал.

>Если лично вас не научили работать с динамической памятью, то это ещё не значит что больше никто не умеет. К сожалению, уже целое поколение выросло, которое считает, что malloc/free -- чёрная магия, а mmap -- нечто вообще непостижимое.

у вас проблемы с русским или просто не читали, на что отвечаете?

>Согласно этому определению объектно-ориентированными языками являются Smalltalk, Object Pascal, C++ и CLOS, a Ada - объектный язык. Бугогага! С++ - объектный, все слышали????? Сэр, я хочу в С++ без костылей создать объект, передать на него ссылку в соседний поток, поюзать и выбросить. Как??????

Господи, до чего ж тупые тролли.

С++ ВООБЩЕ НЕ БИНДИТСЯ К ДРУГИМ ЯЗЫКАМ БЕЗ КОСТЫЛЕЙ. ТОЧКА.

И происходит это потому, что в С++ используется формат вызова this-call, когда (на х86) this передается через регистр ecx. Стало быть, экспорты из либ надо обёртывать, ибо никто либе через this-call передавать параметры не будет - соседний язык не в курсе бинарных финтов компилятора, не знает где находится указатель на таблицу vmt, имен типа BA583MyClass9MyMethod11FFGRE не понимает. И делается это в минимуме так:

pop ecx mov eax, [ecx+vmt_of_my_class] call [eax+real_method_offset] push eax ;надо хоть что то положить в стек, иначе хана и misalignment retn

опс

pop ecx 
mov eax, [ecx+vmt_of_my_class] 
call [eax+real_method_offset] 
push eax ;надо хоть что то положить в стек, иначе хана и misalignment retn

>Наверное, таким образом разработчики пытаются избежать кошмара миграции, который можно видеть на примере библиотеки Qt.

хм. как же они видят кошмар, если на gtk/c пишут. дописка про телепатов от телепатов для ламеров (троллей и тулкитофобов)? =)

предлагаю креш-тест для GTK и QT

два объекта А и В, один поток. А держит единственную ссылку на В.

А посылает В сигнал и тут же его удаляет. прогнать сие через valgrind и просто проверить на наличие #SIGSEGV

>Вы пропустили запятую перед словом "GNOME".

я понимаю, конечно, всю глубину вашего отчаяния... но зачем же так.