Хочу расширить свою специализацию. Хочется изучить программирование под Linux/Unix, но не очень понимаю, с чего начать.
Каков "джентельменский набор" программиста на С++ под Linux/Unix?
Какой дистрибутив Linux/Unix лучше поставить?
Какую среду разработки и компилятор?
Какие библиотеки изучить?
Интересуют самый востребованные (широко используемые) инструменты, такие как QT.
S>Хочу расширить свою специализацию. Хочется изучить программирование под Linux/Unix, но не очень понимаю, с чего начать.
S>Каков "джентельменский набор" программиста на С++ под Linux/Unix?
g++/emacs/valgrind S>Какой дистрибутив Linux/Unix лучше поставить?
Fedora S>Какую среду разработки и компилятор?
emacs, g++ S>Какие библиотеки изучить?
boost/Qt S>Интересуют самый востребованные (широко используемые) инструменты, такие как QT.
Qt
Здравствуйте, uhh, Вы писали:
uhh>Здравствуйте, Sashaka, Вы писали:
S>>Хочу расширить свою специализацию. Хочется изучить программирование под Linux/Unix, но не очень понимаю, с чего начать.
S>>Каков "джентельменский набор" программиста на С++ под Linux/Unix? uhh>g++/emacs/valgrind
Рискуем скатиться во флейм, но выскажусь, так как имею нужный ТС опыт — уже год как переехал на *nix с винды, не понимаю в упор, в чем преимущества емакса, по-моему, создано чужими для хищников.
Остановился на NetBeans (была еще SunStudio, но благополучно умерла вместе с Sun)
Короче, нельзя виндовому программисту переживать такие стрессы, как работа в емаксе, надо все постепенно, иначе ежечасные пятиминутки ненависти гарантированы
S>Хочу расширить свою специализацию. Хочется изучить программирование под Linux/Unix, но не очень понимаю, с чего начать.
S>Каков "джентельменский набор" программиста на С++ под Linux/Unix?
g++, Make, autotools или Cmake
S>Какой дистрибутив Linux/Unix лучше поставить?
любой из мейнстрима, реально, критичных отличий не вижу
S>Какую среду разработки и компилятор?
среда разработки — по вкусу, Make понимают все
S>Какие библиотеки изучить?
pthread и вообще многопоточность в POSIX, очень по ним на собеседованиях спрашивают
Здравствуйте, los puercos, Вы писали:
LP>Остановился на NetBeans (была еще SunStudio, но благополучно умерла вместе с Sun)
На большом проекте ложится и больше не оживает. В отличие от того-же Eclipse.
LP>Короче, нельзя виндовому программисту переживать такие стрессы, как работа в емаксе, надо все постепенно, иначе ежечасные пятиминутки ненависти гарантированы
А как же тогда он пересядет? Еще GDB будет доставлять не по детски.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, los puercos, Вы писали:
LP>>Остановился на NetBeans (была еще SunStudio, но благополучно умерла вместе с Sun)
KP>На большом проекте ложится и больше не оживает. В отличие от того-же Eclipse.
Списибо, буду знать. Вообще, емакс в планах есть, но как-то регулятно откладывается.
Eclipse сразe отправился в топку.
LP>>Короче, нельзя виндовому программисту переживать такие стрессы, как работа в емаксе, надо все постепенно, иначе ежечасные пятиминутки ненависти гарантированы KP>А как же тогда он пересядет? Еще GDB будет доставлять не по детски.
Даже с DDD?
Здравствуйте, los puercos, Вы писали:
LP>Списибо, буду знать. Вообще, емакс в планах есть, но как-то регулятно откладывается.
Может и зря. У него не очень хорошо дела с поиском по тегам и автоподстановкой обстоят.
LP>Eclipse сразe отправился в топку.
А вот это зря, он, конечно, монструозен и как редактор не чета тому же Vim, но очень хорошо справляется с задачей парсинга большого (реально большого) объема кода. И в итоге оказывается довольно юзабельной штукой.
LP>>>Короче, нельзя виндовому программисту переживать такие стрессы, как работа в емаксе, надо все постепенно, иначе ежечасные пятиминутки ненависти гарантированы KP>>А как же тогда он пересядет? Еще GDB будет доставлять не по детски. LP>Даже с DDD?
Как-то так получается, что все эти оболочки (еще можно про cgdb вспомнить, например) хороши. Но как доходит до работы, где-то что-то начинает глючить о отваливаться. И в итоге возвращаешься к чистому GDB. Хотя, если писать GUI, не отлаживать kernel-level или демоны, то, возможно, все будет хорошо
Здравствуйте, los puercos, Вы писали:
LP>Короче, нельзя виндовому программисту переживать такие стрессы, как работа в емаксе, надо все постепенно, иначе ежечасные пятиминутки ненависти гарантированы
После шести лет опыта на visual studio, за месяц пересел на vim. Как домой вернулся. Теперь вспоминаю угрёбищную формошлёпку от ms как страшный сон.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, los puercos, Вы писали:
LP>>Списибо, буду знать. Вообще, емакс в планах есть, но как-то регулятно откладывается.
KP>Может и зря. У него не очень хорошо дела с поиском по тегам и автоподстановкой обстоят.
LP>>Eclipse сразe отправился в топку.
KP>А вот это зря, он, конечно, монструозен и как редактор не чета тому же Vim, но очень хорошо справляется с задачей парсинга большого (реально большого) объема кода. И в итоге оказывается довольно юзабельной штукой.
Не знаю, об одном и том же мы говорим, Eclipse как бы платформа. Но CDT у меня регулярно падает и тормозит дичайше, при парсинге в том числе.
Здравствуйте, los puercos, Вы писали:
KP>>А вот это зря, он, конечно, монструозен и как редактор не чета тому же Vim, но очень хорошо справляется с задачей парсинга большого (реально большого) объема кода. И в итоге оказывается довольно юзабельной штукой.
LP>Не знаю, об одном и том же мы говорим, Eclipse как бы платформа. Но CDT у меня регулярно падает и тормозит дичайше, при парсинге в том числе.
Да, я именно про него говорю. В настройках CDT надо выставить пару флажков: на вкладке Indexer необходимо выставить флажки "Skip implicit references" и "Skip type and macro references", а так же увеличить "Cache limits" на той же вкладке. После этого все будет работать как минимум не хуже чем в случае с NetBeans IDE.
Здравствуйте, los puercos, Вы писали:
LP>>>Короче, нельзя виндовому программисту переживать такие стрессы, как работа в емаксе, надо все постепенно, иначе ежечасные пятиминутки ненависти гарантированы KP>>А как же тогда он пересядет? Еще GDB будет доставлять не по детски. LP>Даже с DDD?
уж лучше тогда использовать Qt Creator + CMake, отлаживать достаточно удобно.
а вообще IMHO у Emacs-а достаточно хорошая поддержка GDB, чтобы ей удобно было пользоваться. мне только не понравились keybinding-и по умолчанию, настроил под себя.
Здравствуйте, Sashaka, Вы писали:
S>Хочу расширить свою специализацию. Хочется изучить программирование под Linux/Unix, но не очень понимаю, с чего начать.
Я примерно года 3 как пересел.
Думаю, примерный порядок действий такой:
Поставь какой-нибудь линукс, освойся, разберись с консолью, напиши какой-нибудь helloworld, скомпилируй его из консоли, запусти.
Создай проект из нескольких файлов, разберись с make, autotools/cmake/scons (сам пользуюсь cmake), собери, запусти.
Разберись с gdb, подебажь свой учебный проект.
Выбери редактор и прочие тулзы для повседневной работы.
Дальше по потребностям.
S>Каков "джентельменский набор" программиста на С++ под Linux/Unix?
g++, gdb
S>Какой дистрибутив Linux/Unix лучше поставить?
Универсального ответа нет. Тот, что нормально поставится и не будет сильно глючить. Попробуй для начала убунту. Год под ним сижу на работе, доволен.
S>Какую среду разработки и компилятор?
Компилятор g++, остальные в 99% случаев под юниксом не нужны.
Нормальную среду разработки, такую, чтобы сидеть только в ней и все делать, не нашел. Работаю так:
Для редактирования среда, которая умеет парсить С++ и умеет хотя бы часть того, что было по студией/ассистом. Я сначала взял NetBeans, но он со временем стал страшно тормозить, к тому же новые версии кажутся хуже старых. Пересел на QTCreator, пока доволен.
Для компиляции настроить хоткей или alt-tab в консоль и make, cmake и т.д.
Для отладки cgdb — оболочка над gdb, раскрашивает код, позволяет работать хоткеями, а не консольным командами, как голый gdb. Но от студийной привычки на каждый чих лезть в дебаггер отказался, т.к. неудобно. Вместо этого всегда делаю обильно логирование, нормальных логов в большинстве случаев хватает, чтобы распознать проблему.
Кроме этого для комфортной работы надо освоить базовые консольные тулзы юникса — grep, find и прочие.
shell script не люблю, умею перл, но это дело вкуса. В любом случае писать мелкие скрипты на чем-то надо.
Системы сборки — make, (cmake | autotools)
Голый gdb желательно тоже уметь хотя бы на базовом уровне, т.к. возможно придется дебажить удаленно на машине, где оболочек нет и поставить не дадут.
Какой-нибудь текстовый редактор с подсветкой синтаксиса, чтобы написать что-то небольшое, не тратя времени на то, чтобы лезть в среду разработки. Выбор большой. scite, kate. Если хочешь стать тру-юниксоидом — vim, но ты будешь страдать
S>Какие библиотеки изучить?
Общечеловеческие все те же, что и под виндой — STL, boost.
Остальное зависит от нужд проекта.
S>Интересуют самый востребованные (широко используемые) инструменты, такие как QT.
QT это для гуя. У меня вот гуя нет, QT даже не щупал. Зависит от проекта.
Здравствуйте, RedUser, Вы писали:
LP>>pthread и вообще многопоточность в POSIX, очень по ним на собеседованиях спрашивают RU>А что, например, спрашивают?
fork/exec, мьютексы, семафоры, условные переменные, производительность, многопоточные паттерны
S>Хочу расширить свою специализацию. Хочется изучить программирование под Linux/Unix, но не очень понимаю, с чего начать.
S>Каков "джентельменский набор" программиста на С++ под Linux/Unix? S>Какой дистрибутив Linux/Unix лучше поставить? S>Какую среду разработки и компилятор? S>Какие библиотеки изучить?
S>Интересуют самый востребованные (широко используемые) инструменты, такие как QT.
Я бы тоже тоже хотел с винды съехать в программирование под *nix.
Только писать гуй на Qt (хотя в проектах для себя использую PyGtk) или чем-то другом совсем не горю желанием.
Куда можно податься по *nix без гуя и чего нужно учить?
Здравствуйте, TrashMiner, Вы писали:
TM>Куда можно податься по *nix без гуя и чего нужно учить?
Так в основном серверный софт под *nix пишут, там никакого гуя и нет. Из специфичного для *nix в целом всё вокруг POSIX крутится. Основные вещи от платформы не зависят — сетевые протоколы, стандарты.
Плюс полезно копнуть в сторону системного программирования. На эту тему по Linux хорошая книжка: Understanding the Linux Kernel, 3rd edition
