LINUX.ORG.RU

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

 


1

0

В списке рассылки gtk-devel-list обсуждаются планы выпуска GTK+ версии 3. Основные подготовительные действия, которые необходимо предпринять в текущей ветке:

  • Спрятать все открытые поля структур с помощью макроса GSEAL(). В случае необходимости предоставить новые методы доступа к этим полям. Также должны быть скрыты поля-указатели "priv" на структуры, содержащие закрытые данные. Эти действия уже практически полностью проведены в репозитории git://git.imendio.com/projects/gtk+.git
  • Реализовать закрытые члены класса, что включает изменения в коде GType.
  • Объявить как deprecated публичные данные класса с помощью макроса GSEAL().
  • Поскольку не останется простого способа для доступа к полям класса, а использование g_object_[sg]et() утомительно, необходимо ввести новые методы доступа, вроде g_object_get_int(), *double(), *string() и т.д.
  • Существует множество макросов, таких как GTK_WIDGET_GET_FLAGS(), которые всегда были причиной многочисленных проблем (см. bug #69872). Необходимо реализовать нормальные методы доступа (в виде функций) и избавиться от этих макросов.
  • GtkStyle, без сомнений, самый сложный тип, нуждающийся в скрытии публичных полей, и до релиза должно быть проведено множество исследований.
  • Избавиться от всего кода, объявленного deprecated в 2.x. Это подразумевает все соответствующие виджеты и функции.
  • Удалить все поля структур из публичного API. Есть два способа достичь этого:
    a) переместить все структуры в закрытые заголовки;
    b) переместить структуры в C-файл реализации, но тогда всей библиотеке придётся использовать соответствующие методы доступа.
    Эти варианты ещё обсуждаются.
  • Отключить deprecated-код по умолчанию во флагах компиляции.
Таким образом, версия 3.0 будет готова к релизу. Все приложения, которые собираются для ветки 2.x с макросом GSEAL() и не используют deprecated-кода, будут без проблем собираться для ветки 3.x. Наверное, таким образом разработчики пытаются избежать кошмара миграции, который можно видеть на примере библиотеки Qt.

>>> Подробности

★★★★

Проверено: JB ()

Ответ на: комментарий от Absurd

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

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

MYMUR ★★★★
()
Ответ на: комментарий от tailgunner

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

lester ★★★★
()
Ответ на: комментарий от lester

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

mv ★★★★★
()
Ответ на: комментарий от lester

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

mv ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

mv ★★★★★
()
Ответ на: комментарий от svu

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

mv ★★★★★
()
Ответ на: комментарий от mv

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

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

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

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

MYMUR ★★★★
()
Ответ на: комментарий от Absurd

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

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

MYMUR ★★★★
()
Ответ на: комментарий от lester

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от MYMUR

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

mv ★★★★★
()
Ответ на: комментарий от Absurd

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

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

MYMUR ★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

Absurd ★★★
()
Ответ на: комментарий от mv

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

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

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

lester ★★★★
()
Ответ на: комментарий от MYMUR

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

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

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

Absurd ★★★
()
Ответ на: комментарий от lester

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от mv

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

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

MYMUR ★★★★
()
Ответ на: комментарий от tailgunner

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

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

MYMUR ★★★★
()
Ответ на: комментарий от lester

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

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

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

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

mv ★★★★★
()
Ответ на: комментарий от Absurd

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

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

MYMUR ★★★★
()
Ответ на: комментарий от lester

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

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

mv ★★★★★
()
Ответ на: комментарий от lester

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

mv ★★★★★
()
Ответ на: комментарий от mv

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

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

lester ★★★★
()
Ответ на: комментарий от lester

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

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

mv ★★★★★
()
Ответ на: комментарий от lester

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

mv ★★★★★
()
Ответ на: комментарий от SergikXP

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

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

tommy ★★★★★
()
Ответ на: комментарий от Absurd

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

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

gaa ★★
()
Ответ на: комментарий от Absurd

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

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

gaa ★★
()
Ответ на: комментарий от svu

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

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

gaa ★★
()
Ответ на: комментарий от Absurd

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

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

gaa ★★
()
Ответ на: комментарий от svu

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

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

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

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

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

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

gaa ★★
()
Ответ на: комментарий от gaa

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

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

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

gaa ★★
()
Ответ на: комментарий от gaa

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

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

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

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

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

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

svu ★★★★★
()
Ответ на: комментарий от gaa

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

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

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

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

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

gaa ★★
()
Ответ на: комментарий от gaa

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

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

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

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

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

naryl ★★★★★
()
Ответ на: комментарий от gaa

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

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

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

Absurd ★★★
()
Ответ на: комментарий от gaa

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

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

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

Absurd ★★★
()
Ответ на: комментарий от gaa

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

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

Absurd ★★★
()
Ответ на: комментарий от gaa

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

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

int - объект?

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

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

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

Absurd ★★★
()
Ответ на: комментарий от MYMUR

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

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

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

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

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

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

Absurd ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.