LINUX.ORG.RU

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

 ,


0

1

Пример:

int x;
double y;
struct { char zs[256]; } z;

int main() {}

Регламентирует ли стандарт C(или C++) размещение x/y/z? Порядок, выравнивание и подобное. Если есть инфа по реализациям(гцц/шланг) - тоже интересно. Вариант просто собрать посмотреть не подойдёт - нужна какая-то стабильность/гарантии, а не просто текущее положение дел.

Ответ на: комментарий от wandrien

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

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

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

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

no-dashi-v2 ★★★
()
Ответ на: комментарий от no-dashi-v2

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

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

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

см выше.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 2)
Ответ на: комментарий от wandrien

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

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

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

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

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

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

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

no-dashi-v2 ★★★
()
Ответ на: комментарий от no-dashi-v2

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

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

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

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

LamerOk ★★★★★
()
Последнее исправление: LamerOk (всего исправлений: 1)
Ответ на: комментарий от no-dashi-v2

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

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

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

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

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от bugfixer

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

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

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

no-dashi-v2 ★★★
()
Ответ на: комментарий от no-dashi-v2

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

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

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

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

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

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

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

wandrien ★★
()
Ответ на: комментарий от Dimez

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

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

bugfixer ★★★★★
()
Ответ на: комментарий от no-dashi-v2

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

vromanov ★★★
()