Re: Initializing simple POD (members) / value_initialized
* Martin T.:
Tech07 wrote:
Martin T. wrote:
Hi all!
For holding various configuration data items, we are considering
using
some structs that would look like so:
struct subject {
size_t id;
std::wstring name;
double length;
// ...
};
struct subject_list {
std::wstring list_id;
std::vector<subject> subjects;
int position;
};
// ...
Now - I find it annoying, that to have proper default initialized
POD
members, I would need to supply a default ctor that initializes all
members to zero.
And after you add a constructor to your POD, it's no longer a POD!
(Though
in practice, it probably is on most compilers?).
I think you misundersood. With POD I was referring to the int, size_t
and double - not to the structs.
I don't think a struct with a std::string in it is a POD. (nor do I
care
here).
The word you're looking for is "aggregate", a struct or raw array that
would be a POD except that there are non-POD members (or array
elements).
In C++0x the initialization rules were changed to support easy default
initialization of aggregates, with the same syntax as used for PODs in
C++98.
This is called "value initialization".
As far as I know value initialization was the only really new thing in
C++03, the rest being just technical corrections of the C++98
standard's wording (and probably value initialization wouldn't have
been there if the C++98 default initialization wasn't so bad and
inconsistent that it was regarded as a defect).
In practice, since not all popular compilers properly support C++
value initialization, there are only a few options available:
* write constructors with initializer lists (fragile), or
* replace direct use of 'int' etc. with classes such as 'Int' etc.
(impractical and possibly quite inefficient), or
* collect the pure POD stuff in pure POD base classes, which can be
default initialized via C++98 rules (maintainance problem).
Choosing what I see as the least of three evils, I recommend just
writing the constructors.
It would have been nice if the language instead had provided e.g. a
pseudo value "uninitialized" compatible with all types, e.g. just
using the keyword "void" for that -- and then required everything to
be initialized or explicitly uninitialized with about the same rules
as the requirement for "const".
And one can do a similar thing for one's own vectors and strings and
stuff, but there it only helps with avoiding inefficiencies. To help
with correctness language support is needed. But alas, it would be a
complete reworking of the language, incompatible with nearly all
existing code. :-( I can think of *one* way of introducing such a
change, and that would be via #pragmas that turned on the new language
rules. That way, new code could benefit.
Cheers & hth.,
- Alf
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]