stealth
написал 30 января 2008 года в 16:36 (1116 просмотров)
Ведет себя
неопределенно; открыл 103 темы в форуме, оставил 124 комментария на сайте.
Установил Ubuntu 7.10 несколько дней назад.
линукс нужен мне для программирования в с++ так как нужная мне программа и библиотеки есть тока под линукс.
прамо можно в терминале набрать например
gcc example.cc
./a.out
я это нашел в форумах. правильно ли это? у меня выдает ошибки (но по другим причинам, в которм я сейчас разбираюсь).
может есть какие нить прогы более удобные для компиляции (вывода), написании итд. в сети нашел KDevelop,а в репозиториях убунту еще много, но не разбираюсь. что посаветуйте
заранее спасибо
Последние комментарии
- OlegL, 17 декабря в 15:00 → Перекличка 21
- REDkiy, 8 июня 2023 года в 9:09 → Как «замокать» файл для юниттеста в Python? 2
- fhunter, 29 ноября 2022 года в 2:09 → Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt? 6
- Иванн, 9 апреля 2022 года в 8:31 → Ассоциация РАСПО провела первое учредительное собрание 1
- Kiri11.ADV1, 7 марта 2021 года в 12:01 → Логи catalina.out в TomCat 9 в формате JSON 1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
vim
Вот тут немного обсуждается <font color=«red»>тыц</font>
Для c++:
g++ example.cc -o progname
Но вообще обычно используются какие-то системы сборки, а не тупо в консоле пишется. make например.
vim, конечно, хорош, слов нет. Но и KDevelop довольно удобная штука. Религия позволяет :)
Geany
А че не ed? :D
Good Luck,
UT
Ещё можно cat вспомнить :)
xemacs и неипет
Code::Blocks
vim. Очередной холивар?=) Для учебных целей вполне хватает и более.
Слабо? :)))
:))))))))))) Alt+Shift+5, ну лан сделал))))))) мона и сед юзать в этом случае
eclipse cdt, на данный момент лучшая IDE под лин.
Но по удобству она все равно сосет у MSVS 2005 + Visual Assist
Зато вроде бесплатная, чего не скажешь про аналогичное решение от мс ;)
Слова человека не осилившего vim.
У которого (равно как и у аналогичных решений на базе emacs сосёт уже m$vs2005.
Если честно все надстройки, выскакивающие просто везде хинты, всячиские типа помогающие автовставки которые отключаются вкакой нить жопе, да и просто иногда не жалание стабильно работать меня расстраивает… силав в простоте, привлекательность в красоте! Тем более не приветсвую всякие попытки вставить свой код программно как это частенько делает М$
По мне так эдитор должен быть прост… знание базовых комманд в vi может привести к грандиозным решениям! Даже поиск настолько в нем прост и удобен, чего не скажешь о обычных эжиторах, выскакивающая менюшка поиска… этож просто дикость… и ваааще не могу уже без горячих клавишь… многое чего понапихал в свой емакс… с тонкой настройкой еще можно поспорить кто у кого сосать будет!
Главный недостаток такого решения — ты должен иметь собственное мнение и представление о том, что тебе нужно.
Интересно, почему это недостаток? Мне кажется преимущество! Ты задумываешься! Жто главное! … конечно для начинающего это проблема, но мне кажется не стоит начинающему искать легкие пути решения и браться за IDE с хинтами в которых надо кликать… а надо идти снизу вверх… тогда обретется и понимаение и мнение etc
Тем более изучения vi считаю базовыми познаниями любых *nix систем. Куда же без него! Ну и конечно бы sed&&awk стоило бы узнать! Этого более чем достаточно для организации быстрого и мощного рабочего пространства!
для C++ Eclipse или NEtBeans, возможно C::B
Визуалка и правда иногда мешает пи написании кода на С/С++ но не сильно
Я долгое время юзал vim, даже сделал под него красивый конфиг.
Но все равно, попробуй по 8 часов в день кодить в msvs и в виме. Вим — это хорошо для кармы и длины достоинства, но msvs (в связке с VA) удобнее.
Верно только в случае когда программируешь только на C/C++. Windows-only, определённой квалификации/пристрастий программиста и думается мне, для определённого типа задач.
При нарушении любого из перечисленных условий утверждение становится в лучшем случае неоднозначным, при нарушении двух условий — окончательно теряет истинность.
ЗЫ: Лучше критикуй FAQ, с вторым замечанием ты прокололся, но первое — рулез!
Спор пустой. IDE — вещь такая же интимная, как WM или производитель монитора.
Пусть человек попробует все вышеперичисленное и выберет сам.
В конце концов, IDE — это лишь инструмент. У нас на работе все пишут в чем хотят, кто-то даже в mcedit :) Я в эклипсе (на генте) и студия на ноуте.
Единообразие инструментов хорошо при парном программировании, но мы парное пока активно не применяем, так что неактуально. И вобще в командной работе лучше, когда у всех стоит одинаковая среда разработки.
Просто кому-то важна карма и крутизна («я пишу в бинарных кодах ручкой на бумажке, я нийбаццо крут!»), кому-то — удобство написания кода, кому-то — удобство рефакторинга и отладки (кстати, мы забыли про отладку. С грустью вспоминаю дебаггер из vs2005, когда приходится использовать все эти обертки от gdb. gdb мощный инструмент, но обертки под него — говно). А еще кто-то просто имеет религиозные пристрастия к тому или иному инструменту.
И категорично заявлять «рулит то-то и то-то» — бесполезно.
Не настолько пустой, как ты представляешь.
Но однозначно не повод для драки.
Не только интимная.
И степень интимности среды разработки меньше, чем WM (где она тоже не абсолютна).
А это (в смысле обеспечения наценки за бренд) — вообще отдельная песня.
И интимность здесь побоку.
Как минимум для изрядной части вышеперечисленного просто попробовать недостаточно.
А пытаться попробовать всё — скорее пустая трата времени.
С оценкой значимости инструмента («всего лишь») не согласен.
Программирование в mcedit — это конечно сильно.
Небесспорно.
Существенно зависит и от модели разработки и от квалификации программистов.
Я считаю это требование как минимум излишним.
Почему?
Пример(ы)?
Не столько кому, сколько где (в плане задачи и модели разработки).
Категорично — нельзя (в смысле некорректно).
А вот применительно к задаче (условиям разработки) можно (пусть не всегда).
To: Longobard Рульная пикча… смеялсо))))) класс
Ну как же. Не все. Не надо так злостно обобщать. Я уж не буду говорить про все, я видел всего две обёртки: emacs’овый gud, и ddd. ddd — реально кал, не спорю. А emacs’овый gud меня очень устраивает — тот самый gdb’шный командный режим, всё поддаётся настройке не хуже чем если без обёрток вообще, но ко всему, добавляется history, которая хранится между сессиями и полный листинг отладки. Единственное «но», не всегда уместна навязчивость emacs’а, в разделении окна на две половинки: в одной gdb, в другой сорец, который сейчас отлаживается. Но я считаю это злом необходимым, потому как чаще всего это удобнее, чем периодические команды list.
А, есть ещё одно неудобство: когда прогу через valgrind гоняешь, и просишь valgrind в случае какой фигни дебуггер запускать, то довольно сложно этот запущенный дебуггер адекватно присобачить к emacs’у. И мне всё никак не собраться, не оформить этот процесс присобачивания в виде, который можно записать в ~/.emacs. Поэтому я до сих пор гоняю valgrind из командной строки.
На счет дебаггинга gdb мне один раз жизнь спас… никак не мог найти мемори леак в программе… она была кроссплатформенной и компилировалась и gcc и MVS Compiller в M$ Windos был итересный баг программа жрала немеренно памяти, но когда сворачиваешь консльное окно память сразу освогбождалась я все офигеваю от этой штуки до сих пор и даже перестал себе верить что такое может быть сейчас уже… в конце концов не выдержал нашел тачку с линуксом… короче в куче расло огромное количество нодов за одну операцию… смог найти тока с помощью гдб. Проблема в том что операция с неверным прирощением нодов выполнялось не часто и на маленькой куче образование было незначительным… а дебагер не смог мне помочь разобраться, количество ожидаемых нодов найти было оч сложно, руками :( Конечно сам дурак был, надо верно следить за то что я и как передаю но всетаки ….
Смысл программы — поиск экстреммумов в функциях н-ного порядка методом ген алгоритмов. Использовал алгоритм кучи для хранения всех особей так как просто было отсекать особи…
А я такую штуку тоже писал на С++, у меня даже где-то библиотечка должна валяться, под это дело написанная. Откуда у тебя там мемлики — хез, у меня таких проблем не было. Хотя такие вещи лучше писать на Python.
Дело в том что при скрещивании не удалял временный класс особи и он всатвлялся по общему алгоритму в хранилище кучи… в конце концов на каждое скрещиваени вставлялось стока особей… я ссыку на переменную неверно указал…
Установил Федора11.
В kdevelop попытался сделать проект на С и С++"hello world»
пишет что «/libtool: fork: retry: Resource temporarily unavailable» а потом больше сотни сообщений об ошибках в строках libtool
.Раньше с таким не сталкивался.Кто что скажет.
Напиши прогу в vi
И скомпиль ее gcc
нашел в инете решение
export LIBTOOL=’$(SHELL) /usr/bin/libtool'