Board index » cppbuilder » Initialization of a struct, false variable...

2005-12-08 07:48:03 PM
cppbuilder89
Hi all,
following global structure:
struct Nachricht
{
int integer;
bool gelesen;
};
Then in one of my functions:
Nachricht news;
When I had a look on the 2 variables I have seen that the
integer variable has allways undefined values. But the bool
variable seems to have allways the value FALSE.
Can I confidence that the bool variables have allways the
value FALSE or not??
Thanks
Marius
 

It is also done randomly as I have noticed...
 

mauro wrote:
will initialise the two members to zero.
Hans.
 

{smallsort}

"mauro" < XXXX@XXXXX.COM >writes:
in the values inside. bool values are not guaranteed to be false.
I've seen one program that depended on an uninitialized boolean value
that worked correctly for over a year before a failure occurred. Some
maintenance coding in totally unrelated section somehow changed the
value that aligned with the variable, and it flipped. Very
surprising, and not easy to track down.
--
Chris (TeamB);
 

mauro wrote:
use '={ 0 };' but it's better IMO to give them their own constructors
eg;
struct Nachricht
{
int integer;
bool gelesen;
Nachricht()
{
integer=0;
gelesen=false;
}
};
..or slightly better especially for nonbuilt-in types:
Nachricht()
:integer( 0 ),
gelesen( false )
{;}
This is better because without it more complicated types (such as class
members) will first be constructed and then assigned. The above code
makes the construction and assignment one operation. For built-in types
this isn't an issue since construction is a 'no-operation' but for
classes the saving can be significant.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

"Hans Galema" < XXXX@XXXXX.COM >wrote in message
double doh[42];
Does this do doh = {0} ?
 

"Duane Hebert" < XXXX@XXXXX.COM >wrote:
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK
 

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >writes:
for non-POD structs.
other tradeoffs by making a POD become non-POD. For one example,
adding a constructor to a struct means that you can no longer use
"offsetof" on that struct.
But I frequently find structs migrate into classes anyway, and so we
might as well start off with them that way if there is any suspicion
that it may happen.
--
Chris (TeamB);
 

Chris Uzdavinis (TeamB) wrote:
ctor doesn't change the size of the struct.
and we read and write them to/from disks without any issues. We even
share them with external libraries. If they aren't POD in theory then
BCB is using some clever magic and they are POD in practice.
going to be treated like a formatted block of memory. Anything with any
intrinsic intelligence uses 'class'.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >writes:
doesn't change, but PODs have certain properties, like being able to
be initialized with memset, and if there's a constructor, memset would
bypass the beginning of the object's life. Further, if there are
externally-visible side-effects, they won't happen either.
A POD-struct is defined in terms of an aggregate with additional
limitations. Class-type aggregates cannot have constructors, among
other things.
if they're not, you have undefined behavior. But the likelihood of
this being a real problem, if all you have is a constructor, is
probably pretty small. It's still worth noting that this is a
potential problem, in case it ever breaks you can't complain. :)
with any upgrade...
needs just a "tiny" helper. And then it starts to grow. And then I
remind myself about how often this happens and wonder why I keep
falling into the same trap!
--
Chris (TeamB);
 

Hmm, the discussion sounds very strange :o)
 

Chris Uzdavinis (TeamB) wrote:
#include <string>
struct Test {
std::string data;
};
int main()
{
Test t = { "Hello World" };
}
Note: due to a bug in BCB6 this will indeed fail to compile.
Try it in BCB2006(preview) or a more modern compiler, and you might
want to rephrase your statement ;?)
--
AlisdairM(TeamB)
 

"Duane Hebert" < XXXX@XXXXX.COM >writes:
double doh[42] = {0};
As assignment? No.
doh = {0}; // error
 

"Alisdair Meredith[TeamB]" wrote:
POD-ness is recursive but aggregate-ness isn't.
All PODs are aggregates, but not vice-versa.
You can use aggregate initialization syntax on any aggregate, whether or not it is a POD.
From ISO C++98 8.5.1:
An aggregate is an array or a class (clause 9) with no
userdeclared constructors (12.1), no private or protected
nonstatic data members (clause 11), no base classes (clause
10), and no virtual functions (10.3).
From 9#4:
A POD-struct is an aggregate class that has no nonstatic
data members of type pointer to member, non-POD-struct,
nonPODunion (or array of such types) or reference, and
has no userdefined copy assignment operator and no
userdefined destructor.
 

"Thomas Maeder [TeamB]" < XXXX@XXXXX.COM >wrote in message
struct spoo {
int x;
double y;
double doh[42];
};
Then
spoo foo = {0};
Is it guaranteed that doh will be initialized to
all zeroes?
With MSVC7.1 this is the case. I wanted to know
if this was guaranteed behavior. From Alan's response,
I take it that it is guaranteed. I know that saying
double doh[42] = {0}; works. I wasn't sure
about when the array was a member of a structure
as I show above.
Thanks.