Thread: sizeof for an extern array

You can't take the sizeof an incomplete type.
You can add something like this after your array definition:

Code:

const int strings_size = sizeof strings / sizeof strings[0];

and then in the other file

Code:

extern const int strings_size;

Alternatively you could use a macro in a header (which you would need to keep updated).
Or you could include a sentinel value at the end of the array so the size isn't needed.

Is this supposed to be an array of string constants? If so, then the best solution would be to define them inline in a header file:

Code:

inline const char strings[][64] = {
    "One",
    "Two",
    "Three"
};

then include this header file in each of the source files that need this array of string constants. You would need to compile with respect to C++17 or later though.

If this really is an array of string variables instead, then I would ask you to re-consider if you really need such global state. If you do, you can still take the above approach, though an unwary reader might mistake them as constants, so there might still be some benefit to using the old extern approach with the calculated size as john.c suggested (or maybe you can warn the unwary reader by writing a comment to explain the global state).

EDIT:

Originally Posted by john.c

Alternatively you could use a macro in a header (which you would need to keep updated).

If you want to do it that way though, I would suggest a modern C++ alternative:

Code:

inline std::array<char[64], 3> strings{
    "One",
    "Two",
    "Three"
};

Again, because of the inline variable, this requires C++17 or later, but this has the advantage of strongly associating the size with what it is the size of (i.e., strings.size()), while thanks to inlining there should be no function call penalty. It also has the advantage of a compile error should you increase the number of elements in the initialiser while forgetting to update the size, whereas with a macro this mistake could pass silently at compile time.

Now that I think about it, my solution is pretty bad. I also forgot this was the C++ forum, so I didn't consider std::array.

It does make sense that they are probably constants. For the string constants you may as well get rid of the [64] and make them pointers. A sentinel is even more feasible in that case as nullptr:

Code:

// file1.cpp
 
// It's global, so give it a big name and capitalize it.
const char *StringConstants[] = {
    "one",
    "two",
    "three",
    nullptr
};
 
// file2.cpp
 
extern const char *StringConstants[];
 
//...
    for (const char **s = StringConstants; *s; ++s)
        std::cout << *s << '\n';

Originally Posted by laserlight

Is this supposed to be an array of string constants? If so, then the best solution would be to define them inline in a header file:

Code:

inline const char strings[][64] = {
    "One",
    "Two",
    "Three"
};

then include this header file in each of the source files that need this array of string constants. You would need to compile with respect to C++17 or later though.

If this really is an array of string variables instead, then I would ask you to re-consider if you really need such global state. If you do, you can still take the above approach, though an unwary reader might mistake them as constants, so there might still be some benefit to using the old extern approach with the calculated size as john.c suggested (or maybe you can warn the unwary reader by writing a comment to explain the global state).

EDIT:

If you want to do it that way though, I would suggest a modern C++ alternative:

Code:

inline std::array<char[64], 3> strings{
    "One",
    "Two",
    "Three"
};

Again, because of the inline variable, this requires C++17 or later, but this has the advantage of strongly associating the size with what it is the size of (i.e., strings.size()), while thanks to inlining there should be no function call penalty. It also has the advantage of a compile error should you increase the number of elements in the initialiser while forgetting to update the size, whereas with a macro this mistake could pass silently at compile time.

thanks for learning me new ways of C++,going to try string constants next time instead of string variables,must be better compiled into constants readonly section than accidently write over it with pointer gone astray