IDE под Linux (Интегрированные среды разработчика)

[alastor]

Да уж.... научатся люди в дельфях/билдере на кнопочки тыкать (не более), а потом говорят, что по другому кодить неудобно. Чушь! Все эти редакторы формочек и есть САМЫЕ БОЛЬШИЕ костыли. На тех же Qt/GTK можно писать и вовсе без применения каких-либо дизайнеров GUI - и вполне даже просто, кроме того - весь код перед тобой, на ладони, а не непонятно где.
З.Ы. Самая умора - сколько действий выполнялось, для того чтоб посмотреть пару строчек кода - Открывались Дельфи, открывалась формочка, кликалось по этой формочке, и после этого только (!) долгожданный код наконец-то показывался. Ужос!

[Skull]

Да уж.... научатся люди в дельфях/билдере на кнопочки тыкать (не более), а потом говорят, что по другому кодить неудобно. Чушь! Все эти редакторы формочек и есть САМЫЕ БОЛЬШИЕ костыли. На тех же Qt/GTK можно писать и вовсе без применения каких-либо дизайнеров GUI - и вполне даже просто, кроме того - весь код перед тобой, на ладони, а не непонятно где.

Вручную кодить интерфейс - вот это точно геморрой. Тем более, что подключение форм что Qt designer, что Glade делается на раз. Я уж не говорю про Kommander, где рисуешь формы, дописываешь логику на shell и получаешь функциональные приложения.

[Dron2004]

Чем вам не нравится эклипса? К ней Qt можно прикрутить...

Eclipse, честно говоря, пока не пробовал...

Это жутчайший костыль. Почитайте про менеджеры компоновки в GKT+ и Qt и поймёте, несколько это удобнее делать в Linux.

Да, возможно, в GTK+ есть горизонтальные и вертикальные "делители" и Table. Удобно.

Да уж.... научатся люди в дельфях/билдере на кнопочки тыкать (не более), а потом говорят, что по другому кодить неудобно. Чушь! Все эти редакторы формочек и есть САМЫЕ БОЛЬШИЕ костыли.

Не согласен. Графический пользовательский интерфейс и формировать надо "графически", а не в текстовом редакторе.
"Костыли" - это рисовать на бумажке, а потом "переносить" координаты в текстовый редактор.

На тех же Qt/GTK можно писать и вовсе без применения каких-либо дизайнеров GUI - и вполне даже просто, кроме того - весь код перед тобой, на ладони, а не непонятно где.

Можно, вот только зачем? Это ведь просто неудобно (см. выше).

З.Ы. Самая умора - сколько действий выполнялось, для того чтоб посмотреть пару строчек кода - Открывались Дельфи, открывалась формочка, кликалось по этой формочке, и после этого только (!) долгожданный код наконец-то показывался. Ужос!

Ну, во-первых, эти действия, ИМХО, вполне логичны. Да и, кроме того, Дельфи'вская форма (как сама форма (.dfm), так и callback-код (.pas)) - обычный тексовый файл. Можно было открыть в Notepad'e и посмотреть.

[Warderer]

Dron2004
Дело всё в том, что без менеджера компоновки то, что вы нарисуете в делфи или MSVS будет достаточно жёстко привязано к тому разрешению, в котором вы создавали форму. А у меня, извините, на мониторе рабочее разрешение 1920х1440. Вы себе представляете, как на нём выглядят формы "графически" созданные в 1024х768? Нет? Отвратительно выглядят. А менеджер компоновки позволит более или менее приемлемо видеть всё в любом разрешении, без костылей в виде snap. В свою бытность программистом (1999-2000гг) к окончанию второго года осознал, что не ни разу за время разработки приложения с немалым количеством управляющих элементов ни разу не открыл "дизайнера". Всё создавал в рантайме. скорость разработки и качество интерфейса при этом существенно улучшились.

[alastor]

Не согласен. Графический пользовательский интерфейс и формировать надо "графически", а не в текстовом редакторе.
"Костыли" - это рисовать на бумажке, а потом "переносить" координаты в текстовый редактор.

А на бумажке никто и не рисует и координаты не переносит. Для этого существуют менеджеры компоновки - они все и делают. И ког получается последовательный и логичный.

Можно, вот только зачем? Это ведь просто неудобно (см. выше).

Вполне даже удобно

Ну, во-первых, эти действия, ИМХО, вполне логичны. Да и, кроме того, Дельфи'вская форма (как сама форма (.dfm), так и callback-код (.pas)) - обычный тексовый файл. Можно было открыть в Notepad'e и посмотреть.

Логичны то они мошт и логичны - только сколько лишних телодвижений. А то что некоторые "программисты" и понятия не имеют что код можно посмотреть и в блокноте (а не собственно в ИДЕ-шке) убеждался лично

[masterd]

Eclipse SDK 3.2 + плагин для PHP - использую для разработки на PHP
NetBeans 5.0 - для Java

[Arceny]

А никто не знает почему в codeblocks , собранном из svn, тормозит жутко окно редактирования кода, конкретно при выделении текста например или перемещения курсора вверх-вниз по клавиатуре.

Релиз кандидат 2 версию я поставить не смог (дистр. gentoo) . В windows с той же RC2 версией всё в порядке. Подобные тормоза жутко раздражают, хотя машинка вроде не слабая: Pentium D 805 , 1 Gb Ram.

[viewizard]

А никто не знает почему в codeblocks , собранном из svn, тормозит жутко окно редактирования кода, конкретно при выделении текста например или перемещения курсора вверх-вниз по клавиатуре.

Эти черти что-то напортачили в линукс версии... там косяки конкретные есть... и походу распинать их это все поправить не получится (уже 3 месяца пытаюсь добится от них исправление одного бага, причем 100% ихнего)... имхо, на линукс версию они частично забили... когда будет стабилизация нормальная - непонятно, вечно прикручивают какую-то ерунду типа biogames...

[Neonix]

Да уж все накинулись на дельфи и другие им подобные IDE и усиленно их матерят....
Не знаю как вы товарищи кодеры на С++ без IDE , а я на дельфях писал чертовски большую и сложную БД у меня на её разработку ушло меньше месяца и неделю на отлов части багов - кто теперь скажет что IDE это фигня и от неё нет толку . Разработка такойже БД на С++ без возможности создавать окна и формы графически (как это позволяет Delphi)
заняла бы по меньшей мере месяца четыре....
ЗЫ: юзал Kdevelop не особо удобно хочу попробовать IDE для Фри Паскаля...

[alastor]

Да уж все накинулись на дельфи и другие им подобные IDE и усиленно их матерят....
Не знаю как вы товарищи кодеры на С++ без IDE , а я на дельфях писал чертовски большую и сложную БД у меня на её разработку ушло меньше месяца и неделю на отлов части багов - кто теперь скажет что IDE это фигня и от неё нет толку . Разработка такойже БД на С++ без возможности создавать окна и формы графически (как это позволяет Delphi)
заняла бы по меньшей мере месяца четыре....
ЗЫ: юзал Kdevelop не особо удобно хочу попробовать IDE для Фри Паскаля...

...И логика программы у Вас на 99% распределена в обработчиках кнопочек, и если к примеру Вашему заказчику придет в голову круто поменять интерфейс (к примеру на web-based) то придется всю программу и переписывать.

[GRS]

Очень интересная тема, хочу спросить.

Вот я как и многие использую Visual C++, дельфи прочие бейсики на дух не переношу, для меня среда разработки это не среда создания форм, а многие примбасы, которые делают процесс программирование легче. Не побоюсь сказать Visual Studio это лучшое что создало MS.

Вопросы у меня такие.
Есть ли в средах разработки под linux/unix средства для отладки, где можно установить точку останову, посмотреть содержимое переменных?
Есть ли макросы наподобие ASSERT ?
Что насчет автоподстановки имен переменных/классов ?
Всплывающих подсказок с параметрами функции ?

Я пока вообще не один редактор не видел, вот интересуюсь, мне пока консоли хватает, но хочу расширить свои способности.

[Skull]

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

Отвечу по KDevelop: есть.

Есть ли макросы наподобие ASSERT ?

Чем не нравятся стандартный механизм исключений языка?

Что насчет автоподстановки имен переменных/классов ?

Есть, но работает не всегда хорошо.

Всплывающих подсказок с параметрами функции ?

Есть (для PHP в Quanta). В KDevelop можно обратиться сразу к документации.

[v04bvs]

Не побоюсь сказать Visual Studio это лучшое что создало MS.

Ну не знаю, мне ихние мышки нравятся больше..

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

Есть, emacs + gud

Есть ли макросы наподобие ASSERT ?

Есть стандартный макрос assert.

Что насчет автоподстановки имен переменных/классов ?
Всплывающих подсказок с параметрами функции ?

Я пока вообще не один редактор не видел, вот интересуюсь, мне пока консоли хватает, но хочу расширить свои способности.

Emacs + XRefactory - есть всё, включая рефакторинги.

[GRS]

Skull

Чем не нравятся стандартный механизм исключений языка?

А могут ли она в компилировался только в режиме отладки, да и при этом сразу же переходить на тот файл и на ту строку, где сработал ASSERT ?
Когда в проекте более 50 файлов, даже по алфавиту ориентироватся долго.

Есть (для PHP в Quanta). В KDevelop можно обратиться сразу к документации.

Мне нужно для С/С++ раз. А два чтобы он мог работать не только с какими-то стандартными классами, но с пользовательскими, которые создаю я.
Мне например удобно писать писать половину названия класса нажимать ctrl+space и когда среда сама за меня дополняет названия класса или переменной или функции (естественно если нет многозадачности, то есть что с таких букв начинаеся не 1 класс/переменная/фунция).


v04bvs

Есть стандартный макрос assert.

Это хорошо. Дополним вопрос, может ли среда разработки при срабатывании этого assert перейти на файл и строку где он сработал ?

Есть, emacs + gud
Emacs + XRefactory - есть всё, включая рефакторинги.

А если это все объеденить это работать будет стабильно ?

[v04bvs]

Есть стандартный макрос assert.

Это хорошо. Дополним вопрос, может ли среда разработки при срабатывании этого assert перейти на файл и строку где он сработал ?

По умолчанию - нет, насколько я знаю. Но тот же emacs не зря называется расширяемым редактором, добавить подобную функциональность совсем не сложно.

Есть, emacs + gud
Emacs + XRefactory - есть всё, включая рефакторинги.

А если это все объеденить это работать будет стабильно ?

Думаю да.
Сразу скажу, это далеко не Visual Studio для Linux-а. Если вам нужно, чтобы всё работало сразу и как VS, посмотрите в сторону KDevelop и Eclipse, если вам важнее функциональность, можете пробовать.
И ещё, XRefactory не свободный продукт и его лицензия на разработчика стоит 400$. Конечно можно его пользовать и на халяву, по словам некоторых людей он ломается без проблем, но это уже на ваше усмотрение. В любом случае его можно 30 дней пользовать без каких либо проблем.

[Neonix]

Вчера весь день изучал Kdevelop - Весьма добротная штука.... Моё мнение о нём изменилось

[jbond]

А теперрь дамы и господа сравним быстродействие программ создааных компиляторами gcc и Visual c++ 6. И потом делаем неутешительный вывод - gcc сравним только с Delphi.

Ps VC++ 2005 еще больше оптимизирует.

Зы Теперь мы понимаем, почем в Линукс ВСЕ тормозит. OpenOffice,...
А все из-за мягко говоря очень средненького компилятора С++

[Hvzh]

А теперрь дамы и господа сравним быстродействие программ создааных компиляторами gcc и Visual c++ 6. И потом делаем неутешительный вывод - gcc сравним только с Delphi.

Ps VC++ 2005 еще больше оптимизирует.

Зы Теперь мы понимаем, почем в Линукс ВСЕ тормозит. OpenOffice,...
А все из-за мягко говоря очень средненького компилятора С++

Результаты сравнительных тестов - в студию!

P.S. А причем тут OOo?

[real_maverick]

А теперрь дамы и господа сравним быстродействие программ создааных компиляторами gcc и Visual c++ 6. И потом делаем неутешительный вывод - gcc сравним только с Delphi.

Ps VC++ 2005 еще больше оптимизирует.

Зы Теперь мы понимаем, почем в Линукс ВСЕ тормозит. OpenOffice,...
А все из-за мягко говоря очень средненького компилятора С++

Меня умиляеют иногда высказывания тупых вантузятников ;-)
"Еще больше оптимизирует" - это просто зачотный зчот ;-))) Ты опции gcc видел хоть раз? Сильно подозреваю что нет. Или может быть ты можешь пересобрать проект под freebsd разрабатывая его на ляликсе к примеру ;-)
Такие высказываения появляются после того как форточник попробовав поставить ляликс смотрит и нифига не может сделать и настроить (тут вантуз конечно рулит - настраивать то ничего не дает ) И кричит как в попу укушенный 'ляликс ...овно'!
В общем сначала учи англ.яз чтобы хоть доки читать мог, потом долго читай и будет тебе щасье ;-))) (может быть - так как тут уж от общего умственного развития сильно зависит).

[v04bvs]

А теперрь дамы и господа сравним быстродействие программ создааных компиляторами gcc и Visual c++ 6. И потом делаем неутешительный вывод - gcc сравним только с Delphi.

Мда..
Сколько платформ поддерживает VC++ ?
Сколько операционных систем?
Про стандарты я даже вспоминать не буду.
Когда хотя бы четверть из тех, что поддерживает gcc будет, тогда и потестим, а пока рано его с gcc сравнивать.

Ps VC++ 2005 еще больше оптимизирует.

Зы Теперь мы понимаем, почем в Линукс ВСЕ тормозит.

Мы это кто? Мы, царь всея руси У меня ничего не тормозит кроме эклипса Что я делаю не так?

OpenOffice,...

Серьёзно? А в венде OpenOffice работает быстрее? Собранный VC++ ? Результаты тестирования предоставьте.

А все из-за мягко говоря очень средненького компилятора С++

Ну-ну.

[Hvzh]

Мы это кто? Мы, царь всея руси У меня ничего не тормозит кроме эклипса Что я делаю не так?

А у меня и эклипс не тормозит

[georgy_sh]

А теперрь дамы и господа сравним быстродействие программ создааных компиляторами gcc и Visual c++ 6. И потом делаем неутешительный вывод - gcc сравним только с Delphi.

Ps VC++ 2005 еще больше оптимизирует.

Зы Теперь мы понимаем, почем в Линукс ВСЕ тормозит. OpenOffice,...
А все из-за мягко говоря очень средненького компилятора С++

... просто нет слов ....

[Skull]

А все из-за мягко говоря очень средненького компилятора С++

... просто нет слов ....

Ага. Похоже, автор ничего кроме OpenOffice и не видел. KDE - точно не видел.

[WolfON]

Меня умиляеют иногда высказывания тупых вантузятников ;-)

ЛОЛ!!!!
Автор наверное сидит под линуксом только по тому, что это 1337 и там одни h4x0r5 ))))

Все читаем:
http://www.citforum.netis.ru/programming/C_comp/

В данном случае у gcc есть железная отмазка - он компилит под все платформы

[v04bvs]

Меня умиляеют иногда высказывания тупых вантузятников ;-)

ЛОЛ!!!!
Автор наверное сидит под линуксом только по тому, что это 1337 и там одни h4x0r5 ))))

Все читаем:
http://www.citforum.netis.ru/programming/C_comp/

В данном случае у gcc есть железная отмазка - он компилит под все платформы

Во-первых gcc там достаточно старый. Сейчас актуальна версия 4.1
Во-вторых результаты у gcc там вполне приличные, где-то впереди, где-то на несколько процентов отстаёт.
В-третьих правильней было бы проверять его в Линуксе (мы ведь обсуждаем его применительно к линуксу?), это вполне может оказать влияние на результаты.
В-четвёртых

Все тесты проводились на Pentium 3

весьма любопытно было бы посмотреть на результаты при использовании платформы AMD. Опять же возможны изменения результатов.

Что у gcc действительно удручает - низкая скорость компиляции C++ и отсутствие (как я понимаю даже намерений реализовывать) precompiled headers. В этом плане VC++ лучше. В остальном это весьма достойный продукт. Не говоря уже про то, что он свободен, и в этом смысле почти не имеет аналогов.

[georgy_sh]

В-третьих правильней было бы проверять его в Линуксе (мы ведь обсуждаем его применительно к линуксу?), это вполне может оказать влияние на результаты.

Конечно к Linux.
И, ИМХО, это окажет влияние на результаты...

[GRS]

Фу осилил.

fatboy

А действительно! Понапридумывали тут: Anjuta, QTDesigner, Glade, Lazarus, Code::Blocks, MinGW, eclipse, KDevelop! К чертовой матери все это! Настоящие крутые программеры пишут только под консоль, под консольЮ, знают наизусть все API всех сред, менеджеров, подсистем и библиотек, им совсем не лень и не жалко времени полазить по 5-6-10 тысачам строк кода чтобы перейти в файл и в ту строку на которую ругается компилятор...

Вообще работа программиста создавать софт для пользователей. Если ты что-то делаешь для себя, это уже хобби и денег никто за это не заплатит. Так что выражение:

Настоящие крутые программеры пишут только под консоль

Не то что мне не нравится, оно не соотсвествует действительности на сегодняшний день.
Вообще графический интерфейс - это фигня. Делается он просто, самое сложное оно в ядре программе. Другое дело что на этот интерфейс хочется затратить как можно меньше времени, поскольку это просто тупое программирование - реакция на события. Самое интересное и сложное всегда внутри.

jbond

А теперрь дамы и господа сравним быстродействие программ создааных компиляторами gcc и Visual c++ 6. И потом делаем неутешительный вывод - gcc сравним только с Delphi.

Ps VC++ 2005 еще больше оптимизирует.

Зы Теперь мы понимаем, почем в Линукс ВСЕ тормозит. OpenOffice,...
А все из-за мягко говоря очень средненького компилятора С++

Я с этим не согласен.
OpenOffice тормозит судя по тому, что программисты низкой квалификации. Ну и кроме того я например заметил, что программы разработанные на gtk работают быстрее Qt. Ведь OpenOffice с библиотекой QT разрабатывался или я не прав ?

v04bvs

Про стандарты я даже вспоминать не буду.
Когда хотя бы четверть из тех, что поддерживает gcc будет, тогда и потестим, а пока рано его с gcc сравнивать.

Компилер 2005 сдудии уже можно сравнивать c gcc, а вот vc6 и vc7 - стандарту во многом не соотсвествуют.



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

[Skull]

OpenOffice тормозит судя по тому, что программисты низкой квалификации.

Это бич всех бывших проприетарных программ, той же Mozilla.

Ну и кроме того я например заметил, что программы разработанные на gtk работают быстрее Qt.

Для GTK+ 1.x это так, для GTK+ 2.x - с точностью до наоборот.

Ведь OpenOffice с библиотекой QT разрабатывался или я не прав ?

Неправ! На собственном виджетсете. См. вывод ldd.

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

Тем не менее всегда нужно помнить об альтернативах и их возможностях. Нельзя на одном vim зацикливаться.

[Sfunx]

А теперрь дамы и господа сравним быстродействие программ создааных компиляторами gcc и Visual c++ 6. И потом делаем неутешительный вывод - gcc сравним только с Delphi.

Ps VC++ 2005 еще больше оптимизирует.

Зы Теперь мы понимаем, почем в Линукс ВСЕ тормозит. OpenOffice,...
А все из-за мягко говоря очень средненького компилятора С++

Под какую платформу сравниваем ? С какими опциями ?
Реально у меня на столе лежат устройства x86-Linux, ARM7T-Linux, ARM9-Linux (OMAP), AVR-standalone system. Их этого всего VC++ умеет лишь x86. И что не все далеко.

Реально под ARM и AVR я компилил gcc и смотрел что там получилось на ассемблере. Так вот - если оптимизация отключена - то получается ужас. Если же включена оптимизация по скорости, то код очень приемлимый. Руками намного лучше и не напишешь. Это я тебе говорю, как программист-ассемблерщик с 13летним опытом.

Когда VC++ научится делать под все эти платформы - тогда и будем сравнивать...

[balvardo]

Здраствуйте оспода Гуру) Вопщем наткнулся я на эту тему когда лазал по гуглу с вопросом " а как же мне под моим любимым линем писать консольные програмулины под Винду". Вопщем ничего особо толкового я тут не вычитал - в основном все бьют себя пяткой в грудь со словами "мое - зе бест оф зе бест" . Товариши Гуру, посоветуйте пожалуйста - мне просто в инст лабы делатть - очень напрягает всевремя бубтаться по виндой.