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

"Утверждён стандарт 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 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 (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 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 (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 (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 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 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 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 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 | Индекс форумов | Темы | Пред. тема | След. тема