Re: static or not?
On Jan 29, 12:14 pm, "Alf P. Steinbach" <al...@start.no> wrote:
kwikius wrote :
<...>
Could add that its an unnecessary requirement AFAICS. (Perhaps the
return type was changed from value to const reference at some point.)
#include <algorithm>
#include <iostream>
struct my{
explicit my (double v_in) : v (v_in){};
double v;
private :
my ( my const &);
};
inline bool operator <
(my const & lhs, my const & rhs)
{
return lhs.v < rhs.v;
}
int main()
{
my x(1),y(2);
my const & r = std::min(x,y);
Consider instead
my const& r = std::min( x, my(2) );
Ouch. hang about. But what difference does it make whether the
arguments are copy constructible or not?
Or is the result r referencing a temporary copied from one of the
inputs or what?
Note: incorrectly compiles with MSVC 7.1, is diagnosed with g++ 3.4.4
and of course with Comeau.
I first learned about this silly requirement of class having an
accessible copy constructor when (among a great many others) helping to
review Andrei Alexandrescu's Mojo library, a way to implement "move"
construction (library-implemented RVO) in current standard C++. That
attempt sort of stranded on this requirement, that the implementation
should be free to make a temporary copy instead of just providing a
reference directly to the rvalue. Happily, will be removed in C++0x
:-), but, of course, that yields more Potential Dangers, like if the
code above was accepted with std::min implemented with ordinary current
references instead of new-fangled moving rvalue references.
Uh.
I wonder if the code above will be valid in C++0x, and if so, how the
heck the compiler could implement the necessary lifetime extension for
the temporary?
hmmm... mental note. When this move widget materialises I'll
investigate, meanwhile maybe my overloads of min/max will return by
value...
<...>
Off-topic, but: Comeau Online's error message is ungrokkable while
g++'s error message is simple and to the point. Difference: that Comeau=
implements concept checking. The C++0x technology that's meant to
provide /simpler/ error messages!
Not exactly a fair comparison. "concept checking" is pretty primitive,
just some function pointer to a function exercising the expression. It
was originally demoed in the "design and evolution of C++" book
AFAIK. It fails really because you still get an error message in some
remote place IIRC, wherever the concept checking function is defined.
For true Concepts the ball keeps moving, but it was shockingly strict
last time I looked. Your type may have the correct bits and pieces but
if you dont say it does in the correct way, you will get an error
message at that point. It would be interesting to try redoing the
above in ConceptGcc to see what output you get. Maybe I will try it
myself...
regards
Andy Little