Планы по выпуску GTK+ версии 3

> В GNU C++ stdlib грустных комментариев тоже достаточно.

Да вот что-то ничего особо страшного не нагрепал. А вот какая-то либа(уж не xerces ли) наотрез отказывалась работать с 6 студией и просила проапдейтить её для поправки stl-я.

>Нечего там грепать. Страуструп сказал - stl, значит - stl, и точка. А страуструп - бох, ага

Мне нравится этот, весьма драматичный:

_Self& append(_CharT __c) { _M_reset(_S_destr_concat_char_iter(_M_tree_ptr._M_data, &__c, 1)); return *this; }

_Self& append() { return append(_CharT()); } // XXX why?

_Self& append(const _Self& __y) { _STLP_ASSERT(__y.get_allocator() == get_allocator()) _M_reset(_S_concat_rep(_M_tree_ptr._M_data,

Прямо глас вопиющего в пустыне "why?"

> Прямо глас вопиющего в пустыне "why?"

А что непонятно?

append() rope Appends the character charT().

>Да ты чоооо?

>А мой компилятор говорит мне "void Bar::foo(int) is private". У меня неправильный компилятор? Или это у тебя неправильный компилятор? Или для тебя "С++ == VC++"? Жги ещё %)))

А такой вариант конечно же успешно компилируется, следовательно приватный член void Bar::foo(int f) все же влияет на семантику, ЧТД.

#include <iostream>

class Bar { public: void foo(double f); };

void Bar::foo(double f){ std::cout<<f<<'\n'; }

int main(void) { Bar bar; bar.foo(21); }

> приватный член void Bar::foo(int f) все же влияет на семантику

ыыыы... на семантику чего он влияет? Созданной программы? Или из-за него компилятор отвергает валидную программу? Или принимает невалидную? "Семантика", блин. Это малохзначащая деталь реализации компилятора...

>Это малохзначащая деталь реализации компилятора...

Нет, это значит что приватные методы это тоже в некотором смысле элемент интерфейса класса. "Запретный интерфейс", скажем так. Иначе бы компилятор функцию с int - параметром попросту не увидел, и подхватил функцию с double аргументом.

ты никогда не видел, что случается, когда программа ведёт себя слишком умно?

Компилятор НЕ ОБЯЗЯН "подхватывать" метод с double, т.к. мы ЯВНО вызвали приватный метод с int. Компилятор выдал ошибку и тут стоит остановится и подумать что мы сделали не так. Тот пример что был выше с short и long тоже правильный, потому что мы ЯВНО не указали, какой метод вызывается и компилятору нужно сконвертить int в long или short, и он не знает во что лучше, и поэтому спрашивает у нас.

> Компилятор НЕ ОБЯЗЯН "подхватывать" метод с double, т.к. мы ЯВНО вызвали приватный метод с int
Java:
class Bar {
public void foo(double f) {
System.out.println(f);
}
private void foo(int f) {
System.out.println(f);
}
};

public class Main {
public static void main(String[] args) {
new Bar().foo(21);
}
}

При запуске выводит 21.0

ничего не поделаешь, это Java. Мы говорили о C++...

> ничего не поделаешь, это Java. Мы говорили о C++...

т.е. Абсурд прав и в C++ нет инкапсуляции?

> Абсурд прав и в C++ нет инкапсуляции?

Инкапсуляции, соотвествующей (неопубликованному) определению Absurd@LOR, в Си++ нет :)

Кстати, D ведёт себя так же, как C++.

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

Более подробно об этом:

http://rsdn.ru/article/mag/200502/abi.xml

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

>> совместимость не нужна, ибо это повод для создания костылей

> Если бы сообщили эту потрясающую мысль Страуструпу в момент создания плюсов - он, возможно, создал бы что-нибудь приличное, и мы с Вами бы тут не беседовали бы.

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

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

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

Если ANSI CL датирован 94м, то как к нему успели пристандартизировать объектную модель в 85м? Ну да не суть важно в контексте дважды вырванной цитаты.

>> Даже в самый первый момент плюсы уже в мелочах были несовместимы с С.

> Такая задача не ставилась

Как-то они не очень преуспели в том, чтобы не ставить эту задачу

> ЕМНИП, юзайте ICC

Лучше уж сразу IAC

>> Ок, как по-вашему должно было бы быть?

> В тру ОО языке указатели не нужны.

Метод разработки программ ИМХО перпендикулярен модели памяти.

> Для идеологии Free Software, где все ошибки при достаточном количестве глаз лежат на поверхности, использование C++ вполне приемлемо (если рассматривать приведенные тобой закономерности как аргумент против C++).

На оплачиваемой работе з/п программиста на C++, как правило, повышенная. Если делать свободное ПО, то Вам усилия для борьбы с косяками C++ никто оплачивать не будет, так что это только в Ваших интересах не писать на C++ и не делать C++-специфичных ошибок.

(кстати, меня всегда интересовало, что будет, если сделать прикольный закрытый проект со всеми стандартизированными фичами C++, так, чтобы его только Comeau мог осилить, а потом, когда он вырастет в размерах, заопенсурсить и по праву назвать Free Software? Как фрисофтварщикам понравится напоминание, что они не смогли осилить написание компилятора своего любимого языка?)

> По сути, гномовцы так и ставят целью сделать. Есть C с ужас какими макросовыми извращениями, в который компилируется Vala - вполне себе нормальный ОО-язык, прошу заметить, с чистым синтаксисом и поддержкой всяких сигналов и рефлексии на уровне языка, причём без здорового рантайма с фреймворком и байткодом а-ля Java и .NET.

> Да, конкретно сейчас в Vala нужна куча костылей, чтобы написать что-то сложнее хеллоуворлда - см. http://www.linux.org.ru/view-message.jsp?msgid=2745907 . В идеале человек будет писать на Vala и вообще не придавать значения тому, что оно компилируется в какой-то там C, точно так же, как сишники не задумываются об ассемблере, который генерируется где-то там внутри GCC.

> Из зависимостей - только glib в минимальном случае. Плюс любые сишные библиотеки, причём напрямую без врапперов.

> Если честно, мне странно, что никто ещё такого вроде не делал.

А ObjC? ObjC и NSObject очень похожи на Vala и GObject (хотя подробностей устройства GObject не знаю). Специально под объектную модель ObjC есть разные языки под Mac OS X (типа F-Script). Аналогично Vala -- специальный язык под объектную модель GObject.

> Обычно ОО-средствами языка страраются решить поставленную задачу, а то, что вы имеете ввиду под ОО ("надо или нет - оно будет использоваться") - фетишизм

Я бы даже сказал академические заморочки

> Не решает. Придется использовать тот самый закат солнца вручную, который был показан в wx. Вместо того, чтобы иметь это все на уровне языка. Представьте себе, что Вы пишете application server на плюсах. Сами applications доступны в виде .so модулей. Дальше Вы его грузите. Дальше Вы получаете ссылку на EJB, ой, главный объект "приложения". И начинаете выяснять, что он умеет-может... Вам придется строить свой собственный ОО, создавая "рефлексию вручную".

Даже уже сделано всё. COM, XPCOM, UNO. Можно использовать вместе разные языки. Сколько языков можно использовать в ASP и сколько в EJB (или как там его?)? Уж лучше COM & XPCOM & UNO.

> Что такое "настоящий ОО"?

Исключительно предмет спекуляции. Также как "настоящее отчаяние" (ц)

> winapi объектную модель не навязывает(а вот дотнет -- навязывает, чем и плох).

+1

Я одного не пойму: почему эти быдло-тролли и остальные противники C, оргазмирующие исключительно на C++, не предлагают само ядро - Linux на C++ переписать???!!!

>Я одного не пойму: почему эти быдло-тролли и остальные противники C, оргазмирующие исключительно на C++, не предлагают само ядро - Linux на C++ переписать???!!!

Почему это не предлагают? Предлагают еще как. Даже ветку вроде отдельную кто-то делал с возможностью включения кода на ЦПП в ядро. Новость была в прошлом году тут. Вот только Торвальдс такой крутой флудер, что его фиг в чем переспоришь в этом вопросе.

> На оплачиваемой работе з/п программиста на C++, как правило, повышенная. Если делать свободное ПО, то Вам усилия для борьбы с косяками C++ никто оплачивать не будет, так что это только в Ваших интересах не писать на C++ и не делать C++-специфичных ошибок.

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

>> Абсурд прав и в C++ нет инкапсуляции?

>Инкапсуляции, соотвествующей (неопубликованному) определению Absurd@LOR, в Си++ нет :)

Инкапсуляция - сокрытие деталей реализации от клиента кода. Если клиенту кода приходится компилировать boost::shared_ptr<Widget> и std::vector< boost::shared_ptr<Widget> > оттого что в private - секции класса лежит std::vector< boost::shared_ptr<Widget> >, то это хреновое я бы сказал сокрытие.

частные случай, который можно отнести практически к любому языку( т.е. так же можно сделать не только в с++ ), и что это доказывает? :)

> Оффтопик: а у нас тут относительно недалеко реактор потёк :) На одном новостном сайте пишут, что ТВЭЛ разрушился и загрязнил первый контур охлаждения, и, типа, ниче серьёзного, а на другом сайте пишут, что разрушился первый контур и произошла утечка охлаждающей жидкости, и тоже ниче особо серьёзного. Если сложить обе новости, то можно предположить, что разрушился ТВЭЛ, разрушился контур охлаждения, и вместе произошла утечка топлива за пределы реактора :)

Потом в интернете появилось "ни одного разрыва" и все забили на рекатор.

Он кстати того же типа, что и чернобыльский, только модифицированный с учетом украинского опыта.

> Он кстати того же типа, что и чернобыльский, только модифицированный с учетом украинского опыта.

На тот момент РБМК-1000 был один из самых совершенных реакторов. Самым большим его косяком была вера в людей ;) Жизненно важную автоматику нельзя отключать.

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

Студент по определению не может писать сложный проект, потому что он только учится (не, ну может, конечно, быть какой-нибудь асоциальный тип, который с самого начала полового созревания думает исключительно о программировании, а не о девках, но психические отклонения сейчас не рассматриваем). Сложный проект пишут много опытных дядек и, возможно, тётек, у которых процесс разработки ПО поставлен на конвейер. Обдумывают архитектуру специальные дядечки с печальными глазами, которые по всем граблям ходили, и Мейерсу к его 50 советам ещё столько же сходу напишут. И сии дядечки стараются избегать использования C++, потому что сроки разработки с его использованием, как правило, затягиваются, плюс всё трудней и трудней найти людей, которые могут на плюсах нормально писать.

Последнее предложение, кстати, не моё, я его услышал от архитекта на собеседовании в одной крупной московской аутсорсинговой конторе :)

> На оплачиваемой работе з/п программиста на C++, как правило, повышенная.

Всё относительно. Это зарплата программистов на "безопасных" явадотнетах пониженная :)

> Даже уже сделано всё. COM, XPCOM, UNO.

Это всё сделано гораздо раньше, когда придумали пайпы. Самый универсальный интерфейс между любыми языками.

>На тот момент РБМК-1000 был один из самых совершенных реакторов. Самым большим его косяком была вера в людей ;) Жизненно важную автоматику нельзя отключать.

Начальник смены Дятлов говорит что все защиты для работы в том конкретном режиме реактора были включены. И работа велась штатно, без авралов.

Т.е. реактор штатно нагрелся выше штатной рабочей температуры и штатно саморазрушился? И персонал штатно сидел и чесал яйца, не обращая внимание на стрелку термометра, конвульсирующую в красной зоне? Чудеса...

>Т.е. реактор штатно нагрелся выше штатной рабочей температуры и штатно саморазрушился? И персонал штатно сидел и чесал яйца, не обращая внимание на стрелку термометра, конвульсирующую в красной зоне? Чудеса...

Я не Дятлов, полемизировать не буду. В книжке "Чернобыль: как это было" отражена его позиция, но полемизировать не получится, т.к он умер от лучевой болезни.

> Он кстати того же типа, что и чернобыльский, только модифицированный с учетом украинского опыта.

У РБМК-1000 один контур охлаждения, а в новости было сказано про утечку в первом контуре, т.е. можно предположить, что контуров в том реакторе больше.

эээ. а чё там про gtk+ версии 3? ;)

GTK+ версии 3 не может перегреться и разрушить активную зону с последующим выбросом радиоактивного топлива в окружающую среду. Классная штука!

ага, и хомячок Вассермана её не разу не перегрызал )

>> Т.е. реактор штатно нагрелся выше штатной рабочей температуры и штатно саморазрушился? И персонал штатно сидел и чесал яйца, не обращая внимание на стрелку термометра, конвульсирующую в красной зоне? Чудеса...

> эээ. а чё там про gtk+ версии 3? ;)

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

Я в зоологии плохо разбираюсь, про хомячков не в курсе...

> Оффтопик: а у нас тут относительно недалеко реактор потёк :) На одном новостном сайте пишут...

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

а на чём обычно энтерпрайз реакторы програмят? на gtk+ или на QT?

PS: следим за рейтиногом, мы сравнялись!

> а на чём обычно энтерпрайз реакторы програмят? на gtk+ или на QT?

На Tk.

> PS: следим за рейтиногом, мы сравнялись!

Уже обогнали! :)

~$gtk-demo

>> PS: следим за рейтиногом, мы сравнялись!

> Уже обогнали! :)

(утирая скупую мужскую слезу) Всем спасибо!

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

надо им оказать помощь, местный биореактор должен сгодится.

>> ...разработчикам требуется реактор для проверки.

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

А если опять они что-то недоправили и произойдёт громадный выброс быдла?

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

Т.е. все кто дожил до диплома - уже ненормальные по-определению.

Что Вы называете "сложным" проектом ? 8) QT+KDE, к примеру это проект где-то на 3- если принять 5ти бальную шкалу сложности. Хочу сказать, что даже эту отметку пересекают считанные единицы "С++ проектов"(ради справедливости надо отметить что и других - тоже 8) - сложности детекта ошибок, заложенных в базовых класах, ростут явно круче чем линейно, по мере усложнения уровней абстрагирования.

Я бы сказал что С для проектов это N*ln(N), а для С++ N^2 8). Неподходит С++ для "больших" проектов... (впрочем как и С)

P.S. Этот вопрос неоднократно уже мусолился в инете. Оценки деградации получались самые разные - привожу "усредненные".

> P.S. Этот вопрос неоднократно уже мусолился в инете.

Этот вопрос также мусолился бабушками у подъезда. Результат: да, нонче языки-то уже не те, вот раньше-то писали мы на коболе и проблем не занли.

Умней аргументы есть ? 8)

> Умней аргументы есть ? 8)

Есть. Проекты одинаковой сложности на C++ и Java(например) имеют сильно неравный размер, сильно увеличивающийся в сторону Java. Потому 10 KLoC на Java сложно адекватно сравнить с 10 KLoC на C++.

Помилуй бог, нам еще только жабы тут не хватало 8) Судя по количеству дохлых Java проектов sf.net, в ней всё обстоит еще гораздо более мрачно 8)

>Проекты одинаковой сложности на C++ и Java(например) имеют сильно неравный размер, сильно увеличивающийся в сторону Java.

JVM это как город спроектированный по регулярному плану, т.е с противопожарными рвами и канализацией. И поэтому потолок для роста объема кода намного выше. А насчет одинаковой сложности это ты загнул - дъявол обычно бывает в мелочах.

> Это всё сделано гораздо раньше, когда придумали пайпы. Самый универсальный интерфейс между любыми языками.

такой же простой неправильный ответ, как и .неЪ

> JVM это как город спроектированный по регулярному плану, т.е с противопожарными рвами и канализацией. И поэтому потолок для роста объема кода намного выше.

Как мне сделать замыкание, не городя дополнительного класса? Как мне не плодить SomethingBean ещё и интерфейс Something, хотя он используется только одним классом, в EJB только из-за того, что EJB это требует? Как мне поработать с файлом, не городя целый экран try-finally?

>> Это всё сделано гораздо раньше, когда придумали пайпы. Самый универсальный интерфейс между любыми языками.

> такой же простой неправильный ответ, как и .неЪ

Мсье идиот и не осилил пайпы. Пройдите на виндовс.

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

>> Инкапсуляции, соотвествующей (неопубликованному) определению Absurd@LOR, в Си++ нет :)

> Инкапсуляция - сокрытие деталей реализации от клиента кода.

Спроси капитана Очевидность - он скжет, что даже Си отвечает такому определению "инкапсуляции".