Miranda functions and Initialization

[JKop]

Is this them all?:
class Dummy
{
public:

Dummy() {}

Dummy(const Dummy& original) { }

Dummy& operator=(const Dummy& lhs) {}

const Dummy * operator&() const { return this; }

Dummy * operator&() { return this; }

~Dummy() {}

};
Also could anyone please inform me of circumstances in which these are
edited and in which they disappear? For example I'm already aware of the
following:

1) Dummy() disappears if you supply another one that takes arguments, eg.
Dummy(int).

2) operator= and the copy constructor will change for every extra member
variable that's added to the class.
--

Now, take the following:

int main()
{
int j;
}
I'm fully aware that j contains no particular value, it hasn't been
initialized.

Now take the following:

int main()
{
int j = 45;
}

I'm fully aware that that's equal to:

int j = int(45);

But, where you have user-defined types, what exactly goes on?

For instance:

SomeClass k = 78.222;
Does that become:

SomeClass k = SomeClass(78.22 2);

And then is the SomeClass(const SomeClass&) copy constructor called? Or...
does the compiler simply look for a different copy constructor, eg.
SomeClass(const double&)? Or is that even valid?

Anyway here's what I'm getting at: I know int() is equal to zero, ie. if you
specify brackets then it gets intialized to zero. Now ofcourse you have the
problem of:

int main()
{
int j();
}

The compiler doesn't know if it's an object definition or a function
declaration (...if only "extern" was compulsory). As such, it assumes a
function declaration.

Is the only way to get around this to write:

int j(0);

?

Anyway here comes my question:

class Chocolate
{
public:

int a;

double b;

};
int main()
{
Chocolate choco;
}
Do "a" and "b" get initialized to zero? And if so, what does it? Is it the
miranda default constructor? What about in the following code:

class Chocolate
{
public:

int a;

double b;

Chocolate() {}

};
int main()
{
Chocolate choco;
}
Do "a" and "b" get initialized to zero in the above?
-JKop

[JKop]

>> SETTINGS sets = SETTINGS(); > In theory yes, in practice no, because many compilers do not
> respect the standard in this regard.

Please explain what you mean - are you saying that not
many compilers will compile the above as specified by the
Standard?

Yes.

What do they do instead?

In the absence of optimization, here's what should happen:

1) A SETTINGS object is created, all values intialized to 0.
2) sets is copy-constructed from the previous object.
3) The original object is destroyed.

And with optimization:

1) sets is created, all values initialized to 0.
Where do these other alleged C++ compilers go wayward?
-JKop

[JKop]

Thanks Rolf.

So now we have:

#include <string>

class Dummy
{
private:

int a;

protected:

std::string name;

public:

double k;
};
class DummyClone
{
private:

int a;

protected:

std::string name;

public:

double k;

public:

DummyClone() {}

DummyClone* operator&() { return this; }
const DummyClone* operator&() const { return this; }

DummyClone(cons t DummyClone& original)
: a(original.a), name(original.n ame), k(original.k) {}

DummyClone& operator=(const DummyClone& lhs)
{
a = lhs.a;
name = lhs.name;
k = lhs.k;
}

~DummyClone() { }
};
int main()
{
Dummy x;

DummyClone y;
}
Is that it now?
-JKop

[Alf P. Steinbach]

* JKop:

>> SETTINGS sets = SETTINGS(); In theory yes, in practice no, because many compilers do not
> respect the standard in this regard.

Please explain what you mean - are you saying that not
many compilers will compile the above as specified by the
Standard?

Yes.

What do they do instead?

In the absence of optimization, here's what should happen:

1) A SETTINGS object is created, all values intialized to 0.
2) sets is copy-constructed from the previous object.
3) The original object is destroyed.

And with optimization:

1) sets is created, all values initialized to 0.

Where do these other alleged C++ compilers go wayward?

According to my notes Visual C++ 7.0 is one such alleged compiler... ;-)

Visual C++ 7.1 seems to do it right.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[John Harrison]

On Sun, 01 Aug 2004 20:07:28 GMT, JKop <NU**@NULL.NULL > wrote:

Thanks Rolf.

So now we have:

#include <string>

class Dummy
{
private:

int a;
protected:

std::string name;
public:

double k;
};
class DummyClone
{
private:

int a;
protected:

std::string name;
public:

double k;

public:

DummyClone() {}
DummyClone* operator&() { return this; }
const DummyClone* operator&() const { return this; }
DummyClone(cons t DummyClone& original)
: a(original.a), name(original.n ame), k(original.k) {}
DummyClone& operator=(const DummyClone& lhs)
{
a = lhs.a;
name = lhs.name;
k = lhs.k;
}

~DummyClone() { }
};
int main()
{
Dummy x;
DummyClone y;
}
Is that it now?
-JKop

Dummy and DummyClone still differ if value initialised

Dummy* d = new Dummy();
DummyClone* dc = new DummyClone();

Here d->a and d->k are guaranteed to be zero (assuming you have a compiler
which implements value initialisation correctly) but dc->a and dc->k are
uninitialised.

john

[John Harrison]

On Sun, 01 Aug 2004 20:04:46 GMT, JKop <NU**@NULL.NULL > wrote:

>> SETTINGS sets = SETTINGS(); In theory yes, in practice no, because many compilers do not
> respect the standard in this regard.

Please explain what you mean - are you saying that not
many compilers will compile the above as specified by the
Standard?

Yes.

What do they do instead?

In the absence of optimization, here's what should happen:

1) A SETTINGS object is created, all values intialized to 0.
2) sets is copy-constructed from the previous object.
3) The original object is destroyed.

And with optimization:

1) sets is created, all values initialized to 0.
Where do these other alleged C++ compilers go wayward?
-JKop

I think many would fail to iniitalise to zero. As I understand it this was
acceptable pre-2003 standard.

john

[JKop]

> Dummy and DummyClone still differ if value initialised

Dummy* d = new Dummy();
DummyClone* dc = new DummyClone();

Here d->a and d->k are guaranteed to be zero (assuming you have a
compiler which implements value initialisation correctly) but dc->a
and dc->k are uninitialised.

john

And there's no way around this?

Also I presume that if you leave it like:

Dummy* d = new Dummy;

the it contains white noise, yes?

Now here's a tricky one:

A class that has only public data, but it has a contructor:

class Chunky
{
public:
int a;
double b;
char c;

Chunky() {}
};
If I do:

Chunky chunks;

Then "a", "b" and "c" contain white noise. That right?

While if I do:

Chunky chunks = Chunky();

Then it still contains white noise (on account of the constructor). That
right?

What I'm getting at is if a certain class has a contructor, are:

Chunk chunks;
Chunky chunks = Chunky();

identical, in that they both contain white noise?
-JKop

[John Harrison]

"JKop" <NU**@NULL.NULL > wrote in message
news:PI******** **********@news .indigo.ie...

Dummy and DummyClone still differ if value initialised

Dummy* d = new Dummy();
DummyClone* dc = new DummyClone();

Here d->a and d->k are guaranteed to be zero (assuming you have a
compiler which implements value initialisation correctly) but dc->a
and dc->k are uninitialised.

john

And there's no way around this?

I don't think so.
Also I presume that if you leave it like:

Dummy* d = new Dummy;

the it contains white noise, yes?
Yes.

Now here's a tricky one:

A class that has only public data, but it has a contructor:

class Chunky
{
public:
int a;
double b;
char c;

Chunky() {}
};
If I do:

Chunky chunks;

Then "a", "b" and "c" contain white noise. That right?
Right.

While if I do:

Chunky chunks = Chunky();

Then it still contains white noise (on account of the constructor). That
right?
Right, value initialisation only makes a difference (as far as I can tell)
for types without a constructor.

What I'm getting at is if a certain class has a contructor, are:

Chunk chunks;
Chunky chunks = Chunky();

identical, in that they both contain white noise?

It depends on the default constuctors of course, but otherwise both are
identical.

john

[JKop]

Which leads me on to POD types.

For instance, take the following:

#include <string>

class Cow
{
public:
int a;
double b;
std::string c;
};

int main
{
Cow dairy_cow = { 5, 67.2, std::string("Mo o!") };
}
It looks like a type is no longer a POD when the above syntax in "main" is
no longer valid. For instance, take:
class Cow
{
public:
int a;
double b;
std::string c;

private:

char t;
};

int main
{
Cow dairy_cow = { 5, 67.2, std::string("Mo o!") };
}
Now the compiler is telling me that a "Cow" can't be defined like that, and
that you've to use a constructor.

I've found the following things render a class no longer a POD:

a) Putting in private or protected member data
b) Putting in a constructor or copy-constructor

And that the following are no problem, it's still a POD:

a) Putting in member functions
b) Putting in operator member functions
(even if they're private or protected)
It's good to know this stuff!

So now I think I fully understand all the initialization stuff in C++.
There's just one thing that I want to figure out:

SomeClass object = SomeClass();
There has to be some sort of way of turning the following:

SomeClass object();

into an object definition. I've tried:

class SomeClass object();
struct SomeClass object();

But still they're a function declaration. That doesn't make sense to me.
It'd even be compatible with C, because while you would prefix "struct" in
C, you still wouldn't put in parenthesis. And there was no "class" in C
either.

Anyone know how to tell the compiler it's an object definition?
-JKop

[Old Wolf]

JKop <NU**@NULL.NULL > wrote:

In the following, are "Dummy" and "DummyClone " identical?
[some stuff snipped from these definitions] class Dummy
{
};

class DummyClone
{
public:
DummyClone* operator&() { return this; }
const DummyClone* operator&() const { return this; }
};
No. DummyClone contains operator& and Dummy does not. You also made
this mistake in your original post.
int main()
{
Dummy x;
DummyClone y;

}

Have I left out any miranda functions? Are there 6 in all?

You included too many. Don't be misled by mistakes in the book
'C++ by Dummies' (which also invented the term 'miranda functions').

If you don't believe it, add these lines to main:

& DummyClone::ope rator &;
& Dummy::operator &;

and note the compiler error.

[JKop]

Old Wolf posted:

You included too many. Don't be misled by mistakes in the book 'C++ by Dummies' (which also invented the term 'miranda functions').
If you don't believe it, add these lines to main:

& DummyClone::ope rator &;
& Dummy::operator &;

and note the compiler error.

Although the following *does* compile:

class Dummy {};

void Blah(Dummy* a) {}
void Blah(const Dummy*) {}

int main()
{
Dummy k = Dummy();
const Dummy j = Dummy();

Blah(&k);
Blah(&j);
}
-JKop