Вообще такое сделал Google и результаты для C++ неутешительные.
Еще бы выступавший на Rust Nation сказал что-то другое :))) Его бы туда просто не пустили. Могу сказать свои ощущения (я могу свободно писать на C++ и на расте, и еще на ряде языков) - для себя я практически не нахожу применения для раста. Он мне после C++ банально не удобен и не выразителен. Пропагандировать что-то и навязывать кому-то свое мнение я не хочу, но оно вот такое.
P.S. А, вот даже нашел свой давнишний комментарий на эту тему. С тех пор принципиально ничего не поменялось - применений для раста в своих разработках по-прежнему не вижу.
Гм, гм, если на элемент связанного списка, после которого нужно вставить новый элемент, уже есть ссылка, то операция вставки - это O(1). Если есть только порядковый индекс i, то это O(i) - нужно "пролистать" до нужного элемента. В случае вектора же это в лучшем случае O(n-i), а в худшем (требуется реаллокация) это O(n). Связные списки имеют свои проблемы, но вот скорость вставки в середину у них ничуть не хуже, чем у вектора.
Разница в том, что это "агрессивный фанатик" не C++, а совсем другого языка на букву "рэ". Восхвалением C++ он никогда не занимался, наоборот - он приходил в статьи, где, по его мнению, занимались "восхвалением C++", и гадил там. Я не просто так порекомендовал вам ознакомиться с его профилем.
А у меня другой вопрос - даже если предположить(!), что вы правы, и обороты "мулька" и т.п. являются, по вашему мнению, "агрессивными" (хотя по моему мнению это сильно напоминает попытку докопаться до столба), как это оправдывает поведение пациента по вышеприведенным ссылкам? :)
По высказываниям одного человека вы судите обо всём комьюнити?
Да если б одного... Просто этот в очередной раз засветился в каментах к статье, которую я читаю, дал повод о себе вспомнить.
Тем более, что с 22 года Роман уже не является активным участником ru-rust.
Извините, не слежу, кто там является активным участником чего. Но если не является - тем лучше для коммьюнити. От таких нужно избавляться. Как говорится, лучше поздно, чем никогда.
По-моему вы просто раздуваете на ровном месте.
А по-моему не на ровном месте. Let's agree to disagree.
Т.е. ничего компилятор из декларации вызываемой функции НЕ учитывает при анализе использования стэк переменных, т.е. по простому будет требовать атрибут на стэке если переменная явно не инициализирована в теле компилируемой функции.
Да нет, я так понимаю (из текста пропозала и из объяснений автора статьи), что будет работать как-то так:
void foo([[indeterminate]] int &arg);
void bar(int &arg);
{
int x;
if (...) {
foo(x); // OK
} else {
bar(x); // Warning
}
}
{
int x;
foo(x); // OK
bar(x); // OK
}
{
int x;
bar(x); // Типа после Васи Пупкина - warning
foo(x); // OK
}
А насчет идеи с переносом [[indeterminate]] из объявления в вызов я в целом согласен, что так было бы лучше:
// Не очень вариант
{
[[indeterminate]] int x;
bar(x);
}
// Вариант получше
{
int x;
bar([[indeterminate]] x);
}
Но вот с таким предложением я не согласен категорически:
Атрибут должен применяться исключительно и только к параметру функции, но не только в декларации, но ещё и в кол сайте.
Это тупо сломает кучу абсолютно рабочего кода наподобие:
int x;
std::cin >> x;
С пропозалом из статьи достаточно будет в декларацию operator>>() добавить для соответствующего аргумента атрибут [[indeterminate]] и васякот, а заставлять расставлять этот атрибут ЕЩЕ И В МЕСТАХ ВЫЗОВА - это бесполезная работа, ничего не дающая абсолютно. В местах вызова он должен расставляться только если речь идет о вызове функций, написанных на старых стандартах без поддержки этого атрибута.
Кстати, только вот на днях беседовал с начинающим программистом C++, который вообще не понимает, зачем нужен const.
Ну пусть попишет без него. Пару раз поищет, где же у него неожиданно поменялись кишки объекта, который он передал в 100500 мест по T& вместо const T& - глядишь, и поймёт.
Вдруг, и вправду, можно сформировать семантику языка так, чтобы было из контекста понятно, какие элементы изменяемые, а какие - нет?
Если под "из контекста" вы подразумеваете "если что-то изменяется, то это не const", то спасибо, но лучше не надо. Константность должна быть частью контракта, потому что это в том числе защита для погромиста от случайных ошибок.
Ну насчёт идеи указывать атрибут при передаче аргумента при вызове функции, а не в момент объявления переменной я и сам уже думал, но тут хочу возразить - вопрос-то от вас был тут вот какой:
Вот в вашем же примере (где атрибут только на стэке) если функция (без атрибута) будет сначало читать, а потом писать будет хотя бы ворнинг?
Ну а теперь представьте, что вы в месте объявления соответствующей переменной (или вызова, как вы предлагаете) указали атрибут, а в очередной версии dllки (сторонней, которую вы не можете контролировать, и в заголовочном файле которой в декларации соответствующей функции никакого атрибута нет, ибо она написана под предыдущий стандарт) взяли и поменяли логику, и теперь там функция из соответствующего аргумента сначала читает, а потом в него пишет. Никакой ворнинг тут ни один язык не выдаст, нет средств у компилятора об этом изменении логики узнать. Вот я что имел в виду.
Ну вот вы и подтвердили мои подозрения, что без использования этого атрибута на стэке он вообще не работает.
Ну я вообще понял по-другому - что если в декларации функции указан этот атрибут для аргумента, то он как бы автоматически распространится на ту переменную на стеке, которая скажем будет передана по ссылке в качестве этого аргумента. Т.е. вот тут:
void fill([[indeterminate]] int &arg);
int x;
fill(x);
erroneous behavior не возникнет, даже если x объявлена без атрибута. А на стеке этот атрибут нужно указывать только если он не используется в сигнатуре соответствующего метода или оператора (потому что соответствующий код написан под предыдущий стандарт). Но, честно говоря, этот момент действительно не очень понятен. Подождём разъяснений начальника транспортного цеха.
Насчёт указания атрибута при использовании переменной, а не при её объявлении, возможно, есть какие-то неочевидные подводные камни, которых я пока не вижу.
Ну вот представьте, публикует некто в научном журнале статью, посвящённую там, условно, неким направлениям в решении какой-то проблемы СТО/ОТО. Целевая аудитории статьи - люди, которые интересуются вопросом, стало быть, они знакомы с проблематикой, вопросов к матаппарату у них тоже нет, просто кто-то считает какие-то направления бесперспективными, кто-то предлагает что-то свое, и так далее. И тут внезапно в обсуждение врывается школотрон, который с ходу заявляет, что ему мол ничего не понятно, что ещё за тензорное исчисление такое, хамит автору и требует(sic!) все изложить от Адама и Евы на уровне, доступном человеку с тремя классами образования. Абсурд? Да, абсурд. Но пациент ведёт себя именно так.
Вот в вашем же примере (где атрибут только на стэке) если функция (без атрибута) будет сначало читать, а потом писать будет хотя бы ворнинг?
В общем случае это невозможно проверить, ибо тело функции на этапе компиляции может быть недоступно и находиться в статической или динамической библиотеке в уже скомпилированном виде. Компилятору будет доступна только декларация прототипа (причём в составе сторонней библиотеки, над которой в общем случае у вас нет контроля, т.е. вы не можете подправить эту декларацию тем или иным образом).
Честно говоря я вообще не понимаю зачем этот атрибут для стэка?
Затем, что без этого атрибута будет erroneous behavior, поскольку компилятор не уверен, что функция запишет в переменную до того, как прочтёт из неё (напомню, что реализация функции компилятору может быть недоступна, см. выше). Но если вы уверены, что это действительно так, то ставите атрибут и erroneous behavior отключается. Это opt-out механизм. Прочтите P2795 по ссылке в статье, там все подробно расписано.
Если я прав в своем подозрении, то это эпик фэйл и не зря так называемые лоббисты хотят разогнать плюсы и его комитет как проф не пригодных.
Предложите "более лучший" пропозал. Это открытый процесс.
Все правильно в этом примере. Если в режиме насыщения из 5 вычесть 10, то получится 0, wrap around, как при модульной арифметике, не произойдет. Все еще непонятно, почему вы решили, что 0 тут - "невалидное значение".
Из этих примеров мне понятно одно: при таком вычитании значение 0 является невалидным для unsigned short.
Почему вы так решили?
Кажется, в комитете сидят умные люди и должны понимать, что средствами диапазона [a, b] нельзя выразить признак, что значение X не входит в этот диапазон.
Это вообще никак не связано с "выражением признака, что значение X не входит в диапазон". Просто для некоторых применений (например, цифровая обработка сигналов) быстрая арифметика с насыщением выгодна. Видимо, это сделано с прицелом на то, что компилятор будет лучше оптимизировать такую арифметику с использованием специализированных наборов процессорных инструкций там, где это поддерживается (DSP extensions на ARM, инструкций наподобие _mm_adds_XXX из SSE, и т.д).
Как начинаю читать статьи про плюсы, так у меня крышу срывает от наплевательского отношения к читателю.
Так не читайте :) Не мучайте себя и не мусорите своими комментариями профессионального незнайки. Вы просто не являетесь целевой аудиторией данной статьи.
Ну да, ну да.
Еще бы выступавший на Rust Nation сказал что-то другое :))) Его бы туда просто не пустили. Могу сказать свои ощущения (я могу свободно писать на C++ и на расте, и еще на ряде языков) - для себя я практически не нахожу применения для раста. Он мне после C++ банально не удобен и не выразителен. Пропагандировать что-то и навязывать кому-то свое мнение я не хочу, но оно вот такое.
P.S. А, вот даже нашел свой давнишний комментарий на эту тему. С тех пор принципиально ничего не поменялось - применений для раста в своих разработках по-прежнему не вижу.
Гм, гм, если на элемент связанного списка, после которого нужно вставить новый элемент, уже есть ссылка, то операция вставки - это O(1). Если есть только порядковый индекс i, то это O(i) - нужно "пролистать" до нужного элемента. В случае вектора же это в лучшем случае O(n-i), а в худшем (требуется реаллокация) это O(n). Связные списки имеют свои проблемы, но вот скорость вставки в середину у них ничуть не хуже, чем у вектора.
А давайте без давайте :) Я так понимаю, тема себя исчерпала.
Разница в том, что это "агрессивный фанатик" не C++, а совсем другого языка на букву "рэ". Восхвалением C++ он никогда не занимался, наоборот - он приходил в статьи, где, по его мнению, занимались "восхвалением C++", и гадил там. Я не просто так порекомендовал вам ознакомиться с его профилем.
А у меня другой вопрос - даже если предположить(!), что вы правы, и обороты "мулька" и т.п. являются, по вашему мнению, "агрессивными" (хотя по моему мнению это сильно напоминает попытку докопаться до столба), как это оправдывает поведение пациента по вышеприведенным ссылкам? :)
Вы явно что-то перепутали насчёт "агрессивного фанатика C++" :) Ознакомьтесь с профилем пациента получше.
В качестве примера токсичности я выбрал два случая (на самом деле три), когда пациент просто приходит и начинает поливать клоунами, долбо@бами, и.т.д.
И что? Типа раст можно "восхвалять", а C++ - нет? Вот за это вас и не любят (С) :)
Да если б одного... Просто этот в очередной раз засветился в каментах к статье, которую я читаю, дал повод о себе вспомнить.
Извините, не слежу, кто там является активным участником чего. Но если не является - тем лучше для коммьюнити. От таких нужно избавляться. Как говорится, лучше поздно, чем никогда.
А по-моему не на ровном месте. Let's agree to disagree.
Да нет, я так понимаю (из текста пропозала и из объяснений автора статьи), что будет работать как-то так:
А насчет идеи с переносом
[[indeterminate]]из объявления в вызов я в целом согласен, что так было бы лучше:Но вот с таким предложением я не согласен категорически:
Это тупо сломает кучу абсолютно рабочего кода наподобие:
С пропозалом из статьи достаточно будет в декларацию
operator>>()добавить для соответствующего аргумента атрибут[[indeterminate]]и васякот, а заставлять расставлять этот атрибут ЕЩЕ И В МЕСТАХ ВЫЗОВА - это бесполезная работа, ничего не дающая абсолютно. В местах вызова он должен расставляться только если речь идет о вызове функций, написанных на старых стандартах без поддержки этого атрибута.Ну пусть попишет без него. Пару раз поищет, где же у него неожиданно поменялись кишки объекта, который он передал в 100500 мест по
T&вместоconst T&- глядишь, и поймёт.Если под "из контекста" вы подразумеваете "если что-то изменяется, то это не
const", то спасибо, но лучше не надо. Константность должна быть частью контракта, потому что это в том числе защита для погромиста от случайных ошибок.P.S.
Приняли пока только в черновик. Думаю, что будет ещё дорабатываться.
Ну насчёт идеи указывать атрибут при передаче аргумента при вызове функции, а не в момент объявления переменной я и сам уже думал, но тут хочу возразить - вопрос-то от вас был тут вот какой:
Ну а теперь представьте, что вы в месте объявления соответствующей переменной (или вызова, как вы предлагаете) указали атрибут, а в очередной версии dllки (сторонней, которую вы не можете контролировать, и в заголовочном файле которой в декларации соответствующей функции никакого атрибута нет, ибо она написана под предыдущий стандарт) взяли и поменяли логику, и теперь там функция из соответствующего аргумента сначала читает, а потом в него пишет. Никакой ворнинг тут ни один язык не выдаст, нет средств у компилятора об этом изменении логики узнать. Вот я что имел в виду.
Ну я вообще понял по-другому - что если в декларации функции указан этот атрибут для аргумента, то он как бы автоматически распространится на ту переменную на стеке, которая скажем будет передана по ссылке в качестве этого аргумента. Т.е. вот тут:
erroneous behavior не возникнет, даже если
xобъявлена без атрибута. А на стеке этот атрибут нужно указывать только если он не используется в сигнатуре соответствующего метода или оператора (потому что соответствующий код написан под предыдущий стандарт). Но, честно говоря, этот момент действительно не очень понятен. Подождём разъяснений начальника транспортного цеха.Насчёт указания атрибута при использовании переменной, а не при её объявлении, возможно, есть какие-то неочевидные подводные камни, которых я пока не вижу.
Ну вот представьте, публикует некто в научном журнале статью, посвящённую там, условно, неким направлениям в решении какой-то проблемы СТО/ОТО. Целевая аудитории статьи - люди, которые интересуются вопросом, стало быть, они знакомы с проблематикой, вопросов к матаппарату у них тоже нет, просто кто-то считает какие-то направления бесперспективными, кто-то предлагает что-то свое, и так далее. И тут внезапно в обсуждение врывается школотрон, который с ходу заявляет, что ему мол ничего не понятно, что ещё за тензорное исчисление такое, хамит автору и требует(sic!) все изложить от Адама и Евы на уровне, доступном человеку с тремя классами образования. Абсурд? Да, абсурд. Но пациент ведёт себя именно так.
В общем случае это невозможно проверить, ибо тело функции на этапе компиляции может быть недоступно и находиться в статической или динамической библиотеке в уже скомпилированном виде. Компилятору будет доступна только декларация прототипа (причём в составе сторонней библиотеки, над которой в общем случае у вас нет контроля, т.е. вы не можете подправить эту декларацию тем или иным образом).
Затем, что без этого атрибута будет erroneous behavior, поскольку компилятор не уверен, что функция запишет в переменную до того, как прочтёт из неё (напомню, что реализация функции компилятору может быть недоступна, см. выше). Но если вы уверены, что это действительно так, то ставите атрибут и erroneous behavior отключается. Это opt-out механизм. Прочтите P2795 по ссылке в статье, там все подробно расписано.
Предложите "более лучший" пропозал. Это открытый процесс.
А вы, простите, точно понимаете, как
assert()работает? А то создается такое впечатление, что нет.Все правильно в этом примере. Если в режиме насыщения из 5 вычесть 10, то получится 0, wrap around, как при модульной арифметике, не произойдет. Все еще непонятно, почему вы решили, что 0 тут - "невалидное значение".
Почему вы так решили?
Это вообще никак не связано с "выражением признака, что значение X не входит в диапазон". Просто для некоторых применений (например, цифровая обработка сигналов) быстрая арифметика с насыщением выгодна. Видимо, это сделано с прицелом на то, что компилятор будет лучше оптимизировать такую арифметику с использованием специализированных наборов процессорных инструкций там, где это поддерживается (DSP extensions на ARM, инструкций наподобие
_mm_adds_XXXиз SSE, и т.д).Так не читайте :) Не мучайте себя и не мусорите своими комментариями профессионального незнайки. Вы просто не являетесь целевой аудиторией данной статьи.
Вы и убили-с.