Zero Unnecessary Temporary Objects: A Revolution
Andrei Alexandrescu
This is a request for a favor.
I believe I have hacked together a complete solution for eliminating
unnecessary temporary objects in C++. The topic relates to the heavy
discussions on move constructors, too. The solution (let's call it ZUTO
(Zero Unnecessary Temporary Objects) henceforth) has the following
characteristics:
1. It does not require language changes.
2. Has no or minimal impact on client code. In many cases, elimination of
many temporary objects is achieved by changing the offending class
definition and recompiling client code. To /totally/ eliminate temporary
objects (and I mean /totally/), client code has only to perform a minor
change when returning lvalues from functions.
3. Lends itself to a library implementation accompanied by simple idioms.
4. Is guaranteed, i.e., you're not at the mercy of a fragile RVO (Return
Value Optimization) implementation which might or might not kick in.
5. Works in all cases, whereas RVO works only in certain cases.
6. Does not require ugly client syntax nor ugly class definition syntax.
(Your mileage might vary for the latter.)
7. Does not do advanced temporary elimination a la loop fusion, which is
solved by using expression templates. (Fortunately, ZUTO is at least much
simpler than expression templates.) So it could be said ZUTO does eliminate
all unnecessary temporaries, for a reasonable definition of "unnecessary"
:o).
8. ZUTO is likely to be supported by all compilers that know enough to
compile std::auto_ptr.
We all are aware of the nuisance that unnecessary temporary objects are. We
are afraid to write elegant code such as:
extern vector<string> Fun();
...
vector<string> v = Fun();
because we know a temporary might be created, which might pretty much ruin
the performance of the application. Even if we could count on a compiler
implementing RVO (which is not guaranteed nor implemented everywhere nor
supported in similar forms on most compilers), the following is /guaranteed/
to create an unnecessary temporary, even though there's no need for it:
extern vector<string> Fun();
...
vector<string> v;
...
v = Fun();
To get rid of that, we have to recourse to the damned hack:
Fun().swap(v);
Furthermore, when passing Fun's result to some function, again an
unnecessary temporary can be created. And so on.
The hack I'm telling about solves all the problems above in a manner that I
believe is elegant enough to deserve attention. I will first talk about it
at The C++ Seminar (see my sig). The implications in C++ idioms, class
design, coding standards, and maybe even compiler design, are possibly quite
deep. Here are some examples:
* One can now design an auto_ptr that does what auto_ptr is designed to do,
but without any of its horrible caveats. In particular, the newly-designed
auto_ptr can be safely stored in certain containers. Any wrongful use will
be flagged at compile time.
* The recommended conventions for passing values to and returning values
from functions might change forever.
* Here are current state-of-the-art recommended canonic signatures and
implementations of some primitive functions:
class T
{
...
T& operator=(const T& rhs)
{
T copy(rhs);
rhs.swap(*this);
return *this;
}
};
const T operator+(const T& lhs, const T& rhs)
{
T copy(lhs);
return copy += rhs;
}
I reached the conclusion that the signatures and implementations above are
about the worst possible to recommend, with or without ZUTO in action. I
consider them simply wrong.
I tested ZUTO on MSVC.NET Everett Beta and MWCW 7.0, and it screams. It's a
pleasure to run through the debugger and see the temporaries disciplinately
flowing from source to destination without any efficiency hitch.
Exactly because the implications might be so deep, I don't want to make a
fool of myself. Maybe I am making some mistake, or I overlooked something,
or I hit onto some compiler bug or extension. So I wanted to ask for some
volunteers to review my article before it goes out. If there are volunteers,
please write me email. The article will be out in 2 months, and I believe
I'll have something done in a couple of weeks.
Andrei
--
All new! THE C++ Seminar: Oct. 28-30 in Vancouver, WA.
http://www.thecppseminar.com/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Nick Thurn
""Andrei Alexandrescu"" <andre...@hotmail.com> wrote in message
news:ao4t70$iqt0s$1...@ID-14036.news.dfncis.de...
> * Here are current state-of-the-art recommended canonic signatures and
> implementations of some primitive functions:
>
> class T
> {
> ...
> T& operator=(const T& rhs)
> {
> T copy(rhs);
> rhs.swap(*this);
> return *this;
> }
> };
>
Hey Andrei,
Did you mean
class T
{
T& operator=(const T& rhs)
{
T copy(rhs);
copy.swap(*this);
return *this;
}
};
I suspect yes. In any case ZUTO sounds great. When will you
post the details?
cheers
Nick
Andrei Alexandrescu
news:T0tp9.50623$g9.1...@newsfeeds.bigpond.com...
> Did you mean
>
> class T
> {
> T& operator=(const T& rhs)
> {
> T copy(rhs);
> copy.swap(*this);
> return *this;
> }
> };
>
> I suspect yes.
Indeed; apologies for the typo.
> In any case ZUTO sounds great. When will you
> post the details?
First, I can't do anything before The C++ Seminar, because it's "all new"
material. Then, I prefer to make available a polished, clearly expressed
version instead of the clutter that's now in my mind. Just kidding. Ok, half
kidding.
By the way, in only less than 24 hours there's been a fantastic turnaround.
There are 36 volunteers already. The interest is huge. I feel like that guy
who claimed can compress any file into 1024 bytes :o).
Andrei
--
All new! THE C++ Seminar: Oct. 28-30 in Vancouver, WA.
http://www.thecppseminar.com/
---
White Wolf
[SNIP]
> By the way, in only less than 24 hours
> there's been a fantastic turnaround.
When do you plan to send out something? (I was one of the volume-tears :-)
> There are 36 volunteers already. The interest is huge.
Yeh yeh. When do I (OK, OK: we) get it? ;-)
> I feel like that guy
> who claimed can compress any file into 1024 bytes :o).
With a lossy compression... :-)
WW
Allan W
>
> I believe I have hacked together a complete solution for eliminating
> unnecessary temporary objects in C++. The topic relates to the heavy
> discussions on move constructors, too. The solution (let's call it ZUTO
> (Zero Unnecessary Temporary Objects) henceforth) has the following
> characteristics:
You make it sound like you've already done this. A web search for ZUTO
produced a surprising number of hits -- well over 10,000, IIRC -- but
they didn't seem related to C++. Attempts to refine the search came
up fruitless.
Have you described it in more detail elsewhere? If it really does
everything you say -- well, I'd like to know more about it.
Robert Klemme
Andrei Alexandrescu schrieb:
> because we know a temporary might be created, which might pretty much ruin
> the performance of the application. Even if we could count on a compiler
> implementing RVO (which is not guaranteed nor implemented everywhere nor
> supported in similar forms on most compilers), the following is /guaranteed/
> to create an unnecessary temporary, even though there's no need for it:
>
> extern vector<string> Fun();
> ...
> vector<string> v;
> ...
> v = Fun();
>
> To get rid of that, we have to recourse to the damned hack:
>
> Fun().swap(v);
why does this get rid of the temporary? isn't the temp created
before swap() is invoked? then, what do we gain?
regards
robert
Andrei Alexandrescu
news:3DA6DD42...@gmx.net...
> > extern vector<string> Fun();
> > ...
> > vector<string> v;
> > ...
> > v = Fun();
> >
> > To get rid of that, we have to recourse to the damned hack:
> >
> > Fun().swap(v);
>
> why does this get rid of the temporary? isn't the temp created
> before swap() is invoked? then, what do we gain?
It is a temporary, but it's not "unnecessary" anymore because it is moved
into the destination (as opposed to copying).
Andrei
Alf P. Steinbach
>
>
>Andrei Alexandrescu schrieb:
>> because we know a temporary might be created, which might pretty much ruin
>> the performance of the application. Even if we could count on a compiler
>> implementing RVO (which is not guaranteed nor implemented everywhere nor
>> supported in similar forms on most compilers), the following is /guaranteed/
>> to create an unnecessary temporary, even though there's no need for it:
>>
>> extern vector<string> Fun();
>> ...
>> vector<string> v;
>> ...
>> v = Fun();
>>
>> To get rid of that, we have to recourse to the damned hack:
>>
>> Fun().swap(v);
>
>why does this get rid of the temporary? isn't the temp created
>before swap() is invoked? then, what do we gain?
I don't think Andrei meant that; I think he meant that use of
swap got rid of the obstacle to RVO, the guarantee of an unneccessary
temporary, that obstacle presumably being the assignment -- without
necessarily getting rid of the temporary (RVO would do that).
One difference between swap and assignment is that swap takes
the vector as non-const reference. I don't quite see how that
in itself would help. I'd rather assume the opposite.
Another difference is that swap may be simple enough that the
compiler understands its semantics. In which case it might
implement "Fun().swap(v)" as e.g. "v.clear(); Fun( &v );",
where the Fun() parameter is a hidden one for RVO. Well, if
this is the case, then I can understand that cryptic comment about
perhaps having hit onto some compiler bug or extension.
<speculation>
In order to make this independent of the compiler's support for
RVO or not one would have to explicitly pass the "RVO" parameter
always for a function returning non-simple type.
Calling a function would then be somewhat awkward unless one
packaged the call in a functor object, "v = Call( Fun )",
where Call( Fun ) is a constructor call on functor class Call.
Here it gets somewhat complicated to analyze because in order
to have assignment automatically use the functor (it seems
to me) one would have to delay the function call until the
execution of the body of the assignment operator, which would
have to pass the "RVO" parameter to the functor object. One
question is then, what about function calls outside the context
of an assignment? Well, for a function with return type T one
could endow the functor object with conversion to T (in an
assignment the assignment operator would take the functor
object directly, not invoking the conversion). The question is
then, with inlining of things, will a normal compiler be able to
optimize away the functor object?
</speculation>
Ok, that's my speculation for now... ;-)
Cheers,
- Alf
John Potter
Klemme) wrote:
> Andrei Alexandrescu schrieb:
> > extern vector<string> Fun();
> > ...
> > vector<string> v;
> > ...
> > v = Fun();
At this point, a copy of the temporary is made in v and then the
temporary is destroyed.
> > To get rid of that, we have to recourse to the damned hack:
> > Fun().swap(v);
In this case, the empty v and the temporary are swapped. The
temporary which is destroyed is now empty.
> why does this get rid of the temporary? isn't the temp created
> before swap() is invoked? then, what do we gain?
We did not get rid of the (possibly) 12 byte temporary, but we did get
rid of the copy of the huge internal array of strings. Looks like
reference counted vector without the overhead. With some
optimizations we could get rid of the 12 bytes using
vector<string> v(Fun());
but that is not the point. However, it may be the point which makes
ZUTO a joke rather than a revolution. The 12 bytes is a necessary
temporary.
John
White Wolf
>
> Andrei Alexandrescu schrieb:
> > because we know a temporary might be created, which might pretty much
ruin
> > the performance of the application. Even if we could count on a
compiler
> > implementing RVO (which is not guaranteed nor implemented everywhere
nor
> > supported in similar forms on most compilers), the following is
/guaranteed/
> > to create an unnecessary temporary, even though there's no need for it:
> >
> > extern vector<string> Fun();
> > ...
> > vector<string> v;
> > ...
> > v = Fun();
> >
> > To get rid of that, we have to recourse to the damned hack:
> >
> > Fun().swap(v);
>
> why does this get rid of the temporary? isn't the temp created
> before swap() is invoked? then, what do we gain?
Of course it does not.
Of ourse it is created.
Copying. This will swap the pointers inside the vectors _only_ thereby
making the v to contain the elements returned by Fun() and making the
unnamed temporary to contain nothing (whatever way the vector represents
that in the implementation). It is the largest saving without the RVO
making it a non-const reference argument instead of return value. But that
is PiTA and requires a cleanup of the vector before each operation.
This is an example how things are solved today. As far as I understood
this is not the ZUTO.
WW
Thomas Mang
Allan W schrieb:
> andre...@hotmail.com ("Andrei Alexandrescu") wrote
> >
> > I believe I have hacked together a complete solution for eliminating
> > unnecessary temporary objects in C++. The topic relates to the heavy
> > discussions on move constructors, too. The solution (let's call it ZUTO
> > (Zero Unnecessary Temporary Objects) henceforth) has the following
> > characteristics:
>
> You make it sound like you've already done this. A web search for ZUTO
> produced a surprising number of hits -- well over 10,000, IIRC -- but
> they didn't seem related to C++. Attempts to refine the search came
> up fruitless.
>
> Have you described it in more detail elsewhere? If it really does
> everything you say -- well, I'd like to know more about it.
And maybe it turns out to be something like:
class Matrix
{
};
Matrix operator+(const Matrix& m1, const Matrix& m2)
{
Matrix temp(m1);
return temp += m2;
}
this will now be transformed into something like:
voi Matrix::operator+(const Matrix& m1, const Matrix& m2, void* targetMem)
{
// copy all bits from "m1" to "targetMem"
// apply to this operator+=(m2)
}
and the client code:
m = m1 + m2;
Now gets transformed by the compiler into:
operator+(m1, m2, &m)
and voila, no temporary.
works almost anywhere, where during the creation of the temporary no special
side effects occurr:
Instead of returning a temporary, take the address of the destination as an
argument, and place the result right into this, returning nothing.
cheers,
thomas
Allan W
> > > Fun().swap(v);
> >
> > why does this get rid of the temporary? isn't the temp created
> > before swap() is invoked? then, what do we gain?
andre...@hotmail.com ("Andrei Alexandrescu") wrote
> It is a temporary, but it's not "unnecessary" anymore because it is moved
> into the destination (as opposed to copying).
Under that definition, we could get rid of all unnecessary copying by
adding the following line into the standard:
Assignments always create temporary objects which may not be
elided.
And there you have it -- temporary objects are never unnecessary anymore.
White Wolf
> Under that definition, we could get rid of all unnecessary copying by
> adding the following line into the standard:
>
> Assignments always create temporary objects which may not be
> elided.
>
> And there you have it -- temporary objects are never unnecessary anymore.
Do you means that if we pass a low that everyone who calls himself Allan W
and posts to clc++mod should wear a 40kgs per foot moon-boot it will not
mean it is unnecessary for you to wear it? Is it just my feeling that you
have left out the smiley? I beleive if you pass such
impractical/unnecessary things into the standard (thereby violating one of
the most fundamental axioms of C++) you make no service to anyone. If you
put a smiley - I get it. If not - it sound like a bad joke. We already
have too many places in C++ where unwanted (and that is the right word:
only a dead temporary is a good temporary) temporaries show their ugly
temporary faces.
--
--
White Wolf aka Attila @ LMF
ICQ#: 26070936
http://wwp.icq.com/26070936
If I'm not online send mail.
NO USENET followups please.
SPAM is not welcome.
Robert Klemme
White Wolf schrieb:
> We already
> have too many places in C++ where unwanted (and that is the right word:
> only a dead temporary is a good temporary) temporaries show their ugly
> temporary faces.
well, at least the ugly faces are only temporary - i can live
with that... :-))
robert
Andrei Alexandrescu
news:3da7f610...@news.earthlink.net...
> We did not get rid of the (possibly) 12 byte temporary, but we did get
> rid of the copy of the huge internal array of strings. Looks like
> reference counted vector without the overhead. With some
> optimizations we could get rid of the 12 bytes using
>
> vector<string> v(Fun());
>
> but that is not the point. However, it may be the point which makes
> ZUTO a joke rather than a revolution. The 12 bytes is a necessary
> temporary.
Heh :o). Actually ZUTO is a bit of a misnomer, because it is "Zero
Unnecessary /Copying/ of Temporary Objects". But ZUCTO is not that nice of a
name :o).
Zuto works by enabling move construction. It is true there are classes for
which move construction doesn't work, for example:
class Matrix
{
double data_[128][128];
...
};
For this kind of data, ZUTO can't help. If I understand it correctly, the
move constructor proposal would not help, either.
Andrei
Andrei Alexandrescu
news:7f2735a5.02101...@posting.google.com...
> andre...@hotmail.com ("Andrei Alexandrescu") wrote
> > It is a temporary, but it's not "unnecessary" anymore because it is
moved
> > into the destination (as opposed to copying).
>
> Under that definition, we could get rid of all unnecessary copying by
> adding the following line into the standard:
>
> Assignments always create temporary objects which may not be
> elided.
>
> And there you have it -- temporary objects are never unnecessary anymore.
I should have known better than posting cocky messages to clc++m :o).
But don't forget that ZUTO works without asking for ANY change in the
Standard - even that mentioned by yourself :oD.
Andrei
Howard Hinnant
<and...@cs.washington.edu> wrote:
| class Matrix
| {
| double data_[128][128];
| ...
| };
|
| For this kind of data, ZUTO can't help. If I understand it correctly, the
| move constructor proposal would not help, either.
That's correct (about the move proposal not helping here either).
--
Howard Hinnant
Metrowerks
Allan W
> > Under that definition, we could get rid of all unnecessary copying by
> > adding the following line into the standard:
> >
> > Assignments always create temporary objects which may not be
> > elided.
> >
> > And there you have it -- temporary objects are never unnecessary anymore.
wo...@freemail.hu ("White Wolf") wrote
> Do you means that if we pass a low that everyone who calls himself Allan W
> and posts to clc++mod should wear a 40kgs per foot moon-boot it will not
> mean it is unnecessary for you to wear it? Is it just my feeling that you
> have left out the smiley? I beleive if you pass such
> impractical/unnecessary things into the standard (thereby violating one of
> the most fundamental axioms of C++) you make no service to anyone. If you
> put a smiley - I get it. If not - it sound like a bad joke. We already
> have too many places in C++ where unwanted (and that is the right word:
> only a dead temporary is a good temporary) temporaries show their ugly
> temporary faces.
You mostly got it. I wasn't making a joke -- I wasn't especially trying
for humor. But I was trying to make a point by pointing out a logical
absurdity. So you're quite right that I wouldn't really want this rule
added to the next standard.
Taking an argument to it's logical absurdity has been an argument
technique for at least 2000 years, and probably even longer. They are
commonly used in formal mathematical proofs. For instance, the easiest
way to prove that you can't divide a number by zero, is to assume that
division by zero WAS defined, and then go on to prove that 0=1. Since
we all know that 0!=1, we are forced to conclude that the original
premise is invalid, i.e. division by zero is NOT defined.
I hope you see now why I made such a statement without a smiley -- I
was trying to show (without rigorous proof) that the original premise
was not valid, at least not in all situations.
Edward Diener
outside of the space issues ? I am not trying to discourage you from working
on your idea and being innovative in general, but I do not understand what
your innovation adds to the C++ language/library itself.
""Andrei Alexandrescu"" <and...@cs.washington.edu> wrote in message
news:H3xKL...@beaver.cs.washington.edu...
> "John Potter" <jpo...@falcon.lhup.edu> wrote in message
> news:3da7f610...@news.earthlink.net...
> > We did not get rid of the (possibly) 12 byte temporary, but we did get
> > rid of the copy of the huge internal array of strings. Looks like
> > reference counted vector without the overhead. With some
> > optimizations we could get rid of the 12 bytes using
> >
> > vector<string> v(Fun());
> >
> > but that is not the point. However, it may be the point which makes
> > ZUTO a joke rather than a revolution. The 12 bytes is a necessary
> > temporary.
>
> Heh :o). Actually ZUTO is a bit of a misnomer, because it is "Zero
> Unnecessary /Copying/ of Temporary Objects". But ZUCTO is not that nice of
a
> name :o).
>
> Zuto works by enabling move construction. It is true there are classes for
> which move construction doesn't work, for example:
>
> class Matrix
> {
> double data_[128][128];
> ...
> };
>
> For this kind of data, ZUTO can't help. If I understand it correctly, the
> move constructor proposal would not help, either.
---
Andrei Alexandrescu
> outside of the space issues ? I am not trying to discourage you from
working
> on your idea and being innovative in general, but I do not understand what
> your innovation adds to the C++ language/library itself.
Mojo (this is the final name, stands for MOve of Joint Objects) is a
technique and a framework for eliminating unnecessary copying of
temporaries. It can eliminate copying 100%. The only condition is that
objects must be cheap to move. Mojo enables comfortable return by value of
large objects and creation of efficient, expressive operators.
Mojo also allows creating types with new interesting properties.
One of the nicest applicabilities of Mojo is in the generic containers area.
Mojo allows creating owning containers with well-defined semantics, a la
that mythical vector< auto_ptr<T> >. Also, Mojo allows efficient compound
containers such that vector< vector<string> > becomes a truly viable
efficient container.
Of course, the legendary YASLI, the one implementation of the STL that puts
all others on welfare, already uses Mojo for all of its containers. The
performance difference on certain compound container operations is in the
orders of magnitude.
The turnaround on the first round of reviews was fantastic. Now Mojo is
provable 100% standard-compliant. Grace to a cool idea by Dave Abrahams and
an important bug fix prompted by Rani Sharoni, Mojo now looks really slick.
Oh, and I almost forgot. I've been told to turn the marketing hype a notch
down.
Andrei the teasing one :o)
--
Now mojoed! THE C++ Seminar: Oct. 28-30 in Vancouver, WA.
http://www.thecppseminar.com/
---
Edward Diener
functionality to C++ as I understand it. I have no problem with that but it
might be seen as less of a revolution than you think, especially for those
less interested in performance and more interested in functionality. Where
is MOJO to be found and with what compilers/implementations does it
currently work ?
BTW, I am glad you got your MOJO working ( that's a joke which you might be
too young to appreciate and has nothing to do with those godawful Mike Myers
movies ).
""Andrei Alexandrescu"" <and...@cs.washington.edu> wrote in message
news:H41qo...@beaver.cs.washington.edu...
> > Would you explain what, if any, are the advantages of your innovation
> > outside of the space issues ? I am not trying to discourage you from
> working
> > on your idea and being innovative in general, but I do not understand
what
> > your innovation adds to the C++ language/library itself.
>
> Mojo (this is the final name, stands for MOve of Joint Objects) is a
> technique and a framework for eliminating unnecessary copying of
> temporaries. It can eliminate copying 100%. The only condition is that
> objects must be cheap to move. Mojo enables comfortable return by value of
> large objects and creation of efficient, expressive operators.
---
Tzvetan Mikov
===================================== MODERATOR'S COMMENT:
This thread is drifting off-topic for comp.std.c++.
Please ensure that any followups are topical.
===================================== END OF MODERATOR'S COMMENT
""Andrei Alexandrescu"" <and...@cs.washington.edu> wrote in message
news:H41qo...@beaver.cs.washington.edu...
> Mojo (this is the final name, stands for MOve of Joint Objects) is a
> technique and a framework for eliminating unnecessary copying of
> temporaries. It can eliminate copying 100%. The only condition is that
> objects must be cheap to move. Mojo enables comfortable return by value of
> large objects and creation of efficient, expressive operators.
Aha, another Powerpuff Girls fan ! :-)
[...]
> The turnaround on the first round of reviews was fantastic. Now Mojo is
> provable 100% standard-compliant. Grace to a cool idea by Dave Abrahams
and
> an important bug fix prompted by Rani Sharoni, Mojo now looks really
slick.
So, when can we see it ?!? Waiting for two months will kill me.
-tzvetan
Werner Salomon
> Mojo (this is the final name, stands for MOve of Joint Objects) is a
> technique and a framework for eliminating unnecessary copying of
> temporaries. It can eliminate copying 100%. The only condition is that
> objects must be cheap to move. Mojo enables comfortable return by value of
> large objects and creation of efficient, expressive operators.
>
> Oh, and I almost forgot. I've been told to turn the marketing hype a notch
> down.
>
> Andrei the teasing one :o)
>
> --
> Now mojoed! THE C++ Seminar: Oct. 28-30 in Vancouver, WA.
> http://www.thecppseminar.com/
it seems to be a great thing for the c++ community. How can I benefit
from Your innovation, if I can't partake in the 'the cpp seminar',
because of distance, time and costs?
Greetings
Werner (very curious how Mojo works)
news user
comp.std.c++ is moderated. Well.
But when a guy like Andrei Alexanderscu ask for volountaries for a review of
a new solution, on which criteria do the moderator reject someone ?
If only guru can participate, I think it's not good. C++ is more used by
"normal" programmer than guru...
Have a good Day.
Stephane Bronsart
""Andrei Alexandrescu"" <and...@cs.washington.edu> wrote in message
news:H41qo...@beaver.cs.washington.edu...
Niklas Matthies
> OK, your MOJO is then a performance enhancement rather than a way to
> add functionality to C++ as I understand it.
It's a tiny bit more than that. It saves you from writing "handle"
classes for objects that cannot be copied, and possibly worrying about
reference counting etc.
-- Niklas Matthies
--
Save Farscape - get informed and involved: http://farscape.wdsection.com/
Together, we can get Farscape back on air. Crackers *do* matter.
Andrei Alexandrescu
news:3dad12c8$0$30456$afc3...@sisyphus.news.be.easynet.net...
> comp.std.c++ is moderated. Well.
> But when a guy like Andrei Alexanderscu ask for volountaries for a review
of
> a new solution, on which criteria do the moderator reject someone ?
> If only guru can participate, I think it's not good. C++ is more used by
> "normal" programmer than guru...
Sorry for the off-topic post. Just to set the record clear:
* Given the interest in move construction in standard C++, I believe my
posts here were on-topic
* I sent the article to *all* (87) of those who sent me email asking for it.
The csc++ moderators did not have any participation to this process.
Andrei
Corey Lubin
===================================== MODERATOR'S COMMENT:
It's not clear that this is related to standardization. This seems to
be
moving more toward issues of C++ programming technique, which
are more appropriate to comp.lang.c++.moderated. I suggest that
further discussion of this topic move over to that newsgroup, except
for issues that are clearly standards-related.
===================================== END OF MODERATOR'S COMMENT
What are the cons to using "Mojo"? I can imagine two similar methods of
accomplishing what you claim, but they both introduce their own small
disadvantages. Are there any usage limitations to Mojo? Any unexpected
behaviour?
Stephen Howe
> be
> moving more toward issues of C++ programming technique, which
> are more appropriate to comp.lang.c++.moderated. I suggest that
> further discussion of this topic move over to that newsgroup, except
> for issues that are clearly standards-related.
Why? All of Stroustrup's guidelines of possible new features to C++
mentioned in "Design and Evolution of C++" are relevant to this such as how
well MOJO integrates with existing C++ features in the standard. It is
entirely relevant here.
Any new feature that is a candidate for the next standard is worth
discussing here.
Stephen Howe
David Abrahams
> > It's not clear that this is related to standardization. This seems to
> > be
> > moving more toward issues of C++ programming technique, which
> > are more appropriate to comp.lang.c++.moderated. I suggest that
> > further discussion of this topic move over to that newsgroup, except
> > for issues that are clearly standards-related.
>
> Why? All of Stroustrup's guidelines of possible new features to C++
> mentioned in "Design and Evolution of C++" are relevant to this such as how
> well MOJO integrates with existing C++ features in the standard. It is
> entirely relevant here.
>
> Any new feature that is a candidate for the next standard is worth
> discussing here.
But mojo is not a new feature; it's a programming technique.
--
David Abrahams
da...@boost-consulting.com * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html
Ken Hagan
>
> Any new feature that is a candidate for the next standard is worth
> discussing here.
Since it isn't even in the public domain yet, I think I have some
sympathy
with the moderator. In any case, anyone who is anyone is already
following
the debate in comp.lang.c++.moderated or gmane.comp.lib.boost.devel.
Multiple fora merely disrupt the discussion.
Balog Pal
> > discussing here.
>
> But mojo is not a new feature; it's a programming technique.
Yes, but 'Move semantics' is an actual proposal to add core support and stuff. If mojo, as claimed in the teaser can solve all those problems usng the current language, that strongly influencs the status of that proposal, and maybe several others related.
Paul
David Abrahams
> > > Any new feature that is a candidate for the next standard is worth
> > > discussing here.
> >
> > But mojo is not a new feature; it's a programming technique.
>
> Yes, but 'Move semantics' is an actual proposal to add core support
> and stuff.
Really? Who wrote that proposal <wink>?
> If mojo, as claimed in the teaser can solve all those
> problems usng the current language
It can't, though it's certainly an interesting _technique_ with some
potential for specialized applications. Did I forget to mention that
it's a programming technique?
> that strongly influencs the status of that proposal, and maybe
> several others related.
Yes, it would, but it doesn't, and besides nobody has been discussing
its relationship to that proposal here (until now).
--
David Abrahams
da...@boost-consulting.com * http://www.boost-consulting.com
Building C/C++ Extensions for Python: Dec 9-11, Austin, TX
http://www.enthought.com/training/building_extensions.html
---
Willow Schlanger (junkmacc1)
> On Sat, 12 Oct 2002 05:52:38 +0000 (UTC), bob....@gmx.net (Robert Klemme) wrote:
>
>
>>
>>Andrei Alexandrescu schrieb:
>>
>>>because we know a temporary might be created, which might pretty much ruin
>>>the performance of the application. Even if we could count on a compiler
>>>implementing RVO (which is not guaranteed nor implemented everywhere nor
>>>supported in similar forms on most compilers), the following is /guaranteed/
>>>to create an unnecessary temporary, even though there's no need for it:
>>>
>>>extern vector<string> Fun();
>>>...
>>>vector<string> v;
>>>...
>>>v = Fun();
>>>
>>>To get rid of that, we have to recourse to the damned hack:
>>>
>>>Fun().swap(v);
I already posted something explaining a cooler way to get rid of the
temporary, but I don't see it here, for some reason. I'll re-post part
of it below (probably my posting was too long):
[snip]
Exhibit C1
---------- -----------------
struct s
{
int x[1024];
};
extern s g();
struct s_g : s
{
s_g()
{
s &t = *this;
t.x[0] = t.x[1023] = 0;
}
};
s g()
{
return s_g();
}
int main()
{
s p;
p = g();
return 0;
}
---------- End of Exhibit C1
And observe the assembly-language code produced:
[snip]
As you can see, the compiler now acts as if the code in Exhibit B1 were
written, yet the semantics of g() is now such that "p = g()" can be used!
We now have the safety and efficiency of g() having the prototype "s g();"
....
I'll re-post my whole tihng under a subject beginning with "Some C/C++
Optimization Idioms I Wish Compilers Supported," where you can learn
about this.
Alf P. Steinbach
(junkmacc1)") wrote:
>Alf P. Steinbach wrote:
>> On Sat, 12 Oct 2002 05:52:38 +0000 (UTC), bob....@gmx.net (Robert Klemme) wrote:
>>
>>
>>>
>>>Andrei Alexandrescu schrieb:
>>>
>>>>because we know a temporary might be created, which might pretty much ruin
>>>>the performance of the application. Even if we could count on a compiler
>>>>implementing RVO (which is not guaranteed nor implemented everywhere nor
>>>>supported in similar forms on most compilers), the following is /guaranteed/
>>>>to create an unnecessary temporary, even though there's no need for it:
>>>>
>>>>extern vector<string> Fun();
>>>>...
>>>>vector<string> v;
>>>>...
>>>>v = Fun();
>>>>
>>>>To get rid of that, we have to recourse to the damned hack:
>>>>
>>>>Fun().swap(v);
Nothing of my (old and now irrelevant, Mojo is now public) posting quoted
here.
>I already posted something explaining a cooler way to get rid of the
>temporary, but I don't see it here, for some reason. I'll re-post part
>of it below (probably my posting was too long):
>
>[snip]
>
>Exhibit C1
>---------- -----------------
>struct s
>{
> int x[1024];
>};
>
>extern s g();
Serves no useful purpose, AFAICS.
>struct s_g : s
>{
> s_g()
> {
> s &t = *this;
> t.x[0] = t.x[1023] = 0;
> }
>};
Requires s to have a default constructor.
>s g()
>{
> return s_g();
>}
Slice, but so what?
>
>int main()
>{
> s p;
> p = g();
>
> return 0;
>}
>---------- End of Exhibit C1
>
>And observe the assembly-language code produced:
A compiler *may* choose to construct p in place, if there isn't some
obscure rule in the standard that forbids it. It's not a guaranteed
optimization. Try it out with
s g(){ return s(); }
>[snip]
Huh, snipped your own posting???
>As you can see, the compiler now acts as if the code in Exhibit B1 were
>written, yet the semantics of g() is now such that "p = g()" can be used!
>
>We now have the safety and efficiency of g() having the prototype "s g();"
>
>....
>
>I'll re-post my whole tihng under a subject beginning with "Some C/C++
>Optimization Idioms I Wish Compilers Supported," where you can learn
>about this.
Exactly what is this idiom?
Cheers,
- Alf