Pull to refresh

Comments 37

Зачем предлагать писать код в gedit, компилировать bash скриптом, а про отладку даже не заикаться? Можно же добавить ещё 1 команду, и появится приличная IDE.

Это сложный квест ;) Некоторые даже команды vim выучили потому что не понятно как из него выйти :D

GCC делает chmod +x a.out за нас, так что можно смело пропускать этот пункт. Больше актуально для бинарников, скачанных из Интернета.

Не лишним было бы добавить парочку флагов для отображения предупреждений, основные для меня - -Wall -Wextra -pedantic, порой очень помогают искать ошибки. На Codeforces этому даже посвящена небольшая статья. Здесь можно было бы добавить про Valgrind, санитайзеры и статические анализаторы, но это уже не совсем уровень новичка.

Также предложил бы новичкам попробовать и Geany (есть в репозиториях практически всех дистрибутивов) - он содержит заранее прописанные параметры компиляции и запуска для многих популярных языков, остаётся лишь нажимать хоткеи и пользоваться.

Не лишним было бы добавить парочку флагов для отображения предупреждений

Понимаю, что за фразой : "....не лишне" могут последовать тома советов, но к обязательному -Wall хорошо бы и -Wfatal-errors что бы не мотать километры скрола в поисках что не так

вместо использования bat файла лучше использовать какую-нибудь систему сборки, например старейший make

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

А если изменился заголовочный файл?

в makefile ты как раз и описываешь список файлов, от которых зависит какой

И в итоге зависимости дублируются: один раз в виде директив #include, второй раз в makefile. А где дублирование — там и баги.

Все компиляторы давно умеют генерировать .o.d файлы со списком зависимостей. Этот файл просто инклудится в Makefile и он чудесным образом начинает отслеживать изменения в заголовочных файлах.

О, ну наконец-то такая возможность появилась.


Осталось только чтобы был хоть какой-нибудь способ узнать о ней, кроме чтения мана от корки до корки или комментариев 5 уровня на Хабре.

Ммм... Ну мне лень ковырять историю gcc, но я уверен что этой возможности не менее 30 лет. Первый попавшийся пост об этой фиче написан аж в 2000 году: http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/

И используется эта штука в каждом первом проекте на C. Так что я вообще не понимаю как вы ее пропустили.

Элементарно: не было у меня проектов на Си. Что, к слову, является следствием в том числе пропущенной информации об этой возможности.

Если у вас не было проектов на С, то зачем так безапелляционно заявлять о том, когда какие фичи появились?

Я об этом, если что:

О, ну наконец-то такая возможность появилась.

Тогда скорее cmake, ибо он легче поможет настроить external depends

$ sudo apt install build-essential

Окажется сильно полезнее, нежели просто gcc. Для желающих есть еще мета-пакеты crossbuild-essential-[ARCH]. И приготовиться доставлять пакеты с суффиксом -dev.

Остальное по вкусу и по потребности.

А где пункт "продать душу дьяволу" ?

А если у меня кеды как быть — тянуть весь гтк или что там сейчас?

Пользователи кедов должны страдать, разумеется :)

kate конечно, сильно лучше gedit хотя по сути своей то-же самое

Помимо apt бывают и другие пакетные менеджеры yum pkg dnf tazpkg brew…
Но первым делом надо ставить mc и vim
И про такое надо было упомянуть
man dlopen
man printf
ctags --c-kinds=+p -R /usr/include
vim -t sockaddr_in
vimtutor
grep something -r .
gcc -o main -S -O2 -march=native -fwrapv main.c -llibs -Wl,-rpath,'$ORIGIN'

И редакторы vscode, sublime_text гораздо веселее чем gedit но без ssh и vim всё равно никуда.

Но первым делом надо ставить mc ranger и vim

для работы с файлами mc, ncdu, fdups, rsync, find, fatrace, mount, df, tar, 7z, dd, file, mimeopen
про ranger ничего не могу сказать.

К программированию на C эти вещи как то слабо относятся.

Без vim вполне себе куда. mc вообще не первым делом, и даже не вторым. Даже не могу вспомнить, когда его запускал в последний раз. VS Code, однозначно must have для программиста. Пожалуй это лучшее произведение Microsoft, что я видел в своей жизни.

Согласен. Можно сразу без телеметрии. Или отключать оную в оригинале. Но для комментариев к данной статье, это перебор. Нам здесь объясняют, как установить gcc без dev tools и gedit как редактор кода. И, главное, как скомпиллировать "Hello world", без всяких там ключей. Ну, если мы осилили установку Linux, конечно.

В 2000 году, наверное, это могло быть актуально. А в 2022 программы на С можно прямо в браузере писать.

И это ещё ерунда. В 2022, школьные рефераты можно прямо на хабре писать.

Все же удобнее так:

#!/bin/bash
rm ./a.out
gcc -o a.out $GEDIT_CURRENT_DOCUMENT_NAME
chmod +x ./a.out
./a.out

Вдруг захочется запустить еще раз, не компилировать же заново.

Всё же удобнее через make. "chmod +x ./a.out" в принципе не нужен, gcc сам помечает файл исполняемым.

Ничего не хочу плохого сказать ни про gedit, ни про vim и прочие "классические" инструменты, в которых писали ещё издревле, но вот почему бы новичкам не начинать сразу с юзер-френдли программ? Тем более, что они есть - vscode и clion, например. Все таки dx очень важен, особенно на первых порах, когда человеку ещё только предстоит адаптироваться к экосистеме языка.

назвать vscode и clion юзерфрендли это сильно..

100500 функционала который новичку понадобится не скоро, жор памяти, инородный системе визуал.. ну такое себе. тогда уж qt-creator больше подойдёт.

вот когда новичёк перестанет быть новичком тогда и clion станет ему другом

а вообще начинать я бы предложил с консольки, чтобы в будущем тыкая, условно, на кнопку debug он знал что же там под капотом запускается и с какими флагами.

вот хоть бы посили чего минусуют, интересно же..

Статья вызывает невольный внутренний возглас: "А на хабр ли я попал!".

Sign up to leave a comment.

Articles