История изменений
Исправление gag, (текущая версия) :
Так и в G-технологиях же уже давно свой GString, разве нет?
В принципе - да, но им не заставляют пользоваться, например:
const gchar *
gtk_entry_get_text (GtkEntry *entry);
Вот мне, кстати, кажется, что код с классами на C++ понять легче, чем код на C, где ООП эмулируется структурами и указателями на функции. Доля велосипедов в коде меньше.
Обычный код с классами, пожалуй, да. Но код с классами на каком-нибудь «профессиональном» C++ диалекте - уже будет сложнее в понимании (без постоянной помощи clang-on-the-fly?), чем эмуляция, в которой всё более менее явно.
Вот это, в принципе, аргумент. А насколько тормознее? На чистом Си очень давно не писал, только чужие проекты патчить приходилось, и как-то не заморачивался быстродействием.
Мне уже попадалась маленькая прога, которая компилировалась минутами с пару гигабайтами израсходованной памяти. Метапрограммирование, что ли применили?
Но помимо этого экстремального примера, можно взять что угодно. Вот собирал минималистичный почтовый (IMAP/POP/NEWS) клиент на Си sylpheed: пара минут. А вот минималистичный быстрый только-IMAP клиент на C++ trojita - 19 минут (всё в один поток).
А что касается патчить: в gdb без pretty принтеров с С++ просто нечего делать. И для qt их, похоже, в Дебиане и вовсе нет. Мне пришлось в QTCreator отлаживать троиту. А и, кстати, кроме времени компиляции есть ещё важный параметр: объём debug info. Так он в С++ просто зашкаливает: 1200 MB для маленького почтовика на С++ против 39 MB в Си (du в каталоге сборки out-of-tree).
И ещё насчёт тяжеловесности.
Тут вопрос, что надо в конкретном случае. Если всё из-коробки, то можно вообще взять Моно-Сишарп. От скорости компиляции я просто обалдел (недавно попробовал собрать keepass2): оно выдало предупреждение и вывалилось. Странно, почему от предупреждения. Поковырялся и понял, что вот за эти 2-3 секунды оно действительно скомпилировало всю прогу. Хоть и не в машинный код, но всё равно просто невероятно быстро.
Т.е. это классно когда нужно что-то простенькое, которое тем не менее использует и sql, и сеть, и... Но если что-то посложнее и вдруг что-то пойдёт не так, тогда я хотел бы чтобы было ясно где искать виновника. И отдельная gui-библиотека, crypto-, network-, sql-,.. лучше. К тому же может, у них и интерфейс более менее унифицированный, так что даже заменить будет не очень сложно, чтобы протестировать.
Как решение всё-в-одном, Qt, пожалуй, даже легковесный framework. Но как gui-тулкит - тяжеленный. А Gtk и в принципе и даже потому что в нём не сидят исходники самих glib, gobject-introspection, gdkpixbuf, atk, cairo,.. - легковесный. Но, хотелось бы ещё полегче, для чего, правда, нужно совершенствование стандарта Си и gcc, и доп. работа по избавлению от велосипедов и замене их на новые стандартные реализации.
Исходная версия gag, :
Так и в G-технологиях же уже давно свой GString, разве нет?
В принципе - да, но им не заставляют пользоваться, например:
const gchar *
gtk_entry_get_text (GtkEntry *entry);
Вот мне, кстати, кажется, что код с классами на C++ понять легче, чем код на C, где ООП эмулируется структурами и указателями на функции. Доля велосипедов в коде меньше.
Обычный код с классами, пожалуй, да. Но код с классами на каком-нибудь «профессиональном» C++ диалекте - уже будет сложнее в понимании (без постоянной помощи clang-on-the-fly?), чем эмуляция, в которой всё более менее явно.
Вот это, в принципе, аргумент. А насколько тормознее? На чистом Си очень давно не писал, только чужие проекты патчить приходилось, и как-то не заморачивался быстродействием.
Мне уже попадалась маленькая прога, которая компилировалась минутами с пару гигабайтами израсходованной памяти. Метапрограммирование, что ли применили?
Но помимо этого экстремального примера, можно взять что угодно. Вот собирал минималистичный почтовый (IMAP/POP/NEWS) клиент на Си sylpheed: пара минут. А вот минималистичный быстрый только-IMAP клиент на C++ trojita - 19 минут (всё в один поток).
А что касается патчить: в gdb без pretty принтеров с С++ просто нечего делать. И для qt их, похоже, в Дебиане и вовсе нет. Мне пришлось в QTCreator отлаживать троиту. А и, кстати, кроме времени компиляции есть ещё важный параметр: объём debug info. Так он в С++ просто зашкаливает: 1200 MB для маленького почтовика на С++ против 39 MB в Си (du в каталоге сборки out-of-tree).
И ещё насчёт тяжеловесности.
Тут вопрос, что надо в конкретном случае. Если всё из-коробки, то можно вообще взять Моно-Сишарп. От скорости компиляции я просто обалдел (недавно попробовал собрать keepass2): оно выдало предупреждение и вывалилось. Странно, почему от предупреждения. Поковырялся и понял, что вот за эти 2-3 секунды оно действительно скомпилировало всю прогу. Хоть и не в машинный код, но всё равно просто невероятно быстро.
Т.е. это классно когда нужно что-то простенькое, которое тем не менее использует и sql, и сеть, и... Но если что-то посложнее и вдруг что-то пойдёт не так, тогда я хотел бы чтобы было ясно где искать виновника. И отдельная gui-библиотека, crypto-, network-, sql-,.. лучше. К тому же может, у них и интерфейс более менее унифицированный, так что даже заменить будет не очень сложно, чтобы протестировать.
Как решение всё-в-одном, Qt, пожалуй, даже легковесный framework. Но как gui-тулкит - тяжеленный. А Gtk и в принципе и даже потому что в нём не сидят исходники самих glib, gobject-introspection, gdkpixbuf, atk, cairo,.. - легковесный. Но, хотелось бы ещё полегче, для чего, правда, нужно совершенствование стандарта Си и gcc, и доп. работа по избавлению от велосипедов и замене их на новые стандартные реализациию