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

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

И если у тебя как у программиста не хватило тямы как это дело можно (и НУЖНО) скрыть --- то это, естественно, язык виноват. Вне всяких сомнений. Да-да, я помню, этот нехороший язык ещё и заставляет тебя иногда использовать такие "нюансы синтаксиса", как константные методы класса.... Просто ужас, а не язык! %)

то-то я удивился увидев от вас такое обращение, беру свои слова обратно - вы достойный собеседник, но никак не отреагировать на столь прямое оскорбление было трудно :) насчет рефлексии - в принципе у нее есть только одна область применения, это взаимодействие между разными модулями разных проектов, в рамках одного проекта она не нужна, или я не прав? :)

tailgunner - вменяемый человек с незашоренным мозгом. Если факт имеет место быть, он с этим соглашается. Из-за вот таких единиц, типа него, на ЛОРе всё ещё бывает интересно.

Название "persistent objects" тебе ни о чём не говорит?

Выпьем же за то, чтоб такие не переводились!

> Я просто принял тебя не за того.

Двойные стандарты? :)

Тебя тоже интересно читать, не смотря на то, что так много звёзд ;)

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

Мы уже проходили таких вот "дядечек", которые были такие же умные как ты (возможно, даже умнее, иначе не работали бы архитекторами в транс-национальной корпорации), избегали Цпп, надизайнили офигенную архитектуру и принялись писать на Жабе. Подозреваю, как раз из тех же самых соображений, что ты озвучил, плюс ещё каких-то своих: "сроки", "людей найти", "кроссплатформенно", "ынтырпрайз" и так далее.... А писали они, надо сказать, VoIP-клиент. Развязку истории рассказать или уже стало понятно? ;)

На всякий случай расскажу: все эти соображения "сроки", "найти людей" и прочие вылились (через некоторое время и некоторое количество KLoC) в то, что им таки ПРИШЛОСЬ найти людей, умеющих нормально писать на плюсах, заплатить им денех _слегка_побольше_, чем своим жаба-девелоперам, и в конечном итоге получить-таки свой VoIP-клиент, который не требует дуалкора с гигом памяти для своей работы.

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

>Начальник смены Дятлов говорит что....

В данном случае "дятлов" --- это не фамилия, и должно быть написано с маленькой буквы.

> насчет рефлексии - в принципе у нее есть только одна область применения, это взаимодействие между разными модулями разных проектов, в рамках одного проекта она не нужна, или я не прав? :)

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

Ну вот OPAL на плюсах написан, но внутри - мешок отвратно работающего говна. О чём это говорит? Что на плюсах ровно так же можно написать плохо, как и на джаве. А вот CCRTP, который тоже на плюсах написан, - совсем другое дело.

> и принялись писать на Жабе. [...] А писали они, надо сказать, VoIP-клиент

И что, даже RT Java им не помогла? o_O

>Ни Си++ надо разрешать кодить только тем кто Си++ терпеть не может.

Этого мало. Вместе с тем надо ещё и уметь. Поэтому тебе разрешать НИКАК нельзя.

>> и принялись писать на Жабе. [...] А писали они, надо сказать, VoIP-клиент

>И что, даже RT Java им не помогла? o_O

Тут скорее более полезно nio. И проекты со реалтаймовым стримингом с применеием nio в сети я видел

> tailgunner - вменяемый человек с незашоренным мозгом. Если факт имеет место быть, он с этим соглашается. Из-за вот таких единиц, типа него, на ЛОРе всё ещё бывает интересно.

чего не скажешь о вас :( ну да ладно

насчет persistent objects - я так и знал вы на яве прогите :) кстати вообще спор ява против с++ считаю немного неуместным - у них разные ниши, и все-таки насчет persistent objects - идея безусловно интересная, чесно говоря впервые про это только что читал( таки как я понял это чисто явовская технология ), ок - это еще одна область применения, хоть и достаточно экзотическая

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

>И если у тебя как у программиста не хватило тямы как это дело можно (и НУЖНО) скрыть --- то это, естественно, язык виноват. Вне всяких сомнений. Да-да, я помню, этот нехороший язык ещё и заставляет тебя иногда использовать такие "нюансы синтаксиса", как константные методы класса.... Просто ужас, а не язык! %)

Ну вообще клиент должен это барахло компилировать поскольку он должен знать размер (sizeof) объекта чтобы положить его в стеке. Но в стек мы его класть не будем, поскольку мы используем pimpl (Ты на pimpl намекаешь ведь так ?). В результате мы потеряли и перформанс, т.к мы не кладем объект в стек, и простоту, так как мы пользуемся костылем под названием pimpl.

> persistent objects - идея безусловно интересная, чесно говоря впервые про это только что читал( таки как я понял это чисто явовская технология )

Совпадение. Persistent objects - это старый обобщенный термин, пригодный для много чего, от сериализации до ORM и ООСУБД. /me даже припоминает язык Persistent Algol 8)

>Ну вот OPAL на плюсах написан, но внутри - мешок отвратно работающего говна. О чём это говорит? Что на плюсах ровно так же можно написать плохо, как и на джаве.

Да никто, блин, не спорит! Я-то как раз и говорю, что говна можно наворотить на чём угодно: и на сях, и на плюсах, и на жабе, и на до-диезе. Но при этом почему-то по факту получается, что одного языка "избегают", а другой объявляют панацеей, хотя на самом деле и в том и в другом случае дело лишь за грамотными специалистами. А их у нас хватает, да. Некоторые вон хреначат пачку шаблонов в хедер (который, возможно, потом инклюдится по всей программе) и орут потом "какая гадость эта ваша заливная рыба".... =\

но в данном случае это на 99.9% относилось к яве :)

> но в данном случае это на 99.9% относилось к яве :)

Лично я ставлю на CLOS :D

>И что, даже RT Java им не помогла? o_O

Всех деталей этой санта-барбары я не знаю, т.к. меня в тот момент там и близко не было. Я знаю результат: потыкавшись и помыкавшись они в конце-концов отдали проект сторонней конторе, которая сначала просто сделала копию того, что было, но на плюсах. А после того, как заказчик ошпарил колени, контора-исполнитель получила контракт на дальнейшее развитие проекта, а впоследствии и новые контракты.

> насчет persistent objects - я так и знал вы на яве прогите :)

Я не программирую на яве, ты не прав. Более того, я её не знаю даже.

> ок - это еще одна область применения, хоть и достаточно экзотическая

Т.е. прозрачно работать с объектами, которые живут между сеансами запуска и сохраняют своё состояние - это экзотика? Пользователи объектных СУБД так не думают.

> Лично я ставлю на CLOS :D

Ты знал, ты знал! :-D

>Ну вообще клиент должен это барахло компилировать поскольку он должен знать размер (sizeof) объекта чтобы положить его в стеке. Но в стек мы его класть не будем, поскольку мы используем pimpl (Ты на pimpl намекаешь ведь так ?). В результате мы потеряли и перформанс, т.к мы не кладем объект в стек, и простоту, так как мы пользуемся костылем под названием pimpl.

Большинство твоих проблем на самом деле решается грамотным проектированием. На месте интерфейса должен быть ИНТЕРФЕЙС, а не исполняющий его обязанности класс (с приватными данными и приватными методами, на которые ругается твой любимый cl.exe). И уж тем более среди этих данных не должно быть многоэтажных шаблонов, которые ты потом в стек кладёшь "ради перфоманса". И много-много других интересных вещей.

> чего не скажешь о вас :( ну да ладно

Да, я плюсами не восторгаюсь, плюсофилам меня читать не интересно.

ты ж больше года сам писал на с++, что потом случилось? :)

Полтора. Собрал волю в кулак и бросил. Но до сих пор есть ломка, так и тянет какую-нибудь гадость на CLOS в плюсатом стиле написать :(

А ещё работу поменял :-D

> Т.е. прозрачно работать с объектами, которые живут между сеансами запуска и сохраняют своё состояние - это экзотика? Пользователи объектных СУБД так не думают.

Пользователи объектных СУБД это разве тоже не экзотика? :)

> Пользователи объектных СУБД это разве тоже не экзотика? :)

Да, пользователи AllegroCache - это экзотика из TOP100 IT-компаний. Ведь всем известно, чтоб подавляющая часть IT-компаний в мире - полное говно ;)

так же как и с++? ;)

По части неприсущих ему свойств - да, говно.

>А, ну ну... GPL на помойку, даёшь LGPL...

отсутствие выбора. программиста заставляют делать программу либо GPL, либо покупать у троллей QT. а если прога бесплатная, но есть причины не открывать код (только не говорите что проги с закрытым кодом не нужны, да, желательно чтоб всё было открыто. но вы живём в реальном мире. иногда лучше прога независимого разработчика без исходников, чем никакая. для контор - другое уже дело. могут купить, но не любят когда им диктуют подобные условия)? вот и пишут чаще всего под GTK+. даже опенсоурс программы.

> Ты уже специализировал std::valarray для максимального использования SSE2 ?

Тебе апстенку показать или сам найдёшь?

> Как будто есть файловая система на С++, бгг.

Есть, бугагист ты наш.

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

Это проблема любого не-человесеского языка. Постоянно что-то приходится помнить. А программистов с хорошей памятью нынче наси сложно, да :)

> Я не ненавижу ни листы ни мапы. Только они должны быть раздельно компилируемыми либо вообще атомарными.

Ничего кроме абстрактой "красивости по Абсурду" это не даёт.

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

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

> А нефиг ВООБЩЕ было оставлять в языке передачь объектов по значению. Это абсолютное зло.

int тоже не по значению передавать? ;)

> И тогда без рефлексии ... приходится изобретать рефлексию вручную.

Смотрим название топика :)

> Это проблема любого не-человесеского языка.

Вот только не надо бессмысленных обобщений. Программируя на С, я не думаю про асм, если это специально не нужно. То же с жабкой. Никаких неявностей, коими богаты плюсы.

> Программируя на С, я не думаю про асм, если это специально не нужно. То же с жабкой. Никаких неявностей, коими богаты плюсы.

Прочитал как "я туда не хожу, там дверей много" :)

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

Увы, слишком много видал таких реализаций. Вы - нет?

> int тоже не по значению передавать? ;)

Тоже. Остальное - дело оптимизирующего компилятора и vm.

> Смотрим название топика :)

В С это естественная часть ОО жизни. Там весь ОО вручную. В отличие от плюсов, которые имеют наглость...

Вернуться в первый класс, видать надо - снова за букварь браться.

> Увы, слишком много видал таких реализаций. Вы - нет?

Язык не отвечает за кривые руки программистов на нём пишущих.

>> int тоже не по значению передавать? ;)

> Тоже. Остальное - дело оптимизирующего компилятора и vm.

Оптимизирующий Компилятор в верованиях явистов является первейшим божеством, это да.

>>> int тоже не по значению передавать? ;)

>> Тоже. Остальное - дело оптимизирующего компилятора и vm.

> Оптимизирующий Компилятор в верованиях явистов является первейшим божеством, это да.

http://c2.com/cgi/wiki?SufficientlySmartCompiler

По теме: было сказано про передачу обьектов. int - примитив.

>> Я не ненавижу ни листы ни мапы. Только они должны быть раздельно компилируемыми либо вообще атомарными.

>Ничего кроме абстрактой "красивости по Абсурду" это не даёт.

Это покрыло бы *больше* потребностей прикладных программистов чем покрывает STL. И несло бы *меньше* накладных расходов в плане вероятных ошибок и сложности компилирования. И даже возможно работало бы немного *быстрее*. Даже Строуструп это понимает, поскольку хочет чтобы компиляторы знали про STL. Однако это свидетельствует о каше в его голове - как это чтобы с одной стороны язык был "микроядерным", а с другой стороны "знал про STL"?

>> Ты уже специализировал std::valarray для максимального использования SSE2 ?

>Тебе апстенку показать или сам найдёшь?

Понятно, слив засчитан.

>Оптимизирующий Компилятор в верованиях явистов является первейшим божеством, это да.

Это плюсоиды на компилятор молятся, не надо проецировать. "Поставьте volatile, хороший компилятор должен (по идее) сгенерировать правильный код" (Ц) Александреску про инициализирование синглетонов.

>> А нефиг ВООБЩЕ было оставлять в языке передачь объектов по значению. Это абсолютное зло.

>int тоже не по значению передавать? ;)

int - объект?

>> И тогда без рефлексии ... приходится изобретать рефлексию вручную.

>Смотрим название топика :)

А в Qt стало быть используется С++ RTTI в отличие от. Интересно.

>Большинство твоих проблем на самом деле решается грамотным проектированием.

У меня проблем с С++ нет. Я просто в этом топике хочу внести лепту в его мучительную смерть. Как сказал какой-то французский писатель "я берусь за перо когда хочу с чем-то покончить".

>На месте интерфейса должен быть ИНТЕРФЕЙС, а не исполняющий его обязанности класс (с приватными данными и приватными методами, на которые ругается твой любимый cl.exe).

А как мне из метода интерфейса вернуть массив? Делать враппер с виртуальными функциями вокруг std::vector, да?

>И уж тем более среди этих данных не должно быть многоэтажных шаблонов, которые ты потом в стек кладёшь "ради перфоманса".

Я не кладу ничего в стек ради перформанса. Я использую pimpl. Только это слишком многа букав для того чтобы сделать еще один долбаный класс.

> int - объект?

В идеальном ОО - да;)