If I needed to initialize only a few select values of a C++ struct, would this be correct:
struct foo {
foo() : a(true), b(true) {}
bool a;
bool b;
bool c;
} bar;
Am I correct to assume I would end up with one struct item called bar with elements bar.a = true, bar.b = true and an undefined bar.c?
You don't even need to define a constructor
struct foo {
bool a = true;
bool b = true;
bool c;
} bar;
To clarify: these are called brace-or-equal-initializers (because you may also use brace initialization instead of equal sign). This is not only for aggregates: you can use this in normal class definitions. This was added in C++11.
c++ tag means C++11. People are welcome to say C++98 or C++03 if they want to discuss an old version. And sometime next year, the bare c++ tag will change again to mean C++14.
std::is_pod<T>::value) and so, in that sense, is equivalent to writing a non-default constructor that sets the same values in an initialiser list.
Yes. bar.a and bar.b are set to true, but bar.c is undefined. However, certain compilers will set it to false.
See a live example here: struct demo
According to C++ standard Section 8.5.12:
if no initialization is performed, an object with automatic or dynamic storage duration has indeterminate value
For primitive built-in data types (bool, char, wchar_t, short, int, long, float, double, long double), only global variables (all static storage variables) get default value of zero if they are not explicitly initialized.
If you don't really want undefined bar.c to start with, you should also initialize it like you did for bar.a and bar.b.
You can do it by using a constructor, like this:
struct Date
{
int day;
int month;
int year;
Date()
{
day=0;
month=0;
year=0;
}
};
or like this:
struct Date
{
int day;
int month;
int year;
Date():day(0),
month(0),
year(0){}
};
In your case bar.c is undefined,and its value depends on the compiler (while a and b were set to true).
ints the members were custom classes that had to meet the definition of trivial (e.g. no non-default constructor), that would be a reason to assign in the body instead of constructing in the init list. however, the number of scenarios in which this is useful are, presumably, a tiny minority, so init lists should definitely be the default recommendation - with the rare exceptions being carefullly qualified and justified, unlike here.
default ctors are inappropriate & standard layout precludes non-default constructors, one must perform 'initialisation' another way, be it operator= or an init function or whatever. It makes sense to do this 'iniitialisation' in the parent's constructor i.e. assign in its body. operator= here is equivalent to in-body assignment of primitives as in the post. Overthinking or tangential maybe, but true ;-)An explicit default initialization can help:
struct foo {
bool a {};
bool b {};
bool c {};
} bar;
Behavior bool a {} is same as bool b = bool(); and return false.
baris a variable.typedef struct foo {} bar;.baris the struct, what'sfoo? Is this the same as defining afoostruct and separately declaring a new variablebaras typefoo?struct foo {//something};foo bar;