Да строго говоря вообще малоосмысленный пост. Всё, про что рассказали, так это про уникальность типа лямбды. Можно было уместить в одну строчку: "тип лямбды уникален". Дальше же пошёл какой-то странный вброс о какой-то "будущей фиче С++", непонятно откуда и почему. Можно хотя бы пропозал? Не то чтобы такой пропозал имел шанс пройти.
Note – не является нормативной частью стандарта. Это не является гарантией, note не обязывает компилятор это выполнять. Правильным ответом было бы "указывает компилятору, что значение данной переменной может неожиданно измениться извне..." К этому можно было бы добавить "... вследствие чего агрессивные оптимизации обычно отключены для переменных с этим квалификатором".
По сути всё, что говорит стандарт на тему волатайла, это именно эта часть: https://eel.is/c++draft/dcl.type.cv#5
Note ниже просто дополнительное объяснение, помощь в трактовании. Но никак не точное значение, гарантия или обязательство для имплементации.
Если интересует где можно понять, почему Note не даёт никаких гарантий, то рекомендую посмотреть вот этот документ, часть 8.2: https://www.google.com/url?sa=t&source=web&rct=j&url=https://ec.europa.eu/eurostat/cros/system/files/ISO%2520reference%2520definitions%2520-%2520%2520guide%25202%2520-%25202004%2520-%2520rev.doc&ved=2ahUKEwjc2rHU9MH5AhVUCBAIHdL5CNkQFnoECCUQAQ&usg=AOvVaw2nLbbk204oJGuKGPgGyuGR
Просто чтобы вы понимали, то, что написано в Note, не значит, что стандарт говорит, что компилятор обязан не оптимизировать. Note – это разъясняющая, ненормативная часть стандарта, которая не даёт никаких гарантий. Их, конечно, пишут, чтобы дать дополнительное объяснение и обычно они соответствуют реальности... Хотя, например, есть ноуты, в которых написано, что разыменование nullptr это UB, хотя сам стандарт этого не доказывает.
В любом случае вы выделяете почему-то совершенно неверные части разъяснения. Вы должны были выделить "because the value of the object might be changed by means undetectable by an implementation". Это причина. Это то, что обозначает волатайл. То, что компилятор не оптимизирует агрессивно, хотя _всё равно_ оптимизирует, лишь следствие, т.к. если бы он слишком агрессивно оптимизировал, наблюдаемое поведение программы могло бы отличаться от написанного, что запрещено. Я надеюсь вы умеете отличать причину от следствия?
Спасибо за подтверждение моего тезиса. Наверно, теперь всем очевидно, что да, volatile указывает компилятору на то, что следует избежать оптимизаций, но это не предназначение, а _потому что_ "because the value of the object might be changed by means undetectable by an implementation". Как можно заметить, выключение ряда оптимизаций является следствием. Т.е. волатайл обозначает переменную, которая может быть изменена извне. Он не выключает абсолютно все оптимизации, это и не является целью. Если бы компиляторщики нашли способ агрессивно оптимизировать даже в случае изменений извне, они бы это сделали. В тесте же единственное предназначение волатайла для отключения оптимизаций. Смешно.
Не учитывая того факта, что это ненормативная часть стандарта, Note. Что-то вроде разъяснений, которые не дают никаких гарантий.
А вы уверены, что составители теста знали С++? Или они застряли где-то в прошлых стандартах, и то не до конца изучив их? Например вопрос про порядок вызова функций имел бы другой ответ в С++17. Последний вопрос бредовый, ибо ладно, допустим, что не запрещено действительно Может быть уб... Но и разрешено тоже, в общем-то, т.к. уб ещё никто не запрещал – это просто поведение, на которое стандарт не налагает никаких требований. Что значит запрещено вообще, ill-formed? С volatile бред, конечно. Нет, абсолютно, совершенно нет, значение слова volatile не отключение компиляторных оптимизаций. Потрудитесь перед составлением теста убедиться в собственной экспертизе.
Гм, ну, так любую работу с байтами на любом языке можно назвать абстракцикй над Си. А там и над ассемблером. Но банально вот до С++20 множество способов, которыми ковыряли и ковыряют байты в Си были попросту запрещены и приводили к неопределённому поведению. Ну а то, что всюду и везде Си апи это да. Но так, если докопаться, везде устроено – что-то в конечном итоге да будет дёргать код, написанный на Си. Это ведь всё ещё не значит, что любая работа с байтами в любом языке Си-way...
Вы, наверно, не в курсе, что запаривание алайнментом, аллокациями и т.д. ещё не значит, что это вообще как-то связано с Си. И то, что в С11, равно как и в С++11, вошёл тот же alignas, ещё не делает написание его или размышление над подобными вещами сишным.
Да и написание своих аллокаторов, вот просто как вообще можно подвязать к Си? Особенно учитывая, что в большинстве случаев такие вещи как аллокаторы выглядят абсолютно иначе, чем как если бы их писали на Си. Тем более что в С++ появляется куча вопросов, которые не так ярко выражены, либо которых вообще нет в Си, таких как пропагировать ли аллокатор на копировании, на перемещении и т.д.
Честно, меня искренне удивляет, когда говоря о низкоуровневых манипуляциях с памятью, люди в большинстве случаев обязательно имеют в виду Си, хотя С++ точно так же имеет кучу средств для этого и, откровенно говоря, выразительнее в этом плане. Даже на собеседовании однажды пришлось писать на Си, под предлогом "ну нам же надо увидеть как вы умеете манипулировать памятью". И честно скажу, с непривычки и из-за необходимости думать о вещах, о которых я обычно не думаю, я допустил ошибку в том коде.
За вторым наблюдал, классно, что приняли. Я думал языковые фичи уже не принимают. Но если всё же принимают, возможно, есть шанс, что ещё войдёт это: https://wg21.link/p1061r1?
Мне кажется, очень полезная возможность, в свете отсутствия особых подвижек в сторону статической рефлексии.
А что насчёт судьбы нетворкинга? Если я не ошибаюсь, плановая встреча с его обсуждением была как раз в этот понедельник.
Выглядит интересно. Но что насчёт основных ожидаемых фич? Экзекуторы и нетворкинг всё же успевают к С++23? На рефлексию, я так понял, надеяться смысла нет.
Также не очень понятно, в чём преимущество spanstream перед обычными stringstream(может, стоило бы прочитать пропозал, но не прочитал пока).
Да строго говоря вообще малоосмысленный пост. Всё, про что рассказали, так это про уникальность типа лямбды. Можно было уместить в одну строчку: "тип лямбды уникален". Дальше же пошёл какой-то странный вброс о какой-то "будущей фиче С++", непонятно откуда и почему. Можно хотя бы пропозал? Не то чтобы такой пропозал имел шанс пройти.
Note – не является нормативной частью стандарта. Это не является гарантией, note не обязывает компилятор это выполнять. Правильным ответом было бы "указывает компилятору, что значение данной переменной может неожиданно измениться извне..." К этому можно было бы добавить "... вследствие чего агрессивные оптимизации обычно отключены для переменных с этим квалификатором".
По сути всё, что говорит стандарт на тему волатайла, это именно эта часть: https://eel.is/c++draft/dcl.type.cv#5
Note ниже просто дополнительное объяснение, помощь в трактовании. Но никак не точное значение, гарантия или обязательство для имплементации.
Если интересует где можно понять, почему Note не даёт никаких гарантий, то рекомендую посмотреть вот этот документ, часть 8.2: https://www.google.com/url?sa=t&source=web&rct=j&url=https://ec.europa.eu/eurostat/cros/system/files/ISO%2520reference%2520definitions%2520-%2520%2520guide%25202%2520-%25202004%2520-%2520rev.doc&ved=2ahUKEwjc2rHU9MH5AhVUCBAIHdL5CNkQFnoECCUQAQ&usg=AOvVaw2nLbbk204oJGuKGPgGyuGR
Просто чтобы вы понимали, то, что написано в Note, не значит, что стандарт говорит, что компилятор обязан не оптимизировать. Note – это разъясняющая, ненормативная часть стандарта, которая не даёт никаких гарантий. Их, конечно, пишут, чтобы дать дополнительное объяснение и обычно они соответствуют реальности... Хотя, например, есть ноуты, в которых написано, что разыменование nullptr это UB, хотя сам стандарт этого не доказывает.
В любом случае вы выделяете почему-то совершенно неверные части разъяснения. Вы должны были выделить "because the value of the object might be changed by means undetectable by an implementation". Это причина. Это то, что обозначает волатайл. То, что компилятор не оптимизирует агрессивно, хотя _всё равно_ оптимизирует, лишь следствие, т.к. если бы он слишком агрессивно оптимизировал, наблюдаемое поведение программы могло бы отличаться от написанного, что запрещено. Я надеюсь вы умеете отличать причину от следствия?
Спасибо за подтверждение моего тезиса. Наверно, теперь всем очевидно, что да, volatile указывает компилятору на то, что следует избежать оптимизаций, но это не предназначение, а _потому что_ "because the value of the object might be changed by means undetectable by an implementation". Как можно заметить, выключение ряда оптимизаций является следствием. Т.е. волатайл обозначает переменную, которая может быть изменена извне. Он не выключает абсолютно все оптимизации, это и не является целью. Если бы компиляторщики нашли способ агрессивно оптимизировать даже в случае изменений извне, они бы это сделали. В тесте же единственное предназначение волатайла для отключения оптимизаций. Смешно.
Не учитывая того факта, что это ненормативная часть стандарта, Note. Что-то вроде разъяснений, которые не дают никаких гарантий.
А вы уверены, что составители теста знали С++? Или они застряли где-то в прошлых стандартах, и то не до конца изучив их? Например вопрос про порядок вызова функций имел бы другой ответ в С++17. Последний вопрос бредовый, ибо ладно, допустим, что не запрещено действительно Может быть уб... Но и разрешено тоже, в общем-то, т.к. уб ещё никто не запрещал – это просто поведение, на которое стандарт не налагает никаких требований. Что значит запрещено вообще, ill-formed? С volatile бред, конечно. Нет, абсолютно, совершенно нет, значение слова volatile не отключение компиляторных оптимизаций. Потрудитесь перед составлением теста убедиться в собственной экспертизе.
Гм, ну, так любую работу с байтами на любом языке можно назвать абстракцикй над Си. А там и над ассемблером. Но банально вот до С++20 множество способов, которыми ковыряли и ковыряют байты в Си были попросту запрещены и приводили к неопределённому поведению. Ну а то, что всюду и везде Си апи это да. Но так, если докопаться, везде устроено – что-то в конечном итоге да будет дёргать код, написанный на Си. Это ведь всё ещё не значит, что любая работа с байтами в любом языке Си-way...
Вы, наверно, не в курсе, что запаривание алайнментом, аллокациями и т.д. ещё не значит, что это вообще как-то связано с Си. И то, что в С11, равно как и в С++11, вошёл тот же alignas, ещё не делает написание его или размышление над подобными вещами сишным.
Да и написание своих аллокаторов, вот просто как вообще можно подвязать к Си? Особенно учитывая, что в большинстве случаев такие вещи как аллокаторы выглядят абсолютно иначе, чем как если бы их писали на Си. Тем более что в С++ появляется куча вопросов, которые не так ярко выражены, либо которых вообще нет в Си, таких как пропагировать ли аллокатор на копировании, на перемещении и т.д.
Честно, меня искренне удивляет, когда говоря о низкоуровневых манипуляциях с памятью, люди в большинстве случаев обязательно имеют в виду Си, хотя С++ точно так же имеет кучу средств для этого и, откровенно говоря, выразительнее в этом плане. Даже на собеседовании однажды пришлось писать на Си, под предлогом "ну нам же надо увидеть как вы умеете манипулировать памятью". И честно скажу, с непривычки и из-за необходимости думать о вещах, о которых я обычно не думаю, я допустил ошибку в том коде.
За вторым наблюдал, классно, что приняли. Я думал языковые фичи уже не принимают. Но если всё же принимают, возможно, есть шанс, что ещё войдёт это: https://wg21.link/p1061r1?
Мне кажется, очень полезная возможность, в свете отсутствия особых подвижек в сторону статической рефлексии.
А что насчёт судьбы нетворкинга? Если я не ошибаюсь, плановая встреча с его обсуждением была как раз в этот понедельник.
Разве их кто-то добавил?
Выглядит интересно. Но что насчёт основных ожидаемых фич? Экзекуторы и нетворкинг всё же успевают к С++23? На рефлексию, я так понял, надеяться смысла нет.
Также не очень понятно, в чём преимущество spanstream перед обычными stringstream(может, стоило бы прочитать пропозал, но не прочитал пока).