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

Но сути это не меняет 8)

> Вот как у тебя всё весело. А тестировать кто будет? Или у тебя это калькулятор на 20.000 строк, 90% из которых - комментарии со смайликами?

Не угадал, программа средней сложности для работы с железом.

> 90% из которых - комментарии со смайликами?

Товарищ не любит комментарии в коде? Вижу "профессионала" ::))

>Не так уж давно все С++ "компилеры" были препроцессорами к С.

хочу такой компилер... Это ж оно наверно в разы быстрей компилить будет %)

>Не так уж давно все С++ "компилеры" были препроцессорами к С.

Я правильный делаю вывод: гтк'шники решили повторить то, что делалось 20 лет назад - прикрутить к С препроцессор?

Ну покажи пример тонкого троллинга, я исправлюсь.

>хочу такой компилер... Это ж оно наверно в разы быстрей компилить будет %)

генту?

> Но сути это не меняет 8)

Нет, конечно. Си разрабатывался как портабельный ассемблер, и в него многие языки компилировались - Модула3, Эйфель, Scheme... Так что аргумент про "препроцессор в Си" к делу не относится совсем.

> Mono, единственного вменяемого фреймворка под все платформы

<troll_mode>4.2 Единственный вменяемый фреймворк под все платформы - llvm+Tango...</troll_mode> Когда допилят... Но это тоже offtopic.

> Не угадал, программа средней сложности для работы с железом.

Железо vs. кривожопый порт. Попкорна мне.

> Товарищ не любит комментарии в коде? Вижу "профессионала" ::))

Обожаю. Но только если со смайликами.

>>хочу такой компилер... Это ж оно наверно в разы быстрей компилить будет %)

>генту?

ты знал...

>Ну покажи пример тонкого троллинга, я исправлюсь.

Перечитай эту тему сначала. Тему о экстрасенсах можно, о коровах летающих (это из последних). Творчество Батарейкина не помешает.

Потом приходи, будем проверять.

> гтк'шники решили повторить то, что делалось 20 лет назад - прикрутить к С препроцессор?

Не, это Vala'исты. Gtk'шники настолько суровы, что решили обойтись стандартным Си-препроцессором.

> Я правильный делаю вывод: гтк'шники решили повторить то, что делалось 20 лет назад - прикрутить к С препроцессор?

Страшно сказать, но цппшники до сих пор не рискуют множественную диспетчеризацию к своему чаду прикрутить. Хотя очень хочется.

>К тому же Qt3 был монолитным, не забывай.

поясни

Как по мне - то лучше иметь набор жестко специализированных макросов (читай препроц) чем весьма расплывчатый и труднопредсказуемый "универсальный" механизмЪ 8)

> Я правильный делаю вывод: гтк'шники решили повторить то, что делалось 20 лет назад - прикрутить к С препроцессор?

Я правильно понимаю: цпп-шники решили забить на опыт последних 20 лет и сделать очередной велосипед с треугольными колёсами?

> Независимого от языка.

Как минимум: в настоящем ООП языке объектом является ВСЕ. Включая функции и классы. Еще - в настоящем ООП язык должен быть способ узнать у объекта все его свойства-методы-...

Где это все в плюсах?

> Почему не использовать язык, где уже она есть?

Можно. Но только если он не крив как плюсы. Я люблю ООП, на уровне языка. Но к плюсам это не относится.

> + того, чего в С++ нет на уровне языка

Вы зачем слова из моей головы достаете?!

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

Вот что удивительно: все защитники "ООП на C" противопоставляют его C++, в то время как существует ещё довольно много других реализаций ООП.

>Как минимум: в настоящем ООП языке объектом является ВСЕ.

Жаба и сишарп ... А царь ненастоящий!!!!

> Как минимум: в настоящем ООП языке объектом является ВСЕ

где это написано?

>> + того, чего в С++ нет на уровне языка

>Вы зачем слова из моей головы достаете?!

закончу школу, зарегистрируюсь и своих слов понапридумываю))

Да, скажите на 7 страницах бреда ктонить упомянул objective-c на котором написана много в макоси? Нет. А почему? Потому что gtk с их Гов.обжектом садится в лужу и нервно курит .

> В какой-то степени это приемущество Gtk. Он делает то, что должен, и не больше. Нужны БД и прочее - обратитесь к соответствующим либам.

А потом трахайся с тем, что либа для работы с бд вернула тебе текст как wchar_t*, а не Glib::ustring. Ну ладно, настоящий индеец и это заборет кучей макросов и биндингов.

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

>Вот что удивительно: все защитники "ООП на C" противопоставляют его C++, в то время как существует ещё довольно много других реализаций ООП.

>Вот что удивительно: все защитники "ООП на C++" противопоставляют его C, в то время как существует ещё довольно много других реализаций ООП.

#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>

int main(int argc, char **argv) {
  void *handle;
  double (*cosine)(double);
  char *error;

  handle = dlopen ("/lib/libm.so.6", RTLD_LAZY);
  if (!handle) {
    fputs (dlerror(), stderr);
    exit(1);
  }

  cosine = dlsym(handle, "cos");
  if ((error = dlerror()) != NULL)  {
  fputs(error, stderr);
  exit(1)
  }

  printf ("%f\n", (*cosine)(2.0));
  dlclose(handle);
}

Это импорт произвольной, заметьте, именно _произвольной_ функции Си
с _произовольным_ именем _откуда угодно_. С++ нам такой легкости и красоты не предоставляет.

Советуется сделать следующий костыль, лишающий нас гибкости и удобства:

/*
 * cfuncs.cc
 */
#include <stdio.h>
#include <stdlib.h>
#include "myclass.h"

// These type of externs mean to export the function
extern "C" IUnknown* create() {
  return new MyClass;
}

extern "C" void destroy(IUnknown *p) {
  delete (MyClass*)p;
}

Притом это при использовании С++ в качестве целевого языка.

> А потом трахайся с тем, что либа для работы с бд вернула тебе текст как wchar_t*, а не Glib::ustring. Ну ладно, настоящий индеец и это заборет кучей макросов и биндингов.

+1 Вы не сравнивайте RAD Qt и SAD GTK+какая-то_либа

> Вот что удивительно: все защитники "ООП на C" противопоставляют его C++, в то время как существует ещё довольно много других реализаций ООП.

4.2 Я защитник ООП на С. Я очень уважаю ООП на других языках (хотя чистый ОО встречается редко). Но я ООП на плюсах - это костыль. Если С - это ассемблер pdp11, возомнивший себя языком высогого уровня, то С++, это ассемблер pdp11, возомнивший себя ОО языком. Прыжок через два уровня (очень условной) иерархии языков породил уродца.

Ты дохера программ написал на objective-c или С++? Чё ты всё время выпендриваешься неагрументированно?

> Я бы задал вопрос о том что вообще в std:: есть полезного.

Не свети на весь ЛОР своей ограниченностью и осиль хотя бы std::list и std::map :) А там авось и до <algorythm> дело дойдёт

>Ну ладно, настоящий индеец и это заборет кучей макросов и биндингов.

Посмеялся)

> Советуется сделать следующий костыль, лишающий нас гибкости и удобства:

Не слушай этого человека, он над тобой издевается, а ты ведешься.

Мля, да посмотри ты на _реальный_ биндинг, не на игрушки из своей головы. PyGtk вполне подойдет.

Относится - по крайней мере в разрезе того вопроса на который я отвечал 8). Кстати, какую реализацию модулы3 Вы имеете ввиду ? Я что-то упустил, очевидно, - такая мне не попадалась. Подробнее если можно...

>Что только не придумают люди, чтобы на C++ не переходить: Макро GSEAL(), указатели "priv", закрытые члены класса...

зато оно под mcs51 собирается и тормозит и тормозит

>Страшно сказать, но цппшники до сих пор не рискуют множественную диспетчеризацию к своему чаду прикрутить. Хотя очень хочется.

А вот сишники взяли да и прикрутили? Или к чему вы клоните?

З.Ы. О замыканиях не забудьте

>то импорт произвольной, заметьте, именно _произвольной_ функции Си

Буэ, белки ржут над хомяком запхавшим кактус за щеку. В яве это делается проще и безопаснее. Хуже того, автоматически.

> Кстати, какую реализацию модулы3 Вы имеете ввиду ?

IIRC, самая первая реализация Модулы3, в SRC, была сделана как транслятор в Си.

> 4.2 Я защитник ООП на С. Я очень уважаю ООП на других языках (хотя чистый ОО встречается редко). Но я ООП на плюсах - это костыль.

Ну и ладно. Но зачем огрызаться на мой пост про мышей и ООП на C словами, что "у вас в плюсах всё ещё хуже"? С логикой какие-то проблемы...

> Вот что удивительно: все защитники "ООП на C" противопоставляют его C++, в то время как существует ещё довольно много других реализаций ООП.

Ключевое слово - защитники. Соответственно, они защищают от нападо C++ников. Потому у не упоминаются другие языки.

>Теперь gtk r.i.p. ибо гтк не модульный и пособствует пропритеарщине своей лицензией.

>> Я правильный делаю вывод: гтк'шники решили повторить то, что делалось 20 лет назад - прикрутить к С препроцессор?

>Я правильно понимаю: цпп-шники решили забить на опыт последних 20 лет и сделать очередной велосипед с треугольными колёсами?

цпп-шники как раз сидят с попкорном и смотрят на жалкие попытки сишников (точнее гтк-шников) прикрутить плюсовый велосипед к своему продукту

>Не свети на весь ЛОР своей ограниченностью и осиль хотя бы std::list и std::map

Мне хватает того что каждая *инстанциация* шаблона std::vector увеличивает бинарь на 4Кб.

> Тем, кто спрашивает, почему тяжело делать байндинги к Qt: дело в том, что к классам С++ почти нереально подобраться из других языков. Си ф-ии можно вызывать непосредственно, поэтому доступ к Gtk из (в том числе) скриптовых языком можно осуществить почти непосредственно, не напрягаясь и не теряя производительность. Для С++ прийдется писать/юзать вропперы. Это сложно, тормознуто, и к тому же приводит по сути к корявому разбиению цпп классов на процедуры (что не надежно и запутанно). Добавьте сюда еще препроцессор moc от Trolltech, который в виде дополнительной надстройки к С++ еще больше все усложнит.

похоже вы никогда не писали биндинги, ваш пост имеет мало общего с действительностью :)

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

>Вот что удивительно: все защитники "ООП на C" противопоставляют его C++, в то время как существует ещё довольно много других реализаций ООП.

>Вот что удивительно: все защитники "ООП на C++" противопоставляют его C, в то время как существует ещё довольно много других реализаций ООП.

Идиот? На сабж посмотри.

>4.2 Я защитник ООП на С. Я очень уважаю ООП на других языках (хотя чистый ОО встречается редко). Но я ООП на плюсах - это костыль. Если С - это ассемблер pdp11, возомнивший себя языком высогого уровня, то С++, это ассемблер pdp11, возомнивший себя ОО языком. Прыжок через два уровня (очень условной) иерархии языков породил уродца.

Нет я помню, что на ЛОРе, но мы кажется обсуждали прикручивание _тех_же_плюсовых_костылей_(с)svu к C? А не ущербность(с)svu плюсового ООП.

>Мне хватает того что каждая *инстанциация* шаблона std::vector увеличивает бинарь на 4Кб.

В это время лемминги пишут ос на яве, а наш хаккер выйдя из вселенной оптимизации поймет как он отстал.

> tk, tk пиарь. История успеха же есть - tkLOR.

че вы гоните, мне, например, tkLOR очень нравится, только им и пользуюсь дома

респект gaa

> Мне хватает того что каждая *инстанциация* шаблона std::vector увеличивает бинарь на 4Кб.

Да-да, а добавление новой переменной типа char увеличивает занятую память как минимум на 1 байт! АААААА!

"Плюсовые костыли к С" - это не мой (с), это буйная фантазия кдешников, разыгравшаяся при виде топика.

>>>IIRC, самая первая реализация Модулы3

Брррр... А где оно живёт ? И живёт ли вообще ?