[boost] Re: New patch for operators.hpp uploaded

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-10-23 12:49:40

"David Abrahams" <dave_at_[hidden]> wrote in message
news:u1y6hhzsa.fsf_at_boost-consulting.com...
> "Andrei Alexandrescu" <andrewalex_at_[hidden]> writes:
>
> > That's way cool, Davem thanks on behalf of everyone.
>
> No prob.

(Sorry for the typo by the way.)

> If you want mojo to be taken seriously, you can't oversell it. So, if
> you want 100% portable efficiency and are willing to forego some of
> the usual expected behaviors from your type, mojo is the way.
>
> Don't get me wrong, I think mojo is quite cool.

I agree 100% (that mojo shouldn't be touted, not that it's quite cool :o)).
The first attempt to mojo (http://moderncppdesign.com/mojo/old), defined a
nice solution. That solution was shown (by Peter Dimov) to have a serious
limitation: temporaries could not be bound to const& anymore. I saw this as
breaking too much existing code to be acceptable.

The next mojo attempt (http://moderncppdesign.com/mojo) was to devise a
framework and a "modus vivendi" that would still eliminate unnecessary
copying by 100%, at the smallest price in terms of "getting used to" and
convenience. Mojo II does not include original clever solutions. They are
already known to the community. The only thing I've attempted was to lucidly
combine the bits and pieces into a coherent whole, something that I haven't
seen yet (I've actually seen mistaken articles such as
http://www.livejournal.com/talkpost.bml?journal=self_similar&itemid=18366).
The first mojo experience, especially the huge (154 emails) feedback, served
very much.

Clearly a transparent solution was not possible, so the attempt was to make
it as transparent as possible. Ideally the programmer could just follow a
number of simple rules and use a simple support library and not worry about
temporaries anymore. After all, temporaries are something you want to get
rid of :o).

One realization I made was that often const stays in the way of temporary
elimination, both in function arguments and in function return type.

> I haven't decided yet
> whether it belongs in boost; that in part depends on documentation and
> especially whether we get a clear and up-front description of the
> limitations.

A discussion of limitations would be indeed great.

Andrei

--
All new!  THE C++ Seminar: Oct. 28-30 in Vancouver, WA.
http://www.thecppseminar.com/