Alias for a std::vector

[Peter Olcott]

[..]
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.

 

[Greg Comeau]

[..]
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.

 

[Peter Olcott]

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.

 

[Thomas J. Gritzan]

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.

 

[Victor Bazarov]

[..]
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

 

[Gavin Deane]

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]

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.

 

[Peter Olcott]

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]

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]

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]

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.

 

[Victor Bazarov]

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

 

[Victor Bazarov]

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

 

[Gavin Deane]

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]

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]

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

 

[Peter Olcott]

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.

 

[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 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 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