nixp.ru v3.0

19 апреля 2024,
пятница,
19:56:46 MSK

stealth написал 30 января 2008 года в 16:36 (1056 просмотров) Ведет себя неопределенно; открыл 103 темы в форуме, оставил 124 комментария на сайте.

Установил Ubuntu 7.10 несколько дней назад.

линукс нужен мне для программирования в с++ так как нужная мне программа и библиотеки есть тока под линукс.

прамо можно в терминале набрать например

gcc example.cc

./a.out

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

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

заранее спасибо

Anarchist

vim

dvig

Вот тут немного обсуждается <font color=«red»>тыц</font>

metal
stealth
gcc example.cc

Для c++:

g++ example.cc -o progname

Но вообще обычно используются какие-то системы сборки, а не тупо в консоле пишется. make например.

OlegL

vim, конечно, хорош, слов нет. Но и KDevelop довольно удобная штука. Религия позволяет :)

DimkaS

Geany

Uncle Theodore
Anarchist
vim

А че не ed? :D

Good Luck,

UT

Anarchist
Uncle Theodore
А че не ed? :D

Ещё можно cat вспомнить :)

lexx

xemacs и неипет

sandy

Code::Blocks

dvig

vim. Очередной холивар?=) Для учебных целей вполне хватает и более.

Anarchist
lexx
xemacs и неипет



:s/x//

Слабо? :)))

lexx
Anarchist

:s/x//

Слабо? :)))

:))))))))))) Alt+Shift+5, ну лан сделал))))))) мона и сед юзать в этом случае

Longobard

eclipse cdt, на данный момент лучшая IDE под лин.

Но по удобству она все равно сосет у MSVS 2005 + Visual Assist

Зато вроде бесплатная, чего не скажешь про аналогичное решение от мс ;)

Anarchist
Longobard
eclipse cdt, на данный момент лучшая IDE под лин.

Но по удобству она все равно сосет у MSVS 2005 + Visual Assist

Слова человека не осилившего vim.

У которого (равно как и у аналогичных решений на базе emacs сосёт уже m$vs2005.

lexx
Longobard
eclipse cdt, на данный момент лучшая IDE под лин.

Но по удобству она все равно сосет у MSVS 2005 + Visual Assist

Зато вроде бесплатная, чего не скажешь про аналогичное решение от мс ;)

Если честно все надстройки, выскакивающие просто везде хинты, всячиские типа помогающие автовставки которые отключаются вкакой нить жопе, да и просто иногда не жалание стабильно работать меня расстраивает… силав в простоте, привлекательность в красоте! Тем более не приветсвую всякие попытки вставить свой код программно как это частенько делает М$

По мне так эдитор должен быть прост… знание базовых комманд в vi может привести к грандиозным решениям! Даже поиск настолько в нем прост и удобен, чего не скажешь о обычных эжиторах, выскакивающая менюшка поиска… этож просто дикость… и ваааще не могу уже без горячих клавишь… многое чего понапихал в свой емакс… с тонкой настройкой еще можно поспорить кто у кого сосать будет!

Anarchist
lexx
и ваааще не могу уже без горячих клавишь… многое чего понапихал в свой емакс… с тонкой настройкой еще можно поспорить кто у кого сосать будет!

Главный недостаток такого решения — ты должен иметь собственное мнение и представление о том, что тебе нужно.

lexx
Anarchist
Главный недостаток такого решения — ты должен иметь собственное мнение и представление о том, что тебе нужно.

Интересно, почему это недостаток? Мне кажется преимущество! Ты задумываешься! Жто главное! … конечно для начинающего это проблема, но мне кажется не стоит начинающему искать легкие пути решения и браться за IDE с хинтами в которых надо кликать… а надо идти снизу вверх… тогда обретется и понимаение и мнение etc

Тем более изучения vi считаю базовыми познаниями любых *nix систем. Куда же без него! Ну и конечно бы sed&&awk стоило бы узнать! Этого более чем достаточно для организации быстрого и мощного рабочего пространства!

Code Monkey

для C++ Eclipse или NEtBeans, возможно C::B

Визуалка и правда иногда мешает пи написании кода на С/С++ но не сильно

Longobard
Anarchist
Слова человека не осилившего vim.

У которого (равно как и у аналогичных решений на базе emacs сосёт уже m$vs2005.

Я долгое время юзал vim, даже сделал под него красивый конфиг.

Но все равно, попробуй по 8 часов в день кодить в msvs и в виме. Вим — это хорошо для кармы и длины достоинства, но msvs (в связке с VA) удобнее.

Anarchist
Longobard
Я долгое время юзал vim, даже сделал под него красивый конфиг.

Но все равно, попробуй по 8 часов в день кодить в msvs и в виме. Вим — это хорошо для кармы и длины достоинства, но msvs (в связке с VA) удобнее.

Верно только в случае когда программируешь только на C/C++. Windows-only, определённой квалификации/пристрастий программиста и думается мне, для определённого типа задач.

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

ЗЫ: Лучше критикуй FAQ, с вторым замечанием ты прокололся, но первое — рулез!

Longobard

Спор пустой. IDE — вещь такая же интимная, как WM или производитель монитора.

Пусть человек попробует все вышеперичисленное и выберет сам.

В конце концов, IDE — это лишь инструмент. У нас на работе все пишут в чем хотят, кто-то даже в mcedit :) Я в эклипсе (на генте) и студия на ноуте.

Единообразие инструментов хорошо при парном программировании, но мы парное пока активно не применяем, так что неактуально. И вобще в командной работе лучше, когда у всех стоит одинаковая среда разработки.

Просто кому-то важна карма и крутизна («я пишу в бинарных кодах ручкой на бумажке, я нийбаццо крут!»), кому-то — удобство написания кода, кому-то — удобство рефакторинга и отладки (кстати, мы забыли про отладку. С грустью вспоминаю дебаггер из vs2005, когда приходится использовать все эти обертки от gdb. gdb мощный инструмент, но обертки под него — говно). А еще кто-то просто имеет религиозные пристрастия к тому или иному инструменту.

И категорично заявлять «рулит то-то и то-то» — бесполезно.

Longobard

Anarchist
Longobard
Спор пустой.

Не настолько пустой, как ты представляешь.

Но однозначно не повод для драки.

Longobard
IDE — вещь такая же интимная, как WM

Не только интимная.

И степень интимности среды разработки меньше, чем WM (где она тоже не абсолютна).

Longobard
или производитель монитора.

А это (в смысле обеспечения наценки за бренд) — вообще отдельная песня.

И интимность здесь побоку.

Longobard
Пусть человек попробует все вышеперичисленное и выберет сам.

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

А пытаться попробовать всё — скорее пустая трата времени.

Longobard
В конце концов, IDE — это лишь инструмент.

С оценкой значимости инструмента («всего лишь») не согласен.

Longobard
У нас на работе все пишут в чем хотят, кто-то даже в mcedit :)

Программирование в mcedit — это конечно сильно.

Longobard
Единообразие инструментов хорошо при парном программировании

Небесспорно.

Существенно зависит и от модели разработки и от квалификации программистов.

Я считаю это требование как минимум излишним.

Longobard
И вобще в командной работе лучше, когда у всех стоит одинаковая среда разработки.

Почему?

Пример(ы)?

Longobard
кому-то — удобство написания кода, кому-то — удобство рефакторинга и отладки (кстати, мы забыли про отладку. С грустью вспоминаю дебаггер из vs2005, когда приходится использовать все эти обертки от gdb. gdb мощный инструмент, но обертки под него — говно).

Не столько кому, сколько где (в плане задачи и модели разработки).

Longobard
И категорично заявлять «рулит то-то и то-то» — бесполезно.

Категорично — нельзя (в смысле некорректно).

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

lexx

To: Longobard Рульная пикча… смеялсо))))) класс

rgo
Longobard
кстати, мы забыли про отладку. С грустью вспоминаю дебаггер из vs2005, когда приходится использовать все эти обертки от gdb. gdb мощный инструмент, но обертки под него — говно

Ну как же. Не все. Не надо так злостно обобщать. Я уж не буду говорить про все, я видел всего две обёртки: emacs’овый gud, и ddd. ddd — реально кал, не спорю. А emacs’овый gud меня очень устраивает — тот самый gdb’шный командный режим, всё поддаётся настройке не хуже чем если без обёрток вообще, но ко всему, добавляется history, которая хранится между сессиями и полный листинг отладки. Единственное «но», не всегда уместна навязчивость emacs’а, в разделении окна на две половинки: в одной gdb, в другой сорец, который сейчас отлаживается. Но я считаю это злом необходимым, потому как чаще всего это удобнее, чем периодические команды list.

А, есть ещё одно неудобство: когда прогу через valgrind гоняешь, и просишь valgrind в случае какой фигни дебуггер запускать, то довольно сложно этот запущенный дебуггер адекватно присобачить к emacs’у. И мне всё никак не собраться, не оформить этот процесс присобачивания в виде, который можно записать в ~/.emacs. Поэтому я до сих пор гоняю valgrind из командной строки.

lexx

На счет дебаггинга gdb мне один раз жизнь спас… никак не мог найти мемори леак в программе… она была кроссплатформенной и компилировалась и gcc и MVS Compiller в M$ Windos был итересный баг программа жрала немеренно памяти, но когда сворачиваешь консльное окно память сразу освогбождалась я все офигеваю от этой штуки до сих пор и даже перестал себе верить что такое может быть сейчас уже… в конце концов не выдержал нашел тачку с линуксом… короче в куче расло огромное количество нодов за одну операцию… смог найти тока с помощью гдб. Проблема в том что операция с неверным прирощением нодов выполнялось не часто и на маленькой куче образование было незначительным… а дебагер не смог мне помочь разобраться, количество ожидаемых нодов найти было оч сложно, руками :( Конечно сам дурак был, надо верно следить за то что я и как передаю но всетаки ….

Смысл программы — поиск экстреммумов в функциях н-ного порядка методом ген алгоритмов. Использовал алгоритм кучи для хранения всех особей так как просто было отсекать особи…

myst

А я такую штуку тоже писал на С++, у меня даже где-то библиотечка должна валяться, под это дело написанная. Откуда у тебя там мемлики — хез, у меня таких проблем не было. Хотя такие вещи лучше писать на Python.

lexx

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

used

Установил Федора11.

В kdevelop попытался сделать проект на С и С++"hello world»

пишет что «/libtool: fork: retry: Resource temporarily unavailable» а потом больше сотни сообщений об ошибках в строках libtool

.Раньше с таким не сталкивался.Кто что скажет.

lexx

Напиши прогу в vi

И скомпиль ее gcc

used

нашел в инете решение

export LIBTOOL=’$(SHELL) /usr/bin/libtool'

Последние комментарии

ecobeingecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.