96

Does initializing a data member and not referencing/using it further take up memory during runtime, or does the compiler simply ignore that member?

struct Foo {
    int var1;
    int var2;

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

In the example above, the member var1 gets a value which is then displayed in the console. var2, however, is not used at all. Therefore, writing it to memory during runtime would be a waste of resources.

Does the compiler take these kinds of situations into an account and simply ignore unused data members, or is the Foo object always the same size, regardless of whether its members are used?

Jan Schultke
  • 17,446
  • 6
  • 47
  • 96
Chriss555888
  • 863
  • 1
  • 6
  • 10
  • 25
    This depends on the compiler, the architecture, the operating system and the optimisation used. – Owl Mar 08 '19 at 10:04
  • 16
    There is a metric ton of low level driver code out there that specifically add do-nothing struct members for padding to match hardware data frame sizes and as a hack to get desired memory alignment. If a compiler started optimizing these out there would be much breakage. – Andy Brown Mar 08 '19 at 10:13
  • 2
    @Andy they're not really do-nothing as the address of the following data members is evaluated. This means the existence of those padding members do have an observable behavior on the program. Here, `var2` doesn't. – YSC Mar 08 '19 at 10:19
  • 4
    I would be surprised if the compiler could optimize it away given that any compilation unit addressing such a struct might get linked to another compilation unit using the same struct and the compiler can't know if the separate compilation unit addresses the member or not. – Galik Mar 08 '19 at 10:33
  • 2
    @geza `sizeof(Foo)` cannot decrease by definition - if you print `sizeof(Foo)` it must yield `8` (on common platforms). Compilers _can_ optimize away the space used by `var2` (no matter if through `new` or on the stack or in function calls...) in any context they find it reasonable, even without LTO or whole program optimization. Where that is not possible they won't do it, as with just about any other optimization. I believe the edit to the accepted answer makes it significantly less likely to be misled by it. – Max Langhof Mar 08 '19 at 13:05
  • @geza I think it all depends on what style of programming is used. In template-heavy code, you have so many tiny functions and tiny structs which only exist to be used once, that the trivial cases are pretty much _everywhere_. – hegel5000 Mar 08 '19 at 14:56
  • @MaxLanghof: Is there anything in the standard that backs up your statement (especially, if `Foo` doesn't have standard layout)? And sure, compilers can do anything which adhere the as-if rule. The question is, do they optimize away `var2` in non-trivial cases? And the answer is: no, they don't, `var2` will still take up memory. Theory is one thing (what can a compiler do), and practice is another (what capabilities compilers have). In my opinion the accepted answer still misleading. Anyways, I may misinterpret the intent of the question, considering the lot of upvotes of the accepted answer. – geza Mar 08 '19 at 22:16
  • @geza My point was not the number 8 but that when inspecting `Foo` using `sizeof` it will, _by definition_, not ignore unused variables. But even that is a moot point because the only thing the standard guarantees are the side effects of your program, not how that is accomplished. `memcpy` and `sizeof` themselves have no side effects, which is why [this](https://godbolt.org/z/GoCxt7) optimization can happen. – Max Langhof Mar 11 '19 at 08:18
  • @MaxLanghof: if the compiler optimizes away `var2` (this can be done, it just needs whole program optimization - but no current compiler has such a feature), then sizeof will be 4. And it is not forbidden by the standard, as far as I know (I could be wrong in this matter). Is there anything in the standard, which guarantee some property of sizeof of structs? You say "*by definition*". Can you cite this definition which says it cannot ignore unused variables? – geza Mar 11 '19 at 08:53
  • @geza The definition is [expr.sizeof#1](http://eel.is/c++draft/expr.sizeof#1). Together with what is said in [basic.types](http://eel.is/c++draft/basic.types) (and [intro.memory](http://eel.is/c++draft/intro.memory)) I don't see how any compiler would be allowed to have the result of `std::cout << sizeof(Foo) << std::endl;` depend on whole program optimization. As in, the above expression results in a specific side-effect in the abstract machine model, and optimization is not allowed to change this side effect. – Max Langhof Mar 11 '19 at 09:08
  • @geza You might argue that the compiler could still print `8` (or whatever) even after internally changing `sizeof(Foo)` to `4`, but the discussion becomes pointless here because nothing in the standard actually exists outside the abstract machine model. An implementation could use flying unicorns instead of bytes and still be standard-conforming, as long as the observable behavior produced is as specified. – Max Langhof Mar 11 '19 at 09:13
  • @MaxLanghof: expr.sizeof#1 doesn't say anything about the value. If `var2` optimized away, it can be 4 (whole program optimization is needed for the compiler to prove that `var2` is really not used). It just says that it returns the number of bytes occupied. If `var2` removed, it would occupy 4. Your argument about "optimization changes side effect" is a valid one, though. Anyways, my important argument is not this, and even, if `sizeof(Foo)` is not allowed to change, it just supports my important comment: the accepted answer is misleading. – geza Mar 11 '19 at 09:20
  • @MaxLanghof: OP asks about RAM usage. And people usually don't care too much about struct usage on stack. Real RAM usage comes from the heap. And on the heap, `var2` will take up space. And this fact is not mentioned in the answer. – geza Mar 11 '19 at 09:21
  • @MaxLanghof: no, I'd argue, that `sizeof(Foo)` can be 4. If it returned 8, while the real size is 4, it would cause a lot of problems. Consider: `var2` is not used at all in a program, so compiler removes it. Now, `sizeof(Foo)` is 4. The number of bytes it occupies. Does this against the standard? No. (at least I don't know any rule which is violated). If this optimization is done reliably (always, if it is possible), then it is not the "optimization changes side" effect any more, because `sizeof(Foo)` was never 8. – geza Mar 11 '19 at 09:27
  • @MaxLanghof: and if you modify the program to use `var2`, `sizeof(Foo)` will become 8. But then, this is a different program, so it is logical that it has a different side effect. – geza Mar 11 '19 at 09:28
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/189800/discussion-between-max-langhof-and-geza). – Max Langhof Mar 11 '19 at 09:32
  • @Zobia Please read the tag wiki before adding it to questions. This is **not** a question about RAM, nor it is a question about compilation warnings. – YSC Mar 12 '19 at 14:27

6 Answers6

112

The golden C++ "as-if" rule1 states that, if the observable behavior of a program doesn't depend on an unused data-member existence, the compiler is allowed to optimized it away.

Does an unused member variable take up memory?

No (if it is "really" unused).


Now comes two questions in mind:

  1. When would the observable behavior not depend on a member existence?
  2. Does that kind of situations occurs in real life programs?

Let's start with an example.

Example

#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{}; }

If we ask gcc to compile this translation unit, it outputs:

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

f2 is the same as f1, and no memory is ever used to hold an actual Foo2::var2. (Clang does something similar).

Discussion

Some may say this is different for two reasons:

  1. this is too trivial an example,
  2. the struct is entirely optimized, it doesn't count.

Well, a good program is a smart and complex assembly of simple things rather than a simple juxtaposition of complex things. In real life, you write tons of simple functions using simple structures than the compiler optimizes away. For instance:

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

This is a genuine example of a data-member (here, std::pair<std::set<int>::iterator, bool>::first) being unused. Guess what? It is optimized away (simpler example with a dummy set if that assembly makes you cry).

Now would be the perfect time to read the excellent answer of Max Langhof (upvote it for me please). It explains why, in the end, the concept of structure doesn't make sense at the assembly level the compiler outputs.

"But, if I do X, the fact that the unused member is optimized away is a problem!"

There have been a number of comments arguing this answer must be wrong because some operation (like assert(sizeof(Foo2) == 2*sizeof(int))) would break something.

If X is part of the observable behavior of the program2, the compiler is not allowed to optimized things away. There are a lot of operations on an object containing an "unused" data-member which would have an observable effect on the program. If such an operation is performed or if the compiler cannot prove none is performed, that "unused" data-member is part of the observable behavior of the program and cannot be optimized away.

Operations that affect the observable behavior include, but are not limited to:

  • taking the size of a type of object (sizeof(Foo)),
  • taking the address of a data member declared after the "unused" one,
  • copying the object with a function like memcpy,
  • manipulating the representation of the object (like with memcmp),
  • qualifying an object as volatile,
  • etc.

1)

[intro.abstract]/1

The semantic descriptions in this document define a parameterized nondeterministic abstract machine. This document places no requirement on the structure of conforming implementations. In particular, they need not copy or emulate the structure of the abstract machine. Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.

2) Like an assert passing or failing is.

s3cur3
  • 2,749
  • 2
  • 27
  • 42
YSC
  • 38,212
  • 9
  • 96
  • 149
  • Comments suggesting improvements to the answer have been [archived in chat](https://chat.stackoverflow.com/rooms/189899/discussion-on-answer-by-ysc-does-an-unused-member-variable-take-up-memory). – Cody Gray - on strike Mar 12 '19 at 16:55
  • 1
    Even the `assert(sizeof(…)…)` does not actually constrain the compiler—it has to provide a `sizeof` that allows code using things like `memcpy` to work, but that doesn’t mean the compiler is somehow required to use that many bytes unless they might be exposed to such a `memcpy` that it *can’t* rewrite to produce the correct value anyway. – Davis Herring Jan 13 '20 at 17:32
  • @Davis Absolutely. – YSC Jan 13 '20 at 17:34
65

It's important to realize that the code the compiler produces has no actual knowledge of your data structures (because such a thing doesn't exist on assembly level), and neither does the optimizer. The compiler only produces code for each function, not data structures.

Ok, it also writes constant data sections and such.

Based on that, we can already say that the optimizer won't "remove" or "eliminate" members, because it doesn't output data structures. It outputs code, which may or may not use the members, and among its goals is saving memory or cycles by eliminating pointless uses (i.e. writes/reads) of the members.


The gist of it is that "if the compiler can prove within the scope of a function (including functions that were inlined into it) that the unused member makes no difference for how the function operates (and what it returns) then chances are good that the presence of the member causes no overhead".

As you make the interactions of a function with the outside world more complicated/unclear to the compiler (take/return more complex data structures, e.g. a std::vector<Foo>, hide the definition of a function in a different compilation unit, forbid/disincentivize inlining etc.), it becomes more and more likely that the compiler cannot prove that the unused member has no effect.

There are no hard rules here because it all depends on the optimizations the compiler makes, but as long as you do trivial things (such as shown in YSC's answer) it's very likely that no overhead will be present, whereas doing complicated things (e.g. returning a std::vector<Foo> from a function too large for inlining) will probably incur the overhead.


To illustrate the point, consider this example:

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];
}

We do non-trivial things here (take addresses, inspect and add bytes from the byte representation) and yet the optimizer can figure out that the result is always the same on this platform:

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

Not only did the members of Foo not occupy any memory, a Foo didn't even come into existence! If there are other usages that can't be optimized then e.g. sizeof(Foo) might matter - but only for that segment of code! If all usages could be optimized like this then the existence of e.g. var3 does not influence the generated code. But even if it is used somewhere else, test() would remain optimized!

In short: Each usage of Foo is optimized independently. Some may use more memory because of an unneeded member, some may not. Consult your compiler manual for more details.

Max Langhof
  • 23,383
  • 5
  • 39
  • 72
  • 6
    Mic drop _"Consult your compiler manual for more details."_ :D – YSC Mar 12 '19 at 14:31
  • Examples like this where the `Foo` object is completely optimized away can be considered as "scalar replacement of aggregate" (SROA aka SRA) optimization, and then some of those scalar members can be optimized away, others into registers. e.g. GCC's `-ftree-sra` option, on at `-O1` and higher (but not `-Og`). (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) – Peter Cordes May 01 '23 at 19:27
22

The compiler will only optimise away an unused member variable (especially a public one) if it can prove that removing the variable has no side effects and that no part of the program depends on the size of Foo being the same.

I don't think any current compiler performs such optimisations unless the structure isn't really being used at all. Some compilers may at least warn about unused private variables but not usually for public ones.

Alan Birtles
  • 32,622
  • 4
  • 31
  • 60
  • 1
    And yet it does: https://godbolt.org/z/UJKguS + no compiler would warn for an unused data member. – YSC Mar 08 '19 at 10:08
  • @YSC clang++ does warn about unused data members and variables. – Maxim Egorushkin Mar 08 '19 at 10:10
  • 3
    @YSC I think that's a slightly different situation, its optimised the structure away completely and just prints 5 directly – Alan Birtles Mar 08 '19 at 10:11
  • @MaximEgorushkin It never happened to me (for data members). Do you have a godbolt link for me? – YSC Mar 08 '19 at 10:15
  • 4
    @AlanBirtles I don't see how it is different. The compiler optimized everything from the object that has no effect on the observable behavior of the program. So your first sentence "the compiler is very unlikely to optimize awau an unused member variable" is wrong. – YSC Mar 08 '19 at 10:16
  • 2
    @YSC in real code where the structure is actually being used rather than just constructed for its side effects its probably more unlikely it would be optimised away – Alan Birtles Mar 08 '19 at 10:21
  • also without removing the unused variable you cannot be certain about the size of `Foo`, so I dont really understand what you mean with "no part of the program depends on the size of Foo being the same". I could imagine that there is a guarantee that a `Foo` containing two `int` is at least as big as two `int`, but I also wouldnt be surprised if there is no such guarantee as per the standard – 463035818_is_not_an_ai Mar 08 '19 at 10:21
  • @user463035818 only if your program depends on the size of a `Foo`. – YSC Mar 08 '19 at 10:24
  • @AlanBirtles on that I agree. "where the structure is actually being used" and "very unlikely" are two different statements. All come down to the _observable behaviour_ of the program and this is, I think, the correct answer. – YSC Mar 08 '19 at 10:25
  • @YSC but isnt it the case that anyhow I cannot rely on `Foo` having a specific size, ie with a `struct Bar { int x;}` I cannot safely `assert(sizeof(Bar) < sizeof(Foo))` even without the optimization? – 463035818_is_not_an_ai Mar 08 '19 at 10:48
  • @user463035818 Yes you can since then the observable behaviour of your program depends on the size of `Foo`: the compiler cannot optimize its member away. – YSC Mar 08 '19 at 10:53
  • @YSC sorry for long possibly offtopic comments, guess I just have a misunderstanding. You are saying that the assert is guaranteed to pass and when I use it I will block the optimization? I (wrongly?) thought that for two structs with same members any of the three can be true `sizeof(A) < sizeof(B)`, `sizeof(A) == sizeof(B)` or `sizeof(A) > sizeof(B)` – 463035818_is_not_an_ai Mar 08 '19 at 10:56
  • @user463035818 It depends what counts as "same members" for you. Does one of the structs have a vtable? Do they have the same base classes? Are there access specifiers? Is there maybe some `#pragma pack` involved? If those are left open, then you are correct that none of the relations can be guaranteed. But for the full definitions `struct A { int x; };` and `struct B { int x, y; }`, you are guaranteed at least `sizeof(A) <= sizeof(B)`, and probably `<` on all existing platforms. And there is no "remove struct member" optimization you might block, there are just contexts in which the... – Max Langhof Mar 08 '19 at 14:24
  • ...compiler may ignore the unused member in the emitted machine code. Up to what level that works depends on many things (see this question :P). – Max Langhof Mar 08 '19 at 14:26
  • @MaxLanghof thanks, i meant same members as in `struct foo {int x;}; struct bar{int y;};`. Can you give me a pointer to why `sizeof(A) <= sizeof(B)` is guaranteed? Thats the missing piece that triggered my confusion – 463035818_is_not_an_ai Mar 08 '19 at 14:29
  • @user463035818 I concede that I can't point to anything in the standard that specifically guarantees what I said. You have [basic.align#5](http://eel.is/c++draft/basic.memobj#basic.align-5), but I don't think the standard bothered with forbidding a crazy C++ implementation from making `alignof(A) > alignof(B)`. It does mention that the [intent is to provide compatibility with C](http://eel.is/c++draft/basic.types#footnote-41) fwiw. That `sizeof(foo) == sizeof(bar)` is almost directly guaranteed by the ODR and http://eel.is/c++draft/basic.types (but again not spelled out I believe). – Max Langhof Mar 08 '19 at 16:24
  • @MaxLanghof thanks again, I opened a question [here](https://stackoverflow.com/questions/55068593/is-it-safe-to-assertsizeofa-sizeofb-when-a-and-b-are-the-same) – 463035818_is_not_an_ai Mar 08 '19 at 18:01
7

In general, you have to assume that you get what you have asked for, for example, the "unused" member variables are there.

Since in your example both members are public, the compiler cannot know if some code (particularly from other translation units = other *.cpp files, which are compiled separately and then linked) would access the "unused" member.

The answer of YSC gives a very simple example, where the class type is only used as a variable of automatic storage duration and where no pointer to that variable is taken. There, the compiler can inline all the code and can then eliminate all the dead code.

If you have interfaces between functions defined in different translation units, typically the compiler does not know anything. The interfaces follow typically some predefined ABI (like that) such that different object files can be linked together without any problems. Typically ABIs do not make a difference if a member is used or not. So, in such cases, the second member has to be physically in the memory (unless eliminated out later by the linker).

And as long as you are within the boundaries of the language, you cannot observe that any elimination happens. If you call sizeof(Foo), you will get 2*sizeof(int). If you create an array of Foos, the distance between the beginnings of two consecutive objects of Foo is always sizeof(Foo) bytes.

Your type is a standard layout type, which means that you can also access on members based on compile-time computed offsets (cf. the offsetof macro). Moreover, you can inspect the byte-by-byte representation of the object by copying onto an array of char using std::memcpy. In all these cases, the second member can be observed to be there.

Farzad Karimi
  • 770
  • 1
  • 12
  • 31
Handy999
  • 766
  • 4
  • 8
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackoverflow.com/rooms/189694/discussion-on-answer-by-handy999-does-an-unused-member-variable-take-up-memory). – Cody Gray - on strike Mar 08 '19 at 18:09
  • 2
    +1: only aggressive whole-program optimization could possibly adjust data layout (including compile-time sizes and offsets) for cases where a local struct object isn't optimized away entirely, . `gcc -fwhole-program -O3 *.c` could in theory do it, but in practice probably won't. (e.g. in case the program makes some assumptions about what exact value `sizeof()` has on this target, and because it's a really complicated optimization that programmers should do by hand if they want it.) – Peter Cordes Mar 08 '19 at 22:58
6

The examples provided by other answers to this question which elide var2 are based on a single optimization technique: constant propagation, and subsequent elision of the whole structure (not the elision of just var2). This is the simple case, and optimizing compilers do implement it.

For unmanaged C/C++ codes the answer is that the compiler will in general not elide var2. As far as I know there is no support for such a C/C++ struct transformation in debugging information, and if the struct is accessible as a variable in a debugger then var2 cannot be elided. As far as I know no current C/C++ compiler can specialize functions according to elision of var2, so if the struct is passed to or returned from a non-inlined function then var2 cannot be elided.

For managed languages such as C#/Java with a JIT compiler the compiler might be able to safely elide var2 because it can precisely track if it is being used and whether it escapes to unmanaged code. The physical size of the struct in managed languages can be different from its size reported to the programmer.

Year 2019 C/C++ compilers cannot elide var2 from the struct unless the whole struct variable is elided. For interesting cases of elision of var2 from the struct, the answer is: No.

Some future C/C++ compilers will be able to elide var2 from the struct, and the ecosystem built around the compilers will need to adapt to process elision information generated by compilers.

atomsymbol
  • 370
  • 8
  • 11
  • 1
    Your paragraph about debug information boils down to "we can't optimize it away if that would make debugging harder", which is just plain wrong. Or I'm misreading. Could you clarify? – Max Langhof Mar 11 '19 at 08:22
  • If the compiler emits debug information about the struct then it cannot elide var2. Options are: (1) Do not emit the debug information if does not correspond to the physical representation of the struct, (2) Support struct member elision in debug information and emit the debug information – atomsymbol Mar 11 '19 at 11:47
  • Perhaps more general is to refer to Scalar Replacement of Aggregates (and then elision of dead stores, *etc.*). – Davis Herring Jan 13 '20 at 18:18
4

It's dependent on your compiler and its optimization level.

In gcc, if you specify -O, it will turn on the following optimization flags:

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

-fdce stands for Dead Code Elimination.

You can use __attribute__((used)) to prevent gcc eliminating an unused variable with static storage:

This attribute, attached to a variable with static storage, means that the variable must be emitted even if it appears that the variable is not referenced.

When applied to a static data member of a C++ class template, the attribute also means that the member is instantiated if the class itself is instantiated.

Toby Speight
  • 27,591
  • 48
  • 66
  • 103
wonter
  • 415
  • 2
  • 14
  • That's for *static* data members, not unused per-instance members (which don't get optimized away unless the whole object does). But yes, I guess that does count. BTW, eliminating unused static variables isn't dead *code* elimination, unless GCC bends the term. – Peter Cordes Mar 08 '19 at 23:00