Qt vs GTK+

примеры того, что надо переписывать, будут?

.Implicit Sharing
.unicode
.QString::arg
.QString::contains (тут и далее +regexp)
.QString::insert/remove/replace
.QString::toDouble(и остальные типы)
.QString::operator
.QString::number

qt это ведь не только gui (http://qt-project.org/doc/qt-5/topics-core.html) - переписать все это для себя можно, но зачем ???

Если мне нужно закрутить 1 шуруп, я беру отвертку; если много — шуруповерт;

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

для текстового редактора хватит и консольки. нафиг там opengl?

консольки мне не хватит, но вопрос для примера - поступило предложение выкинуть qt/gtk и писать все на opengl - хотелось бы посмотреть на приложения на opengl «типа редактора» по сложности, но не предлагать движки

а я и использую vala для генерации gobject boilerplates

Тогда я вообще не вижу смысла не писать весь код на Vala. Ведь, как и в случае с gobject boilerplates можно поставлять _дополнительно_ исходники со сгенерированным C-шным кодом и пускай пользователь компилирует хоть при отсутствующем valac!?

Не знаю, в общем, года 2-3 назад пытался писать исключительно в C-стиле, понял что решения некоторых задач без ООП не могу реализовать. В C тоже можно делать классы/интерфейсы даже проще, чем в GObject, правда с меньшими возможностями, но это тоже ссзб за исключением ядра.

и ты как бы намекаешь, что с чем-то из этого в сишечке есть проблемы, настолько критические что без QString просто не жить?

переписать все это для себя можно, но зачем ???

тебя никто не заставляет :)

Тогда я вообще не вижу смысла не писать весь код на Vala.

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

понял что решения некоторых задач без ООП не могу реализовать.

так делай с ООП, в чем проблема-то? (или ты именно без gobject не можешь?)

В Glib большая часть этого есть, если не ошибаюсь.

так делай с ООП, в чем проблема-то?

На C получается много кода, рефакторить долго. C++ не предлагать, озвучил выше, но и другие причины есть.

Ведь, как и в случае с gobject boilerplates можно поставлять _дополнительно_ исходники со сгенерированным C-шным кодом

я вообще-то это и делал. но это решает только проблему сборки в принципе (без зависимости от valac), но не решает проблему со сборкой GTK2+GTK3 из одной кодобазы.

На C получается много кода, рефакторить долго.

так это получается потому что gobject, а не потому что на C. или ты что-то недоговариваешь.

GTK2+GTK3

С в этом смысле более гибок.

Уважаемые, проблема уже решена. Не надо в комментариях холивар разводить:)

так это получается потому что gobject, а не потому что на C. или ты что-то недоговариваешь.

На Си в ООП стиле получается много кода независимо от того, как этот код реализуется - через GObject или без него. Или я не прав?

В Glib, кстати, тоже используются классы без GObject, но, используя их, много контроля ложится на плечи программиста, хотя по объёму, да, получается примерно сколько и на C++/Vala.

Или я не прав?

без конкретного примера невозможно определить. смотря что надо делать. в C-программах, типично, ООП применяется только там, где нужно. поэтому если и есть увеличение кода по сравнению с C++ — оно незначительное, если вообще есть. по сравнению с Vala, и другими языками с кучей сахара, — да, может быть существенно больше кода. даже без ООП.

Не надо в комментариях холивар разводить:)

с таким названием треда?

Я неточно выразил мысль. Объём в смысле нагрузки на программиста, а не в смысле числа строк или их длины.

Проверка на соответствие типов, на NULL, ручная работа с памятью и контроль за разделяемыми объектами.

Но и объём в смысле числа букв, когда нужно реализовать наследование, вирт. методы, деструкторы.

В средствах языка отсутствуют шаблоны, поэтому, взяв элемент GList программист должен точно знать, к чему приводить void*.

Проверка на соответствие типов, на NULL, ручная работа с памятью и контроль за разделяемыми объектами.

все это не имеет никакого отношения к ООП.

Но и объём в смысле числа букв, когда нужно реализовать наследование, вирт. методы, деструкторы.

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

В средствах языка отсутствуют шаблоны

и это несказанно радует.

поэтому, взяв элемент GList программист должен точно знать, к чему приводить void*.

а можно просто не брать GList, и пользоваться сразу правильными типами, без void *.

и ты как бы намекаешь, что с чем-то из этого в сишечке есть проблемы, настолько критические что без QString просто не жить?

надо быть внимательным при передаче char* в и из функции, ктото должен очистить память; чегото нет вообще (нужно дописать)

да, всё можно написать, но смысла я в этом не вижу, если это _уже_ реализовано в qstring - бери и пользуйся

для меня это настолько критично, что использовать char* для строк я категорически откажусь (и от чистого C тоже)

я возьму шуроповерт и для 1 шурупа

И потратишь больше времени.

надо быть внимательным при передаче char* в и из функции, ктото должен очистить память; чегото нет вообще (нужно дописать)

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

да, всё можно написать, но смысла я в этом не вижу, если это _уже_ реализовано в qstring - бери и пользуйся

так оно и в glib реализовано - бери и пользуйся. а не нравится - есть другие либы. причем, в отличие от C++, все эти либы еще и совместимы друг с другом, ибо char *. да еще и без оверхеда на копирование.

для меня это настолько критично, что использовать char* для строк я категорически откажусь (и от чистого C тоже)

тебе никто не предлагал сишечку и char*. лично я уважаю твой выбор C++, и всячески приветствую использование того инструмента, который ты лучше знаешь, и больше любишь. а вот ты чего-то навязываешь C++, несмотря на то, что тебе ясно сказали «C++ юзал, опыт есть, много, но больше нравится без ++». и аргументы эти уже сто раз были.

надо быть внимательным при передаче char* в и из функции, ктото должен очистить память; чегото нет вообще (нужно дописать)

При передаче в/из библиотеки или плагина строки QString ведь надо преобразовывать в char* и без C не обойтись. К слову, в Vala такой контроль выпоняется автоматически и к мысли, что идеальных языков не придумали.

согласен

да, нужно конвертить, для этого использую QString

Мне это убожество не нужно. Есть char* — и его за глаза хватает!

Разупорись. char * - это не строка. То, что этот тип используют как строку - историческое недоразумение. Строки без UTF-8 в 21 веке не нужны.

Хрюникод нужен только китайцам, ниппонцам и иже с ними!

Ты точно упоролся. Мне он тоже нужен. Зачем нужен зоопарк кодировок, если есть одна и универсальная? ☣

Ты русский? Тогда тебе хрюникод нафик не всрался! А если всрался, пшел вон, фашист сраный!

Мне просто нужно было определиться. И какашки,летающие в сторону GTK, мне помогли:)

Разупорись. char * - это не строка. То, что этот тип используют как строку - историческое недоразумение. Строки без UTF-8 в 21 веке не нужны.

ты как бы намекаешь, что char * не может указывать на UTF8 строку, да?

Я - украинец, а ты - неадекватное шовиныдло.

Указывать-то может, но без костылей с ней не поработаешь.

Сеньоры модераторы, где же вы? Тут нацпол назревает...

Юникодофобия - это хуже нацпола, это хуже всех смертных грехов. Хуже этого только упоротые юзерстайлы в фоксе, которые превращают этот самый фокс в links -g, а вышеупомянутый персонаж этим тоже страдает.

Указывать-то может, но без костылей с ней не поработаешь.

библиотек для работы с utf8 вагон.

И это костыли, когда в 21 веке есть уйма ЯП с нативной поддержкой строк в UTF-8. Да, в Qt эти костыли наиболее безболезненны (QString + trUtf8), но они есть.

И это костыли

не больше чем QString

QString хотя бы в остальные костыли гармонично вписывается.

Уйди. Теперь это не твой тред. А наш.

Нельзя же так с ущербными обращаться, ну?..

QString хотя бы в остальные костыли гармонично вписывается.

меня эти высокие костыльные гармонии слабо интересуют.

проблема уже решена

только тебе так кажется. всем остальным нет. что это значит?

ох уж эти гузские фашики

Ты смотри, осторожней: вчера С++ вместо С стал использовать, сегодня ты культи культивируешь, а завтра за мужика замуж выйдешь?

98% времени я ни на сях, ни на плюсях не пишу, лохматый ты наркоман. Но есть пара проектов на Qt, да и в тех весь интерфейс, не считая трей-менюхи - QWebView.

А на чем пишешь? Веб — это жабоскрипт на клиенте и С на сервере. Больше там ничего нафиг не надо!

Веб - это жабаскрипт на клиенте и жабаскрипт на сервере, кроме этого точно ничего не надо, но у нас ещё пых и питон.

жабаскрипт на сервере

У упоротых наркоманов.

пых и питон

блевотина

У упоротых наркоманов.

Вот кто бы говорил.

блевотина

По сравнению с JS - да. Но заказчики не менее упороты бывают.

В вебе вообще наркоманы сплошные. Как на поделия посмотришь, сразу видно, что явно у человека что-то с башней не так!

Посмотри на скрины собственного браузера, а потом отключи свои наркоманские юзерстили и посмотри ещё раз, а потом задумайся, у кого что-то с башней не так.