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 ()

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

> Выдыхай. Считатель хэшей...

Не дождешься :-)

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

> А когда нужно написать нетривиальный OO-код, CLOS хотя бы позволяет это сделать.

Не спорю. Только пусть это делают квалифицированные программеры. А обычные пусть продолжают обоснованно боятся. Аминь.

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

> Ну хоть честно написал что не смог. Мысль была в контексте утверждения тейлганнера о том, что глубоко лезть в КЛОС люди боятся. Я сказал что правильно делают, что боятся. И не вел флейм "С++ против КЛОС".

Глубоко в CLOS - это на сколько? И что случается с теми, кто залез? Я знаю, что реализации CLOS отличаются в тех местах, которые точно не описаны в стандарте.

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

>> С++ эксперты сказали что перформанс это не главное, а главное - это literate programming, а кэш - это так, фигня.

>Вообще-то ссылку надо... а так, если на слово поверить, эксперты очень нехорошо сказали.

http://groups.google.com/group/comp.lang.c++.moderated/msg/4b532cef7518dac0?

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

А поконкретнее? Это?

> This is clearly suboptimal, in fact it has the worst possible cache utilization characteristics. That's not really a problem of the library's interface, but of its implementation. An expression-template-based library can fairly easily avoid such situations.

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

А поконкретнее? Это?

> This is clearly suboptimal, in fact it has the worst possible cache
> utilization characteristics.

That's not really a problem of the library's interface, but of its
implementation. An expression-template-based library can fairly
easily avoid such situations.

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

>А поконкретнее? Это?

Это отквоченный текст. Ответ - неотквоченный и сводится к тому что "абстракция первична, а утилизация кэша - это деталь неудачной реализации". Типичный плюсофильский треп.

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

> Это отквоченный текст. Ответ - неотквоченный и сводится к тому что "абстракция первична, а утилизация кэша - это деталь неудачной реализации". Типичный плюсофильский треп.

За 1 час можно написать класс matrix, чтобы matrix F = A+B+C+D+E счтитало его правильно, без проблем с кэшем -- т.е. тогда, когда мы уже полностью сформируем выражение и... например будем писать его в файл.

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

Это называется "lasy evaluation", и плюсы, хотя и со скрипом, такое позволяют

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

> А когда нужно написать нетривиальный OO-код, CLOS хотя бы позволяет это сделать.

Ты даже похоже не знаешь, за что надо бить плюсы. Какой КЛОС???!!! Ты бы посмотрел, какая там лямбда кривая !!!

/// тут кстати вроде пока других онанимусов не было, так может я могу и не подписываться? www_linux_org_ru

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

А если считаешь что это "недостаточно предсказуемо", то можно реальные операции сложения выполнять в копирующем конструкторе, и в случае matrix F = A+B+C+D+E он выполнится 1 (прописью: один) раз.

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

> Ты даже похоже не знаешь, за что надо бить плюсы. Какой КЛОС???!!! Ты бы посмотрел, какая там лямбда кривая !!!

Где лямбда кривая? В Лиспе анонимные функции прямые, в плюсах их совсем нет.

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

> Где лямбда кривая? В Лиспе анонимные функции прямые, в плюсах их совсем нет.

Нда... как с такими вести дискуссию? Я им жалуюсь, что лямбда кривая, а они говорят, что ее вообще нет :-)

http://www.boost.org/doc/libs/1_35_0/doc/html/lambda.html

Для тех кто не ходит по ссылкам:

for_each(a.begin(), a.end(), std::cout << _1 << ' ');

распечатает контейнер а.

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

И lazy evaluation в плюсах тоже есть, и тоже кривая...

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

> Глубоко в CLOS - это на сколько? И что случается с теми, кто залез? Я знаю, что реализации CLOS отличаются в тех местах, которые точно не описаны в стандарте.

На твой вопрос я могу дать очень приблизительный ответ. Тебе видимо надо еще спросить тейлганнера (он осторожный), ибо вопрос скорее психологический и не относится прямо к КЛОСу.

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

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

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

> Нда... как с такими вести дискуссию? Я им жалуюсь, что лямбда кривая, а они говорят, что ее вообще нет :-)

> http://www.boost.org/doc/libs/1_35_0/doc/html/lambda.html

Что-то мне подсказывает, что в Лиспе лямбда - это базовое понятие языка, а библиотечная реализация в плюсах - той же природы, что и "множественная диспетчеризация". Или ООП в Си.

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

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

Я ничего не понял. Вернее, понял всё, но не понял, к чему это.

Опять же, интересущие моменты поведения CLOS даже я могу поменять (без какого-либо серьёзного опыта), потому что CLOS для этого и проектировался. А вот что-то в boost::mpl сделать... Собственно, одна из причин гибкости CLOS'а - это существование нескольких независимых реализаций объектной системы в разных лиспах. Одной из задач ставилось разработка чего-то среднего между ними, но обязательно с возможностью поменять практический любой аспект поведения, чтобы удовлетворить всех основных лисповых вендоров (им же надо поддерживать свой старый код, ориентированный на их же старую объектную систему).

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

CLOS в моем понимании не только библиотека, но и способ создания новой __среды__, особенно в сочетании с разными мощными фенечками лиспа.

С моей точки зрения среды должны создаваться специалистами. В пятый раз повторяю.

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

> Что-то мне подсказывает, что в Лиспе лямбда - это базовое понятие языка, а библиотечная реализация в плюсах - той же природы, что и "множественная диспетчеризация". Или ООП в Си.

"библиотечная реализация" гораздо лучше, чем "базовое понятие языка"

Другое дело что язык недостаточен для хорошей реализации.

А еще, прежде чем наезжать не по делу на плюсы, полезно их выучить.

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

> CLOS в моем понимании не только библиотека, но и способ создания новой __среды__, особенно в сочетании с разными мощными фенечками лиспа.

Да

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

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

>Я ничего не понял. Вернее, понял всё, но не понял, к чему это.

Мне уже лень. Спроси у тейлганнера, почему он осторожный. Не факт что он тебе понятно объяснит. Если найдешь хорошее объяснение в инете, запость ссылку.

Также очень помогает набивание шишек :-)

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

> А еще, прежде чем наезжать не по делу на плюсы, полезно их выучить.

Список моих претензий не по делу? Ладно, анонимные функции в бусте можешь в список внести.

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

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

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

Но я считаю, что так и должно быть.

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

Я не знаю, почему должны помирать дядечки, но CLOS именно такой и есть. Кому интересны детали, подробности в Art of MOP.

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

> Я не знаю, почему должны помирать дядечки, но CLOS именно такой и есть. Кому интересны детали, подробности в Art of MOP.

Епрст... помирают конечно не дядечки, помирают проекты.

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

> Я не знаю, почему должны помирать дядечки, но CLOS именно такой и есть. Кому интересны детали, подробности в Art of MOP.

Укажи автора пожалуста

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

>> Избежать можно (whole-program оптимизация), но тогда компилируется медленно

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

Да, но это если надо динамически менять (а это не всегда так)

Nihilist
()
Ответ на: комментарий от anonymous

>>У каждого решения свои плюсы и минусы.

> Краткий ответ: "спасибо, просветил" :-)

> Полный ответ: иногда для ускорения программинга часть А намертво связывают с частью Б, принебрегая модульностью. Например, механизм виртуальной диспетчеризации намертво связали с компилятором.

Плюс в том, что библиотеки из разных источников будут использовать одну и ту же объектную модель. Правда, с учётом того, что там строк-то единых не состоялось, это уже не так принципиально.

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

>> Полный ответ: иногда для ускорения программинга часть А намертво связывают с частью Б, принебрегая модульностью. Например, механизм виртуальной диспетчеризации намертво связали с компилятором.

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

1. Может мне нужна другая РЕАЛИЗАЦИЯ объектной модели, а вовсе не другая объектная модель? А? Точно так же как в С я могу захотеть иметь свой printf, полностью совместимый со стандартом, но оптимизированный по скорости именно для моей задачи?

2. Моя реализация виртуальной диспетчеризации вполне может жить параллельно со стандартной. Смотри рабочий пример, если что не ясно.

Да и вообще я все это затевал, чтобы только доказать на фактах, что С++ местами шаг назад по отношению к С.

// пока что других анонимусов не видно...

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

_________________________________________________________________

В С я могу написать свой printf, полностью соответствущую стандарту, но работающую быстрее на моих данных. Я могу заменить стандартную printf ею.

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

Вывод: С++ хуже чем С в этом аспекте.

_________________________________________________________________

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

Но при этом попытки сэмулировать ООП всякими макросами стандартного препроцессора на С убоги... и кажется даже все сторонники gobject-a сбежали давно...

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

>Но при этом попытки сэмулировать ООП всякими макросами стандартного препроцессора на С убоги..

Попытки сэмулировать ООП хаками поверх С, чем собственно и является С++, убоги. Тем более что от макросов в С++ не избавились.

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

А где кончаются хаки и начинается нечно интересное?

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

> а в текстушке (или хтмл) для кпк есть? а на русском?

Не встречал. Перевод такие книжки, имхо, портит.

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

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

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

Это у Мейерса так часто бывает. В книжках, написанных лисповыми хакерами тоже (PCL, к примеру), но AMOP - книжка, скорее, академическая.

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

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

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

Да, есть только 2 языка - Си и Лисп. Первый - низкоуровневый, второй - наоборот. В обоих я могу наклепать/заменить все что угодно (включая ООП). Все "серединные" языки между ними неполноценны (за редким исключением).

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

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

Серединность -- это баззворд.

Nihilist
()
Ответ на: комментарий от xTERM

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

Правильно. Проблема только в том, КАК И ЧЕМ наклепать на С что-то похожее на (или покруче чем) С++. Стандартный препроцессор, надеюсь, никто не будет предлагать?

( вообще бывает, что за незнанием ООП люди переоценивают свои силы по его наклепу на чистом С :-)

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

Кого эта тема интересует (т.е. _модульный_ наклеп чего-то ОО, помощнее плюсов, поверх чего-то похожего на С) -- вот моя аська 335157744.

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

Может набросаешь как на нем сделать виртуальную диспетчеризацию поверх С? 10 000 строк тебе для этого хватит или мало будет?

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

> его, понимаешь, хороший надо придумать еще...

uid335157744@jabber.ru ;)

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

>Проблема только в том, КАК И ЧЕМ наклепать на С что-то похожее на (или покруче чем) С++

Посмотри топик ;)

В любом случае, gobject на уровне пользователя идеален. Сложности могут возникнуть только при написании своих компонентов. Хотя это миф. Погляди: http://library.gnome.org/devel/gobject/stable/howto-gobject-methods.html#id30... Почти плюсы :) Если _особо_ лень - возьми готовые "препроцессоры" по-типа Vala

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