Ну я историю с++ так детально не знаю, но период до шаблонов вообще можно не считать потому что это не с++, а фигня какая-то, которой пользовались 3 калеки.
Так историческая справка, забавно что первый раз про с++ я узнал из та-дам телевизора в 98 году, из новости что наконец то родили ёжика, с++98. Помню как показывали радующегося страуса. Я тогда из программирования мог только - да ничего толком.
Конечно не причем, наймспэйсы то были, да и вообще свой не совместимый с си манглин имён с самого начала. Модули в этом плане очень рядом конкретно Си никак немашал их запилить ещё тогда.
Да, и т.е. спустя сколько там 40 лет комитет таки запили модули и ничего не отвалилось. Мало того он и сам из хотел сделать, но типа и так пойдет. Си здесь вообще не причем.
constexpr означает const. Конст для переменных объявленных в глобальном скоупе (а именно там обычно дефайнят константы в си) подразумевает static. Поэтому constexpr и static constexpr для переменных в глобальном скоупе это синонимы.
НО статик означает интернал линкэдж, это значит что в каждом цпп файле где инклудится хидер с глобальным констэкспром МОЖЕТ (но не обязан) иметь отдельный сторэдж под эту переменную, что может привести к росту размера бинарника. Если у такой переменной берется адрес, то тогда ТОЧНО будет выделен отдельный сторэдж в каждом цппшнике где берется адрес.
Зачем нужен инлайн? Инлайн означает экстернал линкэдж, это значит что ВСЕ переменные обязаны иметь ровно один сторэдж в независимости от того сколько цппшников берет адрес. Это может не позволить расти размеру бинарника.
Когда деревья были выше, а трава зеленее то сначало читали толмуд Страуструпа, а только потом нажимали кнопки на клавиатуре. Сегодня же сначало пишут программу, а что то читать начинают когда вылезают проблемы. И это хорошо, интернет позволяет так делать, а раньше так бы не получилось. Но да, очень забавно наблюдать как элементарная проблема вызвала столько бурлений.
Но давайте признаем, что виноват на самом деле страус, изобретая с++ он почему то решил что модули это для слабоков, настоящие хакеры помещают весь проект целиком в голову и не допускают таких банальных ошибок.
Хороший писатель != хороший читатель. Из опыта я знаю, что хороший читатель на вес золота, очень редкая птица. Но это навык, который тренируется так же как и решение олимпиадных задач, как подготовка к собеседованиям в фаанги. Правда я не знаю как тренироваться эффективно, не могу ничего посоветовать. Хотя. На моей 3 работе у нас была практика дежурства - это когда один программист весь спринт (2 недели) занимается исключительно и только фиксом крашей. На сегодняшний день я пересмотрел тысячи кол стэков и пофиксил около тысячи крашей и уверен что эта практика помогает не только быть аккуратнее с УБ в своем коде, но и значительно развивает навык чтения в целом. Но первые свои такие дежурства вспоминаются очень больно, сидишь как дурак и пялишься в стэк часами не понимаю буквально все, но это проходит довольно быстро. Писать новый код значительно легче чем чинить старый - тренируйтесь на крышах и багах, они значительно лучше развивают навык чтения кода чем написание нового кода.
Тесты.
Юниты, тдд, моки и прочие баз ворды не помогают. Помогают тесты которые проверяют ожидаемое поведение вашего продукта, а не куска кода. Такие тесты очень устойчивы к изменениям в реализации, не требуют много подготовительной работы и самые понятные. Если ваш продукт это библиотека то тесты которые проверяют его называются юнит тесты, если изолированная фича /микросеовис то интеграционные, если приложение то энд ту энд. Не надо тратить ресурсы на не те тесты, сосредоточьтесь на тех которые будут больше всего полезны вашему продукту.
Комментарии.
Я их не читаю, но пишу. Пишу когда вопрос почему я сделал что то не так как обычно/другие. Что делает код я могу разобраться всегда, зачем он делает именно это я могу узнать из баг трэкера, а вот почему часто не может ответить и сам автор.
Документация.
Не нужна, если есть доступ к исходникам, нужна если нет.
Помощь коллег.
Я тут посмотрел код и вижу что он делает вот это (детальное описание), через гит нашел пару тикетов и вижу зачем он это делает (пункты из задач). В моем тикете мне нужно сделать вот так (описание задачи и предполагаемое решение а лучше пара). Для этого мне нужно поменять вот этот кусок код, но я не знаю почему он делает так и не сломаю ли я что то если переделаю. Из Гита я вижу что ты работал над этим кодом, расскажи какие риски ты видишь или к кому обратиться за помощью. Вот такой запрос о помощи не игнорируется никогда - надо быть готовым к тому что бы вам помогли.
Чаще всего вместо этого я вижу дичь на ревью, потому что человек не захотел подготовиться, а потом начинает активно защищаться когда я заставляю исправить код.
Есть ли гендерный дисбаланс в айти? Есть - это факт который никто не отрицает. Есть ли разница в работе мозга мужчин и женщин - тут уже сложнее в зависимости от того что вы игнорируете как не относящиеся к вопросу и как в целом производите измерения. Я это к чему? К тому что не составит труда сделать исследования которые продемонстрируют оба ответа. Дело в том что бы доказать тотальность в данном случае тождество между мозгом мужчин и женщин нужно значительно больше усилий чем доказать обратное. Чтобы доказать что мозги работают все таки по разному достаточно 1 исследования в ЛЮБОЙ области работы мозга, а вот доказать тождество одной парой, даже набором статей НЕ достаточно. Короче здравый смысл заставляет сильно сомневаться с таким сильным утверждением, что мозги работают одинаково и что бы убедить людей вам придется предоставить очень серьезные доказательства. Те что вы предоставили не вызывают достаточного доверия.
Наличие детей в семье обоих полов говорит о прямо противоположном - у детей мозги ни чем не промыты, а разница в поведении и в том как они справляются с задачами буквально очевидна и сильно коррелирует с полом. Т.е. недостаточно просто предоставить набор исследований не вызывающих доверия которые просто констатирует отстувие разницы нужно ещё как то объяснить почему ее нет, почему физиология не влияет и т.д. Короче шансов у вас убедить большинство в том что разницы нет очень мало.
НО это все фигня - детали. Принципиальный вопрос звучит так - да есть дисбаланс, но почему вы считаете, что это проблема? Более частный вопрос почему вы думаете что устранение дисбаланса решит проблему? А может (крамольная мысль) усиление дисбаланса это лучше?
Начните с основ с пастоновки вопроса/проблемы. Объясните почему 50/50 имеет хоть какой то объективный смысл? Короче с мат частью в вашей статье много проблем она только выглядит наукообразной, но по существу, банальное рацианализаторство.
Лженерики в расте намного слабее темплэйтов плюсовых, как и поддержка компил тайм вычислений в с++ лучше, так что пока раст не догонит с++ в этих аспектах у с++ ещё пока есть чем уделать раст.
Извините, я написал ответ, а сраный хабр его куда в дев нул отправил, а писал я долго и было обидно, но переписывать это с телефона я больше не буду - код на хабре с телефона это просто невыносимая боль. В кратце да, template<template...> для концептов не завезли, что делает их просто сахаром без принципиальных новшеств и менее выразительными чем то же самое на сфинае, но ниша для них есть конечно.
Вы ими то пробовали пользоваться как следует, а не поиграться? Концепты ущербные примерно такие же как лженерики(опечатался, а потом понял что это лучшее их описание) в расте. Без сфинае с++ шаблоны вообще ни о чём. Для самостоятельного курения почему я так считаю вам стоит попробовать реализовать аналог шаблон шаблона на концептах - это не возможно. Если убрать сфинае и параметр паки из с++ то его можно в тот же день закапывать. Единственное, что у страуса получилось так это шаблоны (и то случайно) и это то на что я купился ещё студентом 25 лет назад. Не будь шаблонов, я бы даже и не сунулся в плюсы.
В моем регионе последние пару лет что я слежу все, я повторю ВСЕ из примерно 2 десятков открытых вакансий в любой момент времени это крипта. 3 года назад мне повезло увидеть 1 вакансию на расте и не крипта.
Т.е. вы больше не возражаете, что атрибут на стэке просто опасен. Хотя возможно вы и раньше не возражали, но тогда я не очень понял о чем вы со мной дискутировали.
В любом случае я почитал эти много букв, но мало смысла проползал. Поведение атрибута совершенно гомогенно, что для стэка, что для параметра - полная индульгенция на весь лайфтайм. Т.е. ничего компилятор из декларации вызываемой функции НЕ учитывает при анализе использования стэк переменных, т.е. по простому будет требовать атрибут на стэке если переменная явно не инициализирована в теле компилируемой функции.
Это просто нельзя разрешать использовать т.к. принудительно запрещает компилятору и стат анализаторам сообщать о любых проблемах о которых сегодня они сообщают в каждом месте.
Массовый сценарий - при переходе будет туча эрониус бихэвиоров что-то конечно пофиксят, ну а что-то будет помечено этим атрибутом и тогда ЛЮБОЙ код с такой переменной должен приниматься компилятором как есть без права на ворнинг.
Это хуже чем сейчас само по себе + сейчас я поймаю такую переменную санитайзером и без лишних приседаний сразу пойду это чинить, а с этим атрибутом мне придётся поднимать гит и смотреть это санитайзер глючит или тот кто поставил атрибут был не прав ну или возможно кто то после него - короче лишние приседания перед тем как собственно чинить.
Вот кто то спросит на стэке - у меня эрониус бихэвиор, что мне делать - да просто добавь атрибут - спасибо помогло, а мне потом это чинить - спасибо я такое буду у себя на работе запрещать.
Не за ерониус бихэвиор который ворнинг, а у нас они в ероры принудительно превращаются по настоящему спасибо, а этот опт оут будет просто запрещен - безопаснее по старинке вручную ворнинг подавить в каждом месте чем вот это.
А как тогда получилось у других языков? Там по вашему нету дллек или виртуальных методов? Мало того у них там гарантия даётся, а не какой то невнятный ерониус бихэвиор.
Компилятору будет доступна только декларация прототипа
Я вам секрет чуть ниже открою, компилятору вообще ничего не нужно ни декларации ни определения.
Затем, что без этого атрибута будет erroneous behavior, поскольку компилятор не уверен, что функция запишет в переменную до того, как прочтёт из неё
Ну вот вы и подтвердили мои подозрения, что без использования этого атрибута на стэке он вообще не работает.
Предложите "более лучший" пропозал
Я просто скопирую то что УЖЕ работает в других языках.
Как сейчас в плюсах - на КАЖДОЕ использование неинит переменной компилятор/стат анализ кидает ворнинг. Нельзя одним махом взять и подавить все ворнинги ТОЛЬКО к этой переменной (можно в блоке, файле, программе). Т.е. инструменты требует от вас просмотреть каждый колл сайт и для каждого индивидуально решить фиксить или давить ворнинг.
Как теперь будет (проползал то уже приняли). Вы в ОДНОМ месте ставите атрибут и компилятор затыкается во ВСЕХ кол сайтах. Я не могу усилить форматированием слово во всех ещё сильнее, даже в тех кол сайтах которые ещё только БУДУТ написаны. Это делает проблему использования неинит переменных ещё опасней чем она есть сегодня.
Как это делается в других языках вы и сами можете посмотреть, я лишь могу предложить один из вариантов как это может выглядеть в цпп. Атрибут должен применяться исключительно и только к параметру функции, но не только в декларации, но ещё и в кол сайте.
void sample(){
int hz;
foo([[uninitialised]] &hz);
bar(hz);
}
void foo([[uninitialised]] int& hz){
auto garbage=hz;//error
hz=0;
auto var=hz;
}
void bar(const int& val){
auto var=val;
}
Если удалить атрибут в месте вызова фуу то будет 2 ошибки компиляции. В моем примере при этом для бара атрибут НЕ нужен ЕСЛИ у фуу в декларации тоже есть этот атрибут. Почему? Потому что функция в кол сайте которой есть этот атрибут гарантирует инициализацию аут параметра. Т.е. после вызова фуу хз точно инициализирована в том же самом скоупе (что это значит чуть позже).
Дальше функция фуу находится в чужой либе и вы не можете менять ее (ни декларацию ни определение) - да НЕ проблема ставите как и в примере атрибут в кол сайте, все тоже самое бар уже НЕ требует атрибута. Пришел Вася Пупкин через 5 лет поменял местами фуу и бар и/или вставил фуубар перед фуу и получил ошибку компиляции. И теперь сидит и курит почему так.
Внутри функции чей параметр помечен атрибутом при доступе к параметру ДО инициализации - ошибка компиляции. Ретурн или сроу ДО инициализации параметра - ошибка компиляции. Вызов не ноуэксепт функции/оператора ДО инициализации - ворнинг.
Если кол сайт с атрибутом завернут в трай кэтч, то индульгенция испаряется за пределами скоупа. Например если в моем примере бы фуу была внутри трай, а бар после или внутри кэтча то вызов бара это ошибка компиляции.
Я НИЧЕГО нового здесь не написал, а то что попало в стандарт тупо ещё опасней чем как сейчас.
Подождите, я не понял. Вот в вашем же примере (где атрибут только на стэке) если функция (без атрибута) будет сначало читать, а потом писать будет хотя бы ворнинг?
ИМХО использовать этот атрибут на стэке надо сразу запретить во всех гайдлайнах как опасный. Честно говоря я вообще не понимаю зачем этот атрибут для стэка?
Ещё раз перечитал текст, я начинаю подозревать, что без объявления переменной на стэке с атрибутом, НО пометкой параметра функции филл этим атрибутом компилятор ПРОДОЛЖИТ считать тело сэмпл эрониус.
Если я прав в своем подозрении, то это эпик фэйл и не зря так называемые лоббисты хотят разогнать плюсы и его комитет как проф не пригодных.
А можете подробнее рассказать про индетерминэйт? Из примера создаётся впечатление что этот атрибут стоит не там. В примере он описывает переменную на стэке и вы утверждаете что это говорит компилятору что все ок. Т.е. если функция филл вместо записи сначало прочитает, то все как раньше УБ.
С другой стороны если этот атрибут применить к параметру функции тогда это ИМХО как раз могло бы помочь компилятору диагностировать чтение из неинициализированной переменной.
Ну я не настоящий сварщик, но логически я не вижу как можно померять скорость распространения взаимодействия изолированно только в одном направлении. Исходя из физического смысла этой скорости вам необходимо поменять направление распространение иначе не существует способа определения момента начала/конца распространения. Дело то ведь не в том как синхронизировать часы, нужны то всего 1 часы, а в том как вообще понять когда начинать считать время, или для другого наблюдателя когда заканчивать считать.
Даже если НА САМОМ ДЕЛЕ ™ скорость распространения зависит от чего то, но мы не можем это никак обнаружить, то это просто не важно. Т.е. зачем замерять скорость распространения взаимодействия в одном направлении если на практике такой штуки нету, взаимодействия которыми мы можем управлять всегда туда/обратно, а те которые только к нам они для нас плохо предсказуемое будущее, а те которые от нас это прошлое.
Руку надо переносить на цифровую клавиатуру, хотя честно я понятие не имею как я набираю эти типы - т.е. это вообще не важно. Ну ещё конкретно у этого человека аллергия на цифры, глаза начинают чесаться при чтении, ну бывает, у меня вот аллергия на скобки, у вас ещё на что нибудь - это нормально хотя вероятно не лечится.
Эмбед платформы/СОКи/одноплатники на армах. Это НЕ микроконтроллеры и НЕ вайфай. Они все ещё 32 битные и будут такими ещё очень долго.
А про виндоус смешно было конечно. В общем что и требовалось удостоверить, дальше своего уютного мира вы не выходите, так зачем тогда навязываете свое видение как существенно превосходящее все альтернативы?
Дефайнить ключевые слова запрещено - не скомпилируется. С младшей школы в букварях учат 8 меньше 16 ровно в 2 раза, ну и далее по списку, а вот байт, ворд, дабл ворд, квадрипл ворд которые изначально и были заменили на шорт инт лонг от слабоумия. Зачем нормальным ЛЮДЯМ иметь в голове мапу слова на число и постоянно заниматься приседаниями что бы понимать что больше и что меньше и во сколько раз? Для этого есть числа, они лучше с этим справляются. СайзТ (как и в расте) это именно размер регистра во всех нормальных языках, а если вам байты (их количество) важно - ну например протокол реализовать, то там в 100500 раз лучше иметь и32 и т.д. вместо непонятного инта. Сразу видно, что вы дальше своей платформы ничего не знаете и крос платформ для вас это ругательства. Что написать в коде что бы не усложнять себе жизнь макросами и гарантировано иметь 64 бита везде?
Я не в курсе кто там у вас эталон правильности, но инженеров интела тоже в проф непригодных запишете с их у64, у128, у256, у512 для симд регистров?
Ну я историю с++ так детально не знаю, но период до шаблонов вообще можно не считать потому что это не с++, а фигня какая-то, которой пользовались 3 калеки.
Так историческая справка, забавно что первый раз про с++ я узнал из та-дам телевизора в 98 году, из новости что наконец то родили ёжика, с++98. Помню как показывали радующегося страуса. Я тогда из программирования мог только - да ничего толком.
Конечно не причем, наймспэйсы то были, да и вообще свой не совместимый с си манглин имён с самого начала. Модули в этом плане очень рядом конкретно Си никак немашал их запилить ещё тогда.
Да, и т.е. спустя сколько там 40 лет комитет таки запили модули и ничего не отвалилось. Мало того он и сам из хотел сделать, но типа и так пойдет. Си здесь вообще не причем.
Короткий ответ - inline constexpr
Почему?
constexpr означает const. Конст для переменных объявленных в глобальном скоупе (а именно там обычно дефайнят константы в си) подразумевает static. Поэтому constexpr и static constexpr для переменных в глобальном скоупе это синонимы.
НО статик означает интернал линкэдж, это значит что в каждом цпп файле где инклудится хидер с глобальным констэкспром МОЖЕТ (но не обязан) иметь отдельный сторэдж под эту переменную, что может привести к росту размера бинарника. Если у такой переменной берется адрес, то тогда ТОЧНО будет выделен отдельный сторэдж в каждом цппшнике где берется адрес.
Зачем нужен инлайн? Инлайн означает экстернал линкэдж, это значит что ВСЕ переменные обязаны иметь ровно один сторэдж в независимости от того сколько цппшников берет адрес. Это может не позволить расти размеру бинарника.
Когда деревья были выше, а трава зеленее то сначало читали толмуд Страуструпа, а только потом нажимали кнопки на клавиатуре. Сегодня же сначало пишут программу, а что то читать начинают когда вылезают проблемы. И это хорошо, интернет позволяет так делать, а раньше так бы не получилось. Но да, очень забавно наблюдать как элементарная проблема вызвала столько бурлений.
Но давайте признаем, что виноват на самом деле страус, изобретая с++ он почему то решил что модули это для слабоков, настоящие хакеры помещают весь проект целиком в голову и не допускают таких банальных ошибок.
Код ревью.
Хороший писатель != хороший читатель. Из опыта я знаю, что хороший читатель на вес золота, очень редкая птица. Но это навык, который тренируется так же как и решение олимпиадных задач, как подготовка к собеседованиям в фаанги. Правда я не знаю как тренироваться эффективно, не могу ничего посоветовать. Хотя. На моей 3 работе у нас была практика дежурства - это когда один программист весь спринт (2 недели) занимается исключительно и только фиксом крашей. На сегодняшний день я пересмотрел тысячи кол стэков и пофиксил около тысячи крашей и уверен что эта практика помогает не только быть аккуратнее с УБ в своем коде, но и значительно развивает навык чтения в целом. Но первые свои такие дежурства вспоминаются очень больно, сидишь как дурак и пялишься в стэк часами не понимаю буквально все, но это проходит довольно быстро. Писать новый код значительно легче чем чинить старый - тренируйтесь на крышах и багах, они значительно лучше развивают навык чтения кода чем написание нового кода.
Тесты.
Юниты, тдд, моки и прочие баз ворды не помогают. Помогают тесты которые проверяют ожидаемое поведение вашего продукта, а не куска кода. Такие тесты очень устойчивы к изменениям в реализации, не требуют много подготовительной работы и самые понятные. Если ваш продукт это библиотека то тесты которые проверяют его называются юнит тесты, если изолированная фича /микросеовис то интеграционные, если приложение то энд ту энд. Не надо тратить ресурсы на не те тесты, сосредоточьтесь на тех которые будут больше всего полезны вашему продукту.
Комментарии.
Я их не читаю, но пишу. Пишу когда вопрос почему я сделал что то не так как обычно/другие. Что делает код я могу разобраться всегда, зачем он делает именно это я могу узнать из баг трэкера, а вот почему часто не может ответить и сам автор.
Документация.
Не нужна, если есть доступ к исходникам, нужна если нет.
Помощь коллег.
Я тут посмотрел код и вижу что он делает вот это (детальное описание), через гит нашел пару тикетов и вижу зачем он это делает (пункты из задач). В моем тикете мне нужно сделать вот так (описание задачи и предполагаемое решение а лучше пара). Для этого мне нужно поменять вот этот кусок код, но я не знаю почему он делает так и не сломаю ли я что то если переделаю. Из Гита я вижу что ты работал над этим кодом, расскажи какие риски ты видишь или к кому обратиться за помощью. Вот такой запрос о помощи не игнорируется никогда - надо быть готовым к тому что бы вам помогли.
Чаще всего вместо этого я вижу дичь на ревью, потому что человек не захотел подготовиться, а потом начинает активно защищаться когда я заставляю исправить код.
Есть ли гендерный дисбаланс в айти? Есть - это факт который никто не отрицает. Есть ли разница в работе мозга мужчин и женщин - тут уже сложнее в зависимости от того что вы игнорируете как не относящиеся к вопросу и как в целом производите измерения. Я это к чему? К тому что не составит труда сделать исследования которые продемонстрируют оба ответа. Дело в том что бы доказать тотальность в данном случае тождество между мозгом мужчин и женщин нужно значительно больше усилий чем доказать обратное. Чтобы доказать что мозги работают все таки по разному достаточно 1 исследования в ЛЮБОЙ области работы мозга, а вот доказать тождество одной парой, даже набором статей НЕ достаточно. Короче здравый смысл заставляет сильно сомневаться с таким сильным утверждением, что мозги работают одинаково и что бы убедить людей вам придется предоставить очень серьезные доказательства. Те что вы предоставили не вызывают достаточного доверия.
Наличие детей в семье обоих полов говорит о прямо противоположном - у детей мозги ни чем не промыты, а разница в поведении и в том как они справляются с задачами буквально очевидна и сильно коррелирует с полом. Т.е. недостаточно просто предоставить набор исследований не вызывающих доверия которые просто констатирует отстувие разницы нужно ещё как то объяснить почему ее нет, почему физиология не влияет и т.д. Короче шансов у вас убедить большинство в том что разницы нет очень мало.
НО это все фигня - детали. Принципиальный вопрос звучит так - да есть дисбаланс, но почему вы считаете, что это проблема? Более частный вопрос почему вы думаете что устранение дисбаланса решит проблему? А может (крамольная мысль) усиление дисбаланса это лучше?
Начните с основ с пастоновки вопроса/проблемы. Объясните почему 50/50 имеет хоть какой то объективный смысл? Короче с мат частью в вашей статье много проблем она только выглядит наукообразной, но по существу, банальное рацианализаторство.
Лженерики в расте намного слабее темплэйтов плюсовых, как и поддержка компил тайм вычислений в с++ лучше, так что пока раст не догонит с++ в этих аспектах у с++ ещё пока есть чем уделать раст.
Извините, я написал ответ, а сраный хабр его куда в дев нул отправил, а писал я долго и было обидно, но переписывать это с телефона я больше не буду - код на хабре с телефона это просто невыносимая боль. В кратце да, template<template...> для концептов не завезли, что делает их просто сахаром без принципиальных новшеств и менее выразительными чем то же самое на сфинае, но ниша для них есть конечно.
Вы ими то пробовали пользоваться как следует, а не поиграться? Концепты ущербные примерно такие же как лженерики(опечатался, а потом понял что это лучшее их описание) в расте. Без сфинае с++ шаблоны вообще ни о чём. Для самостоятельного курения почему я так считаю вам стоит попробовать реализовать аналог шаблон шаблона на концептах - это не возможно. Если убрать сфинае и параметр паки из с++ то его можно в тот же день закапывать. Единственное, что у страуса получилось так это шаблоны (и то случайно) и это то на что я купился ещё студентом 25 лет назад. Не будь шаблонов, я бы даже и не сунулся в плюсы.
В моем регионе последние пару лет что я слежу все, я повторю ВСЕ из примерно 2 десятков открытых вакансий в любой момент времени это крипта. 3 года назад мне повезло увидеть 1 вакансию на расте и не крипта.
Т.е. вы больше не возражаете, что атрибут на стэке просто опасен. Хотя возможно вы и раньше не возражали, но тогда я не очень понял о чем вы со мной дискутировали.
В любом случае я почитал эти много букв, но мало смысла проползал. Поведение атрибута совершенно гомогенно, что для стэка, что для параметра - полная индульгенция на весь лайфтайм. Т.е. ничего компилятор из декларации вызываемой функции НЕ учитывает при анализе использования стэк переменных, т.е. по простому будет требовать атрибут на стэке если переменная явно не инициализирована в теле компилируемой функции.
Это просто нельзя разрешать использовать т.к. принудительно запрещает компилятору и стат анализаторам сообщать о любых проблемах о которых сегодня они сообщают в каждом месте.
Массовый сценарий - при переходе будет туча эрониус бихэвиоров что-то конечно пофиксят, ну а что-то будет помечено этим атрибутом и тогда ЛЮБОЙ код с такой переменной должен приниматься компилятором как есть без права на ворнинг.
Это хуже чем сейчас само по себе + сейчас я поймаю такую переменную санитайзером и без лишних приседаний сразу пойду это чинить, а с этим атрибутом мне придётся поднимать гит и смотреть это санитайзер глючит или тот кто поставил атрибут был не прав ну или возможно кто то после него - короче лишние приседания перед тем как собственно чинить.
Вот кто то спросит на стэке - у меня эрониус бихэвиор, что мне делать - да просто добавь атрибут - спасибо помогло, а мне потом это чинить - спасибо я такое буду у себя на работе запрещать.
Не за ерониус бихэвиор который ворнинг, а у нас они в ероры принудительно превращаются по настоящему спасибо, а этот опт оут будет просто запрещен - безопаснее по старинке вручную ворнинг подавить в каждом месте чем вот это.
А как тогда получилось у других языков? Там по вашему нету дллек или виртуальных методов? Мало того у них там гарантия даётся, а не какой то невнятный ерониус бихэвиор.
Я вам секрет чуть ниже открою, компилятору вообще ничего не нужно ни декларации ни определения.
Ну вот вы и подтвердили мои подозрения, что без использования этого атрибута на стэке он вообще не работает.
Я просто скопирую то что УЖЕ работает в других языках.
Как сейчас в плюсах - на КАЖДОЕ использование неинит переменной компилятор/стат анализ кидает ворнинг. Нельзя одним махом взять и подавить все ворнинги ТОЛЬКО к этой переменной (можно в блоке, файле, программе). Т.е. инструменты требует от вас просмотреть каждый колл сайт и для каждого индивидуально решить фиксить или давить ворнинг.
Как теперь будет (проползал то уже приняли). Вы в ОДНОМ месте ставите атрибут и компилятор затыкается во ВСЕХ кол сайтах. Я не могу усилить форматированием слово во всех ещё сильнее, даже в тех кол сайтах которые ещё только БУДУТ написаны. Это делает проблему использования неинит переменных ещё опасней чем она есть сегодня.
Как это делается в других языках вы и сами можете посмотреть, я лишь могу предложить один из вариантов как это может выглядеть в цпп. Атрибут должен применяться исключительно и только к параметру функции, но не только в декларации, но ещё и в кол сайте.
Если удалить атрибут в месте вызова фуу то будет 2 ошибки компиляции. В моем примере при этом для бара атрибут НЕ нужен ЕСЛИ у фуу в декларации тоже есть этот атрибут. Почему? Потому что функция в кол сайте которой есть этот атрибут гарантирует инициализацию аут параметра. Т.е. после вызова фуу хз точно инициализирована в том же самом скоупе (что это значит чуть позже).
Дальше функция фуу находится в чужой либе и вы не можете менять ее (ни декларацию ни определение) - да НЕ проблема ставите как и в примере атрибут в кол сайте, все тоже самое бар уже НЕ требует атрибута. Пришел Вася Пупкин через 5 лет поменял местами фуу и бар и/или вставил фуубар перед фуу и получил ошибку компиляции. И теперь сидит и курит почему так.
Внутри функции чей параметр помечен атрибутом при доступе к параметру ДО инициализации - ошибка компиляции. Ретурн или сроу ДО инициализации параметра - ошибка компиляции. Вызов не ноуэксепт функции/оператора ДО инициализации - ворнинг.
Если кол сайт с атрибутом завернут в трай кэтч, то индульгенция испаряется за пределами скоупа. Например если в моем примере бы фуу была внутри трай, а бар после или внутри кэтча то вызов бара это ошибка компиляции.
Я НИЧЕГО нового здесь не написал, а то что попало в стандарт тупо ещё опасней чем как сейчас.
Подождите, я не понял. Вот в вашем же примере (где атрибут только на стэке) если функция (без атрибута) будет сначало читать, а потом писать будет хотя бы ворнинг?
ИМХО использовать этот атрибут на стэке надо сразу запретить во всех гайдлайнах как опасный. Честно говоря я вообще не понимаю зачем этот атрибут для стэка?
Ещё раз перечитал текст, я начинаю подозревать, что без объявления переменной на стэке с атрибутом, НО пометкой параметра функции филл этим атрибутом компилятор ПРОДОЛЖИТ считать тело сэмпл эрониус.
Если я прав в своем подозрении, то это эпик фэйл и не зря так называемые лоббисты хотят разогнать плюсы и его комитет как проф не пригодных.
А можете подробнее рассказать про индетерминэйт? Из примера создаётся впечатление что этот атрибут стоит не там. В примере он описывает переменную на стэке и вы утверждаете что это говорит компилятору что все ок. Т.е. если функция филл вместо записи сначало прочитает, то все как раньше УБ.
С другой стороны если этот атрибут применить к параметру функции тогда это ИМХО как раз могло бы помочь компилятору диагностировать чтение из неинициализированной переменной.
Вы точно не перепутали ничего в примере?
Ну я не настоящий сварщик, но логически я не вижу как можно померять скорость распространения взаимодействия изолированно только в одном направлении. Исходя из физического смысла этой скорости вам необходимо поменять направление распространение иначе не существует способа определения момента начала/конца распространения. Дело то ведь не в том как синхронизировать часы, нужны то всего 1 часы, а в том как вообще понять когда начинать считать время, или для другого наблюдателя когда заканчивать считать.
Даже если НА САМОМ ДЕЛЕ ™ скорость распространения зависит от чего то, но мы не можем это никак обнаружить, то это просто не важно. Т.е. зачем замерять скорость распространения взаимодействия в одном направлении если на практике такой штуки нету, взаимодействия которыми мы можем управлять всегда туда/обратно, а те которые только к нам они для нас плохо предсказуемое будущее, а те которые от нас это прошлое.
Руку надо переносить на цифровую клавиатуру, хотя честно я понятие не имею как я набираю эти типы - т.е. это вообще не важно. Ну ещё конкретно у этого человека аллергия на цифры, глаза начинают чесаться при чтении, ну бывает, у меня вот аллергия на скобки, у вас ещё на что нибудь - это нормально хотя вероятно не лечится.
https://en.cppreference.com/w/cpp/preprocessor/replace
Эмбед платформы/СОКи/одноплатники на армах. Это НЕ микроконтроллеры и НЕ вайфай. Они все ещё 32 битные и будут такими ещё очень долго.
А про виндоус смешно было конечно. В общем что и требовалось удостоверить, дальше своего уютного мира вы не выходите, так зачем тогда навязываете свое видение как существенно превосходящее все альтернативы?
Дефайнить ключевые слова запрещено - не скомпилируется. С младшей школы в букварях учат 8 меньше 16 ровно в 2 раза, ну и далее по списку, а вот байт, ворд, дабл ворд, квадрипл ворд которые изначально и были заменили на шорт инт лонг от слабоумия. Зачем нормальным ЛЮДЯМ иметь в голове мапу слова на число и постоянно заниматься приседаниями что бы понимать что больше и что меньше и во сколько раз? Для этого есть числа, они лучше с этим справляются. СайзТ (как и в расте) это именно размер регистра во всех нормальных языках, а если вам байты (их количество) важно - ну например протокол реализовать, то там в 100500 раз лучше иметь и32 и т.д. вместо непонятного инта. Сразу видно, что вы дальше своей платформы ничего не знаете и крос платформ для вас это ругательства. Что написать в коде что бы не усложнять себе жизнь макросами и гарантировано иметь 64 бита везде?
Я не в курсе кто там у вас эталон правильности, но инженеров интела тоже в проф непригодных запишете с их у64, у128, у256, у512 для симд регистров?
А можете разжевать для не просветлённых, какое такое фундаментальное преимущество указатель+размер перед размер+указатель.