Размещение глобальных данных

Это как-то делает global statics чем то фундаментально другим?

Делает.

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

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

Это всё условности. Обычно гораздо интересней «а где оно вообще используется». И чтобы на этот вопрос ответить вы точно так же будете переименовывать и смотреть где билд отвалился, вне зависимости от того - спрятали вы этот state за аксесором, или доступаетесь к нему напрямую.

вы точно так же будете переименовывать и смотреть где билд отвалился

POV: когда даёшь функциям двухбуквенные имена

На любом языке можно написать говнокод, да.

Ну а у меня там же в конфигурации будет этот флаг, благо конфигурация не статик а такой же экземпляр объекта приезжающий в контроллеры и команды снаружи в конструкторе, и зачем теперь Глобал?

благо конфигурация не статик а такой же экземпляр объекта приезжающий в контроллеры и команды снаружи в конструкторе

Прелесть какая :) Теперь у нас тот-же самый указатель на конфигурацию хранится в миллионе объектов, и протаскивается через миллион вызовов. Эффективность, мать его! А всё почему - globals нам использовать религия не позволяет. Не, так-то я конечно только за - чем больше народ (причём вроде как даже не совсем juniors - «подаваны» вон имеются, как утверждается) готов творить такую дичь, тем дороже стою лично я. Так что: «вперёд, Фатима» :)

и зачем теперь Глобал?

см выше.

Про преждевременную оптимизацию поговорку знаешь?

Про преждевременную оптимизацию поговорку знаешь?

О чём вы? Я как раз ярый сторонник подхода который предполагает не делать лишних телодвижений. Это господин выше предлагал напрочь отказаться от global state (причём походу исключительно из религиозных соображений так как разумных доводов кроме громких слов я пока не услышал), и вот это не только дополнительный геморрой, но и зачастую тупо менее эффективно в runtime.

А всё почему - globals нам использовать религия не позволяет

А можно мы этот фич-флаг включим не для всех сразу а только для одной сессии или для одного юзера? Нет? А почему? Потому что статик или глобальная? Так что, может все же в религии (как минимум в ИТ-религии) есть рациональное зерно?

Эффективность, мать его!

Настоящие программисты всегда экономят параметры для конструктора, потому что каждый параметр это один пуш и одно присваивание. Правда между ними еще alloc который в 300 (или 1300 если сваливаться в аллокацию старниц в операционной системе) раз медленнее чем обе эти операции вместе взятых.

каждый параметр это один пуш и одно присваивание

Но в возражении не было ничего про пуши и присваивания. В возражении предлагали не строчить лишний код программисту. Повышенной обеспокоенности работой процессора выражено не было.

для одной сессии или для одного юзера?

Уныло - у сессий с юзерами будут свои контексты, где и будут их флаги. Или это было завуалированное предложение все глобальные параметры засовывать в каждую сессию и к каждому юзеру?

А можно мы этот фич-флаг включим не для всех сразу а только для одной сессии или для одного юзера?

Boolean в конфиге превратится в regexp, вычисляться будет один раз в объекте представляющем юзера / сессию, глобальный конфиг останется. Шах и мат.

Настоящие программисты всегда экономят параметры для конструктора

Настоящие программисты экономят прежде всего своё время, и не плодят сущности сверх необходимого.

Настоящие программисты экономят прежде всего своё время, и не плодят сущности сверх необходимого

Это прямо таки эталонный спич, который произносится тогда, когда архитектура уже завалена и стоит выбор между «переделать все и сделать нормально» и «прикрутить костыли из говна, палок и глобальных переменных».

Уверен, программисты Тойоты тоже говорили менеджерам про эффективность и не плодить лишние сущности.

А что там у Тойоты?

когда архитектура уже завалена и стоит выбор между «переделать все и сделать нормально» и «прикрутить костыли из говна, палок и глобальных переменных».

Если бы вы практиковали экстремальное программирование то вы бы существенно снизили вероятность попадания в такую ситуацию. А самые базовые парадигмы этого подхода вы и нарушаете, а именно «кодируете на будущее» и «не стремитесь к самому простому решению которое скорее всего заработает».

Уверен, программисты Тойоты

Удивлён что вы про Боинг в этом контексте не вспомнили. Но дичь которую вы затеяли это всё равно не оправдывает.

Не бывает идеальной архитектуры в вакууме. Это всегда компромисс.

Как по мне, так оба решения имеют право на существование в зависимости от контекста.

Не регламентирует.

А что там у Тойоты?

А у тойоты гнездо багов в прошивке ECU из за чего тачки входили в режим неконтролируемого разгона. Тоже любили глобальные переменные

Там не просто «любили» :))

https://news.ycombinator.com/item?id=9643204

Там не просто «любили» :))

Вот здесь, и (что более важно) вот тут утверждают что проблема имела чисто механический характер, а электроника (и в частности прошивка ECU) - ни при чём.

Если ты не разбираешся в разработке ПО для автомобильных контроллеров, то лучше не приводить примеров оттуда. Использование глобалов и статических переменных там стандарт. Иначе все будет тормозить.

тебе сюда: https://en.cppreference.com/w/cpp/language/initialization

это тебе надо не к языку программирования обращаться — а к ABI — это другой стандарт, и он явным образом никак не пересекается с ЯП C++ — последний лишь определяет, что некоторые сущности, правила и тому подобное implementation defined.

и при большом их объеме могут повлиять на скорость запуска программы

не больше чем в любом другом месте были бы...

зачем там какие то if'ы вообще делать?

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

не надо никаких проверок — она инитится в первый раз и дальше уже готова всегда до конца программы... иначе ты к ней доступ никак не получишь, кроме как вызовом той функции, которая её и инициализирует...
к примеру:

int& new_int(){
    static int var = 88;
    return var;
}

просто не надо надеяться на то что не гарантировано — все от необразованности.

всегда — гарантируется стандартом, что инициализация статических и глобальных данных будет под мутексом.

вот это уже называется использование не ЯП, а конкретной реализации компилятора. Если нужен какой то определённый лейаут — то в C++ имеется tuple<>.

не надо никаких проверок — она инитится в первый раз и дальше уже готова всегда до конца программы…

а как процессор понимает, что исполнение дошло до данной точки в первый раз?

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

а возможно как то хитро строит саму прогу.

вот так он «строит прогу». это если тип обьекта нетривиальный.

https://godbolt.org/z/K6TMYdrqf

потому в стандарте ему места быть не должно

И как потом сохранять бинарные данные для обмена?

аппаратно-независимым образом разумеется. потому что даже на одном физическом компутере оптимальное представление данных может радикально отличаться. например, если он работает в 32 битном или 64 битном режиме.

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

Ну так этот аппаратно-независимый способ выравнивания/упаковки структур как бы должен быть предусмотрен в языке.

Ну так этот аппаратно-независимый способ выравнивания/упаковки структур как бы должен быть предусмотрен в языке.

Нет, не должен.

И как потом сохранять бинарные данные для обмена?

Любым удобным тебе способом.

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

Если сравнивать с размещением внутри функций и возвратом ссылки, то больше.

Не под мьютексом Размещение глобальных данных (комментарий)

можно массив байт, можно tuple... некоторые (в том числе и гугл) применяют возможности конкретного компилятора — но я за бОльшую переносимость.

Нет, не должен.

но возможности для реализации такового предоставляет. А как именно должна быть построена логика — все конвенционально для конкретной программы...

выравнивание возникает потому, что контроллер памяти читает 64 битное слово за один цикл чтения только с адреса кратному 8 байтам. а 32 битное - с кратного 4 байтам. итак далее. если будет некратно, то будет два цикла чтения. вот чтобы этого не было, компилятор так рассчитывает адреса и смещения, чтобы слова попадали на нужные границы. иначе чтение/запись будут медленней.

если бы память читалась одним чтением n-байтового слова с любого адреса - то и выравнивание было бы не нужно.

короче «аппаратно-независимое выравнивание» - это вообще никакого выравнивания. выравнивание необходимо по чисто техническим причинам.

короче «аппаратно-независимое выравнивание» - это вообще никакого выравнивания

В том числе.

выравнивание необходимо по чисто техническим причинам

Этих причин гораздо больше чем ты знаешь. Бывает нужно выравнивание больше чем ширина слова. А бывает что не нужно вообще, несмотря на возникающие дополнительные циклы чтения. Короче, произвольное управление выравниванием необходимо, и поэтому во всех актуальных компиляторах оно так или иначе есть.

Нет, не должен.

но возможности для реализации такового предоставляет. А как именно должна быть построена логика — все конвенционально для конкретной программы…

Совершенно верно. Что компилятор действительно «должен», так это сгенерировать инструкции по чтению/записи переменных в памяти. Пытаться угадать как и где он их расположил – печалащий дилетантизм.

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

Бывает нужно выравнивание больше чем ширина слова.

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