From: Florian Weimer on
> What C++0x features are most relevant to you?

Type-safe variadic functions. The Movable concept (which enables
std::unique_ptr). So far, auto seems nice, too.

I don't particularly care about rvalue references themselves. I'm a
bit skeptical about lambda expressions. They might undermine one of
C++'s strengths (fully deterministic resource management through
RAII), but there are clear benefits, too.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Hakusa on
On Feb 22, 1:21 am, Beman Dawes <beman.da...(a)gmail.com> wrote:

> I'm not sure that's the right question to ask. Viewed in isolation, C+
> +0x does have quite a number of neat features. But the most positive
> impact may well be synergism between features, both new and old, major
> and minor.

> So you might want to ask about features that play well together.

Actually, i still think i asked the right question, but that your
perception of what i want to know may come short of my own perception.
If one believes two features work well together, and is excited to use
both, then i would like to hear about that! What i'm after is what
others are not just interested in, but excited about; whether or not
they choose to be excited about a multitude of features or one in
particular is perfectly within the range of what i'm looking for.

Thank you for helping me clarifying this.

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.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: SG on
On 23 Feb., 03:51, "Hak...(a)gmail.com" <hak...(a)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! ]

From: Mathias Gaunard on
On 23 f�v, 02:51, "Hak...(a)gmail.com" <hak...(a)gmail.com> wrote:

> Vector<int,3> d = a + b + c; // Rvalue refs should have this optimized.

Not particularly.
NRVO and expression templates should be much more useful here.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Hakusa on
On Feb 23, 3:00 pm, SG <s.gesem...(a)gmail.com> wrote:
> On 23 Feb., 03:51, "Hak...(a)gmail.com" <hak...(a)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).

Correct.

> 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. Assuming the compiler doesn't optimize that line to use d
as the temporary (a+b). Though, to be honest, i haven't tested this
yet by looking into the binary...

> 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.

With the exception of my Vector class, i never find this incredibly
useful in real code, but when i'm doing testing, making a vector of
arguments and another of expected results, i find it very useful.

> 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>
> {
> };

> 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

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.

> #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.
> };

I had assumed variadic templates would suffer the same problem and be
harder to work with; harder, yes, but this was just my own ignorance.
Thanks!


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]