2

Suppose I have have a Car.h which define a class called Car , and I have implementation Car.cpp which implement my class Car, for example my Car.cpp can be :

struct Helper { ... };
Helper helpers[] = { /* init code */  };
Car::Car() {}
char *Car::GetName() { .....}

What is the life time of the helpers array ? Do I need say static Helper helpers[]; ? If I have done some bad practices, please let me know.

iammilind
  • 68,093
  • 33
  • 169
  • 336
dan_l
  • 1,692
  • 2
  • 23
  • 40

2 Answers2

3

Any variable declared/defined in global / namespace scope has a complete life time until the code ends.

If you want your Helper helpers[]; to be accessible only within Car.cpp then only you should declare it as static; otherwise let it be a global. In other words,

Helper helpers[];        // accessible everywhere if `extern`ed to the file
static Helper helpers[];  // accessible only in `Car.cpp`

Edit: As, @andrewdski suggested in comment below; you should make helpers[] as static variable since you are using it within this file; even though Helper is not visible outside. In C++, if 2 entirely different unit has same named global variables then compiler silently create a mess by referring them to the same memory location.

iammilind
  • 68,093
  • 33
  • 169
  • 336
  • 1
    I posted an answer that misunderstood the question, but this is correct. I thought the code he posted was the header file! In any case, I would say best practice would be to use `static` to make `helpers` local to the .CPP file (assuming, as seems likely, that is the intent). – andrewdski Jul 15 '11 at 03:24
  • 1
    @andrewdski, yes you are right. However, since the `Helper` is declared within `.cpp` file, it will not have any effect whether `helper[]` is made `static` or not. – iammilind Jul 15 '11 at 03:27
  • 1
    It will pollute the global namespace. Suppose he later writes a Truck.cpp that also needs a `helper` array. – andrewdski Jul 15 '11 at 03:39
  • @iammilind, to clarify andrewdski, the name becames a globally visible name `helper`. Should another file declare a distinct object called `helper` you'll get a linker error about duplicate symbols. Alternately another file could use `extern` and gain access to the original `helper` variable. To prevent this one must use either `static` or an anonymous namespace. – edA-qa mort-ora-y Jul 15 '11 at 07:12
  • @edA-qa mort-ora-y, ya I got his point at that time. I have edited my answer. Thanks @andrewdski, I missed that point of similar name problem – iammilind Jul 15 '11 at 07:14
  • Okay, but it won't *silently* create a mess. The linker will refuse to link -- otherwise you have a severely broken linker. – edA-qa mort-ora-y Jul 15 '11 at 13:05
  • if I have a helper function that should be local to the file , should I also declare it static as well ? How about struct Helper ; can it name-collide with another other types outside of this file ? – dan_l Jul 15 '11 at 18:41
  • @dan_L, `struct Helper` would not collide; but to point that it's just used in the given file, you can put it inside **unnamed** namespace. i.e. `namespace { struct Helper {... }; }`; apart from this whatever function/objects are local to the file, **always** declare them `static`. – iammilind Jul 16 '11 at 02:52
2

Objects defined at file scope are called Static Storage Duration objects.

In most situations you can think of them as being created before main() is entered and destroyed after main() is exited (there are exceptions but I would not worry about that).

  • The order of destruction of static storage duration variables is the reverse order of creation.

  • The order of creation within the same compilation unit (file) is the order they are declared.

    • Note: There is no guarantee about the order of creation of Static Storage Duration objects across different compilation units.
Martin York
  • 257,169
  • 86
  • 333
  • 562