Re: What C++0x features are relevant to you?
On 24 Feb., 01:18, "Hak...@gmail.com" <hak...@gmail.com> wrote:
On Feb 23, 3:00 pm, SG <s.gesem...@gmail.com> wrote:
On 23 Feb., 03:51, "Hak...@gmail.com" <hak...@gmail.com> wrote:
[...]
But rvalue references would not help you in such cases (unless the
array's elements can be moved much faster than copied). Rvalue
references are great in case "logical members" are heap-allocated and
only referenced through a pointer member (see std::vector, for
example).
The way i use rvalue references is in the operator+ function:
// Pseudo code
template< T1, T2, S >
Vector<T2,S>&& operator+( const Vector<T1,S>& a, Vector<T2,S>&& b )
{
b += a;
return std::move(b);
}
Rather than creating a vector with a+b, then another with (a+b)+c, it
should create a temporary with a+b, then add c onto (a+b), then copy
that into d.
You mean a+(b+c), right? Only the 2nd parameter of this operator+
function is an rvalue reference. Anyhow, I'd consider it unsafe and it
is likely not worth the hassle of writing this overload. I would guess
that this doesn't safe any significant amount of time (Have you
measured it?). It's unsafe because it allows you to write things like
auto const& foo = a + (b + c);
where foo would be a dangling reference. In my opinion, one should try
to avoid writing functions that return references to argument objects
which could have been temporaries.
The current draft N3035 still contains some operator+ functions for
strings which return rvalue references. But my understanding is that
this is going to be replaced. See LWG issue #1138:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3018.html#1138
[...]
I'm just doing a little thinking out loud here but maybe an
inheritance relationship is not such a bad idea:
template<class T>
class initializer_list
{
// insert implementation here
public:
T* begin() const;
T* end() const;
};
template<class T, size_t N>
class fixed_size_initlist : public initializer_list<T>
{
};
Just to clarify: The idea is an object of this type family (instead of
initializer_list<T>) would be generated by the compiler for a list
initializer "expression".
template<class T, size_t Dim>
class myvector
{
T coefficients[Dim];
public:
explicit myvector(std::fixed_size_initlist<T,Dim> initlist);
etc.
};
That fixed-size list is EXACTLY what i wish was supported. And,
really, ctors taking initializer lists could just template the size as
well and no functionality would be lost... except for how the compiler
would be generating a new version of the ctor for each different size.
It the size doesn't matter you could still use initializer_list.
That's the idea of the inheritence relationship. Every
fixed_size_list<T,N> *is* an initializer_list<T> which also makes the
first one convertible to the second one. So, you would have the choice
of selecting between one of
void foo1(std::initializer_list<double> il) {
assert(il.size() == 3);
...
}
void foo2(std::fixed_size_initlist<double,3> il) {
...
}
The other problem I have with std::initializer_list is that I don't
understand what happens in cases like this:
// This is supposed to work as far as I can tell.
// range will be of type std::initializer_list<int>
auto && range = {rand(),rand(),rand()};
Suddenly an initialization list can survive past the end of a full
expression. What happens to their elements? How long do they live?
Where do they live? What does a typical implementation look like? ...
Also, Bjarne Stroustrup once answerd the question whether
initializer_lists could be returned from functions with a "Yes". I can
only come to the conclusion that you need something like a heap
allocated array of elements + reference counting for the elements to
live long enough.
Cheers,
SG
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]