Valentin Bonnard wrote in message <352112C0.6D99@pratique.fr>...
>Christopher M. Gurnee wrote:
>
>> Lists, vectors, and deques provide exactly the interface you want.
>
>No
>
>> The line:
>>   x = mylist.insert(y);
>> for iterators x and y is perfectly valid.
>
>No

According to CD2, everything that I wrote in my original post is
correct (references are below).  Although this syntax is not specified
in the sequence requirements subclause (23.1.1), it is specified in
some of the class description subclauses.  I would appreciate it if
someone with access to the FDIS would check to see if any changes have
been made here.

for deque insert: 23.2.1.3 deque modifiers
for list insert: 23.2.2.3 list modifiers
for vector insert: 23.2.4.3 vector modifiers

>> The standard gives a
>> declaration of one of the insert member functions of list as:
>>   iterator insert(iterator position, const T& x = T());
>
>These silly default arguments have been hopefuly removed.

What's so bad about a member function such as:
  iterator insert(iterator position);
(which is what the quoted declaration implies)?  Casper Gripenberg
mentions a few advantages in this thread's entry post to such a
member.  I can't think of any disadvantages offhand.  Granted, such a
member doesn't really add any new functionality, but it is a
convenience (IMHO) and it can lead to constant time improvements.  Am
I missing something?

BTW, in CD2, deque, list, and vector also have "default parameters" in
their ctor, resize, and assign members.  Are there any changes in the
FDIS here?  IMO, except maybe for assign, they all make sense.

- Chris Gurnee
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher M. Gurnee wrote:
>
> Valentin Bonnard wrote in message <352112C0.6D99@pratique.fr>...
> >Christopher M. Gurnee wrote:

> >> The line:
> >>   x = mylist.insert(y);
> >> for iterators x and y is perfectly valid.
> >
> >No

> >> The standard gives a
> >> declaration of one of the insert member functions of list as:
> >>   iterator insert(iterator position, const T& x = T());
> >
> >These silly default arguments have been hopefuly removed.
>
> What's so bad about a member function such as:
>   iterator insert(iterator position);
> (which is what the quoted declaration implies)?

It doesn't make sens. Or it means that you insert an iterator.
I am strongly against it.

> Casper Gripenberg
> mentions a few advantages in this thread's entry post to such a
> member.
...
> and it can lead to constant time improvements.

I think it's a micro optimisation. No one metionned it.
It isn't even implemented in SGI STL. And I don't think it's
legal unless the copy ctor has no side effect.

> BTW, in CD2, deque, list, and vector also have "default parameters" in
> their ctor, resize, and assign members.

Default arguments are removed for insert, and assign. They are usefull
in the constructors.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Why doesn't STL provide insertion of new 'empty' elements
in a container without having to go through the copy constructor?

As an example say I want to insert a new element in my
list and then through some access methods set attributes
in my new element:

list<MyClass> mylist;

list<MyClass>::iterator x = mylist.insert(mylist.begin(), MyClass());

x->SetThis(...);
x->SetThat(...);

It just seems useless to first construct an new object which is
then assigned to the list element via the copy constructor. Calling
the constructor of MyClass() might be a heavy operation, and so might
calling the copy constructor. This means a heavy operation is executed
twice when it would seem logical to just do it once in this case: why
not just let insert() initialize the new element simply with the
default contructor??? And regardless of the 'heaviness' of the
constructor/copy constructor it still seems like unnecessary
work. Why not just do:

// Here insert would create a new MyClass object at position
// y by simply calling MyClass() on the new list element:
x = mylist.insert(y);

x->SetThis(...);
x->SetThat(...);

Or did I miss something? :)

- Casper
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Casper Gripenberg wrote in message <6foreq$6iq@nntp.hut.fi>...
>Why doesn't STL provide insertion of new 'empty' elements
>in a container without having to go through the copy constructor?
>
>As an example say I want to insert a new element in my
>list and then through some access methods set attributes
>in my new element:
>
>list<MyClass> mylist;
>
>list<MyClass>::iterator x = mylist.insert(mylist.begin(), MyClass());
>
>x->SetThis(...);
>x->SetThat(...);
>
[Section of post moved to end]
>
>work. Why not just do:
>
>// Here insert would create a new MyClass object at position
>// y by simply calling MyClass() on the new list element:
>x = mylist.insert(y);
>
>x->SetThis(...);
>x->SetThat(...);
>
>Or did I miss something? :)
>
>- Casper

Lists, vectors, and deques provide exactly the interface you want.
The line:
  x = mylist.insert(y);
for iterators x and y is perfectly valid.  The standard gives a
declaration of one of the insert member functions of list as:
  iterator insert(iterator position, const T& x = T());

At first look, this would seem to be exactly what you *don't* want.
The mylist.insert(y) call would still seem to default construct an
object of type T, possibly copy construct that object into the insert
procedure, and then copy construct it into the list.  However, buried
in the 10 lb standard is a subclause (17.3.4.4 paragraph 4 of CD2)
that states that template member functions with default argument(s),
such as the one above, do not actually exist as such.  Instead, they
are just shorthand for the equivalent and required two declarations
(in this case):
  iterator insert(iterator position);
  iterator insert(iterator position, const T& x);
each with no default parameters.  In any decent implementation, the
former version of insert would default construct a single instance of
T in-place (although doing otherwise would still be permissable).

-Chris Gurnee

[rest of post]
>It just seems useless to first construct an new object which is
>then assigned to the list element via the copy constructor. Calling
>the constructor of MyClass() might be a heavy operation, and so might
>calling the copy constructor. This means a heavy operation is
executed
>twice when it would seem logical to just do it once in this case: why
>not just let insert() initialize the new element simply with the
>default contructor??? And regardless of the 'heaviness' of the
>constructor/copy constructor it still seems like unnecessary
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher M. Gurnee wrote:

> Lists, vectors, and deques provide exactly the interface you want.

No

> The line:
>   x = mylist.insert(y);
> for iterators x and y is perfectly valid.

No

> The standard gives a
> declaration of one of the insert member functions of list as:
>   iterator insert(iterator position, const T& x = T());

These silly default arguments have been hopefuly removed.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]