The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Утверждён стандарт C++17"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Утверждён стандарт C++17"  +/
Сообщение от opennews (ok) on 08-Сен-17, 00:31 
Комитет 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%...(%D1%8F%D0%B7%D1%8B%D0%BA%D0%B8_%D0%A1%D0%B8));
-  Возможность указания 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.dev/opennews/art.shtml?num=47153

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Утверждён стандарт C++17"  +4 +/
Сообщение от Crazy Alex (ok) on 08-Сен-17, 00:31 
Ну, ожидаемо, конечно, но всё равно радует.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Утверждён стандарт C++17"  +12 +/
Сообщение от Аноним (??) on 08-Сен-17, 07:20 
Радует все кроме этого:
"Добавлены дополнительные математические функции, включая эллиптические интегралы и функции Бесселя"

Зачем это было пихать в стандарт? Сторонних библиотек для этого разве не достаточно?
Какое отношение это вообще имеет к C++?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

38. "Утверждён стандарт C++17"  –6 +/
Сообщение от Rihard email on 08-Сен-17, 07:49 
Геймдев? Сейчас это чуть ли не основная сфера использования cpp.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

52. "Утверждён стандарт C++17"  –1 +/
Сообщение от nobody (??) on 08-Сен-17, 09:31 
Научные вычисления. Чем Вам оно мешает?
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

58. "Утверждён стандарт C++17"  +10 +/
Сообщение от Аноним (??) on 08-Сен-17, 10:26 
Геймдев, научные вычисления - конечно не мешает!

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

И вообще, библиотеки не станут нужны, если в стандарте будет все, что "не мешает".

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

61. "Утверждён стандарт C++17"  –1 +/
Сообщение от nobody (??) on 08-Сен-17, 10:56 
Что за юношеский максимализм? Или всё или ничего? Математические функции - вполне себе фундаментальная вешь
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

65. "Утверждён стандарт C++17"  –2 +/
Сообщение от skybon (ok) on 08-Сен-17, 11:18 
Nope.
Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

72. "Утверждён стандарт C++17"  +1 +/
Сообщение от Аноним (??) on 08-Сен-17, 11:38 
> Что за юношеский максимализм? Или всё или ничего? Математические функции - вполне себе фундаментальная вешь

Какие именно математические функции? Их так же много, как и программного кода.

Не было сказано против математических функций вообще. И ни разу "все или ничего".
Про конкретные

В наше время фундаментальной математикой как раз и являются лямбды, комбинаторы, категории. Что как раз и реализовано в стандарте С++ фактически уже на уровне даже синтаксиса, не только библиотечном.

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

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

140. "Утверждён стандарт C++17"  –1 +/
Сообщение от Димон (??) on 09-Сен-17, 21:11 
> Что за юношеский максимализм? Или всё или ничего? Математические функции - вполне
> себе фундаментальная вешь

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

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

73. "Утверждён стандарт C++17"  +4 +/
Сообщение от Lain_13 (ok) on 08-Сен-17, 11:48 
Мне кажется вы не понимаете что означает добавление в стандарт С++ каких-либо новых функций. Это совершенно не означает, что они будут по-умолчанию вам доступны без подключения дополнительных библиотек. Просто компиляторы должны будут предоставлять вам стандартные библиотеки с реализациями этих функций. Так, например, для использования sin вам понадобится подключить стандартную библиотеку math. То же самое верно и для этих новых функций. В стандарт же попадает то, что повсеместно используется. Если алгоритмы анализа цепочек ДНК будут повсеместно использоваться, то их тоже можно будет стандартизировать и предоставлять в форме стандартной библиотеки, а вот подключать эту библиотеку к своему коду или нет решать уже вам.
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

77. "Утверждён стандарт C++17"  –2 +/
Сообщение от Аноним (??) on 08-Сен-17, 12:06 
Это понятно, что вы один из тех, кто уверен, что в стандарты языков нужно включать библиотеки на основании статистики использования. А не по назначению, идеологии и области применения самого языка. Подчеркиваю, области применения языка, а не библиотек на нем написанных.

Вашим первым языком случайно был не PHP?

И что мешает для "повсеместно используемого" продолжать развивать "повсеместно используемые" библиотеки с их собственными внутренними стандартами. Только эмоции мешают!

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

78. "Утверждён стандарт C++17"  +4 +/
Сообщение от Аноним (??) on 08-Сен-17, 12:15 
Спор ни о чём.

Есть разные стратегии развития ЯП.

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

Можно включать в ЯП только то, что стало де-факто стандартом в программировании и "отлажено" на других ЯП. В этом случае ЯП всегда в роли отстающего.

Можно вводить функционал сначала как бета-версию стандарта (типа -moz- и -web-kit-). Но велик риск, что временное с годами станет постоянным.

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

Поэтому, может, лучше вместо обсуждения деталей обсудите свой взгляд на стратегию развития?

Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

82. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 08-Сен-17, 12:32 
Если вас раздражает чужое мнение, и вы не любите когда вам возражают, это никак не значит, что спор был "ни о чем".

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

О том и речь, что добавлением этого функционала из области прикладной математики, снова пытаются сломать стратегию развития С++, которая предполагалась изначально, которую сильно поломали в конце 90х - начале 2000х. С трудом вернули в С++11, и теперь снова пытаются сломать.

Речь как раз и шла о конкретной "стратегии развития" конкретного языка С++.

А вам кажется, что раз есть другие "стратегии" других языков, то давайте притащим их в С++, ведь "можно" же.

Вы даже четыре предложения начали со слова "Можно". Конечно Можно!
Можно изучать "стратегии развития" ЯП, а сами ЯП не учить тоже Можно!

Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

83. "Утверждён стандарт C++17"  –2 +/
Сообщение от Аноним (??) on 08-Сен-17, 12:37 
Стратегию определяю члены комитета. Отсюда импотенция развития С++ в последние годы. Он словно замер между надстройкой над асмом с классами и макросами и ЯП со сборщиками мусора.

Лично мне безразлично куда он пойдёт, imo будущее не за ним, а за web-технологиями и предметно-ориентированными скриптовыми ЯП в сложном ПО (Excel/Calc, VBA, 1С).

Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

86. "Утверждён стандарт C++17"  +1 +/
Сообщение от Аноним (??) on 08-Сен-17, 12:55 
> Стратегию определяю члены комитета.

Здесь согласен, всякие там "комитеты" - большая опасность для развития.
Только кто тут, выше в обсуждениях, "голосует" за "повсеместно используемое"? Не те ли, кто как раз и привык что за них думают разные "комитеты".

Только вам видимо не известно, что отдельные сильные и талантливые личности все таки бывают способны прижать к ногтю целый "комитет". Что собственно, и можно было наблюдать, к счастью, в С++11.

К несчастью, "комитеты" просто так тоже не сдаются.

> Отсюда импотенция развития С++ в последние годы. Он словно замер между надстройкой над асмом с классами и макросами и ЯП со сборщиками мусора.

Понятно, все что было до этого в С++, и то что было внесено в С++11, лично вам кажется "надстройкой над асмом с классами".
То есть это не вы в вашем понимании программирования "застряли", а конечно же сам С++ "застрял" в вашем понимании.

> Лично мне безразлично куда он пойдёт, imo будущее не за ним,

Лично за себя вы сказали.

> а за web-технологиями и предметно-ориентированными скриптовыми ЯП в сложном ПО (Excel/Calc, VBA, 1С).

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

Я лично помню (такой вот я не "будущий"), как в конце 90х представители толпы кричали, что будущее за Windows, а UNIX - это якобы прошлое.

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

119. "Утверждён стандарт C++17"  –3 +/
Сообщение от Анонимный Алкоголик (??) on 08-Сен-17, 18:53 
> Мне кажется вы не понимаете что означает добавление в стандарт С++ каких-либо
> новых функций.

деби л как он есть.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

141. "Утверждён стандарт C++17"  +1 +/
Сообщение от Димон (??) on 09-Сен-17, 21:13 
> Мне кажется вы не понимаете что означает добавление в стандарт С++ каких-либо
> новых функций. Это совершенно не означает, что они будут по-умолчанию вам
> доступны без подключения дополнительных библиотек. Просто компиляторы должны будут предоставлять
> вам стандартные библиотеки с реализациями этих функций. Так, например, для использования
> sin вам понадобится подключить стандартную библиотеку math. То же самое верно
> и для этих новых функций. В стандарт же попадает то, что
> повсеместно используется. Если алгоритмы анализа цепочек ДНК будут повсеместно использоваться,
> то их тоже можно будет стандартизировать и предоставлять в форме стандартной
> библиотеки, а вот подключать эту библиотеку к своему коду или нет
> решать уже вам.

Драйвер базы Oracle 10g тоже нужен в стандартной библиотеке C++20!

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

134. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 09-Сен-17, 14:22 
Вообще в роадмапе C++ есть UI и Networking
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

157. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 14-Сен-17, 18:58 
Давайте!
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

85. "Утверждён стандарт C++17"  +/
Сообщение от nuzhny on 08-Сен-17, 12:43 
Эллиптические интегралы и функции Бесселя в мат. моделировании физических процессов, они в этой области не менее важны, чем синусы и косинусы. Они и правда базовые, но не для школьников, конечно.
Тут надо сказать, что тот же Майкрософт уже лет 15 назад точно ввёл функции Бесселя в свою стандартную библиотеку для С/С++. Почему? Во многом потому, что С++ изначально задумывался как язык для математического моделирования, потому что на Фортране много делать было не удобно. Введение этих функций в стандарт - это уже давно назревшая необходимость.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

89. "Утверждён стандарт C++17"  +/
Сообщение от анон on 08-Сен-17, 13:13 
https://stackoverflow.com/search?q=bessel+c%2B%2B

112 запросов за всё время существования стаковерфлоу - "давно назревшая необходимость"?
давайте без "боги праграмиравания не четают стаковерфлоу", где это вдруг давно назрело?

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

100. "Утверждён стандарт C++17"  –2 +/
Сообщение от Аноним (??) on 08-Сен-17, 14:51 
>давайте без "боги праграмиравания не четают стаковерфлоу"

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

Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

107. "Утверждён стандарт C++17"  +2 +/
Сообщение от Vkni (ok) on 08-Сен-17, 16:56 
Чтобы типичного для числодробильных инженеров уж совершенно ахтунга было поменьше.
Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

122. "Утверждён стандарт C++17"  +/
Сообщение от _ (??) on 08-Сен-17, 23:35 
Потому что они обычно ... как бы это сказать ... ну не программисты они!

По томику - я тоже считаю это клупостью. Или давайте rot13() в стандарт! А чо - необходимость давно назрела :)

Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

90. "Утверждён стандарт C++17"  +1 +/
Сообщение от Аноним (??) on 08-Сен-17, 13:14 
> Эллиптические интегралы и функции Бесселя в мат. моделировании физических процессов, они в этой области не менее важны, чем синусы и косинусы.

Не менее важны для кого и для чего?
А, ну да, вы же написали - "в мат. моделировании физических процессов".

> Они и правда базовые, но не для школьников, конечно.

Базовые для какой области?
(Про фундамент математики уже было написано выше, однако, понятно, что вы - писатель, а не читатель.)

А уж если "не для школьников", то конечно это надо в стандарт С++!

> Тут надо сказать, что тот же Майкрософт уже лет 15 назад точно ввёл функции Бесселя в свою стандартную библиотеку для С/С++.
> Почему?

Потому что это Майкрософт! )))
Помнится, Майкрософт однажды "ввел" код MS Office в код ядра MS Windows. Почему?

> Во многом потому, что С++ изначально задумывался как язык для математического моделирования,

Прямо вот так! Именно для _моделирования_!
Это кто вам сказал? Представитель в "комитете" (см. выше) профсоюза преподавателей мат-моделирования.

Это понятно, что представители физ-мата дальше "моделирования" в области ИТ не продвинулись.

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

Ну конечно, если в самом Фортране что-то неудобно, то это нужно непременно внести именно в стандарт С++!

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

127. "Утверждён стандарт C++17"  –4 +/
Сообщение от pavlinux (ok) on 09-Сен-17, 00:45 
> Базовые для какой области?

Ля... ну напиши быструю сортировку на своём ковносайте с использованием ф-ции Бесселя.
И оно будет в 100500 раз быстрее.

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

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

133. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 09-Сен-17, 10:28 
То есть вы утверждаете, что они "базовые" для области "напиши быструю сортировку на своём ковносайте", и "оно будет в 100500 раз быстрее".

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

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

Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

2. "Утверждён стандарт C++17"  +3 +/
Сообщение от kachsheev (ok) on 08-Сен-17, 00:43 
По некоторым пунктам не хватает примеров кода.

А так проздравляю всех плюсовиков.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Утверждён стандарт C++17"  +/
Сообщение от Шурик on 08-Сен-17, 02:21 
По каким?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

23. "Утверждён стандарт C++17"  +2 +/
Сообщение от hacenator on 08-Сен-17, 03:22 
https://github.com/AnthonyCalandra/modern-cpp-features?utm_c...
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Утверждён стандарт C++17"  –6 +/
Сообщение от Аноним (??) on 08-Сен-17, 01:03 
В студии std::byte конфликтует с винапишным байтом, для тех, кто "using namespace std" это может быть проблемой
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Утверждён стандарт C++17"  +8 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 08-Сен-17, 02:09 
студия для олигофренов, она то c++14 всё ещё нормально не умеет
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

19. "Утверждён стандарт C++17"  +9 +/
Сообщение от Аноним (??) on 08-Сен-17, 02:51 
Что еще смешнее, там даже C99 до сих пор не полный. EpicFail Studio.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

34. "Утверждён стандарт C++17"  –1 +/
Сообщение от iPony on 08-Сен-17, 06:33 
Бось, что большинство c++ разработчиков по твоему мнению будут умственно отсталыми, ибо они еще не перешли на c++14/c++17
Я вот как раз занимаюсь умственно отсталой деятельностью - пишу проект на c++11.
Правда в Netbeans, и вот его парсер подсветки даже простой c++11 часто не может :(
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

43. "Утверждён стандарт C++17"  +2 +/
Сообщение от Аноним (??) on 08-Сен-17, 09:02 
Qt creator и Kdevelop нормально работают с с++11 с++14. Там используется для парсинга clang.
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

59. "Утверждён стандарт C++17"  –1 +/
Сообщение от CHIM email(ok) on 08-Сен-17, 10:42 
Ну мне например NetBeans удобнее показался в работе
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

130. "Утверждён стандарт C++17"  –1 +/
Сообщение от Вареник on 09-Сен-17, 05:40 
NetBeans классный, но у него уклон в веб-стек. Все кроме Java/HTML/CSS/js уже много лет не развивается.

Формально языки поддерживаются, плагины остались, но развития нет и скорее всего не будет.
Котлин и не собираются добавлять, хотя бы поверхностно, комиллировать гибридные проекты.
Scala тоже мимо.

А ведь это Java World - основной конек Оракла...

Поддержку Python похоронили годы назад.

С++ просто оставили как есть.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

160. "Утверждён стандарт C++17"  +/
Сообщение от anonymous (??) on 01-Окт-17, 08:02 
Плагин для Kotlin  в Netbeans 8.2 есть. Как раз недавно завезли.
Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

68. "Утверждён стандарт C++17"  +2 +/
Сообщение от Аноним (??) on 08-Сен-17, 11:29 
QtCreator и без Шланга нормально синтксис C++11, C++14 подсвечивает.
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

44. "Утверждён стандарт C++17"  +1 +/
Сообщение от Аноним (??) on 08-Сен-17, 09:06 
Не путай поддержку стандартов компилятором и реальное использование фич стандарта в коде. Частенько возникает потребность собрать новый код умеренно старым компилятором, а выясняется, что он стандартов пятилетней давности не знает. В инструментарии все новшества должны появляться как можно скорее, а вот программистам можно и обождать тащить их в свои проекты.
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

135. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 09-Сен-17, 15:41 
> Бось, что большинство c++ разработчиков

Из твоего круга общения? И только те, которые на венде?

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

148. "Утверждён стандарт C++17"  –1 +/
Сообщение от iPony on 11-Сен-17, 07:30 
Нет не из моего.
Ничего не поделаешь - ынтерапайз во все дыры.
А студенты хелло вордщики могут и на драфтовых стандартах писать - есть такое.
Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

66. "Утверждён стандарт C++17"  +7 +/
Сообщение от Филимон Задумчивый on 08-Сен-17, 11:20 
Студия глючновата и медленна, не до конца поддерживает стандарты, но с решарпером для C++ и с PVS Studio показывает что не так с кодом задолго до компиляции. Это время на разработку на порядок сокращает. Если вы знаете что-либо подобное ещё, то поделитесь. У неё нет сейчас альтернатив.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

131. "Утверждён стандарт C++17"  –1 +/
Сообщение от Вареник on 09-Сен-17, 05:44 
> Студия глючновата и медленна, не до конца поддерживает стандарты, но с решарпером
> для C++ и с PVS Studio показывает что не так с
> кодом задолго до компиляции. Это время на разработку на порядок сокращает.
> Если вы знаете что-либо подобное ещё, то поделитесь. У неё нет
> сейчас альтернатив.

Какие проблемы прогнать код и через VS-PVC тоже?
Это же не значит что надо разрабатывать под VS и терпеть ее.

Можно почитать статьи PVC, с какими проблемами они стокнулись, упершись в архитектурные ограничения VS и какие костыли изобретали, чтобы не тормозило, вынести в другой процесс (памяти под VS не выделить) и т.д.

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

46. "Утверждён стандарт C++17"  +/
Сообщение от bOOster (ok) on 08-Сен-17, 09:14 
вы с виндовыми примочками - идите быстро, и подальше… microsoft всегда впереди паровоза бежала с очередным га%ном… А потом изобретала костыли совместимости….
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

49. "Утверждён стандарт C++17"  +/
Сообщение от anonymous (??) on 08-Сен-17, 09:20 
>>В студии std::byte конфликтует с винапишным байтом, для тех, кто "using namespace std" это может быть проблемой

typedef unsigned char BYTE;

"BYTE" != "byte"

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

53. "Утверждён стандарт C++17"  –1 +/
Сообщение от nobody (??) on 08-Сен-17, 09:33 
Каким образом, если в WinAPI BYTE (верхним регистром)?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

136. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 09-Сен-17, 15:43 
> Каким образом, если в WinAPI BYTE (верхним регистром)?

Очень удобно читать такой код. /s

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

7. "Утверждён стандарт C++17"  –9 +/
Сообщение от Аноним (??) on 08-Сен-17, 01:11 
Что только не придумывают, лишь бы на Rust не переходить.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Утверждён стандарт C++17"  –10 +/
Сообщение от Аноним (??) on 08-Сен-17, 02:52 
> Что только не придумывают, лишь бы на Rust не переходить.

ЯП с встроенным менеджером пакетов - это для хипстоватых поклонников карго-культа.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

25. "Утверждён стандарт C++17"  +4 +/
Сообщение от Аноним (??) on 08-Сен-17, 03:33 
>> Что только не придумывают, лишь бы на Rust не переходить.
> ЯП с встроенным менеджером пакетов
> ЯП с встроенным

Что только за ценное мнение не заимеют, лишь бы в теме ни зуб ногой.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

152. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 11-Сен-17, 18:31 
Ну вообще Cargo в rust хоть и хорош, но отдельным предметом культа не является.
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

47. "Утверждён стандарт C++17"  –2 +/
Сообщение от bOOster (ok) on 08-Сен-17, 09:15 
> Что только не придумывают, лишь бы на Rust не переходить.

Очередной ремесленник не читавший Кнута? :)

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

50. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 08-Сен-17, 09:20 
а старый код кто будет переписывать? зачем было придумывать новый синтаксис?
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

71. "Утверждён стандарт C++17"  +2 +/
Сообщение от Аноним (??) on 08-Сен-17, 11:34 
В Rust какая-то уродливая объектность. Может, конечно, она и в C++ не идеал, но в Rust хуже.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

8. "Утверждён стандарт C++17"  +/
Сообщение от Фёдор on 08-Сен-17, 01:13 
За что они так с концептами?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

54. "Утверждён стандарт C++17"  +1 +/
Сообщение от nobody (??) on 08-Сен-17, 09:34 
Уже включили в черновик С++2a. Ждём-с через три года...
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

9. "Утверждён стандарт C++17"  –8 +/
Сообщение от saahriktu (ok) on 08-Сен-17, 01:16 
Слишком модно и молодёжно. Чистый Си наше всё. Тем более, что продолжает развиваться как минимум один компилятор Си на чистом Си - PCC (Portable C Compiler). Это продолжение развития того самого компилятора Си, который в середине 70-х был написан Стивеном С. Джонсоном из Bell Labs, используя наработки Алана Снидера. В начале 80-х практически каждый компилятор был основан на PCC, и только к середине 80-х появились независимые компиляторы. И вот, PCC продолжает жить и развиваться. Исходники и документацию можно качать тут: ftp://pcc.ludd.ltu.se/pub
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Утверждён стандарт C++17"  +4 +/
Сообщение от volodja email on 08-Сен-17, 01:53 
да уж за такое время этот компилятор должен генерить код лучше чистого асма
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Утверждён стандарт C++17"  +1 +/
Сообщение от Заморашка on 08-Сен-17, 02:06 
Поддержу. Пишу сейчас на Си+Python. Вот когда стал использовать Питон, ощутил всю ущербность плюсов, и лаконичную чистоту Си. Для Си нужно знасть только арифметику указателей и основы языка - всё остальное в твоих руах, и не надо копать в недра всяких там глубокомысленных терминов, без знания которых плюсы бесполезны. А оно надо, если то же самое можно сделать на Си, не задавая никому никаких вопросов. А для гуев и веба Питон - тоже чисты и простой - всегда в помощь.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

14. "Утверждён стандарт C++17"  +15 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 08-Сен-17, 02:12 
> Для Си нужно знасть только арифметику указателей и основы языка

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 08-Сен-17, 02:13 
покажи ка, что ты там пишешь
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

17. "Утверждён стандарт C++17"  –1 +/
Сообщение от Kroz email(ok) on 08-Сен-17, 02:30 
Я Си уважаю, честно.

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

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

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

18. "Утверждён стандарт C++17"  +/
Сообщение от saahriktu (ok) on 08-Сен-17, 02:50 
Чрезмерное отслеживание ошибок далеко не всегда нужно. Важно чтобы сохранялась нужная логика программы. А не всякая ошибка на неё влияет. Например, printf() возвращает число напечатанных символов, и в случае ошибки вывода оно отрицательное. А откуда ошибка вывода? Ну, допустим, отвалился терминал. Ну и что? Если программа не просто ведёт диалог с юзером, а выполняет какую-то работу в фоне, то она спокойно может продолжать делать то, что нужно.

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

30. "Утверждён стандарт C++17"  +3 +/
Сообщение от Sw00p aka Jerom on 08-Сен-17, 04:30 
>>Чрезмерное отслеживание ошибок далеко не всегда нужно.

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

>>Важно чтобы сохранялась нужная логика программы.

х*як, х*як и в продакшен )) стол перевернулся


Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

55. "Утверждён стандарт C++17"  –3 +/
Сообщение от saahriktu (ok) on 08-Сен-17, 09:51 
Дебажить надо в первую очередь логику, а не вызовы библиотечных функций. Ошибка скорее всего будет именно в ней. А для этого на время отладки нужно подробнее исследовать те данные, которыми манипулирует программа. Можно отладчиком, можно через временно добавленные вызовы библиотечных функций ряда printf(), puts() и putchar().

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

Ну и, да, многое зависит ещё от того, какой именно это софт.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

88. "Утверждён стандарт C++17"  +1 +/
Сообщение от Sw00p aka Jerom on 08-Сен-17, 13:07 
>>Можно, конечно, писать такой софт, который у любого юзера на любых данных будет надёжным как танк.

Не можно, а нужно! Как по вашему, можно ли писать код для адронного коллайдера исходя из вашей логики (выше приведённого утверждения о не обязательности написания абсолютно безошибочного кода)?

>>А можно и дисциплинировать юзеров. Ввёл некорректные данные - ССЗБ, надо было думать что вводишь.

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

>>А если писать софт для аудитории из грамотных и внимательных юзеров, то многие проверки можно опустить. В общем, подходы бывают разные.

"Нормальных" нет, действовать нуно от противного, скептически ко всему относится. Говоря о подходе приведу не совсем удачный пример по этому поводу. Представьте себе такую картину - вызов библиотечных функция открыть, прочитать/записать, закрыть. Исходя из моей логики код будет выглядеть на подобии этого:

1) переменная1 = открыть(что-то)
2) проверить открыт ли "что-то"
3) записать/прочитать(переменная1, что-то)
4) проверить записалось/прочиталось "что-то"
5) закрыть(переменная1) "что-то" (от случая - ещё проверить открыто что-либо или нет)

исходя из вашей же логики будет так:

1) переменная1 = открыть(что-то)
2) записать/прочитать(переменная1, что-то)
3) закрыть(переменная1) "что-то"

а вот пример как избежать обоих вариантов:

1) записать/прочитать_туда-то_что-то(туда-то, что-то)
2) проверить результат

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

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

94. "Утверждён стандарт C++17"  –2 +/
Сообщение от saahriktu (ok) on 08-Сен-17, 13:37 
Кто говорил про полное отсутствие проверок? Я говорю о том, что аудитории софта бывают разные, и про это даже учат в ВУЗах. Один из преподавателй того ВУЗа, где я учился, как положительный пример приводил программиста, который для себя писал программы из десятка строк, в которых кроме него никто ничего не понимал. Ну так вот. Не со всяким софтом взаимодействуют сотни и тысячи юзеров. Не всякий софт работает часами без остановки. Есть локальные аудитории юзеров из 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);
        }
}

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

109. "Утверждён стандарт C++17"  +/
Сообщение от angra (ok) on 08-Сен-17, 17:44 
> Один из преподавателй того ВУЗа, где я учился, как положительный пример приводил
> программиста, который для себя писал программы из десятка строк, в которых
> кроме него никто ничего не понимал.

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

> Ну так вот. Не со всяким софтом взаимодействуют сотни и тысячи юзеров. Не всякий софт работает часами без остановки. Есть локальные аудитории юзеров из 3,5 штук.

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

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

114. "Утверждён стандарт C++17"  –3 +/
Сообщение от Sw00p aka Jerom on 08-Сен-17, 18:06 
>> Ну а дураки создают и лелеют десятилетиями системы из костылей и подпорок.

ну а вся причина в чём ? в том, что в среде Си программистов оч мало бест практисов, оч много небезопасных функций и тд, если в стандартной библиотеке Си не проверяют длину массива или строки, то что ждать от обычного новичка изучающий этот язык ? Вот в С++ немного не так, там есть более-менее нормальный еррор хендлинг, всякие траи с катчами и эксцепшенами есть какойта бест практис в виде шаблонов проектирования а в С всего этого нет, вот и появляются такие утверждения, что всё подряд проверять не нужно. Отсюда и такие программисты, думаю во многом большое влияние на мышление программисты играет именно используемый язык, Си-шнику дайте какой нить Erlang (функциональщина) у него он вызовет отторжение, потомучто мышление сформированно под С. (хотя девиз ирленга - лет ит креш - типа пусть падает если есть ошибка - https://ru.hexlet.io/courses/erlang_101/lessons/practical_er...)

Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

118. "Утверждён стандарт C++17"  –1 +/
Сообщение от saahriktu (ok) on 08-Сен-17, 18:50 
нет, преподавателю непонравился уровень сложности моей программы, и он начал говорить, что совсем необязательно так всё усложнять, вон, люди софт в десятки строк пишут.

Следует различать софтовые комбайны, которые молотят байты под высокой нагрузкой, и всё остальное. А обычный режим юзания софта, про который я говорю, такой: юзеру понадобилось решить какую-то задачу, он "дёрнул за верёвочку", запустился конвейер бинарников и скриптов, который всё обработал и выплюнул ему результат, а затем завершился. Всё. Можно рассматривать и другие режимы юзания софта, например, десктопный, где юзер запустил рано утром какой-нибудь CAD или офисный пакет, и сидит там целый день без большой нагрузки на систему. Но, это уже другое.

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

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

Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

144. "Утверждён стандарт C++17"  +/
Сообщение от Ordu email(ok) on 10-Сен-17, 05:28 
> Один из преподавателй того ВУЗа, где я учился, как положительный пример приводил
> программиста, который для себя писал программы из десятка строк, в которых
> кроме него никто ничего не понимал.
> нет, преподавателю непонравился уровень сложности моей программы, и он начал говорить, что совсем необязательно так всё усложнять, вон, люди софт в десятки строк пишут.

Эмм... Правильно ли я понял: препод посмотрел на переусложнённую программу, и начал распинаться о том, что есть "умельцы", которые из программы в десять строк могут сделать нечитаемое г-но? Если так, то по-моему, это как раз пример того, как не надо. Собственно ты можешь проверить это моё предположение, порывшись в своей памяти. Если я прав, препод обязательно должен был пройтись по тому, насколько эти программы в десять строк неудобны для других. Ещё, вероятно, если он препод с опытом программирования, он мог упомянуть о том, что программист через месяц становится _другим_, в том смысле что он смотрит на свою программу как баран на новые ворота, и никак не может понять, что это за нелепые буквы вообще и какой идиот их написал.
Нужно неоднократно столкнуться с этой ситуацией, для того чтобы обрести скилл, позволяющий программисту писать программы, которые будут поняты ему через месяц. Это умение писать программы, которые проще понять, чем написать заново.

Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

33. "Утверждён стандарт C++17"  +3 +/
Сообщение от Аноним (??) on 08-Сен-17, 06:27 
> Чрезмерное отслеживание ошибок далеко не всегда нужно
> Все символы UTF-8 далеко не всегда нужны, можно и КОИ8-Р
> Физика далеко не всегда нужна, можно и ОБЖ ограничиться
> Крыша над головой далеко не всегда нужна, можно и на голой земле спать
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

51. "Утверждён стандарт C++17"  +3 +/
Сообщение от EHLO on 08-Сен-17, 09:24 
> Крыша над головой далеко не всегда нужна, можно и на голой земле спать

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

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

113. "Утверждён стандарт C++17"  –2 +/
Сообщение от Анонимный Алкоголик (??) on 08-Сен-17, 18:04 
> А выполнение одной и той же
> работы в сотнях мест исходника можно сравнить с написанией сотен операторов
> вместо использования for.

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

149. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 11-Сен-17, 11:11 
А потом ругают си , что память течет и дыры
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

45. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 08-Сен-17, 09:09 
> Но однажды, написав несложную программку (500-1000 строк), я решил, что, коль почти
> все функции могут вернуть ошибку, то неплохо бы ошибки таких функций
> корректно обрабатывать

Это называется на "написал" а "слепил по-быстрому прототип".

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

63. "Утверждён стандарт C++17"  –1 +/
Сообщение от pripolz on 08-Сен-17, 11:09 
Обработка ошибок нужна всегда.

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

В макрос обернул, и всё. CHK( my_func() == ok , MY_FUNK_FAILED )
Один макрос на все проекты.
С++ ники такие тоже используют кстати, просто вместо goto error внутри пишут throw.

-----------

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

21. "Утверждён стандарт C++17"  –1 +/
Сообщение от volodja email on 08-Сен-17, 02:54 
> Поддержу. Пишу сейчас на Си+Python. Вот когда стал использовать Питон, ощутил всю
> ущербность плюсов, и лаконичную чистоту Си. Для Си нужно знасть только
> арифметику указателей и основы языка - всё остальное в твоих руах,
> и не надо копать в недра всяких там глубокомысленных терминов, без
> знания которых плюсы бесполезны. А оно надо, если то же самое
> можно сделать на Си, не задавая никому никаких вопросов. А для
> гуев и веба Питон - тоже чисты и простой - всегда
> в помощь.

пока другие изобретают новый язык в с++ просто апдейтят стандарт и все снова пишут на плюсах )))

кстате щас пишу свой фреймворк на котором можно будет легко (100-500 строк) сделать web 2.0 страницу (webassembly, socket server c10k)

щас с++ уже почти как ява по синтаксису без рефлексии только быстрей )

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

29. "Утверждён стандарт C++17"  +3 +/
Сообщение от Онаним on 08-Сен-17, 03:37 
А нормальный полноценный юникодный строковый тип в С/С++ уже изобрели?
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

32. "Утверждён стандарт C++17"  –3 +/
Сообщение от volodja email on 08-Сен-17, 05:26 
> А нормальный полноценный юникодный строковый тип в С/С++ уже изобрели?

)) да вроде давно уже std::string, std::wstring

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

56. "Утверждён стандарт C++17"  +3 +/
Сообщение от Andrey Mitrofanov on 08-Сен-17, 10:00 
>> А нормальный полноценный юникодный строковый тип
> )) да вроде давно уже std::string, std::wstring

Это же _два_ типа??

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

81. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 08-Сен-17, 12:21 
В С++ никак не определятся с тем, что они хотят слепить.

С одной стороны наследуют идею Си что это надстройка над асмом. С другой - пытаются внедрить функционал интерпритаторов.

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

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

96. "Утверждён стандарт C++17"  –2 +/
Сообщение от Аноним (??) on 08-Сен-17, 14:10 
> В С++ никак не определятся с тем, что они хотят слепить.

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

> С одной стороны наследуют идею Си что это надстройка над асмом.

В соседней новости по LLVM про "надстройку над асмом" тоже вы писали?

> С другой - пытаются внедрить функционал интерпритаторов.

Что в вашем понимании "характерно" для интерпрИтаторов, вы написали ниже, а вот интересно, как вы понимаете "функционал интерпрИтаторов"?

> Для первых характерно явное управление типами и размерами переменных в памяти.

То есть характерность "надстроек над асмом" вы понимаете именно так.
И что по-вашему означает "управление типами"?

Интересно, а как по-вашему будет выглядеть "не-надстройка над асмом"?
А, ну да - интерпрИтатор.

> Для вторых - свобода творчества вроде отрицательных индексов в массивах и обращения по индексу больше,

По-вашему это характерно исключительно для интерпрИтаторов

> чем размер массива без ошибки (массив расширяется или зацикливается).

Да что вы говорите! ИнтерпрИтаторы даже такое умеют! И вам удалось понять, как массивы не только расширяются, но и зацикливаются! Интересно, а как "зацикленный" массив существует по-вашему в памяти?

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

98. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 08-Сен-17, 14:40 
Последняя фраза единственная на которую стоит ответить, потому что она объясняет всё остальное.

В ЯВУ программист не занимается управлением памятью. Сравни типы данных и угадай ЯП:
- целое длиной 1 байт
- целое длиной 2 байта
- целое длиной 4 байта
- дробное длиной 4 байта
- дробное длиной 8 байт

А теперь сравни с этим ЯП:
- число
- строка

В этом суть. Не нужно читать книги в духе "1001 способ создать пустую юникод строку" или "100 способов найти длину строки". Он один. Простым вещам простые решения. Мозгоклюям - С++.

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

132. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 09-Сен-17, 10:10 
А теперь перечитайте диалог с начала, и сами попытайтесь понять, что вы хотели сказать.
Особенно, в чем по-вашему проблема с С++, кроме вашей проблемы, что вы его не знаете, и пытаетесь найти эму оправдаение.
)))

Ну нравятся вам "интерпрИтаторы", так кто вам мешает?

И многие из тех, кто владеют С++, обычно умеют сочетать его с каким-либо из тех ЯП, в области которых вы тут попытались блеснуть познаниями.

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

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

142. "Утверждён стандарт C++17"  +/
Сообщение от Димон (??) on 09-Сен-17, 21:50 
>[оверквотинг удален]
> - целое длиной 2 байта
> - целое длиной 4 байта
> - дробное длиной 4 байта
> - дробное длиной 8 байт
> А теперь сравни с этим ЯП:
> - число
> - строка
> В этом суть. Не нужно читать книги в духе "1001 способ создать
> пустую юникод строку" или "100 способов найти длину строки". Он один.
> Простым вещам простые решения. Мозгоклюям - С++.

А на си и плюсах это

целое длиной хз сколько байт (где байт хз сколько бит)
целое 2 длиной хз сколько байт
целое 3 длиной хз сколько байт
знаковое целое неизвестного формата длиной хз сколько байт с пачкой UB на базовых операциях
знаковое целое 2 неизвестного формата длиной хз сколько байт с пачкой UB на базовых операциях
знаковое целое 3 неизвестного формата длиной хз сколько байт с пачкой UB на базовых операциях

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

143. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 09-Сен-17, 23:22 
> А теперь сравни с этим ЯП:
> - число
> - строка

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

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

154. "Утверждён стандарт C++17"  +1 +/
Сообщение от Анонйм on 13-Сен-17, 06:27 
Про строки - это да, но целые и дробные определённых длин (а ещё точные дробные (decimal) и куча других типов) есть и в Java, и в C#, и в Python, например. Что-то вообще даже не знаю в каком это языке только один числовой тип. Bash какой-нибудь что ли?

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

129. "Утверждён стандарт C++17"  –2 +/
Сообщение от volodja email on 09-Сен-17, 05:26 
> В С++ никак не определятся с тем, что они хотят слепить.
> С одной стороны наследуют идею Си что это надстройка над асмом. С
> другой - пытаются внедрить функционал интерпритаторов.
> Для первых характерно явное управление типами и размерами переменных в памяти. Для
> вторых - свобода творчества вроде отрицательных индексов в массивах и обращения
> по индексу больше, чем размер массива без ошибки (массив расширяется или
> зацикливается).

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

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

145. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 10-Сен-17, 07:07 
Посмотри путь ЯП:
- асм
- язык Си - ускоренное программирование с простым синтаксисом
- С++ - добавили классы

И стоп-игра. Почему???

То, что можно лопатой вскопать 10 га не означает что не нужен трактор. Он нужен, это квантовый скачок, который сразу переводит тебя на новый уровень.

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

А сегодняшние вызовы - это библиотека графических примитивов. Не printf для вывода в консоль (шёл 21 век!!!!!!), а оконные интерфейсы. Я не говорю что это просто, но кому-то придётся стандартизировать этот зоопарк API в ОС. Это возможность выполнения кода в разных ОС и на разных платформах без перекомпиляции.

И не нужно после этого удивляться популярности java и net. Они взяли синтаксис и уверено идут вперёд. А С++ везут в гробу на кладбище истории чтобы зак-пать рядом с ассемблером.

PS: слово "зак-пал" в списке матерных???? Я что-то пропустил?

Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

146. "Утверждён стандарт C++17"  –1 +/
Сообщение от volodja email on 10-Сен-17, 15:33 
>[оверквотинг удален]
> управления памятью. Это юникод, сетевые технологии и параллельные вычисления.
> А сегодняшние вызовы - это библиотека графических примитивов. Не printf для вывода
> в консоль (шёл 21 век!!!!!!), а оконные интерфейсы. Я не говорю
> что это просто, но кому-то придётся стандартизировать этот зоопарк API в
> ОС. Это возможность выполнения кода в разных ОС и на разных
> платформах без перекомпиляции.
> И не нужно после этого удивляться популярности java и net. Они взяли
> синтаксис и уверено идут вперёд. А С++ везут в гробу на
> кладбище истории чтобы зак-пать рядом с ассемблером.
> PS: слово "зак-пал" в списке матерных???? Я что-то пропустил?

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

Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

48. "Утверждён стандарт C++17"  –4 +/
Сообщение от bOOster (ok) on 08-Сен-17, 09:17 
> Поддержу. Пишу сейчас на Си+Python. Вот когда стал использовать Питон, ощутил всю
> ущербность плюсов, и лаконичную чистоту Си. Для Си нужно знасть только
> арифметику указателей и основы языка - всё остальное в твоих руах,
> и не надо копать в недра всяких там глубокомысленных терминов, без
> знания которых плюсы бесполезны. А оно надо, если то же самое
> можно сделать на Си, не задавая никому никаких вопросов. А для
> гуев и веба Питон - тоже чисты и простой - всегда
> в помощь.

Ну шаблоны "узколобым" даются весьма с трудом :)

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

126. "Утверждён стандарт C++17"  +/
Сообщение от pripolz on 09-Сен-17, 00:37 
> Ну шаблоны "узколобым" даются весьма с трудом :)

А ты сам-то, достаточно подробно знаешь "шаблоны" ?

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

137. "Утверждён стандарт C++17"  +1 +/
Сообщение от Аноним (??) on 09-Сен-17, 15:51 
Про шаблоны достаточно знает только Страуструп. А все остальные вообще не знают C++.
Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

151. "Утверждён стандарт C++17"  –1 +/
Сообщение от bOOster (ok) on 11-Сен-17, 16:24 
Александреску неплохо пишет про шаблоны.

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

Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

155. "Утверждён стандарт C++17"  –1 +/
Сообщение от Антонин on 13-Сен-17, 08:12 
Страус труп в гробу переворачивается со всего этого
Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

22. "Утверждён стандарт C++17"  +/
Сообщение от Какаянахренразница (ok) on 08-Сен-17, 03:01 
> И вот, PCC продолжает жить и развиваться

И сколько, говоришь, тестов из GCC TestSuite он проваливает?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

27. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 08-Сен-17, 03:36 
>> И вот, PCC продолжает жить и развиваться
> И на сколько, говоришь, генерированный код медленнее питона?

Fix.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

41. "Утверждён стандарт C++17"  –1 +/
Сообщение от A.Stahl (ok) on 08-Сен-17, 08:38 
>Слишком модно и молодёжно.

На С++17 можно писать в стиле С89 и тебе ничего за это не будет. Язык никого ни к чему не принуждает.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

64. "Утверждён стандарт C++17"  –1 +/
Сообщение от pripolz on 08-Сен-17, 11:18 
>>Слишком модно и молодёжно.
> На С++17 можно писать в стиле С89 и тебе ничего за это
> не будет. Язык никого ни к чему не принуждает.

1) гугли ключевое слово restrict , есть в C99 , нет вообще в СТАНДАРТЕ С++
2) попробуй не ловить эксепшены в С++
3) попробуй ловить эксепшены без деструкторов ( = без классов)
4) самое болезненное - нету инициализации структур и юнионов вида
struct abc {int a, b, c} = {.b = 99};

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

69. "Утверждён стандарт C++17"  +/
Сообщение от A.Stahl (ok) on 08-Сен-17, 11:31 
А разве хоть что-то из этого есть в С89?
Я говорю, что наш дорогой любитель КОИ-8 может писать в стиле классического Си и плюсовый компилятор возражать не будет.
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

74. "Утверждён стандарт C++17"  +/
Сообщение от iPony on 08-Сен-17, 11:50 
Есть конструкции из c89, которые не переварятся в c++
Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

76. "Утверждён стандарт C++17"  +1 +/
Сообщение от A.Stahl (ok) on 08-Сен-17, 11:58 
Поэтому я написал "в стиле", а не "согласно стандарту С89".
Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

97. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 08-Сен-17, 14:37 
> попробуй не ловить эксепшены в С++

-fno-exceptions в руки и вперёд.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

123. "Утверждён стандарт C++17"  +1 +/
Сообщение от KroTozeR (ok) on 08-Сен-17, 23:37 
> самое болезненное - нету инициализации структур и юнионов вида
> struct abc {int a, b, c} = {.b = 99};

struct abc {int a, b, c; abc() {b = 99}};
Учи мат.часть.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

125. "Утверждён стандарт C++17"  –1 +/
Сообщение от pripolz on 09-Сен-17, 00:33 
> Учи мат.часть.

я конечно там имя инстанса структуры пропустил, надо было так.

struct abc {int a, b, c} a1 = {.b = 99};

а ты вспорол чушь не по теме.

struct
abc {int a,b,c}
a1 = {.c = 99},
a2 = {.b = 3};

Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

79. "Утверждён стандарт C++17"  +/
Сообщение от Джо on 08-Сен-17, 12:18 
auto_ptr не заюзаешь
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

35. "Утверждён стандарт C++17"  –2 +/
Сообщение от iPony on 08-Сен-17, 06:36 
А gcc уже научился Emoji в именах переменных?
Последний раз как пробовал, в clang работало, а gcc - нет.
И по стандарту с этим что?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

57. "Утверждён стандарт C++17"  +2 +/
Сообщение от FUser on 08-Сен-17, 10:14 
> А gcc уже научился Emoji в именах переменных?

Ну да, куда же без этого, как жили тораньше без Emoji.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

42. "Утверждён стандарт C++17"  +1 +/
Сообщение от Аноним (??) on 08-Сен-17, 08:58 
все последние годы добавляют только свистелки для ленивых.
код со всей этой ботвой только все больше замусоривается.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

60. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 08-Сен-17, 10:48 
Депрекейтнутый язык без нормального юникода и поддержки платформы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

62. "Утверждён стандарт C++17"  +1 +/
Сообщение от Andrey Mitrofanov on 08-Сен-17, 11:07 
> и поддержки платформы.

ВеHдузятники должны. Страдай.

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

70. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 08-Сен-17, 11:33 
macOS & *BSD
Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

102. "Утверждён стандарт C++17"  +/
Сообщение от Аномномномнимус on 08-Сен-17, 15:21 
Просто у кого-то руки из ЖЖ, всё в BSD ок с юникодами и прочим
Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

103. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 08-Сен-17, 15:23 
Golang и Rust действительно хорош!
Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

138. "Утверждён стандарт C++17"  –2 +/
Сообщение от Аноним (??) on 09-Сен-17, 15:54 
> без нормального юникода

О каком юникоде вы все говорите? Сколько не пользуюсь C++ ни разу проблем с кодировкой не было.

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

139. "Утверждён стандарт C++17"  +5 +/
Сообщение от Аноним (??) on 09-Сен-17, 18:27 
Не пользуйся и дальше. Кто-то мешает?
Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

67. "Утверждён стандарт C++17"  +2 +/
Сообщение от pripolz on 08-Сен-17, 11:26 
> и функции Бесселя

Обмазался. Навека. Почему именно Бесселя?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

75. "Утверждён стандарт C++17"  +1 +/
Сообщение от Аноним (??) on 08-Сен-17, 11:53 
Не вижу особого повода для радости. То, что нужно, не реализовали, вообще ничего. Над вот этим вот списком работа велась почти 4 года. Можно поздравить плюсовиков с очередным проявлением бездарности комитета.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

93. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 08-Сен-17, 13:32 
Так а что нужно-то? Приведи примеры для тех, кто не в теме, плз.
Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

111. "Утверждён стандарт C++17"  +1 +/
Сообщение от Аноним (??) on 08-Сен-17, 18:00 
Самое банальное - модули. Эта тема мусолится ни один год. От C++17 ожидалось очень многое, вышло одно разочарование. Вот, можете почитать:
https://habrahabr.ru/company/infopulse/blog/279927/
https://stdcpp.ru/proposals
Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

87. "Утверждён стандарт C++17"  +/
Сообщение от Lolwat on 08-Сен-17, 13:04 
Модно и молодёжно. Я сам предпочитаю Си, но развитее плюсов тоже радует.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

92. "Утверждён стандарт C++17"  +/
Сообщение от iZEN (ok) on 08-Сен-17, 13:24 
Да, да, "алгоритмы + структуры данных = программы" - наше всё.
Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

159. "Утверждён стандарт C++17"  +/
Сообщение от Алексей (??) on 24-Сен-17, 13:34 
лишь бы что сказать, c++ отнюдь не молодёжный, молодежным я бы назвал Python
Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

91. "Утверждён стандарт C++17"  –2 +/
Сообщение от iZEN (ok) on 08-Сен-17, 13:21 
> Добавлены дополнительные математические функции, включая эллиптические интегралы и функции Бесселя

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

95. "Утверждён стандарт C++17"  +5 +/
Сообщение от Andrey Mitrofanov on 08-Сен-17, 13:38 
>> Добавлены дополнительные математические функции, включая эллиптические интегралы и функции Бесселя
> Это чё же, ещё один шаг к искусственному интеллекту в старейшем языке?

изя, каклькулятор -- не ИИ.

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

99. "Утверждён стандарт C++17"  +/
Сообщение от Я. Р. Ош on 08-Сен-17, 14:47 
На чём там, говоришь, жабка написана?
Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

101. "Утверждён стандарт C++17"  +1 +/
Сообщение от Аноним (??) on 08-Сен-17, 15:08 
Модули где?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

105. "Утверждён стандарт C++17"  +3 +/
Сообщение от Led (ok) on 08-Сен-17, 15:39 
> Модули где?

В Турбо-паскале.

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

108. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 08-Сен-17, 17:44 
У Сиплюсплюсников вместо модулей шаблоны используются!
Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

110. "Утверждён стандарт C++17"  +/
Сообщение от Аноним (??) on 08-Сен-17, 17:57 
Каким боком шаблоны заменили модули? И зачем уже много лет пытаются протянуть в стандарт модули если в с++ уже есть шаблоны?
Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

115. "Утверждён стандарт C++17"  –2 +/
Сообщение от Аноним (??) on 08-Сен-17, 18:07 
Чем модули отличаются от либ со статической/динамической линковкой?
Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

117. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 08-Сен-17, 18:39 
> Чем модули отличаются от либ со статической/динамической линковкой?

Ничем.


Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

156. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 13-Сен-17, 08:44 
Чем грузины.
Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

116. "Утверждён стандарт C++17"  –1 +/
Сообщение от Аноним (??) on 08-Сен-17, 18:39 
> Каким боком шаблоны заменили модули?

Никаким. просто шаблон -- это единица "простыни".

>И зачем уже много лет пытаются протянуть в стандарт модули если в с++ уже есть шаблоны?

Наверно дураки пытаются потому-что они не знают, что модуль -- это паскалевский термин. Библиотечная функция это Чисто_Си-шный термин.


Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

150. "Утверждён стандарт C++17"  +1 +/
Сообщение от Аноним (??) on 11-Сен-17, 12:08 
Это лучше php или C++ как я понял это одно и тоже
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

153. "Утверждён стандарт C++17"  +/
Сообщение от Анонйм on 13-Сен-17, 02:12 
Да.
Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру