LINUX.ORG.RU
ФорумTalks

Почему тулинг для Си такое дерьмо?

 


0

3

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

Си - отсутствие нормальной обработки ошибок, структуры с бесконечным синтаксисом со звездочками для передачи указателей. Возврат одного значения из функций или костыли с массивами. Отсутствие RAII. Постоянный выбор передать в функцию указатель на данные или вернуть новую (хз как лучше, кроме соображений о скорости при больших размерах данных).

Сборка - Makefile с его отвратительным неинтуитивным синтаксисом. Cmake нельзя.

Дебаггинг - в VSCode из коробки для проекта из больше чем 1-го .с файла ничего не работает. Да и не из коробки это работает коряво. Остается lldb и gdb, а это то еще веселье на проекте больше чем хэллоу ворлд. Valgrind тоже не самый лучший вариант. Приходится извращаться с дебагом через printf.

Смотрю на тулзы для разработки под современные SPA фреймворки и там можно найти все что хочешь для удобства.

Почему Си такое говно?

Перемещено Zhbert из development

Ответ на: комментарий от hateyoufeel

Си придумали в комплекте с UNIX - нужно было запилить операционную систему, максимально переносимую на любое железо. Для этого потребовался достаточно низкоуровневый, но универсальный язык, на котором можно было бы закодить основную часть ОС - а потом раскручивать этот код для конкретного железа с минимальными ассемблерными вставками. Поэтому пытаться сравнивать Си с высокоуровневыми языками - это просто натуральная глупость. У этих языков абсолютно разные ниши и области применения.

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 1)
Ответ на: комментарий от Zhbert

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

На самом деле многие претензии к Си оправданы. Это далеко не лучший язык, просто за ним стоят уже десятилетия опыта.

Но в ряде моментов он даже для 70-х годов был отсталым. Например, не поддерживает раздельную компиляцию - до сих пор программа на Си - это собранный компилятором из всех инклудов код. Практическую модульность организуют вручную через подключение линковщиком библиотек и прототипов к ним, включенных в код инклудом (можно и без инклуда). Впрочем в последних стандартах C++ появились модули.

Слабая система типов. Строки, терминированные нулем, а фактически можно сказать, что отсутствие встроенного строкового типа. Хуже того, можно сказать, что массивов (как например в Паскале) в Си тоже не особо есть, а имеется индексный доступ к какой-то части памяти. Правда в C99 появились динамические массивы. Но не все оказались рады особенностям его реализации.

Макросы с аргументами в Си требуют внимательности, очень легко при практическом применении они приводят к ошибке, поэтому в скобки их надо обертывать да почаще :)

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

praseodim ★★★★★
()

Потому, что тем кто пишет под C (матёрые системные программисты) так нравится. Придётся пострадать, пока это обязательно, чего тут поделать. Позже скорее всего будут более современные языки с нормальными IDE.

nebularia ★★★
()
Ответ на: комментарий от vinvlad

Rust без внутренней поддержки со стороны Cи - просто пустое место)

Так не только раст. Чуть ли не для всех ЯП либы пишутся на сях. Взять тот же питон. Все либы для числодробилок и не только…

iron ★★★★★
()
Ответ на: комментарий от xwicked

Почему использование goto является плохим тоном кодинга, в то время как assembler юзает его и в хвост и в гриву? JMP=GOTO.

Перепиши для прикола заменив структурные операторы if(){}else{} while (){} for(;;){} switch(){} на goto.

А потом обрати внимание на читабельность. Кто программировал на нескучных язычках без структурных операторов типа Fortran IV (язык для настоящих мужчин) тот таких вопросов не задаёт.

Psilocybe ★★★★
()
Ответ на: комментарий от Zhbert

Си прям очень хорошо выпрямляет руки.

Учитывая, что биологически человеческая рука не особо ровная и «выпрямление» приведет к сломаному локтевому суставу, то это очень похоже на правду :)

MoldAndLimeHoney
()
Ответ на: комментарий от MoldAndLimeHoney

приведет к сломаному локтевому суставу, то это очень похоже на правду :)

«Здраствуй $USERNAME. Давай cиграем в игру. Всю жизнь ты избегал Си…» (c) Пила

iron ★★★★★
()
Ответ на: комментарий от xwicked

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

Zhbert ★★★★★
()
Ответ на: комментарий от praseodim

Я не спорю. Сам уже давно выберу для своих задач отнюдь на Си, а что-то более подходящее и… упрощающее жизнь. Но я рад, что моими первыми языками были ассемблер, паскаль и си (именно в этом порядке :) ), т.к. ИМХО благордаря им я научился думать и понимать, что я делаю, и что происходит под капотом. Ну и благодаря паре годам программирования под МК, где надо все уложить в пару десятков килобайт, несмотря на сложность задачи.

Шлепая говнокод на питоне такое понимание либо не придет вообще, либо потребует очень много времени.

Zhbert ★★★★★
()
Ответ на: комментарий от praseodim

Но в ряде моментов он даже для 70-х годов был отсталым

Напротив, он был очень прогрессивным в своей простоте. Если сравнивать с автоиндустрией, то Си это первый настоящий автомобиль, а не карета с двигателем.

no-such-file ★★★★★
()
Ответ на: комментарий от u5er

Потому что если использовать его везде и всюду, то код превращается в нечитаемую мешанину.

Ды нет, когда ЛОР'овцы обсуждали мой кроссворд, я в одном месте использовал goto и заплевали все, типо ты кривокодер. Так что вас запугали и вы теперь плюётесь абсолютно бестолково, хотя assembler повсеместно использует JMP.

xwicked ★★☆
()

Дебаггинг - в VSCode из коробки для проекта из больше чем 1-го .с файла ничего не работает. Да и не из коробки это работает коряво. Остается lldb и gdb, а это то еще веселье на проекте больше чем хэллоу ворлд.

Бери QtCreator и твой дебаггинг будет гладким и шелковистым. VSCode - не IDE.

Loki13 ★★★★★
()
Ответ на: комментарий от MOPKOBKA

никаких нормальных типов, глобальные поля в структрах

Это фича. Идея о том что типы должны что-то там контролировать стала популярна последние лет 10-15. В те времена типы указывались для того, чтобы компилятор по-месту знал размер и мог генерировать правильный код. В соседней теме про Паскаль обсудили же. Поэтому да, нет строк и массивов как таковых, так их и нет в реальности для процессора.

no-such-file ★★★★★
()
Ответ на: комментарий от Zhbert

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

Задрали! На assemblere же кодят, почему вы в них не плюётесь? Если в коде технически невозможно другое, то почему бы не использовать? Если взять другой вопрос - функция - это тоже ссылка на другую часть кода. Я залез в недра Qt и охерел от количества мелких функций, которые друг на друга пересылают, я нихера не разобрался, а в goto вы плюётесь... Фанатики, вам запретили goto, теперь вы всем чешете про это, а большим количеством функций - всё тоже самое. Думайте всегда сами, а не читайте книжки.

xwicked ★★☆
()
Ответ на: комментарий от grem

Ты сам читаешь, что пишешь? То cmake нельзя использовать (кем?), то линтер запрещает что-то (это вообще бред).

Что непонятного-то? В колледже ведь, значит преподавателем и запрещено.

Loki13 ★★★★★
()
Ответ на: комментарий от Dimez

И поэтому виновата скамейка, если ты об неё споткнулся, да? ;-)

ты откуда вылез? Функцию можно приравнять к goto и почему?

xwicked ★★☆
()
Ответ на: комментарий от xwicked

@xwickd,

функция - это тоже ссылка на другую часть кода.

это не просто ссылка, это еще и кое-какой рантайм, правда же? Сравнивать функции и готы, и говорить: ну смотрите, и то и другое прыгает на обособленный участок кода, значит они практически одно и то же, ну это очень смелое обобщение. Вы просто проигнорировали огромный пласт абстракций, которые приносит с собой процедурное программирование, вследствие чего процедурное программирование выделяют в отдельную парадигму. А так-то да, у любых двух рандомных вещей можно найти что-то общее и заявлять о их идентичности на этом основании. @xwicked и огурец оба состоят из одного и того же набора атомов и в обоих 90% воды. Ну значит, вы огурец.

FishHook
()
Ответ на: комментарий от no-such-file

Это фича. Идея о том что типы должны что-то там контролировать стала популярна последние лет 10-15.

Нет, ты видимо меня не понял, продвинутейшие типы «как в современном С» появились не сразу. Все 70е судя по тому что я прочитал, не стоило иметь две структуры с одинаковыми по имени полями, иначе возникнут конфликты. Модификаторы к типам тоже поздно появились. Интересно, когда появились указатели на указатели?

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от FishHook

это не просто ссылка, это еще и кое-какой рантайм, правда же?

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

MOPKOBKA ★★★★★
()
Ответ на: комментарий от MOPKOBKA

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

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

Просто потому что тогда ещё не было наработано культуры программирования. Когда появились ЯП высокого уровня никто не знал тогда как с этим вообще жить, какая оптимальная методика использования, какой вообще должен быть язык.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

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

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

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

Тогда уже было все основное.

Когда появились ЯП высокого уровня никто не знал тогда как с этим вообще жить

На момент появления С, уже были ЯП высокого уровня, уже были продвинутые операционные системы.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)

Кстати, Юникс и Си из Белл Лабсов с эдвудовской Глендой - прямые предшественники нынешнего транс-тренда в айти.

token_polyak ★★★★★
()
Последнее исправление: token_polyak (всего исправлений: 1)
Ответ на: комментарий от Loki13

Тогда не надо заниматься самодеятельностью.

grem ★★★★★
()
Ответ на: комментарий от Zhbert

позвать сюда адепта Си и действующего преподавателя — @Croco

Ты аккуратнее, вдруг ТС ему свой минишелл и будет сдавать.

ya-betmen ★★★★★
()
Ответ на: комментарий от xwicked

Так кодят на ассемблере!

; declare some simple class
class TIndex

 field Index  : DWORD = 0 

 ; suppose we have 2 functions to work with Index
 function Inc
 ; just for example - let it be virtual
 virtual_function Dec

endclass

; code section
section '.flat' code readable executable

; implement TIndex functions

proc TIndex.Inc this

 ; increment our object index 
 mov eax,[this]
 inc [eax + TIndex.Index]
 ret
endp ; { TIndex.Inc } 

proc TIndex.Dec this

 ; decrement our object index
 mov eax,[this]
 dec [eax + TIndex.Index]
 
 ret
endp ; { TIndex.Dec } 

; ******************   PROGRAMM ENTRY POINT   ******************
proc Main

 ; make calls of both TIndex functions
 ; this is call of static function of object  
 objfcall IndObj->Inc() ; increment index
 ; make next call via supposed "untyped" pointer to object (just for example)
 ; this is call of virtual function of object
 mov eax,IndObj
 clsfcall TIndex(eax)->Dec() ; decrement index

 ; let see index value after calls
 ; it will be zero
 mov ecx,[IndObj.Index]

; exit process
 invoke ExitProcess, NULL
endp

В KolibriOS например много процедур, да почти в любом коде на ассемблере который я видел, их много.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Ответ на: комментарий от MOPKOBKA

На момент появления С, уже были ЯП высокого уровня, уже были продвинутые операционные системы.

Это примерно как сейчас говорить, что есть квантовые компы и софт для них. Т.е. были конечно, но не массово.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Я конечно мало знаю про те времена, но неужели так мало людей могли получить возможность компиляции на PL/1, с помощью какой нибудь IBM машины? Fortran то уж точно был доступен, самый первый компилятор был оптимизирующим кстати. И даже были удобства, в виде короткой записи маленьких функций:

      ...

      F(X, Y) = X*Y/Y
      R = F(5, 10)
MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)

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

Ghostwolf ★★★★★
()

Почему…

И. А. Крылов «Мартышка и очки» :
«Как ни полезна вещь,— цены не зная ей,
Невежда про нее свой толк всё к худу клонит…» ©.

quickquest ★★★★★
()
Ответ на: комментарий от MOPKOBKA

На момент появления С, уже были ЯП высокого уровня, уже были продвинутые операционные системы.

И где они? А Си вот он, жив. Си в итоге оказался эволюционно продвинутее тех ЯП.

wandrien ★★
()
Ответ на: комментарий от MOPKOBKA

неужели так мало людей могли получить возможность компиляции на PL/1

PL/1: «замах на рупь, результат на копейку», несовместимые клоны сильно затрудняли использование языка.

quickquest ★★★★★
()
Ответ на: комментарий от vinvlad

Си придумали в комплекте с UNIX - нужно было запилить операционную систему, максимально переносимую на любое железо.

Это ты сам придумал? Про переносимость UNIX разговора при изначальной разработке не было, оно пилилось под PDP и только под PDP изначально и работало.

достаточно низкоуровневый, но универсальный язык

Мне нравится, что упоротые сишники не видят никакого противоречия в этих словах.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)

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

buddhist ★★★★★
()
Ответ на: комментарий от buddhist

А что мешает писать и компилировать С-шные программы на Borland C?

tiinn ★★★★★
()
Ответ на: комментарий от etwrq

больше на паскаль походит чем на асм.

Похоже это Flat Assembler. Там есть очень много интересных фишек. Собственно, на нем написана KolibriOS.

iron ★★★★★
()
Последнее исправление: iron (всего исправлений: 1)
Ответ на: комментарий от buddhist

Буквально на аватарку свою посмотри

Можно ещё Форт вспомнить. Это всё эксперименты, интересные, но не выжившие. Опять же сравнивая с автоиндустрией, там были всякие проекты атомных автомобилей, и т.п. впечатляющие концепты. Всё это был поиск. История уже рассудила, кто был прав и по-настоящему прогрессивен.

no-such-file ★★★★★
()

Смотрю на тулзы для разработки под современные SPA фреймворки и там можно найти все что хочешь для удобства.

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

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

Кстати, а что плохого в отладке принтами? Это позволяет не только прописывать нужные условия в нормальном IDE и на нормальном языке вместо ограниченного интерфейса отладчика, но еще и легко сохранять их между запусками. Что-то мне подсказывает, что отладкой чего-то серьезного ты не занимался.

Lrrr ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)