Здравствуйте, Аноним, Вы писали:
А>Какими IDE для C++ Вы пользуетесь для коммерческой кросс-платформенной разработки с закрытым кодом?
vim + cscope + supertab (+ ctags)
И так уже четыре года, третий проект и второе место работы.
Был трёхмесячный период на emacs, но в силу нежелания изучать Common Lisp, не нашёл его достаточно удобным для себя.
К тому же с jabber.el пересел на mcabber.
Re[2]: IDE ?
От:
Аноним
Дата:
19.02.12 10:37
Оценка:
Здравствуйте, potapov.d, Вы писали:
PD>vim + cscope + supertab (+ ctags)
боюсь для меня это не по силам
проект написан на VS2005(mfc) — с множеством форм и видов
> Был трёхмесячный период на emacs, но в силу нежелания изучать Common Lisp, не > нашёл его достаточно удобным для себя.
Ох.. при чём тут common lisp, а ? В Emacs свой язык -- emacs lisp.
И c common list его связывают лишь общие лисповые корни. А так -- совсем
разные языки. Emacs lisp проще гораздо, нечто типа schema.
И учить его для использования emacs вовсе не обязательно.
> Какими IDE для C++ Вы пользуетесь для коммерческой кросс-платформенной > разработки с закрытым кодом?
Сейчас Eclipse+CDT. Вот только не понятно, какая разница, открытый код
или нет того, что ты разрабатываешь.
Posted via RSDN NNTP Server 2.1 beta
Re[6]: IDE ?
От:
Аноним
Дата:
19.02.12 12:39
Оценка:
Здравствуйте, Programador, Вы писали:
P>Здравствуйте, Аноним, Вы писали:
А>>так вроде там код должен быть открыт, если подразумевается ком.использование
P>давно не так
LGPL??? Я не знаток лицензий, т.е. если ком.использование, то линковать только динамически?
Здравствуйте, Аноним, Вы писали:
А>Какими IDE для C++ Вы пользуетесь для коммерческой кросс-платформенной разработки с закрытым кодом?
А вы не путаете IDE и фреймворк (набор библиотек) случаем? Для IDE не имеет значения открытый/закрытый/комерческий код. Только для фреймворков и то все основные давно позволяют всё.
Здравствуйте, Аноним, Вы писали:
А>LGPL??? Я не знаток лицензий, т.е. если ком.использование, то линковать только динамически?
если Qt по свободной лицензии то нельзя лишать других права обновлять Qt. Если линковка статическая то нужно давать свои обьектники если попросят. Смысла в статической линковке особого нет
Здравствуйте, MasterZiv, Вы писали:
MZ> Emacs lisp проще гораздо, нечто типа schema.
Может оно и проще, но у меня выучить его за пару вечеров не получилось. А выделать более длительное время на изучение "ещё одного языка" я не могу.
MZ> И учить его для использования emacs вовсе не обязательно.
В теории — да, но на практике сделать emacs удобным для себя без знания elisp невозможно.
Я тоже забросил emacs по той же причине — нет времени/желания раскуривать elisp. Я делал периодические попытки разобраться в нём, что-то простое я мог написать, но как сделать именно то что мне хотелось от emacs — я так и не осилил. А работать с ним как он есть — мне не нравится.
Промучился года два или три и вернулся на vim.
Здравствуйте, Аноним, Вы писали:
А>проект написан на VS2005(mfc) — с множеством форм и видов
Если вы собираетесь оставаться на mfc, то ни о какой кроссплатформенности речи быть не может. GUI-библиотеку всё равно придётся менять на что-то кроссплатформенное. Вариантов много, самый популярный — Qt.
С уважением, Artem Korneev.
Re[4]: IDE ?
От:
Аноним
Дата:
19.02.12 17:33
Оценка:
Здравствуйте, artem_korneev, Вы писали:
_>Если вы собираетесь оставаться на mfc, то ни о какой кроссплатформенности речи быть не может. GUI-библиотеку всё равно придётся менять на что-то кроссплатформенное. Вариантов много, самый популярный — Qt.
Здравствуйте, MasterZiv, Вы писали:
MZ>Ох.. при чём тут common lisp, а ? В Emacs свой язык -- emacs lisp. MZ>И c common list его связывают лишь общие лисповые корни. А так -- совсем MZ>разные языки. Emacs lisp проще гораздо, нечто типа schema. MZ>И учить его для использования emacs вовсе не обязательно.
Значит у меня не было даже желания выяснить, что за разновидность лиспа там используется. Я в сортах лиспа не разбираюсь.
И на тот момент (да и сейчас), я не вижу вариантов комфортного использования емакса (да и вима) без знания его скриптового языка.
Здравствуйте, MasterZiv, Вы писали:
>> В теории — да, но на практике сделать emacs удобным для себя без знания elisp >> невозможно. MZ>Я emacs lisp не знаю. Но с emacs вполне работаю.
И? Вы смогли допилить его под себя или просто привыкли к тому что есть?
On 02/20/2012 01:37 PM, potapov.d wrote:
> И на тот момент (да и сейчас), я не вижу вариантов комфортного использования > емакса (да и вима) без знания его скриптового языка.
Поверь, вовсе это не обязательно. Большинство функций настоечных можно звать
по M-x и они там будут как в shell в виде комманд. Ну может быть e-lisp
чуть-чуть знать надо, самые основы --
(function param1 param2 param3 )
вызывает функцию function с параметрами param1 param2 param3,
чаще всего все настройки -- это вызовы функций каких-то.
"asdf" -- строка
1 — число
'asdf -- символ (особый вид строки, можно сказать, строковая константа).
первое, что приходит на ум. Один из моих вопросов на rsdn. Вы используете semantic? Если да, то как вы решаете описанную мною проблему?
Ещё я помню множество мелких неудобств, когда я разбивал окно на две части и emacs при вызове функций постоянно пытался открыть во второй половине окна что-то своё, закрывая мой буфер. Но сейчас сходу не скажу как воспроизвести — где-то год назад я слез с emacs.
On 02/21/2012 01:07 PM, artem_korneev wrote:
> Простите за занудство — а что именно вы тогда допиливали?
Это был Emacs 22, если не ошибаюсь, и в основном это была установка и
настройка Slime, установка и настройка всяких dired, и прочих тулзей.
> Сейчас я врятли уже вспомню все смущавшие меня грабли, которые торчали из emacs, > но вот <http://rsdn.ru/forum/unix/3983633.1.aspx>
первое, что приходит на ум. > Один из моих вопросов на rsdn. Вы используете semantic? Если да, то как вы > решаете описанную мною проблему?
Пока нет.
> Ещё я помню множество мелких неудобств, когда я разбивал окно на две части и > emacs при вызове функций постоянно пытался открыть во второй половине окна > что-то своё, закрывая мой буфер. Но сейчас сходу не скажу как воспроизвести — > где-то год назад я слез с emacs.
Так это не неудобство, это фича.
C-x 2, если я не ошибаюсь, и всё в порядке.
Вообще, это отдельная тема -- буфера в Emacs. Я тоже долго с ней не мог
свыкнуться -- я просто физически нетерплю, когда на машине открыты какие-то
ненужные мне окна. А Emacs наоборот их всё время открывает. В общем, я должго
напрягался. Но потом понял -- надо плюнуть. И плюнул.
Выучил
C-x 1
C-x 2
и
C-x k (y) закрывает буфер. (kill buffer)
и всё.
Ну и заради прикола -- тема настолько оказывается "важная"
(я изучал), что специально для таких, как я, в Emacs есть комманда,
кажется kill-some-buffers, которая удаляет один буфер случайным образом.
Ну, разумеется, не нужный (неактивный). А так, как я понял, народ просто не парится.
Здравствуйте, MasterZiv, Вы писали:
>> Ещё я помню множество мелких неудобств, когда я разбивал окно на две части и >> emacs при вызове функций постоянно пытался открыть во второй половине окна >> что-то своё, закрывая мой буфер. MZ>Так это не неудобство, это фича.
Ну кому фича, а кому баг.
Меня эта "фича" изрядно анноила, каждый раз после вызова внешних программ мне приходилось вручную переходить в это окно и возвращать тот буфер, который я хотел там видеть.
MZ>C-x 2, если я не ошибаюсь, и всё в порядке.
Да вот нет. "C-x 2" делит окно на две части, а проблема в том, что emacs может использовать вторую часть окна по своему усмотрению.
У меня 22" монитор и мне было удобно, когда в emacs открыто сразу два файла. Например, хэдер и cpp-файл. Ширина позволяет открыть их сразу. Так вот, при каждом вызове внешних команд, emacs печатал их вывод во второй, неактивной части окна. И потом мне приходилось вручную возвращать всё как было.
Если окно не разбивать самостоятельно — для вывода внешних программ создаётся небольшое окошко в нижней части экрана. Вот мне хотелось чтобы при вертикальном разбиении окна, emacs продолжал создавать окно внизу и не трогал мои окна.
MZ> А так, как я понял, народ просто не парится.
Ну кому лишние буферы не мешают — те не парятся. А мне было сложно находить свои буферы среди 500..600 открытых. В результате, от умного автодополнения пришлось просто отказаться.
Вот таких мелких неудобств при работе с emacs у меня вылезало довольно много. Даже с переходом по тегам грабли вылезали — я не разобрался, как научить emacs запоминать историю переходов, чтобы нормально возвращаться по ней.
В результате, я пересел на Eclipse(ну и иногда — пользуюсь QDevelop). Он мне совсем не нравился в плане интерфейса, но пользоваться им для разработки на C++ всё-таки удобнее, чем emacs. То, что я использую чаще всего — навигация по тегам и автодополнение — в Eclipse нормально работает. Правда, мне не нравится как организована навигация по коду — приходится много тыкать мышью, но я пока тешу себя мыслью, что м.б. соберусь и напишу свой плагин для удобства. Всё-таки Java я немного знаю, в отличие от ELisp.
Здравствуйте, Аноним, Вы писали:
А>Какими IDE для C++ Вы пользуетесь для коммерческой кросс-платформенной разработки с закрытым кодом?
QTCreator думаю неплохой вариант. Интерфейс приятный, автодополнение кода работает лучше, чем у студии без ассиста. Кроме того, можно делать проекты совсем не связанные с Qt. Поддержка файлов проекта CMake — очень приятно для кроссплатформенной разработки.
> Вот таких мелких неудобств при работе с emacs у меня вылезало довольно много.
Ну да, меня тоже это раздражает.
> В результате, я пересел на Eclipse(ну и иногда — пользуюсь QDevelop). Он мне > совсем не нравился в плане интерфейса, но пользоваться им для разработки на C++ > всё-таки удобнее, чем emacs. То, что я использую чаще всего — навигация по тегам > и автодополнение — в Eclipse нормально работает.
Я пока проделал тот же путь, только в Emacs правда под С++ не программировал.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Аноним, Вы писали:
А>>Какими IDE для C++ Вы пользуетесь для коммерческой кросс-платформенной разработки с закрытым кодом?
KP>vim + cscope
почему перешли с emacs на vim?
просто думаю пытаться освоить emacs или углубиться в vim... для меня будет очень полезным комментарий человека активно использовавшего оба.
спасибо
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
