Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-12-14 09:24:52


From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
> Peter Dimov wrote:
> > From: "David Abrahams" <david.abrahams_at_[hidden]>
> > > From: "Peter Dimov" <pdimov_at_[hidden]>
> > >
> > > > Renaming 'append' to 'push_back' is not simply unnecessary, it's
> > harmful.
> > >
> > > That's an interesting point of view that I never expected. Why is it
> > > harmful?
> >
> > Because it's not a push_back.
> >
> > push_back(c, v) is a mutating operation on c.
>
> c.push_back(v) is a mutating operation on c. There is no free
'push_back(c,
> v)' function in the standard library.

Indeed. I consider the two forms semantically equivalent.

> > After it c has one additional element pushed to its back, v.
>
> That's how _you_ decided to define it.

I can't claim credit for it, sorry. ;-)

> > append(a, b) is a pure function that returns the
> > concatenation of a and b.
>
> There is no free 'append' function in the standard library.

I never said there is.

The original suggestion, IIRC, was to rename the existing 'append' in Loki
to push_back. The Lisp meaning of 'append' is different from push_back. I
now see that the Loki append does push_back when the second argument is not
a list; the Lisp append does not AFAIK.

> There is an
> family of overloaded 'append' member functions in 'std::string', and they
> are mutating. For a C++ programmer, there is nothing inherit in 'append'
> name that makes it more "pure" than 'push_back', or that implies the
> non-mutating semantics. And there is nothing inherit in 'push_back' that
> should prevent one from reusing the name in the domain where everything is
> non-mutating, if she thinks that such reuse would be beneficial.

The fact that push_back is a mutating operation in the STL is only part of
the problem, perhaps the least significant part.

More significant is that the STL provides push_back (or push_front) only
when it's efficient. It's not in our case. An 'append' done this way:

std::copy(first, last, std::back_inserter(c));

{a word from our sponsor:

std::for_each(first, last, boost::bind(&C::push_back, &c, _1));

}

is reasonably efficient, but naively translating it into "meta" is not going
to win any awards.

> Sorry, but
> I think that stating that compile-time 'push_back<S, T>::type' expression
is
> "harmful", while 'append<S,T>::type' is not, is an unjustified
exaggeration.

I'll be careful not to state it, then.

> > > From: "Peter Dimov" <pdimov_at_[hidden]>
> > >
> > > > Renaming 'append' to 'push_back' is not simply unnecessary, it's
> > harmful.

Summary of my position:

* The "append" that, well, appends, should be retained under its current
name. (I can definitely live without its current push_back behavior.)

* I see good arguments against providing a "push_back."

--
Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk