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

Бери ассемблер.

Не создавать же новую тему, поэтому спрошу здесь.

Почему в учебниках по C++ часто обходят стороной вопрос форматированного вывода через cout? Им что, стыдно, что он выглядит более громоздко по сравнению с printf из C?

Так может говорить только то, кто не знает оба.

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

http://www.airs.com/blog/archives/370

In the GCC code base, one of the biggest issues was that enums are more restricted by the type system in C++ than they are in C. Another was that in C++ you may not use the same name as a typedef and a struct tag, except for the special case of making the struct tag be a typedef for the struct itself.

Gabriel Dos Reis did the first substantial work on moving the GCC code base to the common subset, and many other people contributed.

sh

Нельзя не знать Си, зная C++

Очень спорное утрверждение.

В чем же? Ну вот допустим я написал код на некоем подмножестве C которое будет успешно компилироваться C++ и Ansi C компилятором. Очевидно, что этот код будет и валиндым C++ и валидным C кодом. Если человек утверждает что он знает C++ то он должен уметь этот код читать и править его в этом стиле-подмножестве. Если он этого не умеет, очевидно что он не знает C++

Да просто cout о другом. Это о том что смотрите, ввод/вывод выглядит интуитивно понятным. А форматирование там интуитивно понятным не выглядит.

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

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

Я интересовался скорее в плане вывода численных значений. В cout частично можно отформатировать «текст» до вывода флагами. В fortan просто есть возможность задать формат(ы) вывода чисел заранее и просто указывать их как параметр при выводе, но текстовые «поля» всё равно придётся дописывать позже.

Флаги и манипуляторы cout действительно выглядят менее понятными, чем форматированный вывод в printf. Возможно поэтому, когда на 4-м курсе нам дополнительно напоминили про C++ (что рассказывалось на первом уже успешно было забыто за ненадобностью на протяжении двух лет), преподаватель намеренно использовал для вывода результатов в терминал/файл исключительно printf.

преподаватель намеренно использовал для вывода результатов в терминал/файл исключительно printf.

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

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

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

Возможно, и в силу привычки, но в данном случае это было действительно быстрее и удобнее. Насчёт нормальных не знаю, так как я не программист. Единственное, что удалось ещё найти из стороннего это Boost.Format.

но в данном случае это было действительно быстрее и удобнее.

Нет, это именно просто оттого что он знает, а кругозора в плюсовых библиотеках не имеет.

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

Единственное, что удалось ещё найти из стороннего это Boost.Format.

Ищите и обрящите: http://cppformat.github.io/latest/index.html ;)

Нет, это именно просто оттого что он знает, а кругозора в плюсовых библиотеках не имеет.

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

С-шный ввод-вывод и плюсовые потоки — это разного калибра инструменты. C-шный ввод-вывод удобен, если нужно пару int-ов в stdout вытолкнуть в шестнадцатиричном виде с лидирующими нулями. А плюсовые потоки позволяют реализовывать вывод в поток собственного объекта. Т.е. с помощью плюсовых потоков можно написать:

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

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

Я там ещё говорил что не знаю плюсов.

Вон ты сейчас же привел нормальную либу для форматирования. Именно об этом я и говорил.

Нет, это именно просто оттого что он знает, а кругозора в плюсовых библиотеках не имеет.

На тот момент (13 лет назад) может так и было, но всё равно используемый способ вывода был самым удобным. Хм, может он о чистом Си рассказывал? Не помню.

Тогда о многопоточности, там где нам это рассказывали не особо задумывались или только начинали смотреть в её сторону из-за начавшегося появления железок. Само собой, что использовалось то, что в данный момент удобнее и чего хватало. Человек писал код для себя, а студентов ему дали вести «добровольно-принудительный» факультатив, а то они вообще ничего не помнят (+ тогда компы не у всех были или только появились). Целью было не столько научить программировать, сколько напомнить базу. По крайней мере, было интереснее, чем рассказывали на первом курсе.

eao197, спасибо :)

Совет дайте?

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

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

- системное программирование (ядра Linux, FreeBSD, драйвера устройств, старые СУБД вроде PostgreSQL и вот это вот все);

- встраиваемое ПО;

- библиотеки, биндинги к которым будут реализованы для кучи других языков (вроде Python, Ruby, Erlang, OCaml, Haskell и т.д.). Сюда же относится и написание требовательных к производительности и потреблению ресурсов кусочков программ на высокоуровневых языках (т.е. была программа на Erlang-е, уткнулись где-то в тормоза Erlang-а, написали процедуру на C). Сюда же относится интеграция кода на высокоуровневых языках с какими-то низкоуровневыми возможностями конкретных платформ.

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

Очень спорное утрверждение.

Если ты не знаешь Си, то ты не знаешь C++.

C знать необходимо.

В современном мире - спорно. Сейчас довольно сильная специализация.

C++ можно уже не учить, лучше сразу двинуть в современном направлении (Python/Go/Rust/Swift).

С++ вполне современен. Python заменить C++ не может(но если что-то можно написать на питоне, то брать C++ для этой задачи не нужно). Go, кстати, тоже - он проигрывает C++ и по язковым возможностям и по скорости и по памяти). Rust - ок, но будущее туманно. Swift не так уж плох, да. Но apple.

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

И во всех трех сейчас применим C++.

И во всех трех сейчас применим C++.

Да, но C там очень много. И в ближайшее время принципиально ничего не изменится.

В ядре юзаются плюсы?

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

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

В ядре юзаются плюсы?

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

Почему весной не стоит?

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

Хорошо, забудь на секунду о циклах. Скажи, позволяет ли наличие Foreign.C говорить о поддержке указателей со стороны языка?

во-первых, ты подменил утверждение.

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

рекурсия в Haskell что, имеет особую поддержку со стороны синтаксиса?

Особую в сравнении с чем? Легко представить язык, в котором RHS не может ссылаться на LHS, и в этом случае рекурсия не будет возможна либо будет сильно затруднена.

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

Ты сегодня особенно агрессивен, мой лысеющий друг.

Но вот макросы вообще-то зря там.

В смысле, ты предпочёл чтобы их там не было? Почему?

И это касается и идущих из коробки вещей типа println? Или только определения своих макросов?

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

Спорность в том, что у людей движущихся в направлении C++ → C очень часто наблюдается дикая каша из конструкций обоих языков. Например винегрет из cout и printf (и этот пример не исчерпывающий). И хоть gcc это часто и прощает, это всё же разные языки.

В смысле, ты предпочёл чтобы их там не было? Почему?

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

И это касается и идущих из коробки вещей типа println? Или только определения своих макросов?

но сама возможность полезная и нужная.

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

Но в целом с макросами вполне можно примириться и даже считать их нужными.

Вот неявное копирование и Deref мне больше не нравятся.

C++ → C
Например винегрет из cout и printf (и этот пример не исчерпывающий).

По-моему что-то тут не так, может быть ты имел ввиду C → C++ ?

В чистом Си никакого cout нет и сделать там винегрет не выйдет никак

после C большинство других языков воспринимаются как надо без синдрома утёнка

Или просто синдром проявится в привычном тебе варианте?..

gcc я не зря упомянул. Он такой маразм прощает.

Или просто синдром проявится в привычном тебе варианте?..

Ты прав судя по Поиск в Vec<u8>/[u8]

А я о сишниках был лучшего мнения.

Нет, не выйдет никак собрать код с cin cout сишным компилятором. Уже хотя бы потому, что там нужно перегружать << >>

gcc я не зря упомянул. Он такой маразм прощает.

У тебя какой-то свой gcc

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

MY_OBJECT my_object;
YOUR_OBJECT your_object;
printf("My object: %s, your object: %s\n",
        my_object_to_string(&my_object),
        your_object_to_string(&your_object));

Ну и сразу пару вопросов:

* кто и когда будет освобождать память под строки, выделенную в my_object_to_string/your_object_to_string?

* если кто-то захочет использовать sprintf вместо printf, то как ему вычислить размер итогового буфера?

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

sprintf

То, наверное, ему нужно использовать принтф, не?

Ну т.е. код говно, но для LOR-а сойдет.

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

Так то не очень трудный язык этот ваш C++

Толстенько.

Надеюсь, в реальных проектах ты та не делаешь?=)

Как?

Стоит ли в наше время учить язык Си? Или сразу же C++ начинать?

Если ты точно хочешь в дальнейшем использовать С++, то можешь начинать сразу с него. В противном случае начни с Си, желательно с K&R.

Си тебе пригодится при работе с другими языками.

Если ты выбираешь между C и C++ для программирования, то бери C++.

Как?

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

Иначе можно сразу осваивать раст как замену сишечке и плюсов, я думаю

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

Хотя это вопрос решаемый, конечно.

Не инициализируешь переменные, не освобождаешь память

Нет

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

А как ты предлагаешь использовать форматированный вывод для произвольных структур?

Хотя это вопрос решаемый, конечно.

Книга в духе K&R решила бы вопрос, как мне кажется.

А как ты предлагаешь использовать форматированный вывод для произвольных структур?

В духе си - в зависимости от стоящей перед тобой задачи, сделать так, как будет наиболее эффективно, просто и полезно для проекта.

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

Возможно, да, просто привык видеть глибовские методы работы со строками. Странно, что в глиб/гтк и прочих подобных либах принято просто возвращать null-terminated string в куче или NULL как признак ошибки, чем это обусловлено?

Кресты на мороз. А ещё лучше и С на мороз. Учи сразу Rust или Go.

О, ещё один IT-хипстор.

которым через указатели или ссылки передается право владения памятью

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

Почему нельзя их реализовать внешними средствами.

Потому что это менее удобно? Да и в чём разница, если это «стороннее средство» шло бы из коробки? Я бы наоборот предпочёл интегрировать макросы в язык получше, возможно, так они менее инородными выглядели бы.

Вот неявное копирование и Deref мне больше не нравятся.

Ты хотел явно копировать, скажем, один инт в другой? И как это выглядело бы?

А дерефом можно как-то в ногу выстрелить или просто неявность смущает?

А давай я напишу функцию elephant, и что тогда? Согласишься ли ты тогда с тем, что в синтаксисе Haskell есть слоны

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