Здравствуйте, Cyberax, Вы писали:
C>Вот не надо. Usability в IDEA лучше, чем во всех остальных редакторах. Нафиг скроллеры со стрелочками вообще нужны, когда есть клавиатура?
Пытаюсь привыкнуть (PyCharm). Пока идет плохо: запускается долго, рендеринг шрифтов плохой, предложение по улучшению кода левые, REPL кривоват. Пока не сдаюсь.
До этого пробовал Аптану — комфорт лучше, но баги с git-итеграцией достали.
Ну что же, поставил я данный продукт, поигрался и готов поделиться впечатлениями. Во-первых сразу же скажу, что у меня были связаны с ним большие ожидания, т.к. в области полноценных C++ IDE выбор очень небольшой (собственно только 3 продукта и могут бороться за первое место) и у каждого варианта есть свои недостатки. А судя по уровню IDEA можно было надеяться на прорыв именно в самой проблемой области (анализатор кода и всё из него следующее). Так вот если кратко, то CLion в общем то оправдал надежды в этой области, но совершенно неожиданно показал дикие (настолько, что для нас этот продукт сейчас не пригоден к использованию) провалы в других областях, вроде как тривиальных.
А теперь по порядку. И начать я хочу с набора вроде как неважных мелочей, чтобы потом не отвлекаться на них при обсуждение принципиальных вещей. И так мелкие огрехи:
1. Сразу бросилось в глаза, что CLion не сообщает Windows о том, что он умеет сам нормально работать с нестандартным DPI. В итоге винда его масштабирует как картинку — получаем размытость, что очевидно неприемлемо для IDE. Очень странно видеть такое у вроде как солидного продукта, в то время как даже мелкие бесплатные утилитки работают корректно. Более того, если для 32-ух битного приложения Windows позволяет указать опцию "не масштабировать" в свойствах exe файла в Проводнике, то для 64-ёх битного кода эта возможность заблокирована (кстати, кто-нибудь знает обоснование этого странного поступка MS?) и надо идти добавлять специальную строку в специальное место реестра (про которое далеко не все знают). Ну т.е. я проблему преодолел своими силами, но в целом дико видеть такое в солидном продукте.
2. Захотелось открыть файл и сразу поразился диалогу для этого. Он не просто совсем не стандартный, но похоже что и ещё не умеет видеть сеть (или я не увидел где это включается?).
3. Про неудобные полосы прокрутки (в которые ещё фиг попадёшь мышкой) тут уже вроде писали. Впрочем иконки на тулбаре тоже крайне мелкие, но тут хотя бы только размера, а не форма.
4. А где локализация? ) Понятно что для программистов это вопрос совершенно не принципиальный. Но с учётом того, что даже мелкие бесплатные редакторы (типа Notepad++) имеют локазализацию (причём работающую по умолчанию), а во всех сравнимых конкурентах (Netbeans, Eclipse, Visual Studio) это уже давно работает, то несколько удивляет. Тем более, что уж для русской версии переводчиков точно не пришлось бы нанимать. )))
Кстати, замечу, что все вышеуказанные проблемы явно не связаны со спецификой C++. Интересно, а в других продуктах компании наблюдаются эти же проблемы или нет? Т.е. это предрелизные проблемы или вообще характерное для них? Я сам не в курсе, т.к. для нас у них раньше не было подходящих продуктов.
Переходим к основному. Первым делом нас конечно встречает редактор. Ну а точнее его настройки, т.к. я сразу полез в них. Ну что я могу сказать... Пожалуй это лучшее, что я видел среди всех IDE. Причём там нет какой-то одной уникальной киллер-фичи, а просто по совокупности разных продуманных мелочей редактор выглядит заметно удобнее всех своих конкурентов. Не буду расписывать тут подробности (авторы сами это легко сделают в рекламных проспектах, в отличие от подробного описания проблем), но можно сказать что тут ожидания полностью оправдались.
Однако подобный редактор — это ничто без анализатора кода (самой проблемой частью для C++). Здесь у нас к сожалению нет какого-то гениального прорыва (типа парсинга 100% компилируемого кода, что кстати вполне возможно с помощью того-же clang'а, но пока слишком медленно), но и провала нет. По охвату кода ситуация наверное как у лидеров, но при этом ещё и быстродействие чуть лучше. В целом получается как минимум на уровне, если не лучший результат. В принципе тоже безусловный позитив, хотя тут ожидания были несколько большими. Ну и надо отметить, что памяти оно отжирает больше того же Netbeans'a (Eclipse'а и VS+VA сейчас под рукой нет, чтобы сравнить), но думаю что для компьютера разработчика это правильный размен.
Ну а дальше я перешёл к изучению системы проектов и тут уже пошёл ужас — её просто не оказалось в IDE вообще. Ну точнее она вся перенесена в сторонний инструмент (чужую систему сборки cmake). Как я понимаю, авторы решили поддержать правильную точку зрения (которой некоторые IDE не соответствуют), что нормальный проект должен уметь собираться без всяких IDE (т.е. не должен быть завязан на настройки проекта из IDE). Я эту точку зрения полностью поддерживаю, но она совершенно не означает то, что сделали в CLion. Для этого достаточно всего лишь обеспечить удобную поддержку запуска произвольных сторонних систем сборки и всё! Отказываться от настроек проекта внутри IDE для этого не требуется. Т.е. авторы CLion вроде как пошли по правильному пути, но зашли по нему куда-то слишком далеко. В принципе такое решение может быть успешным, но только при одном принципиальном условие: если до первого релиза CLion будет поддерживать все известные системы сборки (например мы сейчас используем waf). Надеюсь автор данной архитектуры чётко понимает это? Ну и я что-то сомневаюсь что такое удастся, причём не столько из-за их количества (основных всего штук 15, хотя это тоже не мелкое число), сколько из-за сложности "парсинга" конфигов в некоторых случаях и большого различия в принципах. В целом мне данное решение видится провалом. Можно было сделать гораздо проще — сборку отдать профессиональным инструментам (реализовав удобный их запуск), а настройки проекта оставить только для нужных IDE опций (типа include каталогов для анализатора кода и т.п.). Кстати, я бы ещё может с трудом понял подобное, если бы в папке проекта кроме CMakeLists.txt не появлялось вообще ничего. Однако там появляется целая новая папка с кучей мусора (и почему-то именем ".idea", а не ".clion). Почему нельзя было разместить в ней нужные анализатору кода настройки, а не заниматься сексом с CMakeLists.txt для меня загадка.
Но ещё больше чудес открылось, когда я перешёл к сборке... И тут дело совсем не в её архитектуре. Ну да, cmake, не лучшая система сборки, но и далеко не худшая. Ну да, зашита намертво и поддерживается только она одна. Но это вроде как только пока и обещают изменить к релизу. Всё дело в том, как тут cmake используется! Оно зачем-то создаёт папки (да, не одну, а сразу 5: default, Release, Debug, RelWithDebInfo, MinSizeRel — зачем???) для построения cmake'ом не в каталоге проекта, а где-то в домашнем каталоге пользователя (типа ~\.clion10\system\cmake\generated\7c448f19\7c448f19\)! Мне вот интересно, а "гений", придумавший это решение, вообще понимает, что:
— это может приводить к потери быстродействия (диски с проектами и домашним каталогом могут быть не просто с разной скоростью, а вообще расположены в разных точках планеты)
— это может являться существенной дырой в безопасности (к примеру у нас важные проекты живут на криптодисках, а домашние каталоги пользователей со всяким повседневным хламом естественно без всякой защиты)
— банально неудобно доставить оттуда exe в итоге.
Причём главное что я не понимаю смысла этого гениального решения — какой вообще может быть аргумент в пользу подобного извращения? Да, а в какой-нибудь IDE такое вообще встречалось? Я вот что-то не припомню.
Кстати, я попробовал прикрутить нормальное построение (другим инструментом и в каталоге проекта) через External Tools. Кривизна конечно, но для предрелиза сойдёт. Вроде как всё нормально заработало. Но тут выяснилось, что без корректного CMakeLists.txt не работает анализатор кода (а без него уже смысла в IDE нет). Ну хорошо, поставил корректный файл, но убрал шаг build (из run/debug) и не нажимал его руками. И что вы думаете? Оно всё равно тут же сгенерировало все эти 5 папок с полным содержимым (да, кстати, забыл добавить, что там ещё зачем-то лежат сгенерированные проекты для codeblock — а они то зачем???) в домашнем каталоге... Даже не знаю что сказать на это всё.
Ну и напоследок об остальных компонентах, которые не произвели какого-то яркого (позитивного или негативного) впечатления.
Отладчик — ничего особо интересного, но нормально работает.
Всяческие интеграции — благодаря системе плагинов думаю что в будущем может быть идеально. Ну и даже уже сейчас, до релиза, имеется набор большинства важных вещей.
Если подвести итог с оценками, то по моим ощущениям это выглядело бы так:
— Интерфейс: 3-4.
— Редактор: 5.
— Анализатор кода: 4-5 (выше 4 только за счёт скорости).
— Проекты: 3.
— Сборка: 1.
— Отладчик: 4.
— Интеграции: 4-5 (4 сейчас, а 5 думаю быстро станет после релиза).
Для сравнения покажу такую же свою оценку Netbeans'a (на мой взгляд самого оптимального инструмента сейчас, хотя Eclipse не далеко от него):
— Интерфейс: 4-5.
— Редактор: 4.
— Анализатор кода: 4.
— Проекты: 4.
— Сборка: 4.
— Отладчик: 4.
— Интеграции: 5.
К сожалению для нас из всего этого следует, что переход на новую более удобную IDE похоже не состоится...
P.S. Тут вроде как на форуме присутствовали люди из JB. Надеюсь они передадут это отзыв по назначению. Я всё же его писал не ради самой критики, а с тайной надеждой на чудо в будущем... )))
я вот только одного не понял, чем QtCreator не устраивает в плане анализа кода? он с третьей версии использует clang для этого. этой фитчи я от него ждал несколько лет, и получил.
автодополнене так же основано на использовании clang, торможит очень слабо, в сравнении с этим же clion.
в общем-то, сейчас, QtCreator — мой герой
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>жуть как много букаф %)
Ну это как бы отзыв для разработчиков, в надежде что они прислушаются к доводам разума. )
X>я вот только одного не понял, чем QtCreator не устраивает в плане анализа кода? он с третьей версии использует clang для этого. этой фитчи я от него ждал несколько лет, и получил. X>автодополнене так же основано на использовании clang, торможит очень слабо, в сравнении с этим же clion.
Не пробовал ещё такой вариант. Действительно не тормозит? Я пробовал автодополнение clang'a в других местах (просто редакторах) и на серьёзных библиотеках (типа wxWidgets) тормозило просто дико.
X>в общем-то, сейчас, QtCreator — мой герой
Нууу как полноценная IDE то он конечно послабее главной троицы почти по всем пунктам. Это если не использовать Qt естественно. )
Здравствуйте, alex_public, Вы писали:
_>Не пробовал ещё такой вариант. Действительно не тормозит?
тормозит, но очень слабо. нужно пробовать, сравнивать.
у меня есть только опыт тестирования нетбинса в этой роли — вот он тормозит просто жутко %)
_>Нууу как полноценная IDE то он конечно послабее главной троицы почти по всем пунктам.
ну хз... мне так вообще его возможностей просто ооочень много =)
а что за "главная троица"? о чем речь?
_>Это если не использовать Qt естественно. )
не использую.
stl/boost/всякие_сторонние_либы...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>тормозит, но очень слабо. нужно пробовать, сравнивать. X>у меня есть только опыт тестирования нетбинса в этой роли — вот он тормозит просто жутко %)
Какой-то анализатор на базе clang'а тормозит меньше чем Netbeans? Чудеса какие) Точно надо будет проверить. Может тогда и с некоторыми неудобствами среды можно будет смириться.
X>ну хз... мне так вообще его возможностей просто ооочень много =) X>а что за "главная троица"? о чем речь?
VisualStudio (с VisualAssist естественно), Eclipse, Netbeans. Все остальные не сравнимы с ними по возможностям. Речь естественно про C++ и про Windows (для линуха помнится ещё своё родное решение есть, тоже мощное).
_>>Это если не использовать Qt естественно. ) X>не использую. X>stl/boost/всякие_сторонние_либы...
Здравствуйте, alex_public, Вы писали:
_>Какой-то анализатор на базе clang'а тормозит меньше чем Netbeans? Чудеса какие)
IDE, использующих clang, я пробовал всего одну — QtCreator. и да, он вразы быстрее чем Netbeans. проверь.
(а Netbeans тоже использует clang?)
_>VisualStudio (с VisualAssist естественно), Eclipse
эти не пробовал, так что хз...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, alex_public, Вы писали:
_>Ну что же, поставил я данный продукт, поигрался и готов поделиться впечатлениями. Во-первых сразу же скажу, что у меня были связаны с ним большие ожидания, т.к. в области полноценных C++ IDE выбор очень небольшой (собственно только 3 продукта и могут бороться за первое место) и у каждого варианта есть свои недостатки. А судя по уровню IDEA можно было надеяться на прорыв именно в самой проблемой области (анализатор кода и всё из него следующее). Так вот если кратко, то CLion в общем то оправдал надежды в этой области, но совершенно неожиданно показал дикие (настолько, что для нас этот продукт сейчас не пригоден к использованию) провалы в других областях, вроде как тривиальных.
_>Ну а дальше я перешёл к изучению системы проектов и тут уже пошёл ужас — её просто не оказалось в IDE вообще. Ну точнее она вся перенесена в сторонний инструмент (чужую систему сборки cmake). _>Почему нельзя было разместить в ней нужные анализатору кода настройки, а не заниматься сексом с CMakeLists.txt для меня загадка.
По-моему овет очевиден. Для тех кто использует cmake настройки никуда вводить не надо. И по результатам
их исследований процент таких разработчиков (использующих cmake) достаточно велик.
_>Но ещё больше чудес открылось, когда я перешёл к сборке... И тут дело совсем не в её архитектуре. Ну да, cmake, не лучшая система сборки, но и далеко не худшая. Ну да, зашита намертво и поддерживается только она одна. Но это вроде как только пока и обещают изменить к релизу. Всё дело в том, как тут cmake используется! Оно зачем-то создаёт папки (да, не одну, а сразу 5: default, Release, Debug, RelWithDebInfo, MinSizeRel — зачем???) для построения cmake'ом не в каталоге проекта, а где-то в домашнем каталоге пользователя (типа ~\.clion10\system\cmake\generated\7c448f19\7c448f19\)!
временное решение symlink ".clion10/system" туда, куда ты хочешь,
а так есть http://youtrack.jetbrains.com/issue/CPP-96 голосуйте
_>Кстати, я попробовал прикрутить нормальное построение (другим инструментом и в каталоге проекта) через External Tools. Кривизна конечно, но для предрелиза сойдёт. Вроде как всё нормально заработало. Но тут выяснилось, что без корректного CMakeLists.txt не работает анализатор кода (а без него уже смысла в IDE нет). Ну хорошо, поставил корректный файл, но убрал шаг build (из run/debug) и не нажимал его руками. И что вы думаете? Оно всё равно тут же сгенерировало все эти 5 папок с полным содержимым
_>(да, кстати, забыл добавить, что там ещё зачем-то лежат сгенерированные проекты для codeblock — а они то зачем???) в домашнем каталоге... Даже не знаю что сказать на это всё.
Это способ извлечь информацию о структуре проекта из cmake, проектный генератор codeblocks работает поверх генераторов make/ninja и дает xml с информацией о проекте.
Здравствуйте, Zhendos, Вы писали:
Z>По-моему овет очевиден. Для тех кто использует cmake настройки никуда вводить не надо.
Так я же как раз написал там, что единственный вариант, когда эта стратегия окажется выигрышной, это если они сделают к первому релизу поддержку всех известных (ну скажем 15 топовых) систем построения. Иначе это провал, т.к. вряд ли кто будет менять свою систему построения на чужую неудобную ради чуть более удобного редактора.
Z>И по результатам их исследований процент таких разработчиков (использующих cmake) достаточно велик.
В принципе он может быть даже больше всех остальных систем, по одиночке. Но фокус в том, что их не две на рынке, а намного больше. Так что даже если cmake вообще лидер, то при этом процент от общего числа использований у него всё равно намного меньше 50... Т.е. получаем, что большую часть потенциальных клиентов они посылают.
Z>временное решение symlink ".clion10/system" туда, куда ты хочешь,
Не, так не пойдёт, т.к. я хочу банально в каталог проекта. Т.е. тогда надо делать ссылку каждого уродца типа "~\.clion10\system\cmake\generated\7c448f19\7c448f19\" в "Projects/XXX/Build". Ну теоретически это конечно решение, но опять же через задницу.
Z>а так есть http://youtrack.jetbrains.com/issue/CPP-96 голосуйте
Угу, т.е. теперь ещё бороться с этим... А хотя одна разумная причина для появления на свет этого извращения вообще есть? )
_>>(да, кстати, забыл добавить, что там ещё зачем-то лежат сгенерированные проекты для codeblock — а они то зачем???) в домашнем каталоге... Даже не знаю что сказать на это всё. Z>Это способ извлечь информацию о структуре проекта из cmake, проектный генератор codeblocks работает поверх генераторов make/ninja и дает xml с информацией о проекте.
Т.е. они даже не осилили парсинг cmake файла? А что они тогда думают делать с другими системами построения, которые не являются генераторами чего-то, а строят сами? Например весьма популярные scons/waf? Не говоря уже про банальные make/nmake.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Zhendos, Вы писали:
Z>>По-моему овет очевиден. Для тех кто использует cmake настройки никуда вводить не надо.
_>Так я же как раз написал там, что единственный вариант, когда эта стратегия окажется выигрышной, это если они сделают к первому релизу поддержку всех известных (ну скажем 15 топовых) систем построения. Иначе это провал, т.к. вряд ли кто будет менять свою систему построения на чужую неудобную ради чуть более удобного редактора.
Z>>И по результатам их исследований процент таких разработчиков (использующих cmake) достаточно велик.
_>В принципе он может быть даже больше всех остальных систем, по одиночке. Но фокус в том, что их не две на рынке, а намного больше. Так что даже если cmake вообще лидер, то при этом процент от общего числа использований у него всё равно намного меньше 50... Т.е. получаем, что большую часть потенциальных клиентов они посылают.
Не совсем понял вашу идею, допустим у cmake есть 50%, а остальное делят autotools, qmake и остальные.
Предположим также, что поддержка работы с каждой из них требует примерно одинаковых трудозатрат.
Очевидно же, что наиболее разумное вложение труздозатрат будет в порядке популярности этих систем (c учетом ограниченности "manpower").
Реализовали cmake, получили 50% от рынка, отбили текущие и будующие затраты, после этого выпускаем
следущую версию, с поддержкой следующей по популярности системы сборки.
Зачем им сразу 100%?
Кстати, следует учитывать, что на VS (вернее ее пользователей) они (CLion) не замахиваются,
т.к. есть Resharper C++.
Z>>временное решение symlink ".clion10/system" туда, куда ты хочешь,
Z>>а так есть http://youtrack.jetbrains.com/issue/CPP-96 голосуйте
_>Угу, т.е. теперь ещё бороться с этим... А хотя одна разумная причина для появления на свет этого извращения вообще есть? )
Мне скажем удобно, т.к. исходники я держу на SSD, а директорию для сборки в RAM, поэтому сделал symlink на /tmp, который у меня
в RAM смонтирован и вот уже clion настроен в соотвествии с моими предпочтениями. Возможно это довольно популярный сценария использования.
_>Т.е. они даже не осилили парсинг cmake файла? А что они тогда думают делать с другими системами построения, которые не являются генераторами чего-то, а строят сами? Например весьма популярные scons/waf? Не говоря уже про банальные make/nmake.
А зачем им по сути реализовывать еще один раз cmake внутри clion, если уже есть сам cmake?
Если они могут вызвать его(cmake) со специальными аргументами и получить все что нужно?
PS
Я бы не назвал scons/waf особо популярным. А make или qmake они хотят реализовать
в следующей версии, но пока не решили кто из них популярнее.
Здравствуйте, alex_public, Вы писали:
_>Ну что же, поставил я данный продукт, поигрался и готов поделиться впечатлениями. Во-первых сразу же скажу, что у меня были связаны с ним большие ожидания, т.к. в области полноценных C++ IDE выбор очень небольшой (собственно только 3 продукта и могут бороться за первое место) и у каждого варианта есть свои недостатки. А судя по уровню IDEA можно было надеяться на прорыв именно в самой проблемой области (анализатор кода и всё из него следующее). Так вот если кратко, то CLion в общем то оправдал надежды в этой области, но совершенно неожиданно показал дикие (настолько, что для нас этот продукт сейчас не пригоден к использованию) провалы в других областях, вроде как тривиальных.
_>А теперь по порядку. И начать я хочу с набора вроде как неважных мелочей, чтобы потом не отвлекаться на них при обсуждение принципиальных вещей. И так мелкие огрехи:
_>1. Сразу бросилось в глаза, что CLion не сообщает Windows о том, что он умеет сам нормально работать с нестандартным DPI. В итоге винда его масштабирует как картинку — получаем размытость, что очевидно неприемлемо для IDE. Очень странно видеть такое у вроде как солидного продукта, в то время как даже мелкие бесплатные утилитки работают корректно. Более того, если для 32-ух битного приложения Windows позволяет указать опцию "не масштабировать" в свойствах exe файла в Проводнике, то для 64-ёх битного кода эта возможность заблокирована (кстати, кто-нибудь знает обоснование этого странного поступка MS?) и надо идти добавлять специальную строку в специальное место реестра (про которое далеко не все знают). Ну т.е. я проблему преодолел своими силами, но в целом дико видеть такое в солидном продукте
Другие продукты jetbrains страдают от не 100% DPI. К браузере FireFox та же лажа — жирный шрифт в мыло. _>2. Захотелось открыть файл и сразу поразился диалогу для этого. Он не просто совсем не стандартный, но похоже что и ещё не умеет видеть сеть (или я не увидел где это включается?).
Да это болезнь — тут даже — при копировании папки появляются с заметной задержкой. _>3. Про неудобные полосы прокрутки (в которые ещё фиг попадёшь мышкой) тут уже вроде писали. Впрочем иконки на тулбаре тоже крайне мелкие, но тут хотя бы только размера, а не форма.
Хз так скролл очень редко использую. _>4. А где локализация? ) Понятно что для программистов это вопрос совершенно не принципиальный. Но с учётом того, что даже мелкие бесплатные редакторы (типа Notepad++) имеют локазализацию (причём работающую по умолчанию), а во всех сравнимых конкурентах (Netbeans, Eclipse, Visual Studio) это уже давно работает, то несколько удивляет. Тем более, что уж для русской версии переводчиков точно не пришлось бы нанимать. )))
За идею локализации IDE бить палкой надо.
тебе интуитивно понятны следующие слова?
Datei
geöffnet
Schließen
sparen
Einstellungen
Optionen
Здравствуйте, Zhendos, Вы писали:
Z>Не совсем понял вашу идею, допустим у cmake есть 50%, а остальное делят autotools, qmake и остальные.
В том то и дело, что там совсем не 50%. Об этом и была речь. Т.е. в данной области можно быть лидером, не набирая даже и 30% популярности. Собственно поэтому IDE поддерживающая одну систему сборки и выглядит странно.
Z>Мне скажем удобно, т.к. исходники я держу на SSD, а директорию для сборки в RAM, поэтому сделал symlink на /tmp, который у меня Z>в RAM смонтирован и вот уже clion настроен в соотвествии с моими предпочтениями. Возможно это довольно популярный сценария использования.
Нуу в принципе тоже вариант. А не смущает, что нельзя будет в будущем просто взять из проекта результат построения (придётся строить заново и потом копировать из /tmp)?
Z>А зачем им по сути реализовывать еще один раз cmake внутри clion, если уже есть сам cmake? Z>Если они могут вызвать его(cmake) со специальными аргументами и получить все что нужно?
Для cmake действительно не надо, но для других то так не получится. А я думал что они там некий обобщённый подход разработали для работы с чужими системами сборки (раз уж от своих настроек проекта отказались).
Z>Я бы не назвал scons/waf особо популярным.
Ну да, с помощью них всего лишь строят такие незначительные проекты как Chrome, Samba, Blender, VMware, MongoDB, Node.js и т.д. )))
Z>А make или qmake они хотят реализовать в следующей версии, но пока не решили кто из них популярнее.
Очевидно, что make намного популярнее, т.к. qmake — это по сути игрушка только для пользователей одного специфического фреймворка. Однако не удивлюсь, если они выберут именно qmake, т.к. там вроде тоже какой-то генератор...
Здравствуйте, vpchelko, Вы писали:
V>Другие продукты jetbrains страдают от не 100% DPI. К браузере FireFox та же лажа — жирный шрифт в мыло.
В firefox'е что-то не помню такого. Но даже если бы и было, то т.к. он 32-ух битный, то это отключалось бы в пару кликов мышкой любым пользователем.
V>За идею локализации IDE бить палкой надо.
Однако все серьёзные продукты в этой области имеют данную возможность. Более того, она обычно ещё и включена по умолчанию — похоже большая часть пользователей совсем не против.
V>тебе интуитивно понятны следующие слова? V>Datei V>geöffnet V>Schließen V>sparen V>Einstellungen V>Optionen
Ну я то этот язык не знаю, так что с чего бы они мне были знакомы? ) Не помню чтобы я натыкался на что-то непонятное в русских локализациях IDE.
Здравствуйте, niXman, Вы писали:
X>IDE, использующих clang, я пробовал всего одну — QtCreator. и да, он вразы быстрее чем Netbeans. проверь.
Попробовал поставить и пока немогу оценить качество автодополнения, т.к. он парсит мне исходники как для старого стандарта (ну т.е. я это подозреваю, т.к. скажем cout он видит правильно) и соответственно например класса thread не видно и т.д. Как подобное включается? Причём компилируется этот код нормально (я поставил set(CMAKE_CXX_FLAGS "-std=gnu++1y ${CMAKE_CXX_FLAGS}")). Кстати странно, этот код для IDE непонятен, но как ошибку не отмечает (другие обычно отмечают). А вот код в новом стандарте вида [v=v]{...} вполне себе пометила как ошибку (обычные лямбды при этом не подчёркнуты). Ну это и CLion помечает. А вот Netbeans нормально.
Да, кстати, а кодировку консоли там можно на обычную виндовую сменить? А то выводится непонятно что в ней. )))
X>(а Netbeans тоже использует clang?)
Здравствуйте, alex_public, Вы писали:
_>В firefox'е что-то не помню такого. Но даже если бы и было, то т.к. он 32-ух битный, то это отключалось бы в пару кликов мышкой любым пользователем.
Я не пользуюсь нестандартным DPI — просто проверил, паршиво шрифты рисует. Да понятно что можно все настроить, но по умолчанию бяка.
_>Однако все серьезные продукты в этой области имеют данную возможность. Более того, она обычно ещё и включена по умолчанию — похоже большая часть пользователей совсем не против.
Пользователи — это кто какие? Может кому-то надо... Программисту с опытом это не нужно — будет мешать.
И потом сиди ищи — что-там они тебе налоказиловали, когда в настройках будешь лазить
_>Ну я то этот язык не знаю, так что с чего бы они мне были знакомы? ) Не помню чтобы я натыкался на что-то непонятное в русских локализациях IDE.
Ага VS с русской локализацией. это ужас. Эти дебилы локализовали сообщения компилятора и линкера.
Я вот совсем недавно узнал, что такое "компоновка".
Здравствуйте, alex_public, Вы писали:
X>>IDE, использующих clang, я пробовал всего одну — QtCreator. и да, он вразы быстрее чем Netbeans. проверь. _>Попробовал поставить и пока немогу оценить качество автодополнения, т.к. он парсит мне исходники как для старого стандарта (ну т.е. я это подозреваю, т.к. скажем cout он видит правильно) и соответственно например класса thread не видно и т.д.
В QTCreator есть два режима — с моделью кода на clang и их собственной.
По умолчанию стоит их собственная — она работает очень быстро, но неточно. Если поставить clang'овскую, то автодополнение и подсветка ошибок начинают работать идеально (я не нашёл ни единой ошибки в сложном коде). Но до ужаса медленно, но моём лэптопе показ вариантов дополнения занимает секунду-две в лучше случае (в худшем до 10 секунд).
это ужас. Эти дебилы локализовали сообщения компилятора и линкера. 
