Re: What C++0x features are relevant to you?
On 23 Feb., 03:51, "Hak...@gmail.com" <hak...@gmail.com> wrote:
I have, however, seen that adding both initializer lists and rvalue
reference-support to the same class can greatly help my code, whether
or not one should consider that a synergy.
ex:
Vector<int,3> a = {1,2,3}, b = {2,3,4}, c = {3.4.5}; // I used to have
to do so much more typing.
Vector<int,3> d = a + b + c; // Rvalue refs should have this optimized.
It depends on how you implement your Vector<> class template. It seems
your vector's dimension is part of its type which suggests that you
intend to store an array directly in the vector object (as member).
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).
Regarding synergies: You can combine rvalue references with variadic
templates nicely for "generic perfect forwarding". This will be used
in std::thread, std::async, std::bind, etc.
From a library developer's point of view I'd say the following
features are very useful: rvalue references, variadic templates,
decltype/auto, extended SFINAE (for type traits and such).
From a user's point of view I's say it's nice that I can use a more
flexible library. For example: Containers will support move-only
types, I will be able to return (most) containers from functions
without having to worry about unnecessary copying. unique_ptr seems
nice, too. Basically all the new things that are enabled via the new
core language features + other nifty library features.
But I'm not sure about the usefulness of the std::initializer_list
type. I mean, yes, it'll further simplify toy/example programs like
map<string,string> phonebook = {
{"William Tanner", "555-8531"},
{"Ghostbusters","555-2368"}
};
but I have a hard time imagining something like this in real code
where data comes from user inputs, files, or other sources. It may be
used for some kinds of lookup tables but I would guess that for most
lookup tables arrays with static lifetime are a better fit. I have yet
to see a nice example for std::initializer_list helping in real actual
code.
Also, the size information is not part of the list's type. In many
cases this is a good thing. But in your example you expect 3 elements
in the initializer list. If it's more or less than 3 you'll get an
error *at runtime* which could have been detected at *compile-time* if
the size of the initializer list was somehow part of its type.
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_list : public initializer_list<T>
{
};
where fixed_size_list doesn't have any additional members, so that
slicing is not a problem. The compiler could directly create
fixed_size_list objects for us instead of initializer_lists. They
could be converted to the initializer_lists (sort of a "decay" where
the size is lost) if necessary or used directly like this:
template<class T, size_t Dim>
class myvector
{
T coefficients[Dim];
public:
explicit myvector(std::fixed_size_list<T,Dim> initlist);
etc.
};
Just a thought. Alternativly you could try to use variadic templates
and constrain your constructor template via SFINAE a la
#define REQUIRES(...) \ // for an unnamed template parameter
class=typename std::enable_if<(__VAR_ARGS__)>::type
template<bool... B> struct and_ : std::true_type {};
template<bool... B> struct and_<true,B...> : and_<B...> {};
template<bool... B> struct and_<false,B...> : std::false_type {};
template<class T, size_t Dim>
class myvector
{
T coefficients[Dim];
public:
template<typename... U,
REQUIRES( sizeof...(U)==Dim &&
and_<std::is_convertible<U,T>::value...>::value )
>
explicit myvector(U const&... args);
etc.
};
Ok, so, at least this is another example of how the new core language
features and library features may improve generic programming even
without the concepts feature.
Cheers,
SG
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]