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

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

> Ну я имел в виду написание. Вот ФС на яве я уже видел. И сделал вывод о применимости.

Таненбаумовский GLOBE на яве, кстати, пишется.

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

> Кстати, а как сейчас обстоят дела у явы с такими областями как гуйки, обработка текста, медиакодеки? Я честно не в курсе.

Все в порядке;)

> Резон: скорость. Видите или шрифт побольше сделать?

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

> Мы о красоте диаграммы наследования или о практической применимости говорим?

Они взаимосвязаны. Спросите архитекторов.

> В моей конторе это называлось "стажировка".

Длиной в пару лет? Да у Вас просто благотворительная контора!;)

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

Это безответственно по отношению к опенсорцу.

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

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

Бытует мнение, что сразу обучать настолько высокоуровневому языку как ява -- только во вред. Хотя если ставится цель научить только ООП...

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

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

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

>> Кстати, а как сейчас обстоят дела у явы с такими областями как гуйки, обработка текста, медиакодеки? Я честно не в курсе.

> Все в порядке;)

А где ссылки на success stories, чтоб по ним не ходить?

> Для скорости обычно вполне хватает обозримый кусок кода переделать на обычном С. Не заморачиваясь конфликтом двух объектных моделей.

Сложите мне быстро на C два тензора произвольного типа. Да, я издеваюсь :)

>> В моей конторе это называлось "стажировка".

> Длиной в пару лет? Да у Вас просто благотворительная контора!;)

Месяца на 4 всё затянулось. (У нас проект на тикле был.)

Всё-таки, unit tests в качестве полигона для новичкой сойдёт?

> Это безответственно по отношению к опенсорцу.

Каждый пишет как умеет, и не факт, что тренировочный проект может оказаться хуже уже имеющегося. (/me покосился на $subject) А если окажется, так интернет большой, никто неудачный проект и не обнаружит.

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

>тебе мало библиотек под с++?

По хорошему коду на С++ можно однозначно определить автора. Это как отпечатки пальцев. К сожалению, у этого есть обратная сторона которая на практике сводится к тому что лучше использовать библиотеку на С. Неправославно зато дешево, надежно и сердито.

>Страуструп не пишет компиляторы

CFront. Но до написания библиотеки хотябы типа TurboVision он не снизошел, иначе язык был бы побогаче.

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

>Сложите мне быстро на C два тензора произвольного типа.

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

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

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

Да. Сорсы под NDA, так что показать не могу.

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

> Бытует мнение, что сразу обучать настолько высокоуровневому языку как ява -- только во вред.

Не буду спорить. Начинать с асма и С - неплохая идея. А потом перейти к высокоуровневым - яве, питону, смоллтолку... (ну про функциональщину пока помолчим). Места для плюсов в этой цепочке нет. Учить ОО по плюсам - это вандализм по отношению к неокрепшим детским душам.

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

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

Жабка, при наличии JIT, hotspot, AOT - уже практически компилятор. Вообще, разница сейчас довольно условна. Да и несущественна. Существенна модель, предлагаемая языком.

> но неужели там нет своих "фич"?

Конечно, есть (не люблю полуправды, а идеальных языков не существует). Но другого характера.

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

> Учить ОО по плюсам - это вандализм по отношению к неокрепшим детским душам.

А кто-то учит плюсам ради обучения светлой идее ОО? Тренироваться надо на кошках а не на боевых инструментах.

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

> А где ссылки на success stories, чтоб по ним не ходить?

Тут же ЛОР, по ссылкам все равно не ходят. А ходящие знают где гугл;)

> Сложите мне быстро на C два тензора произвольного типа. Да, я издеваюсь :)

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

ЗЫ А вообще математикой надо на фортране заниматься;)

> А если окажется, так интернет большой, никто неудачный проект и не обнаружит.

Это некрасиво. Стремиться надо к тому, чтобы опенсорц был примером качественного кода. А не радоваться тому, что он является свалкой кошмарного кода.

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

Я и говорю - в плане обучения программированию плюсам места нет. А после того как выучили - в общем, тем более, если люди узнали уже вкус приличного ОО.

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

>> но неужели там нет своих "фич"?

> Конечно, есть (не люблю полуправды, а идеальных языков не существует). Но другого характера.

Кстати, какого? Я пока что встречал из "фич" только похожие на то, что map.put(a.fun().subfun()) выглядит похоже на map.put(a.fun()).subfun(), но второе даёт нульпоинтер.

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

> Я и говорю - в плане обучения программированию плюсам места нет.

За все полторытыщисообщений хоть кто-то хвалил C++ как язык для обучения? Этот вопрос, насколько помню, не стоял.

> А после того как выучили - в общем, тем более, если люди узнали уже вкус приличного ОО.

Тогда они будут знать, что теряют и что приобретают, идя на плюсы.

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

> Тут же ЛОР, по ссылкам все равно не ходят. А ходящие знают где гугл;)

На гугле тоже ссылки %)

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

Ну вот мне и иинтересно, как "реализацию именно для тех типов, которые реально нужны в проекте, сделаю на С" будет выглядеть в данном случае. Пусть у нас есть типы (2,3), (0,1), (3,0)

> Это некрасиво. Стремиться надо к тому, чтобы опенсорц был примером качественного кода. А не радоваться тому, что он является свалкой кошмарного кода.

Для того, чтобы качественный код был, его надо писать. А для этого надо тренироваться.

С какого раза в glib/gtk появилось красивое ОО?

// заголовок "Планы по выпуску GTK+ версии 3" как бы намекает, что с третьего :)

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

> Кстати, какого?

У жабки - в первую очередь, многословность (обратная сторона простого синтакса). Отсутствие эффективного итерирования (обратная сторона отсутствия указателей). Недетерминированность работы gc (иногда это плюс, иногда это минус). Некоторая неконсистентность базовых API (были легкие косяки в первой версии, а теперь их исправить нельзя, ибо совместимость). Навсидку, пожалуй, все. Хотя наверняка товарищи еще вспомнят...

Ну и всякие траблы конкретных API.

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

>За все полторытыщисообщений хоть кто-то хвалил C++ как язык для обучения?

Ну Си например преподают в ВУЗ-ах на курсе системного програмирования.

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

>> За все полторытыщисообщений хоть кто-то хвалил C++ как язык для обучения?

> Ну Си например преподают в ВУЗ-ах на курсе системного програмирования.

Мсье опять путает C и C++?

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

>>> За все полторытыщисообщений хоть кто-то хвалил C++ как язык для обучения?

>> Ну Си например преподают в ВУЗ-ах на курсе системного програмирования.

>Мсье опять путает C и C++?

Нет, не путает. Просто Си пригоден как учебный язык, а Си++ - видимо нет.

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

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

Да. У нас за год даже не успевают сказать "а вот тот тип данных list, который мы с вами изучали есть в STL"

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

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

> Ну вот мне и иинтересно, как "реализацию именно для тех типов, которые реально нужны в проекте, сделаю на С" будет выглядеть в данном случае. Пусть у нас есть типы (2,3), (0,1), (3,0)

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

И еще раз - вычислистику я предпочту делать на фортране. Безо всяких жабок и сей вообще.

> А для этого надо тренироваться.

Безусловно. Но хочется сократить период обучения написанию _приемлемого_ кода. Кстати, именно приемлемого кода на плюсах мало - обычно либо ужасный, либо хороший (после многолетнего опыта).

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

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

Компилировать надо компилятором, а оптимизировать - головой. (с) слова одного очень умного человека.

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

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

Ну то есть тезис о том, что любое тонкое место можно переписать вставкой на C постепенно поблёк.

> И еще раз - вычислистику я предпочту делать на фортране. Безо всяких жабок и сей вообще.

А где кончается вычислистика и начинается GP? Плюсы примерно где-то на этой грани и балансируют. И сразу становится ясно, зачем там перегрузка, конструкторы копирования и т.д.

> Но хочется сократить период обучения написанию _приемлемого_ кода. Кстати, именно приемлемого кода на плюсах мало - обычно либо ужасный, либо хороший (после многолетнего опыта).

Приемлимым кодом обычно назвается то, что из 10 запусков падает не чаще 2 раз. И это -- ужасно.

Кстати, не на основании ли сорсов kde4 сделан вывод, что хорошего кода на плюсах мало? Просто я не знаю более мест, где в опенсорсе можно добыть много материала для подобного анализа.

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

> Ну то есть тезис о том, что любое тонкое место можно переписать вставкой на C постепенно поблёк.

Ок, убирем слово "любое". Большинство тонких мест можно переписать на С. А которые нельзя - возможно, можно и не трогать вообще;)

> И сразу становится ясно, зачем там перегрузка, конструкторы копирования и т.д.

Именно затем, что Страуструпу хотелось побить фортран. Получилось не очень.

> Приемлимым кодом обычно назвается то, что из 10 запусков падает не чаще 2 раз. И это -- ужасно.

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

> не на основании ли сорсов kde4 сделан вывод, что хорошего кода на плюсах мало?

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

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

>> Приемлимым кодом обычно назвается то, что из 10 запусков падает не чаще 2 раз. И это -- ужасно.

> Странное определение.

Маркетинговое.

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

Выбор алгоритма никак не зависит от свойств языка. А алгоритмы и влекут за собой оптимальное или неоптимальное решение.

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

Поверю на слово, ибо профессиональным прогаммистам на C++ я через плечо в экран не заглядывал.

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

>А где кончается вычислистика и начинается GP? Плюсы примерно где-то на этой грани и балансируют. И сразу становится ясно, зачем там перегрузка, конструкторы копирования и т.д.

А чем плох MATLAB ?

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

> А чем плох MATLAB ?

1. Плохой полученного кода без наличия перед глазами матлабовских исходников.

2. В матлабе есть только один тип данных -- матрица. Интервальную арифметику там не замутишь.

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

> Плохой полученного ...

Плохой читабельностью полученного...

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

> А где кончается вычислистика и начинается GP? Плюсы примерно где-то на этой грани и балансируют. И сразу становится ясно, зачем там перегрузка, конструкторы копирования и т.д.

Афигеть, впервые вижу приписывание конструкторов копирования зависти к Фортрану o_O

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

> Именно затем, что Страуструпу хотелось побить фортран. Получилось не очень.

Кстати, в фортране вроде нет возможности определять свои типы данных. А алгебраистам это ой как полезно.

Кстати, на меня произвели сильное впечатление вот эти исходники на фортране: http://num-anal.srcc.msu.su/lib_na/cat/cat541.htm

Слово anal в имени сайта явно не случайно.

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

> Афигеть, впервые вижу приписывание конструкторов копирования зависти к Фортрану o_O

Ну почему зависти? Банальные соображения того, что объект -- это нечто, над чем производятся действия.

Которое оказалось неприменимо в ынтырпрайзе. Там объект -- это тот, кого надо попросить что-то сделать.

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

>> Афигеть, впервые вижу приписывание конструкторов копирования зависти к Фортрану o_O

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

ИМХО, именно правила вызова конструкторов и привели к офигенной сложности Си++. Может быть, Страуструпу следовало оставить value-семантику для struct, и сделать классы reference. Интересно, он как-то обосновал свои решения?

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

> Может быть, Страуструпу следовало оставить value-семантику для struct, и сделать классы reference.

Возможно, тогда бы этого треда не было. Это сильно бы ослабило мои позиции.

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

>ИМХО, именно правила вызова конструкторов и привели к офигенной сложности Си++. Может быть, Страуструпу следовало оставить value-семантику для struct, и сделать классы reference.

Да, так было бы логичнее конечно же. Тогда бы все разговоры любителей плюсов о cons и trade-off имели бы какой-то смысл.

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

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

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

> да операторы нельзя было перегружать (вот точно вам говорю: перегрузка операторов - это Страуструповы комплексы перед фортраном)...

А перегрузка операторов в Питоне, Хаскеле (и Клу тоже :)) - это чьи комплексы перед чем? :D

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

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

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

> Это вредное влияние плюсов, разумеется!;)

Что, Страуструп тоже слямзил машину времени ЛОР? o_O

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

>А если бы в довершение объекты бы жили только в хипе

Это само собой. Только сказав "А" надо сказать и "Б" - если ограничиваемся только подсчетом ссылок, то выносим это на уровень языка и вносим класс weak - референсов. Если не ограничиваемся, то надо делать разметку бинарного представления объекта под gc. В С++ сказано "А", так как разметки объектов под gc нет, но не сказано "Б".

>да операторы нельзя было перегружать

Это не кардинальная проблема. Можно перегружающие библиотеки и не использовать. Лично меня работа с BigInteger в жабке однако коробит.

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

> Историю прогуливал? :D

У нас на специальности из истории освещали разве что исторические аспекты био- и прочих реакторов ;)

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

>Как раз дело в том, что learning curve у плюсов сильно больше (выше и длиннее), чем у голого си, не говоря уж про менеджед языки типа жабки и додиеза.

С этим никто не спорит.

>Мои предложения уже запоздали. Автоматическая коробка шествует по миру. А вот насчет капота я не понял - спецам-то надо иметь доступ для ремонта. Какой же он избыточный?

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

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

>Справедливости ради: в Европе ради экономии топлива все поголовно ездят на механике. Ну и автомат - это считается для лохов.

Они там ради экономии топлива перебираются на машины, начинающиеся в районе педалей и заканчивающиеся в районе "10 см за спинкой кресла" %)

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

>С жабкой такого уже не случится.

...

>Нафига жабщику плюсы?

Пример я, кстати, уже приводил, когда "жаба-йа-йа-арбайтен-арбайтен-оу-е-оу-щит-нихт-арбайтен-уотзефак-си-плас-плас-а рбайтен-арбайтен-дас-ист-фантастиш!"

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

> А "обычных юзеров" можно очень просто оградить от её покупки высокой ценой.

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

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

Вот именно, что "прикрыто", но не более того. Никому не воспрещается снять кожух, залезть в потроха и самостоятельно поменять те же свечи, к примеру.

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

> Может быть, Страуструпу следовало оставить value-семантику для struct, и сделать классы reference.

В D struct - просто размеченная область памяти. Их можно без проблем передавать в C. А class - ссылочный тип дпнных с поддержкой OO. Это действительно решает кучу проблем, но немного усложняет написание шаблонов, т.к. где структуру достаточно присвоить, класс нужно копировать. Приходится городить static if (is(T : struct)) { ...

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