Комитет ISO по стандартизации языка C++ единогласно утвердил (https://herbsutter.com/2017/09/06/c17-is-formally-approved/) спецификацию C++1z в качестве международного стандарта "C++17". Представленные в спецификации возможности уже полностью поддерживаются (http://en.cppreference.com/w/cpp/compiler_support) в компиляторах GCC (https://gcc.gnu.org/projects/cxx-status.html#cxx1z) и Clang (http://clang.llvm.org/cxx_status.html#cxx17), а также частично реализованы в Intel C++ (https://software.intel.com/en-us/articles/c17-features-suppo... и Visual C++ (https://blogs.msdn.microsoft.com/vcblog/2017/08/11/c17-featu.... Поддерживающие C++17 стандартные библиотеки реализованы в рамках проекта Boost (http://www.boost.org/).
В следующие два месяца утверждённая спецификация будет находиться на стадии подготовки документа к публикации, на которой будет проведена работа по редакторской правке орфографических ошибок и опечаток. В начале ноября результирующий вариант документа будет направлен в ISO для публикации под формальным именем ISO/IEC 14882:2017. Тем временем, комитет уже начал работу над следующим стандартом C++20 (C++2a) и рассмотрел на последнем совещании возможные новшества (http://en.cppreference.com/w/cpp/compiler_support#C.2B.2B2a_....
Основные (http://en.cppreference.com/w/cpp/compiler_support) особенности (https://en.wikipedia.org/wiki/C%2B%2B17#New_features) C++17:- Возможность инициализации переменных внутри выражений if и switch;
- Возможность использования кодировки UTF-8 в символьных литералах;
- Шестнадцатеричные литералы с плавающей запятой;
- Указание текстового сообщения в static_assert теперь опционально;
- Удалена поддержка триграфов (https://ru.wikipedia.org/wiki/%D0%A2%D1%...
- Возможность указания typename (как альтернативы классам) в параметрах вложенного шаблона;
- Новые правила вывода типа "auto" из списка инициализации (braced-init-list)- Возможность упрощённого определения вложенных параметров пространств имён: "namespace X::Y {...}" вместо "namespace X { namespace Y {...}}";
- Возможность указания атрибутов для пространств имён и перечислений;
- Новые стандартные атрибуты [[fallthrough]], [[maybe_unused]] и [[nodiscard]];
- Проверка на неизменность (константность) для всех нетипизированных аргументов шаблонов;
- Сворачивание выражений для вариативных шаблонов;- Раскрытие выражений "if" на стадии компиляции, если заданное внутри условие является константой;
- Структурированные привязки, например, "auto [a, b] = getTwoReturnValues()";
- Автоматическое определение типов конструктора шаблонов
(например, теперь можно указывать std::pair(5.0, false), явно не задавая типы "double, bool");- Inline-переменные, которые можно определять в заголовочных файлах;
- Добавлена библиотека для работы с ФС, основанная на boost::filesystem;
- Из библиотеки TS I перенесены std::string_view, std::optional и std::any;
- Добавлен std::uncaught_exceptions в качестве замены std::uncaught_exception;
- Новые функции вставки try_emplace и insert_or_assign для std::map и std::unordered_map;
- Унифицирован доступ к контейнерам std::size, std::empty и std::data;- Определены непрерывные итераторы (contiguous iterators);
- Удалены устаревшие типы и функции, в том числе std::auto_ptr, std::random_shuffle;
- Представлены параллельно выполняемые варианты алгоритмов STL;
- Добавлены дополнительные математические функции, включая эллиптические интегралы и функции Бесселя;- Представлены std::variant и std::byte;
- Новые свойства логического оператора: std::conjunction, std::disjunction и std::negation.URL: https://herbsutter.com/2017/09/06/c17-is-formally-approved/
Новость: http://www.opennet.me/opennews/art.shtml?num=47153
Ну, ожидаемо, конечно, но всё равно радует.
Радует все кроме этого:
"Добавлены дополнительные математические функции, включая эллиптические интегралы и функции Бесселя"Зачем это было пихать в стандарт? Сторонних библиотек для этого разве не достаточно?
Какое отношение это вообще имеет к C++?
Геймдев? Сейчас это чуть ли не основная сфера использования cpp.
Научные вычисления. Чем Вам оно мешает?
Геймдев, научные вычисления - конечно не мешает!Давайте уж тогда сразу в стандарт С++ засунем любые научные теории, в реализациях которых C++ когда-либо засветился. Алгоритмы анализа цепочек ДНК, например, наверняка С++ там активно используется.
И вообще, библиотеки не станут нужны, если в стандарте будет все, что "не мешает".
Что за юношеский максимализм? Или всё или ничего? Математические функции - вполне себе фундаментальная вешь
Nope.
> Что за юношеский максимализм? Или всё или ничего? Математические функции - вполне себе фундаментальная вешьКакие именно математические функции? Их так же много, как и программного кода.
Не было сказано против математических функций вообще. И ни разу "все или ничего".
Про конкретныеВ наше время фундаментальной математикой как раз и являются лямбды, комбинаторы, категории. Что как раз и реализовано в стандарте С++ фактически уже на уровне даже синтаксиса, не только библиотечном.
Если вы этого не заметили, не удивительно, что вам это кажется "юношеским". Потому вам те "функции", о которых идет речь и кажутся "фундаментальными", что вы просто не знаете фундамента математики. Популярные прикладные теории - это не то же самое, что фундамент.
> Что за юношеский максимализм? Или всё или ничего? Математические функции - вполне
> себе фундаментальная вешьНахрен они не нужны в стандартной библиотеке. Но, объективности ради, их наличие не мешает ими не пользоваться. Что тоже важно.
Мне кажется вы не понимаете что означает добавление в стандарт С++ каких-либо новых функций. Это совершенно не означает, что они будут по-умолчанию вам доступны без подключения дополнительных библиотек. Просто компиляторы должны будут предоставлять вам стандартные библиотеки с реализациями этих функций. Так, например, для использования sin вам понадобится подключить стандартную библиотеку math. То же самое верно и для этих новых функций. В стандарт же попадает то, что повсеместно используется. Если алгоритмы анализа цепочек ДНК будут повсеместно использоваться, то их тоже можно будет стандартизировать и предоставлять в форме стандартной библиотеки, а вот подключать эту библиотеку к своему коду или нет решать уже вам.
Это понятно, что вы один из тех, кто уверен, что в стандарты языков нужно включать библиотеки на основании статистики использования. А не по назначению, идеологии и области применения самого языка. Подчеркиваю, области применения языка, а не библиотек на нем написанных.Вашим первым языком случайно был не PHP?
И что мешает для "повсеместно используемого" продолжать развивать "повсеместно используемые" библиотеки с их собственными внутренними стандартами. Только эмоции мешают!
Спор ни о чём.Есть разные стратегии развития ЯП.
Можно включать в ЯП все новинки, отказываясь от неудачных в будущих версиях. В этом случае теряется обратная совместимость.
Можно включать в ЯП только то, что стало де-факто стандартом в программировании и "отлажено" на других ЯП. В этом случае ЯП всегда в роли отстающего.
Можно вводить функционал сначала как бета-версию стандарта (типа -moz- и -web-kit-). Но велик риск, что временное с годами станет постоянным.
Можно не включать в ЯП функционал, который можно запрограммировать средствами самого ЯП и т.о. вынести во внешнюю библиотеку.
Поэтому, может, лучше вместо обсуждения деталей обсудите свой взгляд на стратегию развития?
Если вас раздражает чужое мнение, и вы не любите когда вам возражают, это никак не значит, что спор был "ни о чем".Вы где-то прочитали о стратегиях развития ЯП, теперь вам осталось только понять, чем обусловлена стратегия развития каждого конкретного языка.
О том и речь, что добавлением этого функционала из области прикладной математики, снова пытаются сломать стратегию развития С++, которая предполагалась изначально, которую сильно поломали в конце 90х - начале 2000х. С трудом вернули в С++11, и теперь снова пытаются сломать.
Речь как раз и шла о конкретной "стратегии развития" конкретного языка С++.
А вам кажется, что раз есть другие "стратегии" других языков, то давайте притащим их в С++, ведь "можно" же.
Вы даже четыре предложения начали со слова "Можно". Конечно Можно!
Можно изучать "стратегии развития" ЯП, а сами ЯП не учить тоже Можно!
Стратегию определяю члены комитета. Отсюда импотенция развития С++ в последние годы. Он словно замер между надстройкой над асмом с классами и макросами и ЯП со сборщиками мусора.Лично мне безразлично куда он пойдёт, imo будущее не за ним, а за web-технологиями и предметно-ориентированными скриптовыми ЯП в сложном ПО (Excel/Calc, VBA, 1С).
> Стратегию определяю члены комитета.Здесь согласен, всякие там "комитеты" - большая опасность для развития.
Только кто тут, выше в обсуждениях, "голосует" за "повсеместно используемое"? Не те ли, кто как раз и привык что за них думают разные "комитеты".Только вам видимо не известно, что отдельные сильные и талантливые личности все таки бывают способны прижать к ногтю целый "комитет". Что собственно, и можно было наблюдать, к счастью, в С++11.
К несчастью, "комитеты" просто так тоже не сдаются.
> Отсюда импотенция развития С++ в последние годы. Он словно замер между надстройкой над асмом с классами и макросами и ЯП со сборщиками мусора.
Понятно, все что было до этого в С++, и то что было внесено в С++11, лично вам кажется "надстройкой над асмом с классами".
То есть это не вы в вашем понимании программирования "застряли", а конечно же сам С++ "застрял" в вашем понимании.> Лично мне безразлично куда он пойдёт, imo будущее не за ним,
Лично за себя вы сказали.
> а за web-технологиями и предметно-ориентированными скриптовыми ЯП в сложном ПО (Excel/Calc, VBA, 1С).
Вам осталось только разобраться на чем написано это "настоящее", которое вам все еще кажется "будущим".
Я лично помню (такой вот я не "будущий"), как в конце 90х представители толпы кричали, что будущее за Windows, а UNIX - это якобы прошлое.
> Мне кажется вы не понимаете что означает добавление в стандарт С++ каких-либо
> новых функций.деби л как он есть.
> Мне кажется вы не понимаете что означает добавление в стандарт С++ каких-либо
> новых функций. Это совершенно не означает, что они будут по-умолчанию вам
> доступны без подключения дополнительных библиотек. Просто компиляторы должны будут предоставлять
> вам стандартные библиотеки с реализациями этих функций. Так, например, для использования
> sin вам понадобится подключить стандартную библиотеку math. То же самое верно
> и для этих новых функций. В стандарт же попадает то, что
> повсеместно используется. Если алгоритмы анализа цепочек ДНК будут повсеместно использоваться,
> то их тоже можно будет стандартизировать и предоставлять в форме стандартной
> библиотеки, а вот подключать эту библиотеку к своему коду или нет
> решать уже вам.Драйвер базы Oracle 10g тоже нужен в стандартной библиотеке C++20!
Вообще в роадмапе C++ есть UI и Networking
Давайте!
Эллиптические интегралы и функции Бесселя в мат. моделировании физических процессов, они в этой области не менее важны, чем синусы и косинусы. Они и правда базовые, но не для школьников, конечно.
Тут надо сказать, что тот же Майкрософт уже лет 15 назад точно ввёл функции Бесселя в свою стандартную библиотеку для С/С++. Почему? Во многом потому, что С++ изначально задумывался как язык для математического моделирования, потому что на Фортране много делать было не удобно. Введение этих функций в стандарт - это уже давно назревшая необходимость.
https://stackoverflow.com/search?q=bessel+c%2B%2B112 запросов за всё время существования стаковерфлоу - "давно назревшая необходимость"?
давайте без "боги праграмиравания не четают стаковерфлоу", где это вдруг давно назрело?
>давайте без "боги праграмиравания не четают стаковерфлоу"А зачем инженерам, пишущим числодробилки, читать сайт для погромистов?
Чтобы типичного для числодробильных инженеров уж совершенно ахтунга было поменьше.
Потому что они обычно ... как бы это сказать ... ну не программисты они!По томику - я тоже считаю это клупостью. Или давайте rot13() в стандарт! А чо - необходимость давно назрела :)
> Эллиптические интегралы и функции Бесселя в мат. моделировании физических процессов, они в этой области не менее важны, чем синусы и косинусы.Не менее важны для кого и для чего?
А, ну да, вы же написали - "в мат. моделировании физических процессов".> Они и правда базовые, но не для школьников, конечно.
Базовые для какой области?
(Про фундамент математики уже было написано выше, однако, понятно, что вы - писатель, а не читатель.)А уж если "не для школьников", то конечно это надо в стандарт С++!
> Тут надо сказать, что тот же Майкрософт уже лет 15 назад точно ввёл функции Бесселя в свою стандартную библиотеку для С/С++.
> Почему?Потому что это Майкрософт! )))
Помнится, Майкрософт однажды "ввел" код MS Office в код ядра MS Windows. Почему?> Во многом потому, что С++ изначально задумывался как язык для математического моделирования,
Прямо вот так! Именно для _моделирования_!
Это кто вам сказал? Представитель в "комитете" (см. выше) профсоюза преподавателей мат-моделирования.Это понятно, что представители физ-мата дальше "моделирования" в области ИТ не продвинулись.
> потому что на Фортране много делать было не удобно. Введение этих
> функций в стандарт - это уже давно назревшая необходимость.Ну конечно, если в самом Фортране что-то неудобно, то это нужно непременно внести именно в стандарт С++!
> Базовые для какой области?Ля... ну напиши быструю сортировку на своём ковносайте с использованием ф-ции Бесселя.
И оно будет в 100500 раз быстрее.Но не напишешь же, потому что умственный дayн. Кроме копипасты с гитхаба не продвинулся.
То есть вы утверждаете, что они "базовые" для области "напиши быструю сортировку на своём ковносайте", и "оно будет в 100500 раз быстрее".Ну, допустим (только допустим), что вы правы даже если это все, что вы знаете про алгоритмы и библиотеки.
А теперь перечитайте дискуссию сначала, и попытайтесь объяснить, за что (или против чего) именно вы выступаете.
По некоторым пунктам не хватает примеров кода.А так проздравляю всех плюсовиков.
По каким?
https://github.com/AnthonyCalandra/modern-cpp-features?utm_c...
В студии std::byte конфликтует с винапишным байтом, для тех, кто "using namespace std" это может быть проблемой
студия для олигофренов, она то c++14 всё ещё нормально не умеет
Что еще смешнее, там даже C99 до сих пор не полный. EpicFail Studio.
Бось, что большинство c++ разработчиков по твоему мнению будут умственно отсталыми, ибо они еще не перешли на c++14/c++17
Я вот как раз занимаюсь умственно отсталой деятельностью - пишу проект на c++11.
Правда в Netbeans, и вот его парсер подсветки даже простой c++11 часто не может :(
Qt creator и Kdevelop нормально работают с с++11 с++14. Там используется для парсинга clang.
Ну мне например NetBeans удобнее показался в работе
NetBeans классный, но у него уклон в веб-стек. Все кроме Java/HTML/CSS/js уже много лет не развивается.Формально языки поддерживаются, плагины остались, но развития нет и скорее всего не будет.
Котлин и не собираются добавлять, хотя бы поверхностно, комиллировать гибридные проекты.
Scala тоже мимо.А ведь это Java World - основной конек Оракла...
Поддержку Python похоронили годы назад.
С++ просто оставили как есть.
Плагин для Kotlin в Netbeans 8.2 есть. Как раз недавно завезли.
QtCreator и без Шланга нормально синтксис C++11, C++14 подсвечивает.
Не путай поддержку стандартов компилятором и реальное использование фич стандарта в коде. Частенько возникает потребность собрать новый код умеренно старым компилятором, а выясняется, что он стандартов пятилетней давности не знает. В инструментарии все новшества должны появляться как можно скорее, а вот программистам можно и обождать тащить их в свои проекты.
> Бось, что большинство c++ разработчиковИз твоего круга общения? И только те, которые на венде?
Нет не из моего.
Ничего не поделаешь - ынтерапайз во все дыры.
А студенты хелло вордщики могут и на драфтовых стандартах писать - есть такое.
Студия глючновата и медленна, не до конца поддерживает стандарты, но с решарпером для C++ и с PVS Studio показывает что не так с кодом задолго до компиляции. Это время на разработку на порядок сокращает. Если вы знаете что-либо подобное ещё, то поделитесь. У неё нет сейчас альтернатив.
> Студия глючновата и медленна, не до конца поддерживает стандарты, но с решарпером
> для C++ и с PVS Studio показывает что не так с
> кодом задолго до компиляции. Это время на разработку на порядок сокращает.
> Если вы знаете что-либо подобное ещё, то поделитесь. У неё нет
> сейчас альтернатив.Какие проблемы прогнать код и через VS-PVC тоже?
Это же не значит что надо разрабатывать под VS и терпеть ее.Можно почитать статьи PVC, с какими проблемами они стокнулись, упершись в архитектурные ограничения VS и какие костыли изобретали, чтобы не тормозило, вынести в другой процесс (памяти под VS не выделить) и т.д.
вы с виндовыми примочками - идите быстро, и подальше… microsoft всегда впереди паровоза бежала с очередным га%ном… А потом изобретала костыли совместимости….
>>В студии std::byte конфликтует с винапишным байтом, для тех, кто "using namespace std" это может быть проблемойtypedef unsigned char BYTE;
"BYTE" != "byte"
Каким образом, если в WinAPI BYTE (верхним регистром)?
> Каким образом, если в WinAPI BYTE (верхним регистром)?Очень удобно читать такой код. /s
Что только не придумывают, лишь бы на Rust не переходить.
> Что только не придумывают, лишь бы на Rust не переходить.ЯП с встроенным менеджером пакетов - это для хипстоватых поклонников карго-культа.
>> Что только не придумывают, лишь бы на Rust не переходить.
> ЯП с встроенным менеджером пакетов
> ЯП с встроеннымЧто только за ценное мнение не заимеют, лишь бы в теме ни зуб ногой.
Ну вообще Cargo в rust хоть и хорош, но отдельным предметом культа не является.
> Что только не придумывают, лишь бы на Rust не переходить.Очередной ремесленник не читавший Кнута? :)
а старый код кто будет переписывать? зачем было придумывать новый синтаксис?
В Rust какая-то уродливая объектность. Может, конечно, она и в C++ не идеал, но в Rust хуже.
За что они так с концептами?
Уже включили в черновик С++2a. Ждём-с через три года...
Слишком модно и молодёжно. Чистый Си наше всё. Тем более, что продолжает развиваться как минимум один компилятор Си на чистом Си - PCC (Portable C Compiler). Это продолжение развития того самого компилятора Си, который в середине 70-х был написан Стивеном С. Джонсоном из Bell Labs, используя наработки Алана Снидера. В начале 80-х практически каждый компилятор был основан на PCC, и только к середине 80-х появились независимые компиляторы. И вот, PCC продолжает жить и развиваться. Исходники и документацию можно качать тут: ftp://pcc.ludd.ltu.se/pub
да уж за такое время этот компилятор должен генерить код лучше чистого асма
Поддержу. Пишу сейчас на Си+Python. Вот когда стал использовать Питон, ощутил всю ущербность плюсов, и лаконичную чистоту Си. Для Си нужно знасть только арифметику указателей и основы языка - всё остальное в твоих руах, и не надо копать в недра всяких там глубокомысленных терминов, без знания которых плюсы бесполезны. А оно надо, если то же самое можно сделать на Си, не задавая никому никаких вопросов. А для гуев и веба Питон - тоже чисты и простой - всегда в помощь.
> Для Си нужно знасть только арифметику указателей и основы языкаО какой сказочный дурачок. Тебя ещё ждёт много удивительных открытий.
покажи ка, что ты там пишешь
Я Си уважаю, честно.Но однажды, написав несложную программку (500-1000 строк), я решил, что, коль почти все функции могут вернуть ошибку, то неплохо бы ошибки таких функций корректно обрабатывать (логирование, корректный выход из вызывающей функции с ошибочным кодом возврата и т. п.). Даже если вероятность ошибки мала. Ну то есть для всех функций, даже для printf...
После этого я предпочитаю C++, а Си использую в разве что когда работаю с чужими исходниками.
Кто не понял что произошло, рекомендую повторить мой эксперимент.
Чрезмерное отслеживание ошибок далеко не всегда нужно. Важно чтобы сохранялась нужная логика программы. А не всякая ошибка на неё влияет. Например, printf() возвращает число напечатанных символов, и в случае ошибки вывода оно отрицательное. А откуда ошибка вывода? Ну, допустим, отвалился терминал. Ну и что? Если программа не просто ведёт диалог с юзером, а выполняет какую-то работу в фоне, то она спокойно может продолжать делать то, что нужно.Если же отслеживание ошибок очень критично, то надо просто изначально разбивать программу рекурсивно. Написать процедуру вывода, которая тщательно отслеживает ошибки, и отовсюду обращаться к ней. И т.д. А выполнение одной и той же работы в сотнях мест исходника можно сравнить с написанией сотен операторов вместо использования for.
>>Чрезмерное отслеживание ошибок далеко не всегда нужно.простите, не соглашусь - на ошибках учатся! - Просто автор выше хотел сказать, что нет в языке "удобной" (однозначной) так называемой "обработки ошибок" (практики, методологии), а как обычно принято ? из вашего утверждения следует - не нужны лишние проверки, свалится ПО, берите корку и с лупой под отладчиком. Не ленитесь даже "нормально" работающую программу под отладчиком пропускать не говорю уже о профайлере.
>>Важно чтобы сохранялась нужная логика программы.
х*як, х*як и в продакшен )) стол перевернулся
Дебажить надо в первую очередь логику, а не вызовы библиотечных функций. Ошибка скорее всего будет именно в ней. А для этого на время отладки нужно подробнее исследовать те данные, которыми манипулирует программа. Можно отладчиком, можно через временно добавленные вызовы библиотечных функций ряда printf(), puts() и putchar().Можно, конечно, наезжать на грабли как следствие некорректных данных. И многие проверки, особенно в случаях библиотечных функций, связаны именно с этим. Однако, можно и не наезжать. Программы, юзеры и наборы входных данных бывают разные. Можно, конечно, писать такой софт, который у любого юзера на любых данных будет надёжным как танк. А можно и дисциплинировать юзеров. Ввёл некорректные данные - ССЗБ, надо было думать что вводишь. Защита от дурака нужна только когда есть этот самый дурак. А если писать софт для аудитории из грамотных и внимательных юзеров, то многие проверки можно опустить. В общем, подходы бывают разные.
Ну и, да, многое зависит ещё от того, какой именно это софт.
>>Можно, конечно, писать такой софт, который у любого юзера на любых данных будет надёжным как танк.Не можно, а нужно! Как по вашему, можно ли писать код для адронного коллайдера исходя из вашей логики (выше приведённого утверждения о не обязательности написания абсолютно безошибочного кода)?
>>А можно и дисциплинировать юзеров. Ввёл некорректные данные - ССЗБ, надо было думать что вводишь.
в программировании понятие "предположить" для меня лично не приемлемо, нельзя и не нужно предполагать, что данные не кривые, что руки у юзера нормальные, что сторонняя библиотечная функция работает безошибочно и всё такое (не говорю ещё про безопасность).
>>А если писать софт для аудитории из грамотных и внимательных юзеров, то многие проверки можно опустить. В общем, подходы бывают разные.
"Нормальных" нет, действовать нуно от противного, скептически ко всему относится. Говоря о подходе приведу не совсем удачный пример по этому поводу. Представьте себе такую картину - вызов библиотечных функция открыть, прочитать/записать, закрыть. Исходя из моей логики код будет выглядеть на подобии этого:
1) переменная1 = открыть(что-то)
2) проверить открыт ли "что-то"
3) записать/прочитать(переменная1, что-то)
4) проверить записалось/прочиталось "что-то"
5) закрыть(переменная1) "что-то" (от случая - ещё проверить открыто что-либо или нет)исходя из вашей же логики будет так:
1) переменная1 = открыть(что-то)
2) записать/прочитать(переменная1, что-то)
3) закрыть(переменная1) "что-то"а вот пример как избежать обоих вариантов:
1) записать/прочитать_туда-то_что-то(туда-то, что-то)
2) проверить результатно как видно это банальный враппер на выше перечисленные отдельные функции, всё равно даже внутри этого враппера нам необходимо проверить все три условия (открытия, записи/чтения, закрытия) - что и требовалось доказать.
Кто говорил про полное отсутствие проверок? Я говорю о том, что аудитории софта бывают разные, и про это даже учат в ВУЗах. Один из преподавателй того ВУЗа, где я учился, как положительный пример приводил программиста, который для себя писал программы из десятка строк, в которых кроме него никто ничего не понимал. Ну так вот. Не со всяким софтом взаимодействуют сотни и тысячи юзеров. Не всякий софт работает часами без остановки. Есть локальные аудитории юзеров из 3,5 штук. Есть фильтры командной строки. И т.д.Можно, конечно, писать так
#include <stdio.h>
#include <string.h>
#include <stdlib.h>int main(int argc, char **argv)
{
long int a2, al;
char *buf;
if (argc < 4) {
printf("usage: leftpad string width char\n");
return 1;
}
a2 = atol(argv[2]);
al = a2 - strlen(argv[1]);
if (al < 1) {
printf("%s\n", argv[1]);
return 0;
}
buf = (char *)malloc(a2 + 1);
if (buf == NULL)
return 1;
memset(buf, argv[3][0], al);
buf[al] = '\0';
printf("%s\n", strcat(buf, argv[1]));
free(buf);
return 0;
}Но, можно и так, исходя из предпосылки, что возникновение любой внештатной ситуации уже само по себе "всё, приехали" (например, откуда внезапно закончится оперативка если на машине её 8 гигов и за пределы сотни-другой мегабайт её использование обычно не выходит?):
#include <stdio.h>
#include <string.h>
#include <stdlib.h>char *buf;
char *leftpad(char *str, unsigned int len, char ch){
unsigned int i;
buf = (char *) malloc ((len + 1 + strlen(str)) * (sizeof(char));
for(i = 0; i < len; i++) buf[i] = ch;
return strcat(buf, str);
}int main(int argc, char **argv){
if(argc < 4){
printf("usage: leftpad string length char\n");
return 1;
}
unsigned int al = (unsigned int) atol(argv[2]);
printf("%s\n", leftpad(argv[1], al, argv[3][0]));
free(buf);
return 0;
}Про более простые случаи вообще молчу.
#include <stdio.h>char bcharz[] = " !@$^&*|=()[]\\:;\"\'<>,?{}";
int main(){
char c, bci;
while((c = getchar()) != EOF){
for(bci=0; bci < 24 ; bci++) if (bcharz[bci] == c) putchar ('\\');
putchar(c);
}
}
> Один из преподавателй того ВУЗа, где я учился, как положительный пример приводил
> программиста, который для себя писал программы из десятка строк, в которых
> кроме него никто ничего не понимал.Подозреваю, что преподаватель приводил этот пример совсем не в качестве положительного, но ты услышал то, что хотел услышать - оправдание для своей лени.
> Ну так вот. Не со всяким софтом взаимодействуют сотни и тысячи юзеров. Не всякий софт работает часами без остановки. Есть локальные аудитории юзеров из 3,5 штук.
Это называется не софт, а костыли. Используют их, когда нужно временное грубое решение или вообще предполагается однократный запуск. Крайний, но очень часто использумый вариант - однострочник на perl. Если же костыль продолжает регулярно использоваться, то умные люди его со временем заменяют на нормальное решение. Ну а дураки создают и лелеют десятилетиями системы из костылей и подпорок. Вот только пример дураков это как НЕ надо делать.
>> Ну а дураки создают и лелеют десятилетиями системы из костылей и подпорок.ну а вся причина в чём ? в том, что в среде Си программистов оч мало бест практисов, оч много небезопасных функций и тд, если в стандартной библиотеке Си не проверяют длину массива или строки, то что ждать от обычного новичка изучающий этот язык ? Вот в С++ немного не так, там есть более-менее нормальный еррор хендлинг, всякие траи с катчами и эксцепшенами есть какойта бест практис в виде шаблонов проектирования а в С всего этого нет, вот и появляются такие утверждения, что всё подряд проверять не нужно. Отсюда и такие программисты, думаю во многом большое влияние на мышление программисты играет именно используемый язык, Си-шнику дайте какой нить Erlang (функциональщина) у него он вызовет отторжение, потомучто мышление сформированно под С. (хотя девиз ирленга - лет ит креш - типа пусть падает если есть ошибка - https://ru.hexlet.io/courses/erlang_101/lessons/practical_er...
нет, преподавателю непонравился уровень сложности моей программы, и он начал говорить, что совсем необязательно так всё усложнять, вон, люди софт в десятки строк пишут.Следует различать софтовые комбайны, которые молотят байты под высокой нагрузкой, и всё остальное. А обычный режим юзания софта, про который я говорю, такой: юзеру понадобилось решить какую-то задачу, он "дёрнул за верёвочку", запустился конвейер бинарников и скриптов, который всё обработал и выплюнул ему результат, а затем завершился. Всё. Можно рассматривать и другие режимы юзания софта, например, десктопный, где юзер запустил рано утром какой-нибудь CAD или офисный пакет, и сидит там целый день без большой нагрузки на систему. Но, это уже другое.
Ещё раз повторяю, что я говорил даже не про десктопные комбайны, и не про то, что 365 дней в году молотит байты или следит за датчиками. Это, конечно, нужно дебажить, и очень-очень тщательно.
Но, этим ничего ни разу не ограничивается. Есть юниксвей и куча маленьких бинарников, которые склеиваются в конвейеры, которые вызываются при необходимости, пайпами. И тут уже совсем не обязательно перехватывать ошибки библиотечных функций как при ядерной войне.
> Один из преподавателй того ВУЗа, где я учился, как положительный пример приводил
> программиста, который для себя писал программы из десятка строк, в которых
> кроме него никто ничего не понимал.
> нет, преподавателю непонравился уровень сложности моей программы, и он начал говорить, что совсем необязательно так всё усложнять, вон, люди софт в десятки строк пишут.Эмм... Правильно ли я понял: препод посмотрел на переусложнённую программу, и начал распинаться о том, что есть "умельцы", которые из программы в десять строк могут сделать нечитаемое г-но? Если так, то по-моему, это как раз пример того, как не надо. Собственно ты можешь проверить это моё предположение, порывшись в своей памяти. Если я прав, препод обязательно должен был пройтись по тому, насколько эти программы в десять строк неудобны для других. Ещё, вероятно, если он препод с опытом программирования, он мог упомянуть о том, что программист через месяц становится _другим_, в том смысле что он смотрит на свою программу как баран на новые ворота, и никак не может понять, что это за нелепые буквы вообще и какой идиот их написал.
Нужно неоднократно столкнуться с этой ситуацией, для того чтобы обрести скилл, позволяющий программисту писать программы, которые будут поняты ему через месяц. Это умение писать программы, которые проще понять, чем написать заново.
> Чрезмерное отслеживание ошибок далеко не всегда нужно
> Все символы UTF-8 далеко не всегда нужны, можно и КОИ8-Р
> Физика далеко не всегда нужна, можно и ОБЖ ограничиться
> Крыша над головой далеко не всегда нужна, можно и на голой земле спать
> Крыша над головой далеко не всегда нужна, можно и на голой земле спатьТы что?! Крыша всегда нужна. Выходя из дома, обязательно возьми с собой крышу.
> А выполнение одной и той же
> работы в сотнях мест исходника можно сравнить с написанией сотен операторов
> вместо использования for.Вот это к сожалению и происходит в C.
Когда по ходу выясняется, что практически каждая функция может закончиться ошибкой. В итоге любая операция (хуже всего что и встроенные - сложения, умножения (и в C++ это тоже)), вызов функции - это заодно и очередной часто нетривиальный кусок кода проверки ошибки.
А потом ругают си , что память течет и дыры
> Но однажды, написав несложную программку (500-1000 строк), я решил, что, коль почти
> все функции могут вернуть ошибку, то неплохо бы ошибки таких функций
> корректно обрабатыватьЭто называется на "написал" а "слепил по-быстрому прототип".
Обработка ошибок нужна всегда.> неплохо бы ошибки таких функций корректно обрабатывать (логирование, корректный выход из вызывающей функции с ошибочным кодом возврата и т. п.).
В макрос обернул, и всё. CHK( my_func() == ok , MY_FUNK_FAILED )
Один макрос на все проекты.
С++ ники такие тоже используют кстати, просто вместо goto error внутри пишут throw.-----------
теперь представь картину: вот смотришь ты на кусок кода. В нём вызывается 10 функций, а ещё выделяется память. Ты понимаешь, что любая из функций может бросить эксепшн, что потенциально приведёт к утечке памяти, если только это не отслеживать исключительно внимательно, изворачиваясь с дополнительными конструкциями кода.
> Поддержу. Пишу сейчас на Си+Python. Вот когда стал использовать Питон, ощутил всю
> ущербность плюсов, и лаконичную чистоту Си. Для Си нужно знасть только
> арифметику указателей и основы языка - всё остальное в твоих руах,
> и не надо копать в недра всяких там глубокомысленных терминов, без
> знания которых плюсы бесполезны. А оно надо, если то же самое
> можно сделать на Си, не задавая никому никаких вопросов. А для
> гуев и веба Питон - тоже чисты и простой - всегда
> в помощь.пока другие изобретают новый язык в с++ просто апдейтят стандарт и все снова пишут на плюсах )))
кстате щас пишу свой фреймворк на котором можно будет легко (100-500 строк) сделать web 2.0 страницу (webassembly, socket server c10k)
щас с++ уже почти как ява по синтаксису без рефлексии только быстрей )
А нормальный полноценный юникодный строковый тип в С/С++ уже изобрели?
> А нормальный полноценный юникодный строковый тип в С/С++ уже изобрели?)) да вроде давно уже std::string, std::wstring
>> А нормальный полноценный юникодный строковый тип
> )) да вроде давно уже std::string, std::wstringЭто же _два_ типа??
В С++ никак не определятся с тем, что они хотят слепить.С одной стороны наследуют идею Си что это надстройка над асмом. С другой - пытаются внедрить функционал интерпритаторов.
Для первых характерно явное управление типами и размерами переменных в памяти. Для вторых - свобода творчества вроде отрицательных индексов в массивах и обращения по индексу больше, чем размер массива без ошибки (массив расширяется или зацикливается).
> В С++ никак не определятся с тем, что они хотят слепить.А вы, конечно, давно определись с тем что вы "лепите" (см. ниже).
> С одной стороны наследуют идею Си что это надстройка над асмом.
В соседней новости по LLVM про "надстройку над асмом" тоже вы писали?
> С другой - пытаются внедрить функционал интерпритаторов.
Что в вашем понимании "характерно" для интерпрИтаторов, вы написали ниже, а вот интересно, как вы понимаете "функционал интерпрИтаторов"?
> Для первых характерно явное управление типами и размерами переменных в памяти.
То есть характерность "надстроек над асмом" вы понимаете именно так.
И что по-вашему означает "управление типами"?Интересно, а как по-вашему будет выглядеть "не-надстройка над асмом"?
А, ну да - интерпрИтатор.> Для вторых - свобода творчества вроде отрицательных индексов в массивах и обращения по индексу больше,
По-вашему это характерно исключительно для интерпрИтаторов
> чем размер массива без ошибки (массив расширяется или зацикливается).
Да что вы говорите! ИнтерпрИтаторы даже такое умеют! И вам удалось понять, как массивы не только расширяются, но и зацикливаются! Интересно, а как "зацикленный" массив существует по-вашему в памяти?
Последняя фраза единственная на которую стоит ответить, потому что она объясняет всё остальное.В ЯВУ программист не занимается управлением памятью. Сравни типы данных и угадай ЯП:
- целое длиной 1 байт
- целое длиной 2 байта
- целое длиной 4 байта
- дробное длиной 4 байта
- дробное длиной 8 байтА теперь сравни с этим ЯП:
- число
- строкаВ этом суть. Не нужно читать книги в духе "1001 способ создать пустую юникод строку" или "100 способов найти длину строки". Он один. Простым вещам простые решения. Мозгоклюям - С++.
А теперь перечитайте диалог с начала, и сами попытайтесь понять, что вы хотели сказать.
Особенно, в чем по-вашему проблема с С++, кроме вашей проблемы, что вы его не знаете, и пытаетесь найти эму оправдаение.
)))Ну нравятся вам "интерпрИтаторы", так кто вам мешает?
И многие из тех, кто владеют С++, обычно умеют сочетать его с каким-либо из тех ЯП, в области которых вы тут попытались блеснуть познаниями.
Другое дело, что вы не знаете ни С++, ни о других языках без ошибок рассуждать не можете, путаетесь в понятиях и терминологии.
>[оверквотинг удален]
> - целое длиной 2 байта
> - целое длиной 4 байта
> - дробное длиной 4 байта
> - дробное длиной 8 байт
> А теперь сравни с этим ЯП:
> - число
> - строка
> В этом суть. Не нужно читать книги в духе "1001 способ создать
> пустую юникод строку" или "100 способов найти длину строки". Он один.
> Простым вещам простые решения. Мозгоклюям - С++.А на си и плюсах это
целое длиной хз сколько байт (где байт хз сколько бит)
целое 2 длиной хз сколько байт
целое 3 длиной хз сколько байт
знаковое целое неизвестного формата длиной хз сколько байт с пачкой UB на базовых операциях
знаковое целое 2 неизвестного формата длиной хз сколько байт с пачкой UB на базовых операциях
знаковое целое 3 неизвестного формата длиной хз сколько байт с пачкой UB на базовых операциях
> А теперь сравни с этим ЯП:
> - число
> - строкаЧто-то не припомню я ни одного ЯП, в котором можно было работать с подобными типами, совсем не задумываясь об их внутреннем представлении. Если целые хранятся иначе, чем числа с плавающей точкой, при операциях над ними может потребоваться преобразование. Если используются только числа с плавающей точкой, то есть ограничения на точность. Если ширина целых чисел фиксирована, то возможно переполнение. И так далее.
Про строки - это да, но целые и дробные определённых длин (а ещё точные дробные (decimal) и куча других типов) есть и в Java, и в C#, и в Python, например. Что-то вообще даже не знаю в каком это языке только один числовой тип. Bash какой-нибудь что ли?
> В С++ никак не определятся с тем, что они хотят слепить.
> С одной стороны наследуют идею Си что это надстройка над асмом. С
> другой - пытаются внедрить функционал интерпритаторов.
> Для первых характерно явное управление типами и размерами переменных в памяти. Для
> вторых - свобода творчества вроде отрицательных индексов в массивах и обращения
> по индексу больше, чем размер массива без ошибки (массив расширяется или
> зацикливается).я думаю исходят из простых практических соображений поэтому язык мультипарадигменный
вот думаю что с массивами действительно было бы не плохо сделать зацикливание индексов как в питоне, но для этого и не надо ничего менять можно просто класс написать c++, с размерами переменных то же самое хочешь управляй (std типы), хочешь не управляй (типы компилятора)
Посмотри путь ЯП:
- асм
- язык Си - ускоренное программирование с простым синтаксисом
- С++ - добавили классыИ стоп-игра. Почему???
То, что можно лопатой вскопать 10 га не означает что не нужен трактор. Он нужен, это квантовый скачок, который сразу переводит тебя на новый уровень.
Новый уровень (уже старый и давно всеми пройденный) - это отказ от управления памятью. Это юникод, сетевые технологии и параллельные вычисления.
А сегодняшние вызовы - это библиотека графических примитивов. Не printf для вывода в консоль (шёл 21 век!!!!!!), а оконные интерфейсы. Я не говорю что это просто, но кому-то придётся стандартизировать этот зоопарк API в ОС. Это возможность выполнения кода в разных ОС и на разных платформах без перекомпиляции.
И не нужно после этого удивляться популярности java и net. Они взяли синтаксис и уверено идут вперёд. А С++ везут в гробу на кладбище истории чтобы зак-пать рядом с ассемблером.
PS: слово "зак-пал" в списке матерных???? Я что-то пропустил?
>[оверквотинг удален]
> управления памятью. Это юникод, сетевые технологии и параллельные вычисления.
> А сегодняшние вызовы - это библиотека графических примитивов. Не printf для вывода
> в консоль (шёл 21 век!!!!!!), а оконные интерфейсы. Я не говорю
> что это просто, но кому-то придётся стандартизировать этот зоопарк API в
> ОС. Это возможность выполнения кода в разных ОС и на разных
> платформах без перекомпиляции.
> И не нужно после этого удивляться популярности java и net. Они взяли
> синтаксис и уверено идут вперёд. А С++ везут в гробу на
> кладбище истории чтобы зак-пать рядом с ассемблером.
> PS: слово "зак-пал" в списке матерных???? Я что-то пропустил?посмотри современный с++ код ))) удивишься, там управления памятью по минимому да и принтф давно уже не используется в нормальных проектах, есть конечно нюансы но не критичные
к нормальному авто управлению памяти без потери скорости не возможно прийти поэтому в с++ его нет, но если очень хочется с большой вероятностью можно написать фреймворк который из с++ делает яву
только это не нужно никому ))
> Поддержу. Пишу сейчас на Си+Python. Вот когда стал использовать Питон, ощутил всю
> ущербность плюсов, и лаконичную чистоту Си. Для Си нужно знасть только
> арифметику указателей и основы языка - всё остальное в твоих руах,
> и не надо копать в недра всяких там глубокомысленных терминов, без
> знания которых плюсы бесполезны. А оно надо, если то же самое
> можно сделать на Си, не задавая никому никаких вопросов. А для
> гуев и веба Питон - тоже чисты и простой - всегда
> в помощь.Ну шаблоны "узколобым" даются весьма с трудом :)
> Ну шаблоны "узколобым" даются весьма с трудом :)А ты сам-то, достаточно подробно знаешь "шаблоны" ?
Про шаблоны достаточно знает только Страуструп. А все остальные вообще не знают C++.
Александреску неплохо пишет про шаблоны.В реализациях языка Страуструпа шаблоны были весьма ущербными.
Страус труп в гробу переворачивается со всего этого
> И вот, PCC продолжает жить и развиватьсяИ сколько, говоришь, тестов из GCC TestSuite он проваливает?
>> И вот, PCC продолжает жить и развиваться
> И на сколько, говоришь, генерированный код медленнее питона?Fix.
>Слишком модно и молодёжно.На С++17 можно писать в стиле С89 и тебе ничего за это не будет. Язык никого ни к чему не принуждает.
>>Слишком модно и молодёжно.
> На С++17 можно писать в стиле С89 и тебе ничего за это
> не будет. Язык никого ни к чему не принуждает.1) гугли ключевое слово restrict , есть в C99 , нет вообще в СТАНДАРТЕ С++
2) попробуй не ловить эксепшены в С++
3) попробуй ловить эксепшены без деструкторов ( = без классов)
4) самое болезненное - нету инициализации структур и юнионов вида
struct abc {int a, b, c} = {.b = 99};
А разве хоть что-то из этого есть в С89?
Я говорю, что наш дорогой любитель КОИ-8 может писать в стиле классического Си и плюсовый компилятор возражать не будет.
Есть конструкции из c89, которые не переварятся в c++
Поэтому я написал "в стиле", а не "согласно стандарту С89".
> попробуй не ловить эксепшены в С++-fno-exceptions в руки и вперёд.
> самое болезненное - нету инициализации структур и юнионов вида
> struct abc {int a, b, c} = {.b = 99};struct abc {int a, b, c; abc() {b = 99}};
Учи мат.часть.
> Учи мат.часть.я конечно там имя инстанса структуры пропустил, надо было так.
struct abc {int a, b, c} a1 = {.b = 99};
а ты вспорол чушь не по теме.
struct
abc {int a,b,c}
a1 = {.c = 99},
a2 = {.b = 3};
auto_ptr не заюзаешь
А gcc уже научился Emoji в именах переменных?
Последний раз как пробовал, в clang работало, а gcc - нет.
И по стандарту с этим что?
> А gcc уже научился Emoji в именах переменных?Ну да, куда же без этого, как жили тораньше без Emoji.
все последние годы добавляют только свистелки для ленивых.
код со всей этой ботвой только все больше замусоривается.
Депрекейтнутый язык без нормального юникода и поддержки платформы.
> и поддержки платформы.ВеHдузятники должны. Страдай.
macOS & *BSD
Просто у кого-то руки из ЖЖ, всё в BSD ок с юникодами и прочим
Golang и Rust действительно хорош!
> без нормального юникодаО каком юникоде вы все говорите? Сколько не пользуюсь C++ ни разу проблем с кодировкой не было.
Не пользуйся и дальше. Кто-то мешает?
> и функции БесселяОбмазался. Навека. Почему именно Бесселя?
Не вижу особого повода для радости. То, что нужно, не реализовали, вообще ничего. Над вот этим вот списком работа велась почти 4 года. Можно поздравить плюсовиков с очередным проявлением бездарности комитета.
Так а что нужно-то? Приведи примеры для тех, кто не в теме, плз.
Самое банальное - модули. Эта тема мусолится ни один год. От C++17 ожидалось очень многое, вышло одно разочарование. Вот, можете почитать:
https://habrahabr.ru/company/infopulse/blog/279927/
https://stdcpp.ru/proposals
Модно и молодёжно. Я сам предпочитаю Си, но развитее плюсов тоже радует.
Да, да, "алгоритмы + структуры данных = программы" - наше всё.
лишь бы что сказать, c++ отнюдь не молодёжный, молодежным я бы назвал Python
> Добавлены дополнительные математические функции, включая эллиптические интегралы и функции БесселяЭто чё же, ещё один шаг к искусственному интеллекту в старейшем языке?
>> Добавлены дополнительные математические функции, включая эллиптические интегралы и функции Бесселя
> Это чё же, ещё один шаг к искусственному интеллекту в старейшем языке?изя, каклькулятор -- не ИИ.
На чём там, говоришь, жабка написана?
Модули где?
> Модули где?В Турбо-паскале.
У Сиплюсплюсников вместо модулей шаблоны используются!
Каким боком шаблоны заменили модули? И зачем уже много лет пытаются протянуть в стандарт модули если в с++ уже есть шаблоны?
Чем модули отличаются от либ со статической/динамической линковкой?
> Чем модули отличаются от либ со статической/динамической линковкой?Ничем.
Чем грузины.
> Каким боком шаблоны заменили модули?Никаким. просто шаблон -- это единица "простыни".
>И зачем уже много лет пытаются протянуть в стандарт модули если в с++ уже есть шаблоны?
Наверно дураки пытаются потому-что они не знают, что модуль -- это паскалевский термин. Библиотечная функция это Чисто_Си-шный термин.
Это лучше php или C++ как я понял это одно и тоже
Да.