Неиспользуемая переменная-член занимает память?

Инициализация переменной-члена, а не обращение к ней / ее использование, дополнительно занимает оперативную память во время выполнения, или компилятор просто игнорирует эту переменную?

struct Foo {
    int var1;
    int var2;

    Foo() { var1 = 5; std::cout << var1; }
};

В приведенном выше примере член var1 получает значение, которое затем отображается в консоли. Однако «Var2» вообще не используется. Поэтому запись его в память во время выполнения будет пустой тратой ресурсов. Учитывает ли компилятор такие ситуации и просто игнорирует неиспользуемые переменные, или объект Foo всегда имеет один и тот же размер, независимо от того, используются ли его члены?

Золотое правило C ++ «как если бы» ¹ гласит, что если наблюдаемое поведение программы не зависит от существования неиспользуемого члена-данных, компилятору разрешается его оптимизировать .

Неиспользуемая переменная-член занимает память?

Нет (если он «действительно» не используется).

Теперь возникают два вопроса:

1. Когда наблюдаемое поведение не зависело бы от существования члена?
2. Встречаются ли подобные ситуации в реальных программах?

Начнем с примера.

пример

#include <iostream>

struct Foo1
{ int var1 = 5;           Foo1() { std::cout << var1; } };

struct Foo2
{ int var1 = 5; int var2; Foo2() { std::cout << var1; } };

void f1() { (void) Foo1{}; }
void f2() { (void) Foo2{}; }

Если мы попросим gcc скомпилировать эту единицу перевода , он выдаст:

f1():
        mov     esi, 5
        mov     edi, OFFSET FLAT:_ZSt4cout
        jmp     std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
f2():
        jmp     f1()

f2то же самое f1, и никакая память никогда не используется для хранения фактического Foo2::var2. ( Clang делает нечто подобное ).

Обсуждение

Некоторые могут сказать, что это другое, по двум причинам:

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

Что ж, хорошая программа - это умная и сложная сборка простых вещей, а не простое сопоставление сложных вещей. В реальной жизни вы пишете множество простых функций, используя простые структуры, которые компилятор не оптимизирует. Например:

bool insert(std::set<int>& set, int value)
{
    return set.insert(value).second;
}

Это реальный пример std::pair<std::set<int>::iterator, bool>::firstнеиспользования элемента данных (здесь ). Угадай, что? Он оптимизирован ( более простой пример с фиктивным набором, если эта сборка заставляет вас плакать).

Сейчас самое время прочитать отличный ответ Макса Лангхофа (проголосуйте за него, пожалуйста). Это объясняет, почему, в конце концов, концепция структуры не имеет смысла на уровне сборки, выводимой компилятором.

«Но если я сделаю X, то факт, что неиспользуемый член будет оптимизирован, станет проблемой!»

Было несколько комментариев, в которых утверждалось, что этот ответ должен быть неправильным, потому что какая-то операция (например assert(sizeof(Foo2) == 2*sizeof(int))) что-то сломает.

Если X является частью наблюдаемого поведения программы ² , компилятору не разрешается выполнять оптимизацию. Есть много операций с объектом, содержащим "неиспользуемый" элемент данных, которые могли бы иметь заметный эффект на программу. Если такая операция выполняется или компилятор не может доказать, что ничего не было выполнено, этот «неиспользуемый» элемент данных является частью наблюдаемого поведения программы и не может быть оптимизирован .

Операции, влияющие на наблюдаемое поведение, включают, но не ограничиваются:

• взяв размер типа объекта ( sizeof(Foo)),
• взяв адрес элемента данных, объявленный после "неиспользованного",
• копирование объекта с помощью такой функции, как memcpy,
• манипулирование представлением объекта (например, с memcmp),
• квалификация объекта как изменчивого ,
• и т . д.

¹⁾

[intro.abstract]/1

Семантические описания в этом документе определяют параметризованную недетерминированную абстрактную машину. Этот документ не предъявляет требований к структуре соответствующих реализаций. В частности, им не нужно копировать или имитировать структуру абстрактной машины. Скорее, соответствующие реализации требуются для имитации (только) наблюдаемого поведения абстрактной машины, как описано ниже.

²⁾ Похоже на то, что утверждение прошло успешно или нет.

Важно понимать, что код, создаваемый компилятором, не имеет фактических сведений о ваших структурах данных (потому что таких вещей не существует на уровне сборки), как и оптимизатор. Компилятор создает только код для каждой функции , но не структуры данных .

^{Хорошо, он также записывает постоянные разделы данных и тому подобное.}

Исходя из этого, мы уже можем сказать, что оптимизатор не будет «удалять» или «исключать» члены, потому что он не выводит структуры данных. Он выводит код , который может использовать или не использовать элементы, и среди его целей экономия памяти или циклов за счет исключения бессмысленного использования (например, записи / чтения) членов.

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

По мере того, как вы делаете взаимодействие функции с внешним миром более сложным / неясным для компилятора (принимать / возвращать более сложные структуры данных, например std::vector<Foo>, скрывать определение функции в другом модуле компиляции, запрещать / препятствовать встраиванию и т. Д.) , становится все более и более вероятным, что компилятор не может доказать, что неиспользуемый член не действует.

Здесь нет жестких правил, потому что все зависит от оптимизаций, которые делает компилятор, но пока вы делаете тривиальные вещи (например, как показано в ответе YSC), очень вероятно, что никаких накладных расходов не будет, тогда как выполнение сложных вещей (например, возврат a std::vector<Foo>из функции, слишком большой для встраивания), вероятно, вызовет накладные расходы.

Чтобы проиллюстрировать это, рассмотрим этот пример :

struct Foo {
    int var1 = 3;
    int var2 = 4;
    int var3 = 5;
};

int test()
{
    Foo foo;
    std::array<char, sizeof(Foo)> arr;
    std::memcpy(&arr, &foo, sizeof(Foo));
    return arr[0] + arr[4];
}

Здесь мы делаем нетривиальные вещи (берем адреса, проверяем и добавляем байты из байтового представления ), и все же оптимизатор может выяснить, что результат всегда один и тот же на этой платформе:

test(): # @test()
  mov eax, 7
  ret

Мало того, что участники Fooне занимали никакой памяти, Fooони даже не возникли! Если есть другие варианты использования, которые нельзя оптимизировать, то, например, это sizeof(Foo)может иметь значение - но только для этого сегмента кода! Если бы все использования можно было оптимизировать таким образом, то существование, например var3, не влияет на сгенерированный код. Но даже если он будет использоваться где-то еще, test()останется оптимизированным!

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

Компилятор оптимизирует неиспользуемую переменную-член (особенно общедоступную) только в том случае, если он сможет доказать, что удаление переменной не имеет побочных эффектов и что никакая часть программы не зависит от ее размера Foo.

Я не думаю, что какой-либо текущий компилятор выполняет такую ​​оптимизацию, если структура вообще не используется. Некоторые компиляторы могут, по крайней мере, предупреждать о неиспользуемых частных переменных, но обычно не о публичных.

В общем, вы должны предположить, что получили то, о чем просили, например, «неиспользуемые» переменные-члены присутствуют.

Поскольку в вашем примере оба члена являются членами public, компилятор не может знать, будет ли какой-либо код (особенно из других единиц перевода = другие файлы * .cpp, которые компилируются отдельно, а затем связываются) обращаться к «неиспользуемому» члену.

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

Если у вас есть интерфейсы между функциями, определенными в разных единицах перевода, обычно компилятор ничего не знает. Интерфейсы обычно соответствуют некоторому предопределенному ABI (например, этому ), так что разные объектные файлы могут быть связаны вместе без каких-либо проблем. Обычно ABI не имеют значения, используется член или нет. Итак, в таких случаях второй член должен физически находиться в памяти (если позже компоновщик не удалит его позже).

И пока вы находитесь в границах языка, вы не можете наблюдать, что происходит какое-либо устранение. Если позвонишь sizeof(Foo), получишь 2*sizeof(int). Если вы создаете массив Foos, расстояние между началом двух последовательных объектов Fooвсегда равно sizeof(Foo)байтам.

Ваш тип является стандартным типом макета , что означает, что вы также можете получить доступ к членам на основе вычисленных смещений во время компиляции (см. offsetofМакрос). Более того, вы можете проверить побайтовое представление объекта, скопировав его в массив charusing std::memcpy. Во всех этих случаях можно наблюдать присутствие второго члена.

Примеры, представленные другими ответами на этот вопрос, которые исключены var2, основаны на единственном методе оптимизации: постоянное распространение и последующее исключение всей структуры (а не исключение только var2). Это простой случай, и оптимизирующие компиляторы его реализуют.

Для неуправляемых кодов C / C ++ ответ заключается в том, что компилятор, как правило, не игнорирует var2. Насколько мне известно, такое преобразование структуры C / C ++ не поддерживается в отладочной информации, и если структура доступна как переменная в отладчике, var2ее нельзя исключить. Насколько я знаю, текущий компилятор C / C ++ не может специализировать функции в соответствии с исключением var2, поэтому, если структура передается или возвращается из не встроенной функции, то var2ее нельзя исключить.

Для управляемых языков, таких как C # / Java с JIT-компилятором, компилятор может безопасно исключить, var2потому что он может точно отслеживать, используется ли он и уходит ли он в неуправляемый код. Физический размер структуры в управляемых языках может отличаться от размера, сообщаемого программисту.

Компиляторы C / C ++ 2019 года не могут быть исключены var2из структуры, если не исключена вся переменная структуры. Для интересных случаев исключения var2из структуры ответ: Нет.

Некоторые будущие компиляторы C / C ++ смогут исключить var2из структуры, и экосистема, построенная вокруг компиляторов, должна будет адаптироваться для обработки информации исключения, генерируемой компиляторами.

Это зависит от вашего компилятора и уровня его оптимизации.

В gcc, если вы укажете -O, будут включены следующие флаги оптимизации :

-fauto-inc-dec 
-fbranch-count-reg 
-fcombine-stack-adjustments 
-fcompare-elim 
-fcprop-registers 
-fdce
-fdefer-pop
...

-fdceозначает удаление мертвого кода .

Вы можете использовать, __attribute__((used))чтобы предотвратить удаление gcc неиспользуемой переменной со статическим хранилищем:

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

При применении к статическому элементу данных шаблона класса C ++ атрибут также означает, что создается экземпляр элемента, если создается экземпляр самого класса.