Comments 66
> и/или знаете методы получше
Просто используйте clang для сборки всего проекта. А то у вас clang использует libc++, а gcc libstdc++. В результате в одной программе будет два STL'я (но это не проблема, libc++ на это рассчитан). А проблема будет когда вы из C++ захотите в ObjectiveC++ передать что-либо из STL.
Просто используйте clang для сборки всего проекта. А то у вас clang использует libc++, а gcc libstdc++. В результате в одной программе будет два STL'я (но это не проблема, libc++ на это рассчитан). А проблема будет когда вы из C++ захотите в ObjectiveC++ передать что-либо из STL.
Да я бы рад использовать, но не выходит. В проекте (не мной) использованы некоторые фичи из C++11, которые шлангом не воспринимаются, увы. К примеру, некоторые лямбды.
А насчёт осторожности — так я же предупредил, что всё сложно.
А насчёт осторожности — так я же предупредил, что всё сложно.
Пример, пожалуйста. Если не завести баг (я могу это сделать для вас), то оно так и останется.
Если говорить о clang 3.1 из Xcode, то он загнулся на такой штуке:
Ругается, что не видит p1 и p2. А вот последний clang 3.1 (из оф сборки) я пока не успел на этом опробовать.
QObjectList list = getList();
std::sort (list.begin(), list.end(),
[] (QObject *p1, QObject *p2)
{
return qobject_cast<QWidget*>(p1)->windowTitle() <
qobject_cast<QWidget*>(p2)->windowTitle();
});
Ругается, что не видит p1 и p2. А вот последний clang 3.1 (из оф сборки) я пока не успел на этом опробовать.
Говоря про слабую поддержку C++11 шлангом вы про какую версию? Свежий 3.1 очень даже хорошо поддерживает. clang.llvm.org/cxx_status.html
Ответил выше, шланг кое-что не поддерживает.
И да, у меня 3.1.
Свежий 3.1 из репозитория или фруктовый 3.1 из XCode? Это разные вещи, как выяснилось. Люди говорят, что фруктовая версия — это что-то посередине между 3.0 и 3.1.
$ clang --version
Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0
Thread model: posix
Кроме того, официальный clang 3.1 вышел всего неделю назад, так что да, яблочный слегка устарел, видимо, из-за этого мои проблемы и возникли.
Советую попробовать новый, они очень активно работали на поддержкой новых плюсов. Может как раз ваши случаи заработают :)
Спасибо, попробую, может действительно полегчает =)
Нет, не вышло. clang 3.1, скачанный в виде бинарников с офсайта, не собирает вообще ничего, увы. Проверить легко:
Ругаться будет так:
// file main.cpp
#include <iostream>
int main()
{
std::cout << "Hello, clang!";
return 0;
}
Ругаться будет так:
$ clang-3.1 -c -Wall -pedantic -std=c++0x -stdlib=libc++ main.cpp
In file included from main.cpp:1:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
/usr/include/c++/v1/string:1952:10: error: overload resolution selected implicitly-deleted copy assignment operator
__r_ = _STD::move(__str.__r_);
^
/usr/include/c++/v1/string:1942:9: note: in instantiation of member function 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__move_assign' requested here
__move_assign(__str, true_type());
^
/usr/include/c++/v1/string:1961:5: note: in instantiation of member function 'std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__move_assign' requested here
__move_assign(__str, integral_constant<bool,
^
(............blablablabla............)
/usr/include/c++/v1/memory:1941:5: note: copy assignment operator is implicitly deleted because '__compressed_pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, std::__1::allocator<char> >'
has a user-declared move constructor
__compressed_pair(__compressed_pair&& __p)
^
1 error generated.
Как написал Howard Hinnant в аналогичной проблеме llvm.org/bugs/show_bug.cgi?id=12861 — у вас старая libc++.
О как, спасибо. =)
Собрал транковую libc++, не помогло =(
Clang точно её подхватывает? Попробуйте передать параметр -### чтобы увидеть командную строку со всеми -I опциями.
$ clang++-3.1 -c -std=c++0x -stdlib=libc++ -### main.cpp
clang version 3.1 (tags/RELEASE_31/final)
Target: x86_64-apple-darwin11.3.0
Thread model: posix
"/usr/local/clang-3.1/bin/clang" "-cc1" "-triple" "x86_64-apple-macosx10.7.0" "-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-main-file-name" "main.cpp" "-pic-level" "2" "-mdisable-fp-elim" "-masm-verbose" "-munwind-tables" "-target-cpu" "core2" "-target-linker-version" "123.2.1" "-coverage-file" "main.o" "-resource-dir" "/usr/local/clang-3.1/bin/../lib/clang/3.1" "-fmodule-cache-path" "/var/folders/b5/4r3g3pvx4nb0kh7fvrmjcdww0000gn/T/clang-module-cache" "-stdlib=libc++" "-std=c++0x" "-fdeprecated-macro" "-fdebug-compilation-dir" "/Users/Valentine/Projects/testcpp11" "-ferror-limit" "19" "-fmessage-length" "238" "-stack-protector" "1" "-mstackrealign" "-fblocks" "-fobjc-runtime-has-arc" "-fobjc-runtime-has-weak" "-fobjc-dispatch-method=mixed" "-fobjc-default-synthesize-properties" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "main.o" "-x" "c++" "main.cpp"
Что-то не вижу "-l", только "-stdlib=libc++"
Я думаю в этом и проблема.
Оказалось всё проще — я неправильно установил libc++, хедеры брались из старой версии. После правильного симлинка всё заработало =)
Хотя, всё ж не всё даже новый clang понимает, к сожалению. Теперь на
Хотя, всё ж не всё даже новый clang понимает, к сожалению. Теперь на
std::reverse падает:/usr/include/c++/v1/algorithm:2086:89: error: no type named 'iterator_category' in 'std::__1::iterator_traits<QList<QObject *>::iterator>'
_VSTD::__reverse(__first, __last, typename iterator_traits<_BidirectionalIterator>::iterator_category());
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
Это не проблема clang, это проблема Qt.
Qt в qiterator.h делает то, чего делать нельзя никогда (и вообще запрещено стандартом):
А в libc++ эти имена находятся в std::__1.
Qt в qiterator.h делает то, чего делать нельзя никогда (и вообще запрещено стандартом):
namespace std {
struct bidirectional_iterator_tag;
struct random_access_iterator_tag;
}А в libc++ эти имена находятся в std::__1.
Уф, спасибо за разъяснения. В общем, новым clang'ом с libc++ собрать проект не выйдет. Увы.
Вообще-то выйдет. Просто замените этот кусок кода в qiterator.h на #include , должно сработать.
Интересно, нужно ли Qt при этом пересобирать?
Хороший вопрос! Вообще думаю что не нужно.
Но если у QList или ещё чего-нибудь есть какие-то методы, расположенные внутри so библиотек, то они скомпилированы для libstdc++ и их вообще нельзя вызывать при компиляции программы с libc++, так как in-memory layout соответствующих классов в этих библиотеках разный.
Но если у QList или ещё чего-нибудь есть какие-то методы, расположенные внутри so библиотек, то они скомпилированы для libstdc++ и их вообще нельзя вызывать при компиляции программы с libc++, так как in-memory layout соответствующих классов в этих библиотеках разный.
Точнее, выйдет, но без "-std=c++11 -stdlib=libc++", видимо.
Вот завёл баг, плюсуйте его bugreports.qt-project.org/browse/QTBUG-25960
Это на маке? Это свежим клангом? У меня отлично работает без единого замечания этот пример. Шланг вообще лучше собрать ручками. Такое ощущение, что у вас кланг библиотеки как-то не так засасывает.
Я ничего не путаю? На маке использую LLVM для обхода безумного GPL 3?
Да, на маке gcc заменили llvm+clang из-за безумного GPLv3, более адекватной модульной архитектуры. Компания FSF против Apple тоже тут замешана.
waqur.livejournal.com/484044.html
Тут ещё обсуждение есть.
Тут ещё обсуждение есть.
Очень интересная заметка. Я думаю этот материал был бы отличной статьёй для Хабра ;-)
Ну так оформите ;)
Заметка хорошая, да, если немного добавить интересного из комментов к ней, то действительно что-то интересное получится.
Заметка хорошая, да, если немного добавить интересного из комментов к ней, то действительно что-то интересное получится.
Называется скрестить ужа с ежом, clang-3.1 поддерживает большинство фич С++11 и уже почти вровень с gcc-4.7 идёт!
UFO just landed and posted this here
Это логотип LLVM: llvm.org/Logo.html
Одна из проблем сборки GCC — сборка universal, когда нужна совместимость между разными версиями макоси. Плюс даже если все собрать, то с собой нужно таскать gcc'шный рантайм, потому как на целевых машинах его может просто не быть.
По этой причини мы собираем все clang'ом. (причем его тоже собираем сами, т.к. яблочный падает на нашем проекте при парсинге сложных шаблонных конструкций) Но здесь тоже есть подводные камни — линковка qmake при сборке Qt с использованием старой SDK (скажем 10.6) ломается поэтому мы применяем следующее шаманство — собираем qmake с новой SDK а сам фреймворк уже с требуемой.
По этой причини мы собираем все clang'ом. (причем его тоже собираем сами, т.к. яблочный падает на нашем проекте при парсинге сложных шаблонных конструкций) Но здесь тоже есть подводные камни — линковка qmake при сборке Qt с использованием старой SDK (скажем 10.6) ломается поэтому мы применяем следующее шаманство — собираем qmake с новой SDK а сам фреймворк уже с требуемой.
Вообще, за все время разработки под яблоко у меня сложилось стойкое ощущение того что Apple не очень-то стремиться облегчить жизнь разработчика, а скорее прилагает все силы чтобы эта жизнь не была сахаром.
Кстати, у меня ощущения немного другие. По факту:
Так что, на мой взгляд, Apple всё делает именно для разработчиков. А все «подводные камни» начинаются когда используешь не родные фреймворки и инструменты. Тут уж надо не к Apple претензии предъявлять, а к Nokia (в данном случае), у них с макосью нелады какие-то, Qt 4.8.2 вообще закрашилось сразу же, к примеру.
Достаточно сравнить Cocoa/Carbon с MFC/WTL/WinAPI или даже с .NET (для винды), либо с GTK/GTK+ (для линукса) — и сразу становится понятно, кто именно печётся о девелоперах.
- Бесплатный крутой Xcode + SDK (в отличие от винды)
- Весьма хорошая документация (в отличие от всего)
- Богатство API Cocoa и при этом полная адекватность его (в отличие от всего)
- Хороший основной язык, а связка Objective-C++ многим жизнь облегчала
- Высокий уровень совместимости и переносимости бинарников и исходников
- Unix, и это круто
- Доступность единого центра дистрибуции (это и плюс и минус, конечно)
Так что, на мой взгляд, Apple всё делает именно для разработчиков. А все «подводные камни» начинаются когда используешь не родные фреймворки и инструменты. Тут уж надо не к Apple претензии предъявлять, а к Nokia (в данном случае), у них с макосью нелады какие-то, Qt 4.8.2 вообще закрашилось сразу же, к примеру.
Достаточно сравнить Cocoa/Carbon с MFC/WTL/WinAPI или даже с .NET (для винды), либо с GTK/GTK+ (для линукса) — и сразу становится понятно, кто именно печётся о девелоперах.
Бесплатный крутой Xcode + SDK (в отличие от винды)
То что он падучий и глюкавый — это конечно мелочи. К тому же некоторые вещи сделаны очень нелогично, на мой взгляд. Think different… Да еще всякие прыжки с тем что: «вот у нас есть XCode 4.3, так вот он не будет работать на Snow. Но вы не расстраивайтесь, скоро мы выпустим 4.4 — на Льве он тоже работать не будет. Вам просто нужно покупать новую железку каждый год, потому что мы каждый год стараемся выпускать новую версию ОС»
А собственно с чего топик начался? Да с того что у них системный GCC 4.2 — который не позволяет не то чтобы писать новые фичи из c++11 так еще и 99-й не держит. Это тоже отличная «забота»…
Высокий уровень совместимости и переносимости бинарников и исходников
И если уж совсем докапываться то даже собранное на «самом лучшем» 4.2 с SDK 10.5 гарантированно упадет на 10.5, рантайм там от 4.0. Какая еще раз вы сказали «совместимость»?
А все «подводные камни» начинаются когда используешь не родные фреймворки и инструменты.
В этом минус по моему — «хотите писать для нас — то только так как мы вам говорим и там где мы скажем». А не так что взял и написал на чем душе угодно. Скорее уж они привязывают разработчика к своей платформе и делают все возможное чтобы код написанный для этой платформы не мог быть использован на другой.
А что до языка, то многие контрукции мне кажутся громоздкими и перегруженными.
Простите за некоторую эмоциональность, просто мне вся эта суета вокруг яблока, количество пользователей (от общекго числа) которого менее 10%, а с учетом того что они заставляют разработчиков сидеть только на своем железе, то и того меньше.
> падучий и глюкавый
Сравним с MSVS? Xcode у меня упал за всю работу раза два, в то время как студия падает весьма регулярно, да ещё иногда винду с собой прихватывает. Под linux вообще молчу — действительно хороших IDE там нет (если не считать Qt Creator), а что есть — ещё более падучее и глюкавое. Ну или написано на java.
> у нас есть XCode 4.3, так вот он не будет работать на Snow
А Вы пробовали запустить MSVS 2011 на win98? Конечно, пример не самый удачный, но показательный. Прогресс на месте не стоит. И у девелопера должна быть максимально актуальная ось, а об обратной совместимости он должен думать сам и заранее — какие версии поддерживать, какие API юзать.
> нужно покупать новую железку каждый год, потому что мы каждый год стараемся выпускать новую версию ОС
Новая ось будет работать на старой железке. Время перехода с PPC на Intel опустим — он завершён почти полностью, что хорошо. А то, что новая версия оси выходит регулярно — так это плюс, как мне кажется. Я не маковод со стажем, не фанат мака и так далее, но меня новые версии всё больше радуют.
> у них системный GCC 4.2
Дык зато Clang 3.1 у них имеется. На него и переходят потихоньку, и на то есть причины (это уже Столлмана касается), и шланг развивается достаточно быстро. Пока он до GCC не дотягивает (о том и топик), но, я так полагаю, в обозримом будущем вполне может его и обойти.
> собранное на «самом лучшем» 4.2 с SDK 10.5 гарантированно упадет на 10.5, рантайм там от 4.0
Ну так и .NET 4.5 не заработает в Win98, раз уж на то пошло. Обратная совместимость не может быть бесконечной.
> Скорее уж они привязывают разработчика к своей платформе
Это делают все, увы. Qt — единственный адекватный кроссплатформенный фреймворк, но и у него куча недостатков. И вообще — если разработчик хочет написать платформонезависимый код, он его напишет, и никто ему не сможет помешать.
> А что до языка, то многие контрукции мне кажутся громоздкими и перегруженными.
Ну, это на вкус и цвет… Мне ObjC показался куда более адекватным, чем, к примеру, C# и Vala. А его мощь и магия рантайма впечатляют.
> вся эта суета вокруг яблока
Ох, суета она вокруг всего. Вокруг осей, вокруг языков, вокруг фреймворков. Это же чудесное пространство для холиваров! )
> то и того меньше
Доля макоси растёт непрерывно, в России не так заметно, но всё же. Доля устройств с iOS растёт совсем уж огромными темпами, а это так же способствует продвижению яблок на рынке.
Ох, коммент уже дошёл до состояния мини-топика. =)
Сравним с MSVS? Xcode у меня упал за всю работу раза два, в то время как студия падает весьма регулярно, да ещё иногда винду с собой прихватывает. Под linux вообще молчу — действительно хороших IDE там нет (если не считать Qt Creator), а что есть — ещё более падучее и глюкавое. Ну или написано на java.
> у нас есть XCode 4.3, так вот он не будет работать на Snow
А Вы пробовали запустить MSVS 2011 на win98? Конечно, пример не самый удачный, но показательный. Прогресс на месте не стоит. И у девелопера должна быть максимально актуальная ось, а об обратной совместимости он должен думать сам и заранее — какие версии поддерживать, какие API юзать.
> нужно покупать новую железку каждый год, потому что мы каждый год стараемся выпускать новую версию ОС
Новая ось будет работать на старой железке. Время перехода с PPC на Intel опустим — он завершён почти полностью, что хорошо. А то, что новая версия оси выходит регулярно — так это плюс, как мне кажется. Я не маковод со стажем, не фанат мака и так далее, но меня новые версии всё больше радуют.
> у них системный GCC 4.2
Дык зато Clang 3.1 у них имеется. На него и переходят потихоньку, и на то есть причины (это уже Столлмана касается), и шланг развивается достаточно быстро. Пока он до GCC не дотягивает (о том и топик), но, я так полагаю, в обозримом будущем вполне может его и обойти.
> собранное на «самом лучшем» 4.2 с SDK 10.5 гарантированно упадет на 10.5, рантайм там от 4.0
Ну так и .NET 4.5 не заработает в Win98, раз уж на то пошло. Обратная совместимость не может быть бесконечной.
> Скорее уж они привязывают разработчика к своей платформе
Это делают все, увы. Qt — единственный адекватный кроссплатформенный фреймворк, но и у него куча недостатков. И вообще — если разработчик хочет написать платформонезависимый код, он его напишет, и никто ему не сможет помешать.
> А что до языка, то многие контрукции мне кажутся громоздкими и перегруженными.
Ну, это на вкус и цвет… Мне ObjC показался куда более адекватным, чем, к примеру, C# и Vala. А его мощь и магия рантайма впечатляют.
> вся эта суета вокруг яблока
Ох, суета она вокруг всего. Вокруг осей, вокруг языков, вокруг фреймворков. Это же чудесное пространство для холиваров! )
> то и того меньше
Доля макоси растёт непрерывно, в России не так заметно, но всё же. Доля устройств с iOS растёт совсем уж огромными темпами, а это так же способствует продвижению яблок на рынке.
Ох, коммент уже дошёл до состояния мини-топика. =)
>Под linux вообще молчу — действительно хороших IDE там нет (если не считать Qt Creator), а что есть — ещё более падучее и глюкавое. Ну или написано на java.
Разверните, пожалуйста, «ну или написано на java» — я не понимаю, в чём тут проблема.
В том, что если выкинуть ограничение «не должно быть написано на java», то уже нельзя будет сказать «хороших IDE там нет»? :D
Разверните, пожалуйста, «ну или написано на java» — я не понимаю, в чём тут проблема.
В том, что если выкинуть ограничение «не должно быть написано на java», то уже нельзя будет сказать «хороших IDE там нет»? :D
Просто все IDE, написанные на java, которые я видел, были страшно тормозными и глючно-падучими. Поэтому это и идёт отдельным пунктом.
Прекрасно пользуюсь как самим Eclipse (для разработки на Qt, кстати), так и Momentics (который основан на Eclipse). И если под Виндой они порой, действительно, подтормаживают периодически, то под Линуксом — одно удовольствие. А падений так вообще не припомню.
> Тут уж надо не к Apple претензии предъявлять, а к Nokia (в данном случае), у них с макосью нелады какие-то, Qt 4.8.2 вообще закрашилось сразу же, к примеру.
Ну так эти мелочи вполне себе отлаживаются и фиксятся, а фиксы можно в Qt project сливать. Просто макоюзеров у кутей меньше, чем линукс или виндовс. Хотя точно знаю, что сами разрабы креатора сидят на маках почти все.
Ну так эти мелочи вполне себе отлаживаются и фиксятся, а фиксы можно в Qt project сливать. Просто макоюзеров у кутей меньше, чем линукс или виндовс. Хотя точно знаю, что сами разрабы креатора сидят на маках почти все.
У меня не особо много времени для вылавливания чужих багов =)
А мои критичные багрепорты (со стабильным крашем на ровном месте, в частой ситуации) так и висят…
Увы и ах.
А мои критичные багрепорты (со стабильным крашем на ровном месте, в частой ситуации) так и висят…
Увы и ах.
Кстати, если они сидят на маках, то почему криейтор под мак тупил до недавних версий? Один глюк с mkspec чего стоил — криейтор не умел собирать с gcc, только шлангом.
>Достаточно сравнить Cocoa/Carbon с MFC/WTL/WinAPI или даже с .NET (для винды), либо с GTK/GTK+ (для линукса) — и сразу становится понятно, кто именно печётся о девелоперах.
Я вот только не понял, почему вы выкинули из сравнения собственно сам сабж — Qt?
При его добавлении в список пара ваших «в отличие от всего» становятся не соответствующими действительности.
Я вот только не понял, почему вы выкинули из сравнения собственно сам сабж — Qt?
При его добавлении в список пара ваших «в отличие от всего» становятся не соответствующими действительности.
Я перечислял именно родные средства, предоставляемые разработчиками оси. Qt же является полностью сторонней разработкой, поэтому его и нет ни в одном списке.
Ведь разговор шёл о заботе о разработчиках авторами оси, ведь так? А разработчики Qt заботятся обо всех осях, за что им и спасибо =)
Ведь разговор шёл о заботе о разработчиках авторами оси, ведь так? А разработчики Qt заботятся обо всех осях, за что им и спасибо =)
>Ведь разговор шёл о заботе о разработчиках авторами оси, ведь так?
Под Linux нет ни одного фреймворка, разработанного «авторами ОСи», каждый из фреймворков является сторонней разработкой, и Qt тут на равных правах с Gtk, WxWidgets и так далее.
Под Linux нет ни одного фреймворка, разработанного «авторами ОСи», каждый из фреймворков является сторонней разработкой, и Qt тут на равных правах с Gtk, WxWidgets и так далее.
С этим я и не спорю, Qt Creator из рассмотрения выбросил сознательно — он под все три рассматриваемые оси идёт.
Тогда я не понимаю смысла вашего сравнения, извините.
«Сравним только то, что от „авторов оси“, а если такового нет, то возьмём что-нибудь стороннее по своему усмотрению, причём не самое лучшее».
На мой взгляд было бы логичнее просто сравнить доступные средства разработки, но остаивать правильность именно моего взгляда я не собираюсь.
«Сравним только то, что от „авторов оси“, а если такового нет, то возьмём что-нибудь стороннее по своему усмотрению, причём не самое лучшее».
На мой взгляд было бы логичнее просто сравнить доступные средства разработки, но остаивать правильность именно моего взгляда я не собираюсь.
Доступные это одно, а «родные» — совсем другое. Изначально разговор шёл о заботе Apple о разработчиках. Соответственно, я и начал сравнивать их с другими разработчиками оси. Под винду и мак я перечислил родные фреймворки и ide, под линь (за отсутствием таковых) — основные доступные, рассчитанные на разработку GUI-программ именно под Linux. Вообще, сравнивать тут Linux с виндой и макосью дело не особо осмысленное. В лини даже гуи часто в виме пишут.
>Изначально разговор шёл о заботе Apple о разработчиках. Соответственно, я и начал сравнивать их с другими разработчиками оси.
А почему не с другими разработчиками фреймворков? При чём тут вообще ОСи? Какое-то сравнение ежа с ужом, право слово…
>… под линь — основные доступные, рассчитанные на разработку GUI-программ именно под Linux
Вы, возможно, удивитесь, но Gtk не является «средством, рассчитанным на разработку GUI-программ именно под Linux». Насквозь кроссплатформенные Gimp, Inkscape, Firefox, Google Chrome, Pidgin, Gajim, Wireshark смотрят на вас с недоумением.
Ещё раз говорю: хотите сравнивать удобство фреймворков — сравнивайте удобство фреймворков. Я не понимаю, откуда условие «именно от разработчиков ОСи». Ну да, Эппл разрабатывает как фреймворк, так и ОСь. Ну так они ещё и смартфоны делают. И что, будем теперь сравнивать удобство фреймворков, разработанных другими производителями смартфонов?
А почему не с другими разработчиками фреймворков? При чём тут вообще ОСи? Какое-то сравнение ежа с ужом, право слово…
>… под линь — основные доступные, рассчитанные на разработку GUI-программ именно под Linux
Вы, возможно, удивитесь, но Gtk не является «средством, рассчитанным на разработку GUI-программ именно под Linux». Насквозь кроссплатформенные Gimp, Inkscape, Firefox, Google Chrome, Pidgin, Gajim, Wireshark смотрят на вас с недоумением.
Ещё раз говорю: хотите сравнивать удобство фреймворков — сравнивайте удобство фреймворков. Я не понимаю, откуда условие «именно от разработчиков ОСи». Ну да, Эппл разрабатывает как фреймворк, так и ОСь. Ну так они ещё и смартфоны делают. И что, будем теперь сравнивать удобство фреймворков, разработанных другими производителями смартфонов?
Почитайте первый коммент, пожалуйста. PSyton начал разговор именно об apple, я сравнил с другими производителями.
Sign up to leave a comment.
Qt/Objective-C++11 или сборка Qt-проекта с помощью GCC-4.7 и Clang