LINUX.ORG.RU

KDevelop 4.3

 , , , , , ,


0

2

Cостоялся выход версии 4.3 интегрированной среды разработки KDevelop. Как обычно, в релиз вошел ряд новых возможностей, а также исправления ошибок и улучшения производительности.

Неполный список изменений:

  • Поддержка С++11.
    Новая версия стандарта теперь частично поддерживается в KDevelop. Парсер теперь поддерживает такие новые возможности языка, как списки инициализации, лямбды, for-циклы по коллекции и шаблоны с переменным числом аргументов. Также поддерживаются =default и =delete методы, auto, ссылки на временные объекты (rvalue-references) и много другого. Тем не менее, С++11 включает много изменений и некоторые из них еще не поддерживаются. Разработчики ставят за цель улучшить поддержку в последующих релизах, чтобы сделать KDevelop отличной средой для разработки с использованием C++11.
  • Восстановление состояния редактора.
    С выходом версии 4.3 разработчики синхронизировались с Kate по функционалу работы с файлами: свернутые блоки кода, закладки и прочее теперь корректно восстанавливаются для последних 20 открытых файлов.
  • Улучшенная интеграция с системами контроля версий.
    Была добавлена область просмотра изменений в проекте, которая показывает файлы в проекте, измененные с момента последнего коммита. Также улучшен режим Review, который теперь автоматически обновляется по мере внесения изменений в код проекта.
  • Интеграция с проектами KDE
    Инфраструктура проектов KDE была адаптирована для поддержки projects.kde.org. Это позволило иметь полный список всех проектов KDE с возможностью их загрузки для быстрого начала старта работы над ними.
  • Улучшения интеграция konsole
    Встроенный konsole в KDevelop получил ряд улучшений — теперь при использовании bash стало возможно управлять сессией KDevelop, т.е. открывать и создавать файлы, выполнять поиск по файлам и пр. Просто введите help!, чтобы узнать, что теперь можно делать.
  • Форматирование кода
    Встроенное форматирование также было улучшено — теперь оно может переопределять настройки выравнивания редактора. Более того, «Custom Script Formatter», ранее поддерживавший Gnu Indent, был расширен с упрощением добавления собственных скриптов форматирования. Одним из примеров является kdev_format_source.sh, поставляемый с KDevelop, позволяющий задавать правила форматирования путем размещения файлов format_sources в дереве проекта. В связке с мощным форматировщиком uncrustify, скрипт позволяет легко работать в больших гетерогенных проектах.
  • Исправления ошибок
    Было исправлено более 170 ошибок по сравнению с KDevelop 4.2.3. Среди прочих, теперь нормально поддерживается SVN 1.7, улучшен разбор C++, улучшено взаимодействие с GDB. Также исправлено много падений и прочих проблем.
  • Оптимизации
    Кроме добавления новых возможностей и улучшения стабильности, этот релиз иммет ряд заслуживающих внимания оптимизаций — открытие больших проектов теперь должно происходить значительно быстрее. Также быстрее стал инструмент Quickopen, что делает более комфортной работу в больших проектах.

У проекта появился форум, на котором можно получить поддержку и ответы на вопросы. Также доступны список рассылки, а также канал IRC #kdevelop на freenode.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 1)

Товарищи, а его с cuda можно как-нибудь интегрировать? Компилятор nvcc для файлов *.cu прописать, или там библиотеки нужные подрубить? У кого есть рецептик?

Больше всего головной боли доставляет конструкция запуска ядра - kernel<<<grid,block>>>(params) - на неё все IDE практически ругаются.

(конечно, понятно, что это убогость CUDA скорее, могли бы его сделать чуть более совместимым с C/C++)

BattleCoder ★★★★★
()

Отлично, IDE с лучшей поддержкой C++11 нету.

NegatiV
()
Ответ на: комментарий от BattleCoder

BattleCoder



Товарищи, а его с cuda можно как-нибудь интегрировать? Компилятор nvcc для файлов *.cu прописать, или там библиотеки нужные подрубить? У кого есть рецептик?

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

Pavval ★★★★★
() автор топика
Ответ на: комментарий от Pavval

ЕМНИП ест как makefile-based проект.

это неудобно, тогда пробовать не буду. :-)

samy_volosaty ★★★★★
()
Ответ на: комментарий от BattleCoder

kernel<<<grid,block>>>(params) - на неё все IDE практически ругаются.

а IDE какое до этого дело? anjuta молчит.

У кого есть рецептик?

а вручную правила в Makefile.am дописывал.

samy_volosaty ★★★★★
()
Ответ на: комментарий от abalakin

А про указатели ... Вы не поверите во сколько раз можно ускорить код просто правильно организовав обращение к памяти... и указатели тут очень кстати оказываются.

Какие откровения!

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

Вы говорите такие глупости, как будто никогда сами программ не писали.

Ммм, в С/С++ есть такая замечательная штука — «библиотека» называется. Любую конструкцию реализуем на С/С++ (оба подходят) — один раз и хоть сколь угодно сложно внутри, делаем из нее библиотеку и пользуемся сколько дальше легко и просто (и гибко ;) ).

Держите это технологические преимущество в секрете! На этом можно сделать деньги!

Более того, этой же библиотекой можно потом на любом языке пользоваться ... Назовите хотя бы еще один язык с такими возможностями?

Ээээ... Любой из мейнстримных?

mv ★★★★★
()
Ответ на: комментарий от abalakin

Любую конструкцию реализуем на С/С++ (оба подходят) — один раз и хоть сколь угодно сложно внутри, делаем из нее библиотеку и пользуемся сколько дальше легко и просто (и гибко ;) ).

Что за язык такой C/C++? Нет такого, lol.

Более того, этой же библиотекой можно потом на любом языке пользоваться ... Назовите хотя бы еще один язык с такими возможностями?

Если на C писать, то да, все верно. А C++ только для C++.

gensym ★★
()
Ответ на: комментарий от mv

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

Вы говорите такие глупости, как будто никогда сами программ не писали.

Не Вы что, только вчера узнал что такой язык есть С/С++ ... вот книжку умную прочитал, восхитился возможностями

Более того, этой же библиотекой можно потом на любом языке пользоваться ... Назовите хотя бы еще один язык с такими возможностями?

Ээээ... Любой из мейнстримных?

Хотя бы один пример кода можно? Только чтобы потом результат запускался еще где-то (не на родном языке программирования) и не тащил за собой весь язык/интерпретатор в виде зависимости.

abalakin ★★
()
Ответ на: комментарий от gensym

Что за язык такой C/C++? Нет такого, lol.

С и С++ настолько близки, что почти один язык. С++ похож на «улучшенный» С :)

Если на C писать, то да, все верно. А C++ только для C++.

extern «C» { } вроде никто не отменял. А с классами так действительно не получится в общем случае. Приходится «извращаться» и писать всю реализацию класса в заголовочном файле через inline функции :(

abalakin ★★
()
Ответ на: комментарий от m0rph

не, с этим проблем у меня нет, а вот жирные шрифты выглядят ужасно... Похоже, что радуга для имён жёстко прописана в коде...

frozenix ★★★
()
Ответ на: комментарий от abalakin

Более того, этой же библиотекой можно потом на любом языке пользоваться ... Назовите хотя бы еще один язык с такими возможностями?

Ээээ... Любой из мейнстримных?

Хотя бы один пример кода можно? Только чтобы потом результат запускался еще где-то (не на родном языке программирования) и не тащил за собой весь язык/интерпретатор в виде зависимости.

Пардон, не вполне корректный вопрос. На компилируемых (типа паскаля или фортрана) так конечно же можно сделать, для них ограничения другие — скорость + не все конструкции легко/можно реализовать.

abalakin ★★
()
Ответ на: комментарий от abalakin

Хотя бы один пример кода можно? Только чтобы потом результат запускался еще где-то (не на родном языке программирования) и не тащил за собой весь язык/интерпретатор в виде зависимости.

lispworks. Демонстрационный пример могу написать, но только за деньги, т.к. чужое невежество бесплатно не исправляю.

mv ★★★★★
()
Ответ на: комментарий от abalakin

Пардон, не вполне корректный вопрос. На компилируемых (типа паскаля или фортрана) так конечно же можно сделать, для них ограничения другие — скорость + не все конструкции легко/можно реализовать.

Сделать можно на любом языке, рантайм которого поддерживает механизм shared object в данной операционной системе.

mv ★★★★★
()

как быстро лисперы набежали, видимо другого способа заявить о себе у них просто нет

vaino
()
Ответ на: комментарий от abalakin

С и С++ настолько близки, что почти один язык. С++ похож на «улучшенный» С :)

facepalm.cpp

madgnu ★★★★★
()
Ответ на: комментарий от samy_volosaty

Фактически я сейчас вручную Makefile редактирую. Сами исходники редактирую в kate. Этот вариант оказался для меня наболее удобным, хотя и понимаю, что ручное редактирование Makefile - не Ъ.

cmake не осилил что-то... может, потом. Сейчас времени на это нет.

В прошлом году не осилил даже makefile-в, вместо этого писал скрипт build.sh =) который запускал руками nvcc и компоновал все объектные файлы тоже руками... сейчас понимаю, что это как-то неправильно и негибко. Хотя работало.

BattleCoder ★★★★★
()
Ответ на: комментарий от frozenix

«Похоже, что радуга для имён жёстко прописана в коде...»

К сожалению, некоторые цвета действительно нельзя никак поменять.
Например, цвет имен функций.
При попытке создать другую цветовую схему с темным фоном ждет облом.
Пару лет назад еще запостил этот баг.
Сказали, что пофиксят... потом... может быть...
Честно говоря, меня эта фича волнует куда больше, чем поддержка нового стандарта C++ :)
Ну и на больших проектах, типа linux kernel, их парсер впадал в ступор или отжирал немерянно памяти.
Уж лучше бы оставили поддержку ctags как в kdevelop-3.

Dead ★★★★
()
Ответ на: комментарий от m0rph

Это всё-таки синтаксическая подсветка, пусть и с более глубоким анализом кода.

sv75 ★★★★★
()
Ответ на: комментарий от frozenix

Круто, кто-то еще, кроме kdevelop, поддерживает С++11?

QtCreator 2.5 (beta)

anonymous
()
Ответ на: комментарий от BattleCoder

ручное редактирование Makefile - не Ъ.

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

я использую autotools (autoconf, automake и т.д.) удобно, когда надо собрать на разных системах с немного разным функционалом, да и писать меньше, чем при редактировании мейкфайлов.

samy_volosaty ★★★★★
()
Ответ на: комментарий от sv75

Да как то не замечал поддержку ctags в четвертой ветке.
Я так понял они на свой чудопарсер ставку сделали.

Dead ★★★★
()

Оно уже юзабельно по сравнению с Qt Creator?
Заодно подскажите какую-нибудь хорошую IDE для плюсов. Чтобы по функциональности превышала nano и при этом не тормозила на нетбуке (Creator не тормозит, а вот всякие эклипсы как-то боязно пробовать).

h31 ★★★★
()
Ответ на: комментарий от Dead

Уж лучше бы оставили поддержку ctags как в kdevelop-3.

ctags — говно мамонта. У CDT в свое время были аналогичные проблемы после выкидывания сего артефакта. В итоге сейчас этот ctags забыли как страшный сон...

dion
()
Ответ на: комментарий от Vernat

чего так плюсистов то троллят?

Я конкретно в том комменте даже и не думал троллить.

mv ★★★★★
()
Ответ на: комментарий от seed_stil

MSVC, не все конечно поддерживает, ну так и kdevelop тоже

vaino
()
Ответ на: комментарий от anonymous

Значительно лучше поддерживает CMake проекты.

h4tr3d ★★★★★
()
Ответ на: комментарий от h31

Так и используй Creator. Было бы время, допилил бы там cmake плагин до уровня kdevelop, а так пока небольшим костыликом пользуюсь: https://gitorious.org/hatred-qt-creator-plugins/cmakeprojectmanager2 - в списке файлов проекта отображает всё дерево.

h4tr3d ★★★★★
()
Ответ на: комментарий от samy_volosaty

Прямо-таки требования о переносимости нет, но вообще она была бы желательна...

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

Вроде как cmake посовременнее autotools, читал в описании...

Просто java людей портит =), на жабе привык набирать в eclipse - половину проблем разработчика IDE тут решает. Некоторые ещё idea хвалят, что она типа круче в этом.

А вот eclipse CDT убог, PyDev, кстати, тоже. К другим ЯП, кроме java слабовата среда эта.

В vim тоже кодил =) но всё-таки это не моё. Слишком долго надо под себя это всё подстраивать и привыкать к этому... а текст редактировать (особенно когда есть доступ только по консоли/ssh) - vim - лучший вариант, никакой nano с ним не сравнится как по удобству, так и по функциональности.

P.S. emacs не пробовал.

BattleCoder ★★★★★
()
Ответ на: комментарий от mv

Над гибкостью плюсов до соплей смеяться можно.

Будь добр, укажи в твоем понимании «правильный» переносимый гибкий язык программирования!

alexl83u
()
Ответ на: комментарий от sv75

sv75

А что, там совсем убрали поддержку ctags?

Да.

Pavval ★★★★★
() автор топика
Ответ на: комментарий от mv

Переносимости кода нет даже в линуксе на одном дистрибутиве, т.к. версии одного компилятора разные, не говоря уж о платформообразующих библиотеках типа boost/qt. Нет, можно и без них писать, но зачем?

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

Если, при разработки программного обеспечения используются какие-либо библиотеки, например: Qt, boost, DXperience и т.д., то это уже говорит о том, что программа будет нуждаться в изменении, если измениться API этих библиотек.

И код хоть на C#, C, C++, Java, Delphi, Python - все равно будешь вносить изменения в код своей программы, если поменяется API библиотек (смотри выше ^^^).

alexl83u
()
Ответ на: комментарий от abalakin

С и С++ настолько близки, что почти один язык. С++ похож на «улучшенный» С :)

Сразу видно что С++ вы совсем не знаете =) Хотя да, синтаксически эти два языка немного похожи, но это в общем то и все.

NegatiV
()
Ответ на: комментарий от Dead

Кого бесят ненастраиваемые цвета - берем, блеать, и фиксим. Общество рукожопых не тут.

Pavval ★★★★★
() автор топика

Лучшая среда разработки под Linux становится еще лучше! :)

anonymous
()

>> В связке с мощным форматировщиком uncrustify, скрипт позволяет легко работать в больших гетерогенных проектах.

Это круто, а то раньше были проблемы при одновременной работе с разными проектами с разным форматированием...

Ура! Пользую сабж с версии 4.0

jerry_ru
()
Ответ на: комментарий от BattleCoder

Я anjuta использую. в ней autotools родной формат для проектов. правда, начиная с 2.0 в ней чувствуется какая-то незавершенность в каждой версии (по сравнению с 1.2.х), но жить можно.

для мелких вещей вполне mc хватает.

samy_volosaty ★★★★★
()
Ответ на: комментарий от abalakin

С и С++ настолько близки, что почти один язык.

Перестаньте уже глупости говорить.

x4DA ★★★★★
()
Ответ на: комментарий от BattleCoder

P.S. emacs не пробовал.

Самое время попробовать.

x4DA ★★★★★
()
Ответ на: комментарий от alexl83u

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

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

Почитай чейнджлоги gcc и подумай над тем, какие изменения могут сломать компиляцию.

P.S.: И вообще, куда ЛОР катится? Какая серая неведомая фигня не только два раза «ку» перед пятизвёздочным лиспером в теме про кресты не делает, но ещё и осмеливается дерзить не по канонам сайта!

mv ★★★★★
()
Ответ на: комментарий от Pavval

«Кого бесят ненастраиваемые цвета - берем, блеать, и фиксим. Общество рукожопых не тут.»

Можно попробовать пофиксить, но смущает некоторые моменты.
Я так понял, что есть некоторые цвета, которых нет в kate syntax highliter, но которые присутствуют в семантическом парсере кода. Эти цвета на данный момент либо генерируются либо захардкожены.
Из этого пока вижу два выхода:
1. Хачить парсер и вводить дополнительный диалог для настройки сабжевых цветов-шрифтов. В итоге будет выглядеть криво с юзерской точки зрения (два диалога для одного и того же функционала).
2. Хачить интерфейс к kate syntax highliter и добавлять туда новые цвета. Пока не совсем ясно как это сделать грамотно, чтобы потом это приняли в апстрим. Опять же, это потребует преодаления довольно высокого порога вхождения в реализацию этих интерфейсов.

Dead ★★★★
()
Ответ на: комментарий от h4tr3d

Так и используй Creator

Хочется чего-то большего. То же автодополнение там весьма не очень - предлагает всё подряд.
Да уж, CMake - это хорошо. Qmake не смог самостоятельно даже -lpthread в опции компилятора закинуть, пришлось вручную прописывать. CMake всё нормально подхватил.

h31 ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.