C++ для Си-программиста

фанаты раста не осилили сделать нормальный дизайн

О кстати... расскажи нам об ошибках в дизайне Redox.

Человек написал, что пишет под микроконтроллеры, а Rust для них ещё не готов к сожалению.

Потоки (cin/cout/cerr/clog). - после этого прекращаешь использовать printf, scanf, ...

Религиозный фанатизм.

Желание писать безопасный код.

std::string - после этого прекращаешь ... бояться переполнений, и т. п.

std::string string;
string[-1] = '\0';

Если есть желание выстрелить себе в ногу, то С++ это позволит делать. Но может и защитить, если вы попросите.

Читаем http://www.cplusplus.com/reference/string/string/operator[] (скопируйте текст, а то движок LOR'а неправильно её определяет), раздел Exception safety до полного просветления. Желание вывалить сюда полный список undefined behaviour подавляем на корню. А потом пишем безопасный код:

std::string string;
string.at(-1) = '\0';

http://www.cplusplus.com/reference/string/string/operator[] (скопируйте текст, а то движок LOR'а неправильно её определяет)

http://www.cplusplus.com/reference/string/string/operator[]/

Какой это нахрен C++, если на каждом шагу mutex_acquire/mutex_lock

Если этот код нельзя собрать компилятором С, но можно компилятором С++, то это код на С++.

И тут я такой с неоспоримым аргументом: игры. Да, те самые ААА, на которых зарабатывают миллиарды, пишут почти исключительно на плюсах. Или два вас С++, используемый в игровых движках, опять не С++?

Ну и на засыпку: любой прикладной софт сложнее блокнота. Хотя и они на плюсах.

Будьте добры, аналог

Который бы заставлял помнить все эти %s/d/f-3?

Который при ошибке в букве или типе аргумента выдаст белиберду, и девелопер об этом даже не узнает?

Который при аргументах сложнее базовых типов превращается в нечитабельного монстра?

Который может завершиться ошибкой, но большинство об этом даже не задумывается?

А если серьезно, ты привел, один из двух примеров, когда printf имеет хоть какие-то преимущества. И то, если нормально написать (по одной переменной на строку), то код будет даже читабельней.

Человеку, который начинает изучать C++, я не рекомендую пользоваться printf, хотябы для того, чтобы «набить руку» с потоками. Когда освоится с iostream, пускай выбирает для каждого конкретного случая подходящий инструмент. Статей 'printf vs cout' в и-нете уйма.

Как ты это сделал?

Который при ошибке в букве или типе аргумента выдаст белиберду, и девелопер об этом даже не узнает?

Уже лет 15-20 компиляторы Си проверяют типы аргументов по форматной строке.

А если серьезно, ты привел, один из двух примеров, когда printf имеет хоть какие-то преимущества. И то, если нормально написать (по одной переменной на строку), то код будет даже читабельней.

Не будет. А судя по D, Rust и Go, iostreams вообще никто не любит. Да, да, спасибо, что написал про миллионы мух.

А судя по D, Rust и Go, iostreams вообще никто не любит.

Поэтому для C++ уже давно есть разные type-safe альтернативы и printf-у и iostreams. Начиная от boost.format и заканчивая fmtlib. Последняя, кстати говоря, требует наличия у пользовательских типов оператора сдвига в ostream. Так что с iostreams в C++ все не так однозначно плохо, как здесь любят рассказывать.

fmtlib. Последняя, кстати говоря, требует наличия у пользовательских типов оператора сдвига в ostream

Потому что обычно у пользовательских типов есть операция вывода в ostream (по очевидным причинам).

с iostreams в C++ все не так однозначно плохо, как здесь любят рассказывать.

Насколько я понял, вопрос был в том, что удобнее. Ответ вполне однозначен - форматная строка.

Насколько я понял, вопрос был в том, что удобнее. Ответ вполне однозначен - форматная строка.

Берем чуток другие условия:

template<typename A, typename B>
void print(const A & a, const B & b) {
  std::cout << "[" << a << "," << b << "]" << std::endl;
}

пытаемся реализовать эту шаблонную функцию через printf

Форматная строка - это не обязательно printf.

Хваленое удобство форматной строки проявляется, естественно, только в тех случаях, когда есть возможность автоматически вызвать преобразование объекта в строку. В современных языках эта возможность есть, в fmtlib тоже. Мы же о современной ситуации говорим?

println!("[{},{}]", a, b);

?

eao197
Сынок

Чувак, ты в полного неадеквата превратился

Боженьки ты мой, а это что, доча? Ну тогда тысяча извинений.

Я дал тебе ссылку на Си++ в ядре

Ну вот тебе ссылка на C# в ядре: http://singularity.codeplex.com/SourceControl/latest#base/Kernel/Singularity/...

И где это ядро?

Кстати, если ты забыл: GCC тоже написан на Си++ :D

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

Если этот код нельзя собрать компилятором С

define «компилятор C». А то, знаешь ли, если gcc натравить, отлично соберется.

Ну вот тебе ссылка на C# в ядре: http://singularity.codeplex.com/SourceControl/latest#base/Kernel/Singularity/...

Что именно ты хотел доказать этим баяном?

низкоуровневое системное программирование

Не видел его там ни разу, что вообще-то неудивительно, потому что пока низкоуровневые API обернешь в нормальные плюсовые обертки, чтобы RAII и прочие плюшки, на C уже проект закончить успеешь. Да и низкоуровневые трюки на сишке, как ни странно на порядки проще проворачиваются. За примерами далеко ходить не надо: представь, каково было бы подсовывать подмену системным функциям из libc, используй она плюсовый ABI.

высокоуровневое системное программирование

Не вполне понимаю, что бы это значило. Наверное, речь идет о чем-то вроде mc. Ну поскольку весб лоулевел уже на сишке, а пока нарисуешь «c++-way wrappers» — словом, выше по тексту. Очень мало плюсовых приложений в этой нише. На ум сходу разве что aria2c приходит из того, чем пользуюсь.

встроенные системы

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

численные и научные расчеты

Внезапно, тут всех победили Python и R: если фундамент написан на чем-то быстром (превед, сишечка!), то какая разница, что за клей посередине. Вроде бы видел либы для R на плюсах, да и opencv с dlib-ом не на голой сишке писаны. Будем считать «ограниченно годен».

общее прикладное программирование

Я как-то приводил пример, что из запущенного прикладного ПО у меня с libstdc++ слинкован только FF.

По поводу использования C++ в разработке ОС
reddit
windows 10

Как говорится, «на заборе тоже написано». И опять-таки, все, что было сделано в плюсах выше 2003-го стандарта для разработчиков ПО — по сути сглаживание STL-ных костылей.

Как разработчику прикладухи мне совершенно фиолетово на variadic templates, lambdas и прочий мусор, а уж заставлять меня различать move от copy semantics — ей богу, последнее свинство. Пока я напишу пяток операторов копирования/ввода/вывода/сравнения на все случаи жизни, конкуренты уже выкатят готовый продукт на дотнете.

Что именно ты хотел доказать этим баяном?

Что в пурпурном ядре вполне может быть C++, раз уж в сингулярное дотнеты затащили. Только где эти ядра? (hint: а нигде!)

Что именно ты хотел доказать этим баяном?

Что в пурпурном ядре вполне может быть C++

Этот факт доказал кто-то другой - ссылкой на исходники Fuchsia, которую я запостил повторно.

Только где эти ядра? (hint: а нигде!)

Это всё, что ты можешь возразить? Ну вот тебе еще ядерного кода: https://opensource.apple.com/source/IOATAFamily/IOATAFamily-253.0.1/IOATAComm...

Твой ход.

Который бы заставлял помнить все эти %s/d/f-3?

Намного легче, чем бред сивой кобыли из iomanip

Который при ошибке в букве или типе аргумента выдаст белиберду, и девелопер об этом даже не узнает?

Ну кто же виноват, что ты без -Wall собираешь? Вон в седьмом gcc до чего дошли: https://gcc.gnu.org/gcc-7/changes.html

Warnings about format strings now underline the pertinent part of the string, and can offer suggested fixes. In some cases, the pertinent argument is underlined.

    test.c:51:29: warning: format '%s' expects argument of type 'char *', but argument 3 has type 'int' [-Wformat=]
       printf ("foo: %d  bar: %s baz: %d", 100, i + j, 102);
                             ~^                ~~~~~
                             %d

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

if (vector_container.begin() != vector_container.end) // 194 строки ругани от g++-4.9, 240 от g++-6.2

Да, раз пошла такая пьянка, что такое std::endl (тип, статическая переменная, функция) и почему рекомендуют избегать его необдуманного использования для вывода перевода строки? Кстати, в сишечке просто лепишь «\n» и не думаешь ни о чем в 99% случаев

Fuchsia

Давай ты не будешь тянуть хипстоту сюда. Виртуальные машины, знаешь ли, аж на жабоскрипте пишут. Да, можно, вот только зачем? Ровно как и на кой черт сдался C++ в ядре, если там ни исключения кинуть, ни «богатым функционалом STL и еще 1001 кривой крестолибы» не воспользоваться?

Ну вот тебе еще ядерного кода

Матерь божья! zeroCommand на сишке состоял бы из одного memset, потому что язык дает кое-какие гарантии. Однако в плюсах не POD-тип приходится занулять поэлементно. Просто праздник для тех, кому платят «за количество строк кода». Затем идет портянка из гетторов/сеттеров (в ведре! не инлайнами!). Кучка переопределяемых макросов «super» (10 из 10, господи! лучше только #define true 0 #define false 1). Ну а в конце строчек 20 полезного кода, котрый хоть что-то делает.

Очередное подтверждение знаменитому

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.

ваш Си++ не Си++!!11 Ваши ядра не ядра!!!11

Лан.

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

Да ладно. Нормальным инструментом *так* сделать просто невозможно.

Ты бы выбрал в качестве инструмента молоток, у которого из ручки гвозди торчат?

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

Дерьма в современном C++ очень много и с каждым стандартом становится все больше.

Речь о том, что на выходе получается, а не о том, что там в стандарте языка.

Языки выбирают по «батарейкам» в комплекте и стоимости поддержки.

Драйвера на чём писать будешь? Или видеокодеки? Ява/дотнет?

сокеты, потоки, процессы — часть стандартной библиотеки.

Ты идиот? Прицепи стороннюю библиотеку какую хочешь, нахрена это всё именно в стандарте?

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

А вот сокеты не нужны, согласен. Хорошо, что их не приняли. Плохо, что приняли ФС.

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

В контексте разговора «С-шный printf удобнее C++ных iostreams» форматная строка — это именно форматная строка printf.

И? Где здесь C-шная форматная строка? Точно так же и на C++написать можно:

fmt::print("[{},{}]\n", a, b);

Положа руку на сердце, C++ не может похвастаться каким-то преимуществами ни в одной области

Любая прикладуха. Почти всё, что сейчас запущенно у меня - на с/с++ написано. На явах всяких - тормозное говно, с двумя модными фреймворками и тремя уровнями абстракций, которое сжирает тонны памяти. Если на десктопе всё будет на яве/дотнете, то никакой памяти не хватит с этим работать.

Не видел его там ни разу

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

Вы хотели перечня ниш — вам их дали. То, что вас не устраивает увиденное — это ваши личные проблемы.

Игровые движки и графен (я сам хз, просто предположил/обозначил)?

А вообще, зачем вам C++ ?

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

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

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

Короче, сумма всех этих пунктов и заставляет меня посмотреть в сторону плюсов.

Ну ТС знает Си, то есть какое-то подмножество C++ он знает, а это значит, что он не попадает в категорию «не знающих c++ вообще» =) А так да, Мейерса ещё правильного выбрать надо, а то прочитает про синглтон Мейерса и так и не узнает, что в C++11 он уже неактуален.

Который бы заставлял помнить все эти %s/d/f-3?

Намного легче, чем бред сивой кобыли из iomanip

То есть по-твоему setw, setprecision, left/right менее понятны чем %-6.2f ? Громоздко - еще соглашусь. Но по читабельности...

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

Где?

$ clang++ test.cpp
test.cpp:21:45: error: reference to non-static member function must be called;
      did you mean to call it with no arguments?
        if (vec_container.begin() != vec_container.end) {};
                                     ~~~~~~~~~~~~~~^~~
                                                      ()
/usr/lib/gcc/i686-pc-linux-gnu/4.9.3/include/g++-v4/bits/stl_vector.h:565:7: note:
      possible target for call
      end() _GLIBCXX_NOEXCEPT
      ^
/usr/lib/gcc/i686-pc-linux-gnu/4.9.3/include/g++-v4/bits/stl_vector.h:574:7: note:
      possible target for call
      end() const _GLIBCXX_NOEXCEPT
      ^
1 error generated.

Да, раз пошла такая пьянка, что такое std::endl (тип, статическая переменная, функция) и почему рекомендуют избегать его необдуманного использования для вывода перевода строки?

Избегать???
А ну-ну, раскрой миру правду. Поведай, что же такого страшного в endl, то должно призвать всех срочно отказать от него?

Где?

Я же писал: в gcc. clang я рассматриваю исключительно в виде плагинов на основе libclang, поскольку на моей практике у него огромные проблемы с генерацией отладочной информации.

P. S. И конечно же это проблема языка. а не компилятора, да...

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

Поведай, что же такого страшного в endl

Забавно, крестолюбы не знают детали реализации своей же стандартной библиотеки. std::endl производит обязательный сброс буферов, что ведет к серьезному снижению производительности в некоторых случаях.

что плохого в том, чтоб писать на С++ как на С с классами?

помоему это как раз разумно: использовать возможности там где это необходимо, и не херачить везде шаблонами.

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

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

Забавно, крестолюбы не знают детали реализации своей же стандартной библиотеки. std::endl производит обязательный сброс буферов, что ведет к серьезному снижению производительности в некоторых случаях.

Да тебе маркетологом быть.

Кейсов, когда это реально импактит производительность программы 0.01%, а то и ниже.

И ты забыл упомянуть про бенефиты такого endl: нормальная работа с логами, пайпами, выводом из нескольких тредов.

Так что, поверь, крестолюбы не знают детали реализации своей же стандартной библиотеки. И предпочитают не чинить то, что не поломано.

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

На сишку посмотри. 100% обратная совместимость.

И ты забыл упомянуть про бенефиты такого endl: нормальная работа с логами, пайпами, выводом из нескольких тредов.

Ну-ка давай поподробнее про «вывод из нескольких тредов». Люблю, знаешь ли, крестоанекдоты поутру.

На сишку посмотри. 100% обратная совместимость.

И 1% развития.
И, кстати, не 100% - как минимум дропнули gets.

Ну-ка давай поподробнее про «вывод из нескольких тредов». Люблю, знаешь ли, крестоанекдоты поутру.

http://softwareengineering.stackexchange.com/questions/185064/using-a-stream-...

http://softwareengineering.stackexchange.com/questions/185064/using-a-stream-...

И где же там про многопоточный вывод в std::cout?

И 1% развития.

Атомики, потоки, generic-и (не нужны, кстати). Все остальное в POSIX.

Я как-то приводил пример, что из запущенного прикладного ПО у меня с libstdc++ слинкован только FF.

С каких пор вы стали пупом земли? Ах да...

о господи, «std::endl производит обязательный сброс буферов»...

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

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

Ай-ай-ай, а для вывода в файл, стало быть, уже не годится?

а что, там какие-то проблемы?

смешные вы все, ей богу. кривизну своих рук приписываете С++су.

define «компилятор C».

Компилятор языка программирования C.

А то, знаешь ли, если gcc натравить, отлично соберется.

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

Даю маячок, «GCC - GNU Compiler Collection».

Поведай, что же такого страшного в endl

Полагаю, он расстроился, что std::endl вызывает сброс буфера.