Стоит ли в нынче щас учить язык Си?

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

Не подменил а уточнил

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

Особую в сравнении с чем?

это к тебе вопрос. какая поддержка со стороны синтаксиса тебе нужна, чтобы считать, что в языке есть та или иная функциональность?

RHS не может ссылаться на LHS

не понял. приведи пример

Ты сегодня особенно агрессивен

никогда не любил безапелляционных идиотов

лысеющий друг

во-первых, я тебе не друг. во-вторых, я полностью лысый, а не лысеющий

позволяет ли наличие Foreign.C говорить о поддержке указателей со стороны языка?

ты определись - мы всё-таки говорим о наличии или поддержке со стороны языка? и что именно ты подразумеваешь под поддержкой?

std::string в стандартной библиотеке С++ это более поддержка строк, чем forM* в стандартной библиотеке Haskell - поддержка циклов?

Передай это разработчикам GCC которые успешно с сишки на плюсы мигрировали

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

Дескриптор файла за память считаем? Утечка ресурсов пострашнее утечек памяти будет, КМК.

RAII работает с любыми ресурсами. Это тебе не сборка мусора.

дело в том что кресты = говно

Все, что используют - говно. Так уж получается. Java тоже говно, винда - говно, линь - говно, си - говно...

были изначально неудачно реализованы

Аналитика уровня ЛОР.

Вангую, что идеальным языком, по мнению ТС, является что-то липсоподобное.

если подстрочно мигрировать FORTRAN-код на С

Не выйдет, придется переписывать.

имхо, без Си не очень будет понятно как работает Си++ «под капотом», и как делать на Си++ некоторые оптимизции в Си стиле, но это не помешает освоить сам Си++ и писать на нём программы.

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

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

Я вот много на Си писал (не то чтобы гуру, но это был мой основной язык), ща изучаю Плюсы, сначала настороженно на них смотрел - теперь кайфую )

все циклы в основном понятны while, do, for и т.д. Указатели тоже предельны ясны, сперва конечно немного недопонимал этих указателей, но 10-20 раз перечитал стало понятно. Но не суть.

okay, раз изич тебе там все, то си учить нет смысла, не занимай свой мозг

кстати, зная си, прикольно листать исходники самого си++ - вернее gcc/g++ например, и смотреть как работает скажем new, new[] - через malloc ) а между delete и delete [] вообще разницы нет (как и между new и new - всего лишь обертки) (немного грубо говоря) хотя наверное это очевидные вещи и 99% людей тут это знают.

это к тебе вопрос. какая поддержка со стороны синтаксиса тебе нужна, чтобы считать, что в языке есть та или иная функциональность?

Нет, к тебе. Если я накостылю на Haskell ООП в духе GObject, будет ли это означать поддержку Хаскеллом ООП? Или ты просто решил начать придираться к словам?

никогда не любил безапелляционных идиотов

Тогда почему ведёшь себя как один из них?

я полностью лысый, а не лысеющий

Сорри, давно тебя не встречал IRL.

std::string в стандартной библиотеке С++ это более поддержка строк, чем forM* в стандартной библиотеке Haskell - поддержка циклов?

Я нахожу этот вопрос некорректным.

Я нахожу этот вопрос некорректным.

я тоже. именно потому я его и задал. вот вопрос того же уровня корректности:

Если я накостылю на Haskell ООП в духе GObject, будет ли это означать поддержку Хаскеллом ООП

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

Сорри, давно тебя не встречал IRL.

бывает

Не выйдет, придется переписывать.

усилия сопоставимы. с тем же успехом можно мигрировать код с C++ на C#, например (я видел такие проекты),- в итоге получается совершенно неидиоматичный код, но сам процесс достаточно прямолинеен

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

усилия сопоставимы. с тем же успехом можно мигрировать код с C++ на C#, например

Нет. Си это ПРАКТИЧЕСКИ надмножество C++. Нужно будет просто подправить в некоторых местах некоторые шероховатости, и сишный код у тебя скомпилируется плюсовым компилятором.

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

Или сразу же Rust начинать?

fix.

А плюсовые потоки позволяют реализовывать вывод в поток собственного объекта.

Враньё. Не потоки, а твои ручные кастыли. Поток не может сам вывести даже голую структуру.

Тогда как с C-шными printf-ами такого уже не сделать.

Собственно как и крестовые. А написать кастыль - можно всегда.

char * __to_string(struct_t st) {
  static char buf[32];//конечно, тут надо сделать массив массива
  //и искать в рантайме свободный, но это такое. В крестах просто срётся всё дерьмо в хип.
  sprintf(buf, "{x: %u, y: %u}", st.x, st.y);
  return buf;
}
printf("%s", __to_string(my_struct)); //то же самое, что в  крестах

Можно сделать импрувнутый вариант для камекадзэ. Даже не поленился - гуглим/пишем разворачивалку __VA_ARGS__ + кладём чутка дерьма + 3минуты времени и вуаля - готово.

https://ideone.com/RlkPm2

Мне конечно лень это причёсывать и делать всё это нормально, но ничего сложного в том, чтобы допилить это до юзабельного состояния нет.

Было бы всё вообще идеально, если бы пацаны смогли сделать нормальный генерик, а не помойку.

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

s/надмножество/подмножество/

Дескриптор файла за память считаем?

Конечно считаем. Что-то я совсем забыл про остальные ресурсы.

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

Враньё. Не потоки, а твои ручные кастыли.

Какие ручные костыли? Ты пишешь реализацию вывода в поток какого-то типа в operator << и все ок. Си этого делать не позволяет.

В крестах просто срётся всё дерьмо в хип.

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

если бы пацаны смогли сделать нормальный генерик, а не помойку.

Вот тут согласен.

Разница только в том, что...

Ну так о чем спорить тогда? Типобезопасный ввод/вывод в Си практически невозможно сделать нормально. Но он особо и не нужен там.

Ты пишешь реализацию вывода в поток какого-то типа в operator << и все ок.

ну вот тебе написали вывод принтф с методом __to_string и все ок.

Как сделаешь, так и будет. По умолчанию - да, в хип.

а не по умолчанию, показывай пример.

типобезопасный ввод/вывод в Си практически невозможно сделать нормально.

то есть метод __to_string не типобезопасный? С чего бы? если у него есть конкретный тип? то есть перегрузка оператора << — типобезопасна, а метод __to_string не безопасен?

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

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

В том-то и суть, что даже при условии реализации костыля а-ля GObject об ООП в Хаскелле будет говорить несколько странно. Наконец-то ты понимаешь о чём я.

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

и по-прежнему будет кодом на C. потому что чтобы это был код на C++, тебе потребуется другая стандартная библиотека, классы как единица абстракции, исключения вместо кодов возрата, какие-то непонятные функторы вместо коллбеков, обобщённое программирование на шаблонах а не макросах, и ещё куча всего

то, что код у тебя скомпилировался, не делает его кодом на C++. я могу написать приложение на Tcl, а в коде на C++ создать интерпретатор и скормить ему Tcl-код строковым литералом. волшебство - минимум действий и код скомпилировался (и даже работает)! переписал я программу на C++? нет

Наконец-то ты понимаешь о чём я.

нет. ты как нёс ересь, так и несёшь ересь. ещё и не отвечаешь на вопросы. тебе их повторить?

и по-прежнему будет кодом на C. потому что чтобы это был код на C++, тебе потребуется другая стандартная библиотека, классы как единица абстракции ...

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

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

Делает

я могу написать приложение на Tcl, а в коде на C++ создать интерпретатор и скормить ему Tcl-код строковым литералом.

Нет, так не считается. Вот если ты Tcl откомпилируешь(оттранслируешь) в C++ код — другое дело

Давай я помогу пацану наказать тебя за балабольство.

Если код соответствует стандарту C++ и успешно компилируется плюсовым компилятором то это будет код на C++ независимо от того

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

Как любой дополнение не присваивает оригинал. Если ты спастишь текст авторства меня и дополнишь его своим - это не делает цитату, которая соответствует обоим цитатой твой - он в любом случае остаётся моей.

Давай попроще - есть чай, он состоит из воды и неведомой херни. Вода - есть и чай и вода, но вода не есть чай - вода есть вода, даже если из неё состоит раствор «чай». И так со всем.

Тем более кресты основаны на конкретном, кастрированном стандарте си, который является основой для более новых стандартов си. Точно так же, как и код на с89 не является кодом на с99 и с11 - он является кодом на си89, который является частью с99/с11.

Код на си даже не сконпелируется на крестовом конпеляторе, если специально не писать на С/С++, а С/С++ не си. В любой сишном коде есть маллок и он не работает в крестах в сишном стиле, даже этой причины достаточно для их несовместимости.

и по-прежнему будет кодом на C.

И кодом на C++.

потому что чтобы это был код на C++, тебе потребуется другая стандартная библиотека, классы как единица абстракции, исключения вместо кодов возрата, какие-то непонятные функторы вместо коллбеков, обобщённое программирование на шаблонах а не макросах, и ещё куча всего

Это твои религиозные убеждения. Философия C++ на том и стоит, что тебе никто не навязывает ничего. Пиши так, как тебе нравится/как вы решили в проекте писать.

ну вот тебе написали вывод принтф с методом __to_string и все ок.

И что мне это дало? Мне нужно знать, что и кто использует. Нет единого подхода. А << в С++ - это стандарт.

а не по умолчанию, показывай пример.

Гугл в помощь. Читай про работу с памятью в потоках ввода/вывода в крестах. Не скажу, что это все красиво и удобно, но оно хотя бы есть.

И да, никто тебе не мешает делать руками как в Си, если в твоем проекте это целесообразно.

Гугл в помощь. Читай про работу с памятью в потоках ввода/вывода в крестах. Не скажу, что это все красиво и удобно

Ну как всегда, хочешь сделать в крестах по-людски, пиши уродливый кривой громоздкий код, да?

То есть там настолько сложно все, что ты даже пример не осилил.

Нет единого подхода. А << в С++

А в сишке printf(«%s») не стандарт? Ну если у тебя нет функции, преобразующей структуру в строку, ты не сможешь ее вызвать, да. А если у тебя в крестах << не перегружен, сможешь? Нет.

Ну как всегда, хочешь сделать в крестах по-людски, пиши уродливый кривой громоздкий код, да?

Да, но лучше, чем в Си.

А в сишке printf(«%s») не стандарт?

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

Да, но лучше, чем в Си.

Ну так покажи, как оно лучше-то? Даже интересно.

чёрт возьми, идеальное сравнение

что-то более дружелюбное: D, Rust

на этом дружелюбном уже можно окошко нарисовать, быстро, и так, чтоб глаза не вытекли?

А где можно, кроме делфи, шарпа и кутей?

если ты Tcl откомпилируешь(оттранслируешь) в C++ код — другое дело

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

Это твои религиозные убеждения

это вывод из опыта работы с кодом на C и C++, а не убеждения. сугубо прагматичные соображения, продиктованые практикой

Пиши так, как тебе нравится

работает для проекта из одного человека

как вы решили в проекте писать

работает для проприетарного проекта с фиксированной группой разработчиков

я ткнул тебя носом в циклы

Сам тут задвигаешь про идиоматичный код, и вдруг такая дешевая софистика с переходом на личности. Смотрю ты знатно ЧСВ прокачал за последние годы. Начальником что-ли стал? Жаль, читать тебя стало неприятно: снобизм и пустота в духе акадэмической илитки.

Жаль

счас расплачусь

Ну так покажи, как оно лучше-то? Даже интересно.

Так все уже показано.

это вывод из опыта работы с кодом на C и C++, а не убеждения. сугубо прагматичные соображения, продиктованые практикой

Нет, это религиозные убеждения.

работает для проекта из одного человека

Нет, это работает для проектов любых сложностей. Стандарты кодирования никогда не видел?

работает для проприетарного проекта с фиксированной группой разработчиков

Нет, это работает вне зависимости от открытости проекта.

-х годах.>Стоит ли в нынче щас учить язык Си?

Надеюсь мой ответ актуален, вопрос задан месяц назад?

Ты удивишся но на этот вопрос ответа нет.

Язык программирования это инструмент. Ответь себе на вопрос, зачем тебе вообще нужен такой инструмент как «язык программирования Си». На экосистеме Windows язык Си мёртв. Если твоя система Windows в сторону Си даже не смотри. На экосистеме Андроида такого языка как Си вообще нет. Единственное место где Си жив — это Linux и BSD-системы. В Линуксе Си занимает нишу системного языка. Хотя, тут я оговорюсь, Си считается языком общего назначения. Почему-то сейчас вспомнил слова своего преподователя: «освоишь Си сможешь сделать всё, что угодно».

Си и C++ — это РАЗНЫЕ языки. На двух зайцах ты никуда не уедешь. Выбирай, либо Си, либо C++. Те люди, которые говорят, что надо знать и то, и другое — самые настоящие мазохисты. Не слушай этих людей! Те люди, которые говорят, что C++ это надмножество языка Си, либо нагло врут, либо безнадёжно застряли в 1980-х годах. Не забывай на дворе 2016 год, на сегодня актуальный «стандарт» языка Си, это C11.

И ещё раз, прежде всего задай себе вопрос: «Зачем мне вообще нужен этот инструмент?»

Дурацкий какой-то вопрос!

Ты сначала С изучи, а потом уже думай, нужно ли тебе еще какое-нибудь убожество, или же божественного с головой хватит!

А плюсовые потоки позволяют реализовывать вывод в поток собственного объекта.

Ты повнимательней читай себя, а то какую-то охинею пишешь. Ничто не мешает сделать

int print_my_struct(FILE *stream, const struct my_struct *s);

Тогда как с C-шными printf-ами такого уже не сделать.

http://www.gnu.org/software/libc/manual/html_node/Customizing-Printf.html

Почему это уебище до сих пор не в бане?

Имхо, для C сейчас осталось три большие ниши

Есть еще четвертая: оградить кодовую базу от «современных C++ прогромиздов». Как говорит один уважаемый человек

Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

Сам-то ты ему в прыщи на жопе не годишься. Чего растявкался-то, ламерюшка?

отвратительная работа с памятью

Это у C-то отвратительная работа с памятью?! Нигде больше нет такой восхитительной работы с памятью, как C: нарезаешь и расфасовываешь как хочешь, без дебильных ограничений, привнесенных в язык во благо слабоумных олигофренов.

мигрировали

Ну вообще-то, целью миграции gcc на кресты была «более строгая проверка типов», а не «фабрики-синглтоны-исключения».

Ты повнимательней читай себя, а то какую-то охинею пишешь.

Ну ладно я не внимательно себя читаю. Но вы-то внимательно читаете надеюсь? Изобразите, плз, на чистом C вот эту конструкцию:

MyClass my_object;
YourClass your_object;
cout << "My object: " << my_object << ", your object: " << your_object << endl;

Как то, что вы предлагаете использовать в обобщенном коде?