Alias for a std::vector

[Peter Olcott]

I am trying to refer to the same std::vector in a class by two different names,
I tried a union, and I tried a reference, I can't seem to get the syntax right.
Can anyone please help? Thanks

[Victor Bazarov]

Peter Olcott wrote:

I am trying to refer to the same std::vector in a class by two
different names, I tried a union, and I tried a reference, I can't
seem to get the syntax right. Can anyone please help? Thanks

See FAQ 5.8.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Peter Olcott]

struct Test {
union {
std::vector<intFred;
std::vector<intCharlie;
};
};
struct Test2 {
union {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};
};

Neither of these two compile

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:tf******************************@comcast.com. ..

Peter Olcott wrote:

>I am trying to refer to the same std::vector in a class by two
different names, I tried a union, and I tried a reference, I can't
seem to get the syntax right. Can anyone please help? Thanks

See FAQ 5.8.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jim Langston]

"Victor Bazarov" <v.********@comAcast.netwrote in message

news:tf******************************@comcast.com. ..

>Peter Olcott wrote:

>>I am trying to refer to the same std::vector in a class by two
different names, I tried a union, and I tried a reference, I can't
seem to get the syntax right. Can anyone please help? Thanks

See FAQ 5.8.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

"Peter Olcott" <ol****@att.netwrote in message
news:XVwEg.772$Tl4.125@dukeread06...

struct Test {
union {
std::vector<intFred;
std::vector<intCharlie;
};
};
struct Test2 {
union {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};
};

Neither of these two compile

Please don't top post. I fixed the order of your post.

std::vector is a container. You can only use POD (Plain Old Data) in
unions, not classes or (probably) templates.

If you want Charlie to be an alias to Fred, make it a reference.

std::vector<intFred;
std::vector<int>& Charlie = Fred;

[Peter Olcott]

"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...

>"Victor Bazarov" <v.********@comAcast.netwrote in message
news:tf******************************@comcast.com ...

>>Peter Olcott wrote:
I am trying to refer to the same std::vector in a class by two
different names, I tried a union, and I tried a reference, I can't
seem to get the syntax right. Can anyone please help? Thanks

See FAQ 5.8.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

"Peter Olcott" <ol****@att.netwrote in message
news:XVwEg.772$Tl4.125@dukeread06...

>struct Test {
union {
std::vector<intFred;
std::vector<intCharlie;
};
};
struct Test2 {
union {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};
};

Neither of these two compile

Please don't top post. I fixed the order of your post.

std::vector is a container. You can only use POD (Plain Old Data) in unions,
not classes or (probably) templates.

If you want Charlie to be an alias to Fred, make it a reference.

std::vector<intFred;
std::vector<int>& Charlie = Fred;

My second example above tries this, and it does not compile.

[Ian Collins]

Peter Olcott wrote:

"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...

>>
std::vector is a container. You can only use POD (Plain Old Data) in unions,
not classes or (probably) templates.

If you want Charlie to be an alias to Fred, make it a reference.

std::vector<intFred;
std::vector<int>& Charlie = Fred;

My second example above tries this, and it does not compile.

No it doesn't, you still have them in a union.

--
Ian Collins.

[Peter Olcott]

"Ian Collins" <ia******@hotmail.comwrote in message
news:4k************@individual.net...

Peter Olcott wrote:

>"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...

>>>
std::vector is a container. You can only use POD (Plain Old Data) in unions,
not classes or (probably) templates.

If you want Charlie to be an alias to Fred, make it a reference.

std::vector<intFred;
std::vector<int>& Charlie = Fred;

My second example above tries this, and it does not compile.

No it doesn't, you still have them in a union.

--
Ian Collins.

[Peter Olcott]

"Ian Collins" <ia******@hotmail.comwrote in message
news:4k************@individual.net...

Peter Olcott wrote:

>"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...

>>>
std::vector is a container. You can only use POD (Plain Old Data) in unions,
not classes or (probably) templates.

If you want Charlie to be an alias to Fred, make it a reference.

std::vector<intFred;
std::vector<int>& Charlie = Fred;

My second example above tries this, and it does not compile.

No it doesn't, you still have them in a union.

--
Ian Collins.

struct Test2 {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};

That was just a cut-and-paste error. The above code does not compile.

[Peter Olcott]

"Ian Collins" <ia******@hotmail.comwrote in message
news:4k************@individual.net...

Peter Olcott wrote:

>"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...

>>>
std::vector is a container. You can only use POD (Plain Old Data) in unions,
not classes or (probably) templates.

If you want Charlie to be an alias to Fred, make it a reference.

std::vector<intFred;
std::vector<int>& Charlie = Fred;

My second example above tries this, and it does not compile.

No it doesn't, you still have them in a union.

--
Ian Collins.

Here is the whole program and the error messages:

#include <vector>

struct Test2 {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};

int main() {
}
O:\cpp>set echo on

O:\cpp>cl -GX -O2 t.cpp 1>Error

O:\cpp>type Error
t.cpp
T.CPP(7) : error C2327: 'Test2::Fred' : member from enclosing class is not a
type name, static, or enumerator
T.CPP(7) : error C2065: 'Fred' : undeclared identifier
T.CPP(7) : error C2864: 'Charlie' : only const static integral data members can
be initialized inside a class or struct

[Salt_Peter]

Peter Olcott wrote:

"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:tf******************************@comcast.com. ..
Peter Olcott wrote:
I am trying to refer to the same std::vector in a class by two
different names, I tried a union, and I tried a reference, I can't
seem to get the syntax right. Can anyone please help? Thanks

See FAQ 5.8.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

"Peter Olcott" <ol****@att.netwrote in message
news:XVwEg.772$Tl4.125@dukeread06...

struct Test {
union {
std::vector<intFred;
std::vector<intCharlie;
};
};
struct Test2 {
union {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};
};

Neither of these two compile

Please don't top post. I fixed the order of your post.

std::vector is a container. You can only use POD (Plain Old Data) in unions,
not classes or (probably) templates.

If you want Charlie to be an alias to Fred, make it a reference.

std::vector<intFred;
std::vector<int>& Charlie = Fred;

My second example above tries this, and it does not compile.

As was explained, the second example implements a union with the
afore-mentioned consequences.

#include <iostream>
#include <ostream>
#include <vector>

struct Test
{
std::vector<intFred;
std::vector<int>& Charlie;
public:
Test() : Fred(), Charlie(Fred) { }
~Test() { }
void getLocations() const
{
std::cout << "&Fred = " << &Fred;
std::cout << "\n&Charlie = " << &Charlie;
std::cout << std::endl;
}
};

int main()
{
Test test;
test.getLocations();
return 0;
}

/*
&Fred = 006BFDD8
&Charlie = 006BFDD8
*/

[Peter Olcott]

"Salt_Peter" <pj*****@yahoo.comwrote in message
news:11*********************@m79g2000cwm.googlegro ups.com...

>
Peter Olcott wrote:

>"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...

>"Victor Bazarov" <v.********@comAcast.netwrote in message
news:tf******************************@comcast.com ...
Peter Olcott wrote:
I am trying to refer to the same std::vector in a class by two
different names, I tried a union, and I tried a reference, I can't
seem to get the syntax right. Can anyone please help? Thanks

See FAQ 5.8.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
"Peter Olcott" <ol****@att.netwrote in message
news:XVwEg.772$Tl4.125@dukeread06...
struct Test {
union {
std::vector<intFred;
std::vector<intCharlie;
};
};
struct Test2 {
union {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};
};

Neither of these two compile

Please don't top post. I fixed the order of your post.

std::vector is a container. You can only use POD (Plain Old Data) in
unions,
not classes or (probably) templates.

If you want Charlie to be an alias to Fred, make it a reference.

std::vector<intFred;
std::vector<int>& Charlie = Fred;

My second example above tries this, and it does not compile.

As was explained, the second example implements a union with the
afore-mentioned consequences.

#include <iostream>
#include <ostream>
#include <vector>

struct Test
{
std::vector<intFred;
std::vector<int>& Charlie;
public:
Test() : Fred(), Charlie(Fred) { }
~Test() { }
void getLocations() const
{
std::cout << "&Fred = " << &Fred;
std::cout << "\n&Charlie = " << &Charlie;
std::cout << std::endl;
}
};

int main()
{
Test test;
test.getLocations();
return 0;
}

/*
&Fred = 006BFDD8
&Charlie = 006BFDD8
*/

That was simply a cut-and-paste error. I posted the whole program and the
compiler error messages on a previous post.

[Victor Bazarov]

Peter Olcott wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:4k************@individual.net...

>Peter Olcott wrote:

>>"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...
std::vector is a container. You can only use POD (Plain Old Data)
in unions, not classes or (probably) templates.

If you want Charlie to be an alias to Fred, make it a reference.

std::vector<intFred;
std::vector<int>& Charlie = Fred;
My second example above tries this, and it does not compile.

No it doesn't, you still have them in a union.

--
Ian Collins.

struct Test2 {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};

That was just a cut-and-paste error. The above code does not compile.

Correct. Declarations of members shall not have any initialisation
unless they are of static integral constants. All initialisation has
to go to the constructor initialiser list.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Victor Bazarov]

Peter Olcott wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:4k************@individual.net...

>Peter Olcott wrote:

>>"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...
std::vector is a container. You can only use POD (Plain Old Data)
in unions, not classes or (probably) templates.

If you want Charlie to be an alias to Fred, make it a reference.

std::vector<intFred;
std::vector<int>& Charlie = Fred;
My second example above tries this, and it does not compile.

No it doesn't, you still have them in a union.

--
Ian Collins.

Here is the whole program and the error messages:

#include <vector>

struct Test2 {
std::vector<intFred;
std::vector<int>& Charlie = Fred;

Drop the "= Fred" portion, and add here:

Test2() : Charlie(Fred) {}

};

int main() {
}
O:\cpp>set echo on

O:\cpp>cl -GX -O2 t.cpp 1>Error

O:\cpp>type Error
t.cpp
T.CPP(7) : error C2327: 'Test2::Fred' : member from enclosing class
is not a type name, static, or enumerator
T.CPP(7) : error C2065: 'Fred' : undeclared identifier
T.CPP(7) : error C2864: 'Charlie' : only const static integral data
members can be initialized inside a class or struct

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Ian Collins]

Peter Olcott wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:4k************@individual.net...

>>Peter Olcott wrote:

>>>
My second example above tries this, and it does not compile.

No it doesn't, you still have them in a union.

--
Ian Collins.

Here is the whole program and the error messages:

#include <vector>

struct Test2 {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};

int main() {
}

As shown else thread, you can't do this, a minimum solution is

struct Test2 {
std::vector<intFred;
std::vector<int>& Charlie;

Test2() : Charlie(Fred) {}
};
--
Ian Collins.

[Peter Olcott]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:cq******************************@comcast.com. ..

Peter Olcott wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:4k************@individual.net...

>>Peter Olcott wrote:
"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...

>
std::vector is a container. You can only use POD (Plain Old Data)
in unions, not classes or (probably) templates.
>
If you want Charlie to be an alias to Fred, make it a reference.
>
std::vector<intFred;
std::vector<int>& Charlie = Fred;
>

My second example above tries this, and it does not compile.

No it doesn't, you still have them in a union.

--
Ian Collins.

struct Test2 {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};

That was just a cut-and-paste error. The above code does not compile.

Correct. Declarations of members shall not have any initialisation
unless they are of static integral constants. All initialisation has
to go to the constructor initialiser list.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Ah that seems to be right, I will try it.

[Peter Olcott]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:u_******************************@comcast.com. ..

Peter Olcott wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:4k************@individual.net...

>>Peter Olcott wrote:
"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...

>
std::vector is a container. You can only use POD (Plain Old Data)
in unions, not classes or (probably) templates.
>
If you want Charlie to be an alias to Fred, make it a reference.
>
std::vector<intFred;
std::vector<int>& Charlie = Fred;
>

My second example above tries this, and it does not compile.

No it doesn't, you still have them in a union.

--
Ian Collins.

Here is the whole program and the error messages:

#include <vector>

struct Test2 {
std::vector<intFred;
std::vector<int>& Charlie = Fred;

Drop the "= Fred" portion, and add here:

Test2() : Charlie(Fred) {}

Yes that did it, thanks.

>

>};

int main() {
}
O:\cpp>set echo on

O:\cpp>cl -GX -O2 t.cpp 1>Error

O:\cpp>type Error
t.cpp
T.CPP(7) : error C2327: 'Test2::Fred' : member from enclosing class
is not a type name, static, or enumerator
T.CPP(7) : error C2065: 'Fred' : undeclared identifier
T.CPP(7) : error C2864: 'Charlie' : only const static integral data
members can be initialized inside a class or struct

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jerry Coffin]

In article <d5xEg.773$Tl4.593@dukeread06>, ol****@att.net says...

[ ... ]

struct Test2 {
union {
std::vector<intFred;
std::vector<int>& Charlie = Fred;
};
};

[ ... ]

My second example above tries this, and it does not compile.

This is still trying to put a vector<intinside of a union, and (as
already mentioned) you can only put PODs into unions. There's also the
minor detail that in-place initialization like you've tried to use above
can be used with things like static const variables, or with
enumerators, but not with normal data members. Try something like this:

struct Test3 {
std::vector<intFred;
std::vector<int&Charlie;

Test3() : Charlie(Fred) {}
};

....and there's a good chance your compiler will be happier.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Peter Olcott]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:u_******************************@comcast.com. ..

Peter Olcott wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:4k************@individual.net...

>>Peter Olcott wrote:
"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...

>
std::vector is a container. You can only use POD (Plain Old Data)
in unions, not classes or (probably) templates.
>
If you want Charlie to be an alias to Fred, make it a reference.
>
std::vector<intFred;
std::vector<int>& Charlie = Fred;
>

My second example above tries this, and it does not compile.

No it doesn't, you still have them in a union.

--
Ian Collins.

Here is the whole program and the error messages:

#include <vector>

struct Test2 {
std::vector<intFred;
std::vector<int>& Charlie = Fred;

Drop the "= Fred" portion, and add here:

Test2() : Charlie(Fred) {}

The basic idea works, yet I don't know the required syntax for all of my other
constructors.
What is the syntax for an initializer list when the constructor has parameters?

>

>};

int main() {
}
O:\cpp>set echo on

O:\cpp>cl -GX -O2 t.cpp 1>Error

O:\cpp>type Error
t.cpp
T.CPP(7) : error C2327: 'Test2::Fred' : member from enclosing class
is not a type name, static, or enumerator
T.CPP(7) : error C2065: 'Fred' : undeclared identifier
T.CPP(7) : error C2864: 'Charlie' : only const static integral data
members can be initialized inside a class or struct

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Jim Langston]

"Peter Olcott" <ol****@att.netwrote in message
news:1ZxEg.782$Tl4.716@dukeread06...

>
"Victor Bazarov" <v.********@comAcast.netwrote in message
news:u_******************************@comcast.com. ..

>Peter Olcott wrote:

>>"Ian Collins" <ia******@hotmail.comwrote in message
news:4k************@individual.net...
Peter Olcott wrote:
"Jim Langston" <ta*******@rocketmail.comwrote in message
news:W0**************@newsfe02.lga...
>
>>
>std::vector is a container. You can only use POD (Plain Old Data)
>in unions, not classes or (probably) templates.
>>
>If you want Charlie to be an alias to Fred, make it a reference.
>>
>std::vector<intFred;
>std::vector<int>& Charlie = Fred;
>>
>
My second example above tries this, and it does not compile.
>
No it doesn't, you still have them in a union.

--
Ian Collins.

Here is the whole program and the error messages:

#include <vector>

struct Test2 {
std::vector<intFred;
std::vector<int>& Charlie = Fred;

Drop the "= Fred" portion, and add here:

Test2() : Charlie(Fred) {}

The basic idea works, yet I don't know the required syntax for all of my
other constructors.
What is the syntax for an initializer list when the constructor has
parameters?

Test2( int SomeInt, std::string SomeString ): Charlie( Fred ), OtherVar(
SomeInt ) { /*...*/ };

>

>>

>>};

int main() {
}
O:\cpp>set echo on

O:\cpp>cl -GX -O2 t.cpp 1>Error

O:\cpp>type Error
t.cpp
T.CPP(7) : error C2327: 'Test2::Fred' : member from enclosing class
is not a type name, static, or enumerator
T.CPP(7) : error C2065: 'Fred' : undeclared identifier
T.CPP(7) : error C2864: 'Charlie' : only const static integral data
members can be initialized inside a class or struct

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Victor Bazarov]

Peter Olcott wrote:

[..]
The basic idea works, yet I don't know the required syntax for all of
my other constructors.
What is the syntax for an initializer list when the constructor has
parameters?

What book are you reading that doesn't describe parameterized c-tors
and their initialiser lists????

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Peter Olcott]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:eb**********@news.datemas.de...

Peter Olcott wrote:

>[..]
The basic idea works, yet I don't know the required syntax for all of
my other constructors.
What is the syntax for an initializer list when the constructor has
parameters?

What book are you reading that doesn't describe parameterized c-tors
and their initialiser lists????

I figured it out. It was not merely parameterized constructors with
initialization lists, I have done this before. It was the case where the
constructor has a body far too large to be contained in the declaration. I
intentionally avoided paying attention to initialization lists because IMO they
represent bad (non orthogonal) language design.

>
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Greg Comeau]

In article <zIQEg.929$Tl4.354@dukeread06>, Peter Olcott <ol****@att.netwrote:

>"Victor Bazarov" <v.********@comAcast.netwrote in message
news:eb**********@news.datemas.de...

>Peter Olcott wrote:

>>[..]
The basic idea works, yet I don't know the required syntax for all of
my other constructors.
What is the syntax for an initializer list when the constructor has
parameters?

What book are you reading that doesn't describe parameterized c-tors
and their initialiser lists????

I figured it out. It was not merely parameterized constructors with
initialization lists, I have done this before. It was the case where the
constructor has a body far too large to be contained in the declaration. I
intentionally avoided paying attention to initialization lists because IMO they
represent bad (non orthogonal) language design.

I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another
level. Also, on this note, if the body of the ctor is so far
too large that may also be problematic in its own right.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Peter Olcott]

"Greg Comeau" <co****@panix.comwrote in message
news:ec**********@panix2.panix.com...

In article <zIQEg.929$Tl4.354@dukeread06>, Peter Olcott <ol****@att.net>
wrote:

>>"Victor Bazarov" <v.********@comAcast.netwrote in message
news:eb**********@news.datemas.de...

>>Peter Olcott wrote:
[..]
The basic idea works, yet I don't know the required syntax for all of
my other constructors.
What is the syntax for an initializer list when the constructor has
parameters?

What book are you reading that doesn't describe parameterized c-tors
and their initialiser lists????

I figured it out. It was not merely parameterized constructors with
initialization lists, I have done this before. It was the case where the
constructor has a body far too large to be contained in the declaration. I
intentionally avoided paying attention to initialization lists because IMO
they
represent bad (non orthogonal) language design.

I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two entirely
different syntax ways of doing this. Initialization lists and assignment, the
former being the oddball.

level. Also, on this note, if the body of the ctor is so far
too large that may also be problematic in its own right.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Thomas J. Gritzan]

Peter Olcott schrieb:

"Greg Comeau" <co****@panix.comwrote in message

>I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two entirely
different syntax ways of doing this. Initialization lists and assignment, the
former being the oddball.

There are "two different syntax ways" for normal types:

int *pi = new int(5);
int i(5); // both: initialize i to 5

i = 5; // assign/reset i to 5

So there are two different ways for class members, too. It is not bad
language design, it is quite necessary.

By the way:

int& refi(i); // initialize int&
const int ci(7); // initialize const int

refi = &i; // can't bind to another object
ci = 11; // not possible, it's const

So references and const member variables have to use initialization list,
since assignment is not possible.

--
Thomas

[Victor Bazarov]

Peter Olcott wrote:

[..]
It is bad language design (non orthogonal) because there are two
entirely different syntax ways of doing this. Initialization lists
and assignment, the former being the oddball.

Very sorry to hear (read) that. You apparently do not understand
the difference. Read the FAQ, read more good books.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Gavin Deane]

Peter Olcott wrote:

"Greg Comeau" <co****@panix.comwrote in message

<snip>

I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two entirely
different syntax ways of doing this. Initialization lists and assignment, the
former being the oddball.

You are aware that initialisation and assignment are two entirely
different things aren't you? It seems odd to object that two entirely
different concepts have entirely different syntax.

Gavin Deane

[Peter Olcott]

"Thomas J. Gritzan" <Ph*************@gmx.dewrote in message
news:ec*********@newsreader2.netcologne.de...

Peter Olcott schrieb:

>"Greg Comeau" <co****@panix.comwrote in message

>>I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two entirely
different syntax ways of doing this. Initialization lists and assignment, the
former being the oddball.

There are "two different syntax ways" for normal types:

int *pi = new int(5);
int i(5); // both: initialize i to 5

i = 5; // assign/reset i to 5

So there are two different ways for class members, too. It is not bad
language design, it is quite necessary.

It is not necessary at all. One syntactic way of specifying anything is all that
is required. Whenever there is more than one syntactic way of specifying
anything, additional unnecessary learning curve is created. Language design
should favor the language user over the compiler writer by the same ratio of
language users to compiler writers, thus if the compiler writer has a 1,000 fold
greater burden to save the language user 0.1% effort, this is a good tradeoff.

>
By the way:

int& refi(i); // initialize int&
const int ci(7); // initialize const int

refi = &i; // can't bind to another object
ci = 11; // not possible, it's const

So references and const member variables have to use initialization list,
since assignment is not possible.

--
Thomas

[Peter Olcott]

"Gavin Deane" <de*********@hotmail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

>
Peter Olcott wrote:

>"Greg Comeau" <co****@panix.comwrote in message

<snip>

I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two entirely
different syntax ways of doing this. Initialization lists and assignment, the
former being the oddball.

You are aware that initialisation and assignment are two entirely
different things aren't you? It seems odd to object that two entirely
different concepts have entirely different syntax.

Gavin Deane

Initialization is merely the first assignment.

[Gavin Deane]

Peter Olcott wrote:

"Gavin Deane" <de*********@hotmail.comwrote in message

You are aware that initialisation and assignment are two entirely
different things aren't you? It seems odd to object that two entirely
different concepts have entirely different syntax.

Initialization is merely the first assignment.

If you read that in a book, throw the book away. If you read it on a
website, delete the website from your list of favourites. Search the
history of this group for countless discussions of the difference
between initialisation and assignment.

You've already discovered that with a class member of reference type,
by the time you first get the chance to assign to it, the opportunity
to initialise it (and references must be initialised) has been missed
and so the code cannot be correct.

Gavin Deane

[Gavin Deane]

Thomas J. Gritzan wrote:

So references and const member variables have to use initialization list,
since assignment is not possible.

It is perfectly possible to assign to a (non-const) reference and
thereby reseat it, including reference class members. What is not
possible is to leave a reference member out of the initialiser list and
reseat it in the constructor body by assignment, for the same reason
that this is not allowed

int main()
{
int& i;
}

References are not allowed to refer to nothing when they are created.

Gavin Deane

[Marcus Kwok]

Gavin Deane <de*********@hotmail.comwrote:

It is perfectly possible to assign to a (non-const) reference and
thereby reseat it, including reference class members.

How do you reseat a reference? I thought this was always impossible in
a conformant program.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Victor Bazarov]

Gavin Deane wrote:

Thomas J. Gritzan wrote:

>So references and const member variables have to use initialization
list, since assignment is not possible.

It is perfectly possible to assign to a (non-const) reference and
thereby reseat it, [..]

Are you sure? You seem a bit confused about what "reseating" means
and what the effects of assigning to a reference would be.

#include <cassert>

struct A {
int a;
};

struct B {
A &ra;
B(A& r) : ra(r) {}
};

int main() {
A a1 = {1}, a2 = {2};
B ba1(a1), ba2(a2), ba1_again(a1);

// program runs fine now.
// please _reseat_ ba1.ra to refer to a2
// without any reconstruction of ba1.
// and see if the program still works

assert(ba1_again.ra.a == 1);
}

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Victor Bazarov]

Marcus Kwok wrote:

Gavin Deane <de*********@hotmail.comwrote:

>It is perfectly possible to assign to a (non-const) reference and
thereby reseat it, including reference class members.

How do you reseat a reference? I thought this was always impossible
in a conformant program.

One can play a reconstruction trick using placement new. The same trick
is played when "chaining" constructors. I don't use it, and many people
consider those tricks rather unnecessary. There are always right ways to
use the tool and wrong ways.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Gavin Deane]

Victor Bazarov wrote:

Gavin Deane wrote:

Thomas J. Gritzan wrote:

So references and const member variables have to use initialization
list, since assignment is not possible.

It is perfectly possible to assign to a (non-const) reference and
thereby reseat it, [..]

Are you sure?

No

You seem a bit confused

I was. I'm better now.

about what "reseating" means
and what the effects of assigning to a reference would be.

Thanks for catching that.

Gavin Deane

[Peter Olcott]

"Gavin Deane" <de*********@hotmail.comwrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...

>
Peter Olcott wrote:

>"Gavin Deane" <de*********@hotmail.comwrote in message

You are aware that initialisation and assignment are two entirely
different things aren't you? It seems odd to object that two entirely
different concepts have entirely different syntax.

Initialization is merely the first assignment.

If you read that in a book, throw the book away. If you read it on a
website, delete the website from your list of favourites. Search the
history of this group for countless discussions of the difference
between initialisation and assignment.

You've already discovered that with a class member of reference type,
by the time you first get the chance to assign to it, the opportunity
to initialise it (and references must be initialised) has been missed
and so the code cannot be correct.

Gavin Deane

Initialization, semantically across languages is merely the first assignment.
The fact that C++ has things that can only be initialized and not otherwise
assigned to does not change this fundamental essential semantic meaning.
Initialization is still simply a special case of assignment.

[Victor Bazarov]

Peter Olcott wrote:

"Gavin Deane" <de*********@hotmail.comwrote in message
news:11**********************@p79g2000cwp.googlegr oups.com...

>>
Peter Olcott wrote:

>>"Gavin Deane" <de*********@hotmail.comwrote in message
You are aware that initialisation and assignment are two entirely
different things aren't you? It seems odd to object that two
entirely different concepts have entirely different syntax.

Initialization is merely the first assignment.

If you read that in a book, throw the book away. If you read it on a
website, delete the website from your list of favourites. Search the
history of this group for countless discussions of the difference
between initialisation and assignment.

You've already discovered that with a class member of reference type,
by the time you first get the chance to assign to it, the opportunity
to initialise it (and references must be initialised) has been missed
and so the code cannot be correct.

Gavin Deane

Initialization, semantically across languages is merely the first
assignment. The fact that C++ has things that can only be initialized
and not otherwise assigned to does not change this fundamental
essential semantic meaning. Initialization is still simply a special
case of assignment.

C++ has things that cannot be assigned to (arrays) and things that when
assigned to just create an illusion of that (references). Both, however,
have clear initialisation meaning and requirements. Why do you need to
mix the two distinct operations, is beyond my comprehension. C++ is not
"other languages" in many aspects, and besides, we don't discuss "other
languages" here.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Peter Olcott]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:ec**********@news.datemas.de...

Peter Olcott wrote:

>"Gavin Deane" <de*********@hotmail.comwrote in message
news:11**********************@p79g2000cwp.googleg roups.com...

>>>
Peter Olcott wrote:
"Gavin Deane" <de*********@hotmail.comwrote in message
You are aware that initialisation and assignment are two entirely
different things aren't you? It seems odd to object that two
entirely different concepts have entirely different syntax.

Initialization is merely the first assignment.

If you read that in a book, throw the book away. If you read it on a
website, delete the website from your list of favourites. Search the
history of this group for countless discussions of the difference
between initialisation and assignment.

You've already discovered that with a class member of reference type,
by the time you first get the chance to assign to it, the opportunity
to initialise it (and references must be initialised) has been missed
and so the code cannot be correct.

Gavin Deane

Initialization, semantically across languages is merely the first
assignment. The fact that C++ has things that can only be initialized
and not otherwise assigned to does not change this fundamental
essential semantic meaning. Initialization is still simply a special
case of assignment.

C++ has things that cannot be assigned to (arrays) and things that when
assigned to just create an illusion of that (references). Both, however,
have clear initialisation meaning and requirements. Why do you need to
mix the two distinct operations, is beyond my comprehension. C++ is not
"other languages" in many aspects, and besides, we don't discuss "other
languages" here.

Instead of C++ overloading the meaning of the term [initialization] to make it
mean something slightly different than what it means everywhere else, C++ should
have adopted the universal convention of the meaning of this term. If they want
to have something slightly different than what [initialization] means everywhere
else, they could come up with a different term. In any case there is no absolute
requirement for initialization lists, the same semantics could be derived using
the assignment operator. In the case of things such as references, this
initialization form of assignment would only be valid in declarations.

>
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[peter koch]

Peter Olcott skrev:

Instead of C++ overloading the meaning of the term [initialization] to make it
mean something slightly different than what it means everywhere else, C++ should
have adopted the universal convention of the meaning of this term. If they want
to have something slightly different than what [initialization] means everywhere
else, they could come up with a different term. In any case there is no absolute
requirement for initialization lists, the same semantics could be derived using
the assignment operator. In the case of things such as references, this
initialization form of assignment would only be valid in declarations.

You simply don't get it. The difference between C++ and most other
languages is that most other languages don't allow you to have special
initialisation: they have only assignment. This is the case in e.g. C
or Pascal (where there is no initialisation) and Java (where the
initialisation is system-defined). So those other languages do not need
to have a special notion of initialisation precisely because there us
none. This is related to the rules in C++ that guarantee destruction
and that objects always are in a valid state. It is for exactly the
same reason that initialisation-lists are a necessary, clean and
unavoidable part of the syntax.

/Peter

[Peter Olcott]

"peter koch" <pe***************@gmail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

>
Peter Olcott skrev:

>Instead of C++ overloading the meaning of the term [initialization] to make
it
mean something slightly different than what it means everywhere else, C++
should
have adopted the universal convention of the meaning of this term. If they
want
to have something slightly different than what [initialization] means
everywhere
else, they could come up with a different term. In any case there is no
absolute
requirement for initialization lists, the same semantics could be derived
using
the assignment operator. In the case of things such as references, this
initialization form of assignment would only be valid in declarations.

You simply don't get it. The difference between C++ and most other
languages is that most other languages don't allow you to have special
initialisation: they have only assignment. This is the case in e.g. C
or Pascal (where there is no initialisation) and Java (where the
initialisation is system-defined). So those other languages do not need
to have a special notion of initialisation precisely because there us
none. This is related to the rules in C++ that guarantee destruction
and that objects always are in a valid state. It is for exactly the
same reason that initialisation-lists are a necessary, clean and
unavoidable part of the syntax.

/Peter

Why couldn't the same thing be accomplished using the operator=() syntax?

[Victor Bazarov]

Peter Olcott wrote:

"peter koch" <pe***************@gmail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

>>
Peter Olcott skrev:

>>Instead of C++ overloading the meaning of the term [initialization]
to make it
mean something slightly different than what it means everywhere
else, C++ should
have adopted the universal convention of the meaning of this term.
If they want
to have something slightly different than what [initialization]
means everywhere
else, they could come up with a different term. In any case there
is no absolute
requirement for initialization lists, the same semantics could be
derived using
the assignment operator. In the case of things such as references,
this initialization form of assignment would only be valid in
declarations.

You simply don't get it. The difference between C++ and most other
languages is that most other languages don't allow you to have
special initialisation: they have only assignment. This is the case
in e.g. C or Pascal (where there is no initialisation) and Java
(where the initialisation is system-defined). So those other
languages do not need to have a special notion of initialisation
precisely because there us none. This is related to the rules in C++
that guarantee destruction and that objects always are in a valid
state. It is for exactly the same reason that initialisation-lists
are a necessary, clean and unavoidable part of the syntax.

/Peter

Why couldn't the same thing be accomplished using the operator=()
syntax?

Same thing as in

Widget myChildWidget(0,0,width,height,myMainWidget);

? How would you do it? This has to invoke a constructor. Once it's
invoked, you have to initialise the members

class Widget {
Canvas myCanvas;
Widget & parent;
public:
Widget(int x, int y, int w, int h, Widget& parent)
: myCanvas(x, y, w, h), myParent(parent) { }

Where and how would you use your "operator=() syntax"?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Salt_Peter]

Peter Olcott wrote:

"Greg Comeau" <co****@panix.comwrote in message
news:ec**********@panix2.panix.com...

In article <zIQEg.929$Tl4.354@dukeread06>, Peter Olcott <ol****@att.net>
wrote:

>"Victor Bazarov" <v.********@comAcast.netwrote in message
news:eb**********@news.datemas.de...
Peter Olcott wrote:
[..]
The basic idea works, yet I don't know the required syntax for all of
my other constructors.
What is the syntax for an initializer list when the constructor has
parameters?

What book are you reading that doesn't describe parameterized c-tors
and their initialiser lists????

I figured it out. It was not merely parameterized constructors with
initialization lists, I have done this before. It was the case where the
constructor has a body far too large to be contained in the declaration. I
intentionally avoided paying attention to initialization lists because IMO
they
represent bad (non orthogonal) language design.

I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two entirely
different syntax ways of doing this. Initialization lists and assignment, the
former being the oddball.

No Sir, the former is a brilliant, efficient syntax. Why construct an
unitialized object and afterwards provide it with attributes when you
can build it once as required? Or construct an object and have to limit
or fix its attributes? Or loose the ability to construct and object
that requires const attributes.

Constructors are a cornerstone of C++ and init lists simplify the
construction syntax greatly. Ignoring the immense power that an init
list provides is foolhardy. Take as an example a simple template, for a
moment.

template < class T >
class N
{
T m_t;
public:
N( T t ) : m_t( t ) { }
~N() { }
};

int main()
{
N< int n( 10 );
N< double d(11.1);
N< char c( 'a' ); // etc...
}

Init lists are too powerful and yet so simple_to_use to be ignored.

[Greg Comeau]

In article <_30Fg.1162$Tl4.145@dukeread06>,
Peter Olcott <ol****@att.netwrote:

>"Greg Comeau" <co****@panix.comwrote in message
news:ec**********@panix2.panix.com...

>In article <zIQEg.929$Tl4.354@dukeread06>, Peter Olcott <ol****@att.net>
wrote:

>>>"Victor Bazarov" <v.********@comAcast.netwrote in message
news:eb**********@news.datemas.de...
Peter Olcott wrote:
[..]
The basic idea works, yet I don't know the required syntax for all of
my other constructors.
What is the syntax for an initializer list when the constructor has
parameters?

What book are you reading that doesn't describe parameterized c-tors
and their initialiser lists????

I figured it out. It was not merely parameterized constructors with
initialization lists, I have done this before. It was the case where the
constructor has a body far too large to be contained in the declaration. I
intentionally avoided paying attention to initialization lists because IMO
they
represent bad (non orthogonal) language design.

I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two entirely
different syntax ways of doing this. Initialization lists and assignment, the
former being the oddball.

Let's assume this is true. Show us how to do it with assignment only
while still retaining all the semantics necessary. In that
description please also remember than C++ derived from C.

>level. Also, on this note, if the body of the ctor is so far
too large that may also be problematic in its own right.

--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Greg Comeau]

In article <k41Fg.1164$Tl4.31@dukeread06>, Peter Olcott <ol****@att.netwrote:

>"Thomas J. Gritzan" <Ph*************@gmx.dewrote in message
news:ec*********@newsreader2.netcologne.de...

>Peter Olcott schrieb:

>>"Greg Comeau" <co****@panix.comwrote in message
I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two entirely
different syntax ways of doing this. Initialization lists and assignment, the
former being the oddball.

There are "two different syntax ways" for normal types:

int *pi = new int(5);
int i(5); // both: initialize i to 5

i = 5; // assign/reset i to 5

So there are two different ways for class members, too. It is not bad
language design, it is quite necessary.

It is not necessary at all. One syntactic way of specifying anything is all that
is required. Whenever there is more than one syntactic way of specifying
anything, additional unnecessary learning curve is created. Language design
should favor the language user over the compiler writer by the same ratio of
language users to compiler writers, thus if the compiler writer has a 1,000 fold
greater burden to save the language user 0.1% effort, this is a good tradeoff.

The spirit of these are both reasonable tenets to follow.
I just don't see where/why they are coming into play in this discussion.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Greg Comeau]

In article <_41Fg.1165$Tl4.941@dukeread06>,

>
"Gavin Deane" <de*********@hotmail.comwrote in message
news:11**********************@75g2000cwc.googlegr oups.com...

>Peter Olcott wrote:

>>"Greg Comeau" <co****@panix.comwrote in message

<snip>

>I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two entirely
different syntax ways of doing this. Initialization lists and assignment, the
former being the oddball.

You are aware that initialisation and assignment are two entirely
different things aren't you? It seems odd to object that two entirely
different concepts have entirely different syntax.

Initialization is merely the first assignment.

At best, that sounds like a data-centeric definition.
It's a subset of the issues on the table which need
to be considered.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Jim Langston]

"Peter Olcott" <ol****@att.netwrote in message
news:_41Fg.1165$Tl4.941@dukeread06...

>
"Gavin Deane" <de*********@hotmail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...

>>
Peter Olcott wrote:

>>"Greg Comeau" <co****@panix.comwrote in message

<snip>

>I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two
entirely
different syntax ways of doing this. Initialization lists and
assignment, the
former being the oddball.

You are aware that initialisation and assignment are two entirely
different things aren't you? It seems odd to object that two entirely
different concepts have entirely different syntax.

Gavin Deane

Initialization is merely the first assignment.

Not always true. In some flavors of Basic, for example, variables are
initialized to known values by the program before you do any assignment.
Initialization in other languages is commonly used to refer to the
programming language itself, not the programming, setting variables to known
values.

Such is the fact that in my OS in my compiler if I compile and run in debug
mode the values are initialized to known values (0 for ints and floats,
etc...). In release mode they are not initialized and I have to set them.

Initialization as used in C is refered to as the first assignment because C
variables are not initialized by the operating system so the word was not
used to mean that (except for the statement, "C does not initialized
variables for you").

Now we are in C++ where we can have the language initialize variables for us
with syntax, I.E.
int* MyInt = new int();

That is true initalization, and is not a "first assignment".

You may want initialization to merely mean the first assignment, but the
truth of the matter is, it doesn't merely mean that, and is now more
commonly used in C++ to mean system initialization ( new int() ) or class
initialization of variables ( MyClass::MyClass(): MyInt( 0 ) {} )

[Peter Olcott]

"Greg Comeau" <co****@panix.comwrote in message
news:ec**********@panix2.panix.com...

In article <_30Fg.1162$Tl4.145@dukeread06>,
Peter Olcott <ol****@att.netwrote:

>>"Greg Comeau" <co****@panix.comwrote in message
news:ec**********@panix2.panix.com...

>>In article <zIQEg.929$Tl4.354@dukeread06>, Peter Olcott <ol****@att.net>
wrote:
"Victor Bazarov" <v.********@comAcast.netwrote in message
news:eb**********@news.datemas.de...
Peter Olcott wrote:
>[..]
>The basic idea works, yet I don't know the required syntax for all of
>my other constructors.
>What is the syntax for an initializer list when the constructor has
>parameters?
>
What book are you reading that doesn't describe parameterized c-tors
and their initialiser lists????

I figured it out. It was not merely parameterized constructors with
initialization lists, I have done this before. It was the case where the
constructor has a body far too large to be contained in the declaration. I
intentionally avoided paying attention to initialization lists because IMO
they
represent bad (non orthogonal) language design.

I don't understand. What you did was to ignore a cornerstone
feature of initialization because it was deemed bad language
design (why do you think so??) only to introduce same on another

It is bad language design (non orthogonal) because there are two entirely
different syntax ways of doing this. Initialization lists and assignment, the
former being the oddball.

Let's assume this is true. Show us how to do it with assignment only
while still retaining all the semantics necessary. In that
description please also remember than C++ derived from C.

If you don't already know how to do it, I would guess that I would likely be
wrong. I have never needed to use the initializer list syntax until recently, I
try to keep my code very simple. I would expect that you would know all the
little nuances that I have never learned, so I estimate that I am likely
incorrect.

>

>>level. Also, on this note, if the body of the ctor is so far
too large that may also be problematic in its own right.

--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Jerry Coffin]

In article <i_2Fg.1174$Tl4.641@dukeread06>, ol****@att.net says...

[ ... ]

Initialization, semantically across languages is merely the first assignment.
The fact that C++ has things that can only be initialized and not otherwise
assigned to does not change this fundamental essential semantic meaning.

First of all, what happens "across languages" is pretty much irrelevant.

Second, C++ has two separate operations: assignment and initialization.
The two do different things in different ways under different
circumstances. Yes, some initializations are a lot like assignments --
but others are not.

There is a separate syntax for each as well. Given that they have
different semantics, this seems perfectly reasonable, at least to me.

It should also be noted that in the case of a derived class, an
initialization list can/does specify how the base class sub-part of the
current object is to be initialized:

class base {
int x;
public:
base(int i) : x(i) {}
};

class derived : public base {
int y;
public:
derived(int i, int j) : base(i), y(j) {}
};

Now, it's true that you could assign to y instead of using an assignment
-- but you could not 'assign' to the base, or directly assign to
base::x. It's private, which is specifically intended to prevent that.

Initialization is still simply a special case of assignment.

Rather the contrary. Consider, for one example, invariant objects. An
invariant object is created (initialized) with a value, and by the
nature of the object, that value can never change (vary).

In C++ that's pretty easy to do: you have a public ctor that takes a
parameter specifying the initial value. You also make the asignment
operator private (and usually don't implement it).

Yes, if you wanted to badly enough you could undoubtedly create a
language in which you created a "first-time-only" assignment operator,
and a "subsequent assignments" operator (or whatever you prefer to call
them). In the end, this wouldn't really change much except the spelling
of things though. You still end up with a simple fact: there are some
pretty good reasons to separate the two (the invariant objects mentioned
above being only one of them).

As long as you separate the two, all you're really doing compared to the
current C++ situation is changing the spelling of the names you give to
operators. If you think it's important to spell "initialization" as some
sort of variant of "operator=", go ahead and design a language that does
so. Unless it has far more than that to attract users, however, don't be
too suprised if you're the only one who ever uses that language though.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Thomas J. Gritzan]

Peter Olcott wrote:

"Thomas J. Gritzan" <Ph*************@gmx.dewrote

>There are "two different syntax ways" for normal types:

int *pi = new int(5);
int i(5); // both: initialize i to 5

i = 5; // assign/reset i to 5

So there are two different ways for class members, too. It is not bad
language design, it is quite necessary.

It is not necessary at all.

It is.

One syntactic way of specifying anything is all that
is required.

Yes. That's why there is one syntactic way for assignment:

x = y;

and one syntactic way for initialization:

int i(5);

Lets say assignment would work for both things, and the first assignment
binds the reference (in normal functions and in constructors as well):

int i, j;
int& ri;
// much code
ri = i; // does it bind the reference to i or does it assign?
// more code
ri = j; // this will assign, doesn't it?

If you comment out the "ri = i;" line, you will change the behaviour of the
"ri = j;" line. This is bad and error phrone.

Whenever there is more than one syntactic way of specifying
anything, additional unnecessary learning curve is created. Language design
should favor the language user over the compiler writer by the same ratio of
language users to compiler writers, thus if the compiler writer has a 1,000 fold
greater burden to save the language user 0.1% effort, this is a good tradeoff.

What should be many times differs to what really is in the world.

--
Thomas

[Greg Comeau]

In article <d24Fg.1182$Tl4.813@dukeread06>,
Peter Olcott <ol****@att.netwrote:

>Instead of C++ overloading the meaning of the term [initialization]
to make it mean something slightly different than what it means
everywhere else, C++ should have adopted the universal convention
of the meaning of this term.

I believe this is an operative sentence in this discussion.
Therefore, it would be helpful for you to define what the
alledged and/or actual definition is in your opinion. That
might help to reveal why there is a difference of discussion here.

>If they want to have something slightly different than what
[initialization] means everywhere else, they could come up
with a different term.

You may have a point, but I suspect there is subset relationship
that exists due to to limitations whereby it is oft considered the rule,
but in actuality is "merely" a subset.

>In any case there is no absolute
requirement for initialization lists, the same semantics could be
derived using the assignment operator.

Let's assume this is true. Show us how. And also why it is superior.

>In the case of things such as references, this
initialization form of assignment would only be valid in declarations.

Hmm, seems to me you're already making special rules while at
the same time arguing such specialiality is unncessary and bad.
I'm certain you said that and I did not misinterpret it.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Greg Comeau]

In article <hD4Fg.1185$Tl4.306@dukeread06>,
Peter Olcott <ol****@att.netwrote:

>"peter koch" <pe***************@gmail.comwrote in message
news:11**********************@75g2000cwc.googlegr oups.com...

>Peter Olcott skrev:

>>Instead of C++ overloading the meaning of the term [initialization] to make
it
mean something slightly different than what it means everywhere else, C++
should
have adopted the universal convention of the meaning of this term. If they
want
to have something slightly different than what [initialization] means
everywhere
else, they could come up with a different term. In any case there is no
absolute
requirement for initialization lists, the same semantics could be derived
using
the assignment operator. In the case of things such as references, this
initialization form of assignment would only be valid in declarations.

You simply don't get it. The difference between C++ and most other
languages is that most other languages don't allow you to have special
initialisation: they have only assignment. This is the case in e.g. C
or Pascal (where there is no initialisation) and Java (where the
initialisation is system-defined). So those other languages do not need
to have a special notion of initialisation precisely because there us
none. This is related to the rules in C++ that guarantee destruction
and that objects always are in a valid state. It is for exactly the
same reason that initialisation-lists are a necessary, clean and
unavoidable part of the syntax.

Why couldn't the same thing be accomplished using the operator=() syntax?

Show us.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?