Alias for a std::vector

[Salt_Peter]

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]

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.

 

[Greg Comeau]

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]

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.

 

[Jim Langston]

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]

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.

 

[Jerry Coffin]

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.

 

[Thomas J. Gritzan]

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.

 

[Greg Comeau]

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]

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.

 

[Gavin Deane]

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.

If you never write a class that has any of:

a const data member
a reference data member
a member of class type that provides no default constructor
a member of class type that provides no assignment operator
a base class that provides no default constructor or for which the
default constructor is not appropriate in your context

and you're not worried about:

possible efficiency problems in default initialising then assigning to
members vs directly initialising as required
possibly violating the principle of least surprise when other people
read your code

then you can avoid using initialiser lists if you want to. But remove
any one of those caveats and you need to use the initialiser list. Once
you are using it for some objects out of necessity, there is a strong
argument for clarity and consistency that you should use it all the
time.

Gavin Deane

 

[Greg Comeau]

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.

It is important to keep things simple. But
I suspect you've only been using a subset of C++, hence limiting
your C++ programming universe. Nothing wrong with that per se.
But the breadth and width of programming is immense, and C++ captures
various aspects of that. This limiting often results in things being
"not as they should seem." A year later you'll wonder how you ever
thought such things.

 

[Greg Comeau]

If you never write a class that has any of:

a const data member
a reference data member
a member of class type that provides no default constructor
a member of class type that provides no assignment operator
a base class that provides no default constructor or for which the
default constructor is not appropriate in your context

and you're not worried about:

possible efficiency problems in default initialising then assigning to
members vs directly initialising as required
possibly violating the principle of least surprise when other people
read your code

then you can avoid using initialiser lists if you want to. But remove
any one of those caveats and you need to use the initialiser list. Once
you are using it for some objects out of necessity, there is a strong
argument for clarity and consistency that you should use it all the
time.

Yep. So long as you mention it, folks may also wan tot have a look at
http://www.comeaucomputing.com/techtalk/#meminit

 

[Howard]

I have never needed to use the initializer list syntax until recently, I
try to keep my code very simple.

For me, the initialization list is the _simpler_ choice. In any new class
that I write, I put everything I can there. I only write code in the body
of the constructor if I _have_ to.

And it seems logical to me, as well as simple. It's stating in explicit
terms exactly what the initial state of the object will be.

Assignments are changes to state, and until an object is initialized, it
doesn't make semantic sense to "change" its state.

(Plus, how would you specify a specific constructor to use in order to
initialize the base class from a derived class constructor, if you didn't
have the initializer list?)

-Howard

 

[Peter Olcott]

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.

What I am calling for is to keep the communication conventions as uniform as
possible. Its okay for a language to define specialized operations on the
specialized elements of this language. What is not okay it to add yet another
incompatible meaning to a pre-existing commonly understood term. In other words
don't make the details of explaining aspects of the language any more difficult
than necessary.

Minimizing the divergence of common terminology and programming conventions
minimizes the learning curve, and eliminates wasted time. There is already a
commonly understood meaning and syntax for the initialization of things, don't
make a whole different way of doing this if it is at all possible to avoid.

 

[Greg Comeau]

For me, the initialization list is the _simpler_ choice. In any new class
that I write, I put everything I can there. I only write code in the body
of the constructor if I _have_ to.

And it seems logical to me, as well as simple. It's stating in explicit
terms exactly what the initial state of the object will be.

Assignments are changes to state, and until an object is initialized, it
doesn't make semantic sense to "change" its state.

(Plus, how would you specify a specific constructor to use in order to
initialize the base class from a derived class constructor, if you didn't
have the initializer list?)

Exactly.

 

[Greg Comeau]

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.

What I am calling for is to keep the communication conventions as uniform as
possible. Its okay for a language to define specialized operations on the
specialized elements of this language. What is not okay it to add yet another
incompatible meaning to a pre-existing commonly understood term. In other words
don't make the details of explaining aspects of the language any more difficult
than necessary.

Minimizing the divergence of common terminology and programming conventions
minimizes the learning curve, and eliminates wasted time. There is already a
commonly understood meaning and syntax for the initialization of things, don't
make a whole different way of doing this if it is at all possible to avoid.

I think I agree completely with what you just wrote....
certainly as a goal, and hopefully in practice when possible.
I just don't think it is coming into play in this case.