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

я против С ничего не имею, реализовали, работает - что еще надо? значит молодцы

>языку, имеющему наглость называть себя

ROFL =D

> более-менее приличных вещей

мое ИМХО - использование вещей из IsKindOf, ClassByName и т.п. это плохо, это и есть костыли - причем в тексте программы( точнее в проектировании модели программы и необходимых классов/интерфейсов ), а не в самом языке, именно в этих местах скорее всего и проявятся лажи при расширении кода программы, так что называть это "приличными вещами" я бы не стал

>Вижуал ?

Ну вообще, по стандарту он должен отвалиться в "неоднозначностью", т.к есть неявная конверсия int->double.

И как ты без IsKindOf реализуешь динамическую диспетчеризацию по двум аргументам? Визиторы городить будешь на каждый чих?

> В принципе, все это можно делать и на С.

Ещё б это нельзя было сделать на Тьюринг-полном языке :)

Вопрос в удобстве и только в нём. Риторический вопрос: удобен ли GObject?

> это плохо

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

> Надо - используете (gobject), не надо - не используете.

Сделайте мне libxml++ без GObject

>В ОО языках это именно так "надо или нет - оно будет использоваться". На то они и ОО.

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

>А когда ОО "как бы" (кагбэ?) есть, но приходится городить огороды для более-менее приличных вещей...

Какая степень необходимости использования этих "более-менее приличных вещей" по отношению к имеющимся возможностям С++?

может я не так понял вопрос, но как по мне использование интерфейсов и виртуальных функций вполне решает эту задачу

> Ну и в сях вон ООП нагородили. Тоже типа рабочее решение.

Вопрос в количестве костылей.

Вполне удобен. Вопрос привычки;)

Нет, вопрос не в удобстве. Удобство субъективно. А вот тот факт, что плюсы являются ОО только на момент компиляции - это объективно. Как и все вытекающие из этого следствия по недостаточной функциональности в том, что касается ОО.

Это тот случай когда "надо".

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

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

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

Да, это все возможно. Но то, что это Вам придется делать САМОМУ - говорит о качестве ОО в плюсах.

>>Ну вообще, по стандарту он должен отвалиться в "неоднозначностью", т.к есть неявная конверсия int->double.

У тебя каша в голове. man method overloading

interface I_Application
{
public: //////////////////////////////////////////////
bool CanSomething( void ) = 0;
bool CanSomethingElse( void ) = 0;
...

public: //////////////////////////////////////////////
void DoSomething( ... ) = 0;
...

public: //////////////////////////////////////////////
menu* GetObjectMenu( object* inObject );
void PrefsDialog( ... ) = 0;
void Run( ... ) = 0;
...
};

?


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

> Это тот случай когда "надо".

И в итоге проект намертво завязнет в GOjbect. Прелестно!

> Нет, вопрос не в удобстве. Удобство субъективно.

Да вот что-то с удобного-разудобного "C с ООП" разработчики с радостью перескакивают на python или mono. Может у них нет необходиомсти в такой привычке?

> А вот тот факт, что плюсы являются ОО только на момент компиляции - это объективно.

Не перескакивайте с темы на тему.

>>Ну вообще, по стандарту он должен отвалиться в "неоднозначностью", т.к есть неявная конверсия int->double.

>У тебя каша в голове. man method overloading

man Sutter 2005. И man Stroustrup "C++ - Эволюция и дизайн" ("Как я рожал ёжиков").

> Дальше Вы получаете ссылку на EJB, ой, главный объект "приложения". И начинаете выяснять, что он умеет-может... Вам придется строить свой собственный ОО, создавая "рефлексию вручную".

Вроде никто и не говорит, что в плюсах рефлексия есть.

Да, для подгрузки классов из плагинов C++ не подходит. И? У него от этого сразу отсыхает ОО?

Дык вот этот Ваш интерфейс и есть - рефлексия вручную.

>> Это тот случай когда "надо".

>И в итоге проект намертво завязнет в GOjbect. Прелестно!

За завязывание на бусте и std:: надо вообще как минимум расстреливать.

Что такое "намертво завязнет"? Да, gobject будет в зависимостях. И что?

> Может у них нет необходиомсти в такой привычке?

Безусловно, гораздо проще использовать языки, где ОО не на уровне макросов-библиотек. Глупо с этим спорить. Но не языки, где ОО на уровне языка, но сделано криво-косо.

>> И в итоге проект намертво завязнет в GOjbect. Прелестно!

> За завязывание на бусте и std:: надо вообще как минимум расстреливать.

Пройди к психиатру на лечение плюсофобии.

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

> И? У него от этого сразу отсыхает ОО?

Картинка с плагинами демонстрирует костыльность ОО в плюсах.

Еще раз: ОО времени компиляции является костылем. Настоящий ОО в языке возможен только через полноценную поддержку в рантайме, включая как минимум рефлексию (а лучше - MOP, в смысле read/write).

пример Ъ кода в студию :)

> Что такое "намертво завязнет"? Да, gobject будет в зависимостях. И что?

А то, что придётся учить этот "ооп на ц" дабы не словить где-нибудь проблем из-за путаницы его классов с классами C++, на каждое преобразование строки навешать по врапперу...

Я уж не говорю про отвратную документацию этого libxml++, которую надо смотреть, параллельно влезая в доки по libxml.

> Картинка с плагинами демонстрирует костыльность ОО в плюсах.

Демонстрирует непредназначенность плюсов к runtime oop.

> Настоящий ОО в языке возможен только через полноценную поддержку в рантайме, включая как минимум рефлексию (а лучше - MOP, в смысле read/write).

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

Пожалуй, единственная претензия к "оно таки там есть". Слишком сильное утверждение.

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

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

http://groups.google.ru/group/comp.lang.c++.moderated/browse_thread/thread/57...

> Безусловно, гораздо проще использовать языки, где ОО не на уровне макросов-библиотек. Глупо с этим спорить.

То есть мы плавно подошли к тому, что gtk лучше использовать в биндингах от него к более другим языкам?

Какого именно? Пример рефлексии на жабке? Как посмотреть класс, его интерфейсы-методы и пр?

> Картинка с плагинами демонстрирует костыльность ОО в плюсах.

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

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

Какой оно даёт выигрыш, учитывая что

> использование памяти - все-таки vms очень беспечно с ней обращаются, в среднем.

?

пример того как это может пригодится на практике - ну узнаю я, что обьекта 5 методов и их имена, ну и накуя мне это надо? :)

> А то, что придётся учить этот "ооп на ц"

Это (если это правда) не проблемы gobject, это проблемы кривого байндинга.

> дабы не словить где-нибудь проблем из-за путаницы его классов с классами C++

use namespaces luke

> на каждое преобразование строки навешать по врапперу...

Не очень понял, нафига...

> Я уж не говорю про отвратную документацию этого libxml++

Правильно. Не говорите. Ибо тут это совершенно ни к селу, ни к городу.

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

В смысле удобства и скорости разработки - да.

Сравнивать использование проца и памяти в одном предложении - это, извините, Выше моих скромных интеллектуальных возможностей. Для меня это разные "оси".

C++ УГ по определению. страусиха совершила кардинальную ошибку, что сделала на базе С. Хотел как лучше, получилось как всегда, а большинство сишных проектов так и остались на С и их не меньше, чем плюсовских, и даже больше. Разработчики жабы правильно сделали, что создали другой язык, но в стиле С. И на него поперло больше народу, чем на плюсы. А истина такова, что 100%-ной переносимости не бывает.

> В смысле удобства и скорости разработки - да.

А почему б не предоставить _сишный_ интерфейс для рисования кнопочек языку более высокого уровня, чтобы он на основе его построил свои объекты?

> Сравнивать использование проца и памяти в одном предложении - это, извините, Выше моих скромных интеллектуальных возможностей. Для меня это разные "оси".

Ну да, Ваши программы идеально сферичны и не выделяют память, а только нагружают процессор :)

Интерфейс гтк - сишный. Но не процедурный, а ОО. Кстати, windows.h - тоже во многом ОО API. Только кривоватый. И тоже сишный.

>> А то, что придётся учить этот "ооп на ц"

> Это (если это правда) не проблемы gobject, это проблемы кривого байндинга.

Кстати, попытался найти то место в доке, где была отсылка на gobject и с удивлением обнаружмл, что теперь там все строки -- std::string.

>> дабы не словить где-нибудь проблем из-за путаницы его классов с классами C++

> use namespaces luke

Нет, я об использовании g-классов как классов c++.

>> на каждое преобразование строки навешать по врапперу...

> Не очень понял, нафига...

Потому что в остальном проекте строки, допустим, std::wstring. А libxml++ требует Glib::ustring.

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

Вазвращаясь к тому что каждый програмист обязан в своей жизни написать парсер конфигов, посмотрим на такой пример:

Можно на методы повесить аннотации типа @ConfigurableProperty(propertyName="listen_port", mandatory=true) тип параметра здесь можно взять из непосредственно из метода, чтобы сконвертировать String->int, а потом, после того как инстанциировал класс по имени, запросить все методы с аннотациями и вызвать их с параметрами из конфига. Так можно вносить в проект новые подсистемы без изменения корневого кода в проекте.

> Интерфейс гтк - сишный. Но не процедурный, а ОО.

Да, неточно выразился. Именно процедурный.

> Кстати, windows.h - тоже во многом ОО API. Только кривоватый. И тоже сишный.

В том-то и дело, что он только похож на ОО. Там макросов MS_OBJECT нет :)

Если я сравниваю потребление проца - я результаты сравнения использую сами по себе, не накладывая на результаты сравнения потребления памяти.