C++0x: auto(matic types) and expression templates
slavkop...@mailinator.com
problem with automatic typing.
auto x = get_temp() + other;
Assuming get_temp() returns an r-value, if get_temp() + other is
defined to return an expression template, the result of the right-hand-
side expression will end up holding a reference to a temporary. The
assignment to an auto-typed variable then holds a copy of this
expression template object (and the reference).
I could be wrong about this, but as far as I understand, this
temporary (returned by get_temp()) will be destroyed at the end of the
statement (unless directly assigned to a local const reference?).
Even if this is not the case, it is problematic to have the auto
variable hold and re-evaluate the expression template on every use.
Hiding the expression-template's copy constructor doesn't seem like an
optimal solution.
Would be nice if there was a way of setting the preferred auto-
conversion type...:
template <....>
struct MyExpressionTemplate {
operator auto EvaluatedType() { // notice "auto" keyword
/// ...
}
};
Although I mention expression templates specifically, this problem may
be troublesome when using any 'proxy' objects (objects that are meant
to be locked only temporarily... etc).
If I've posted in the wrong place, please redirect me. (I hope this
isn't a double-posting, I did a search before posting.)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
SG
> Not sure if this is the right place to post, but this may be a small
> problem with automatic typing.
>
> auto x = get_temp() + other;
>
> Assuming get_temp() returns an r-value, if get_temp() + other is
> defined to return an expression template, the result of the right-hand-
> side expression will end up holding a reference to a temporary. The
> assignment to an auto-typed variable then holds a copy of this
> expression template object (and the reference).
Yes, apparently the use of "auto" for type deduction in combination
with expression templates can have surprizing effects. I also noticed
this.
> I could be wrong about this, but as far as I understand, this
> temporary (returned by get_temp()) will be destroyed at the end of the
> statement (unless directly assigned to a local const reference?).
Yes, that is correct.
> Even if this is not the case, it is problematic to have the auto
> variable hold and re-evaluate the expression template on every use.
Yes, that's probably true in many cases. But I guess there are also
cases where you would want to have the expression object
(unevaluated).
> Hiding the expression-template's copy constructor doesn't seem like an
> optimal solution.
I'm not following you.
> Would be nice if there was a way of setting the preferred auto-
> conversion type...:
>
> template <....>
> struct MyExpressionTemplate {
> operator auto EvaluatedType() { // notice "auto" keyword
> /// ...
> }
>
> };
Interesting! It's a conversion that is automatically invoked prior
type deduction for "auto". I like the idea. You may want to use a
ref qualifier for that in some (all?) cases:
operator auto EvaluatedType() && {
/// ...
}
> Although I mention expression templates specifically, this problem may
> be troublesome when using any 'proxy' objects (objects that are meant
> to be locked only temporarily... etc).
Hmmm.... I can't think of examples besides expression objects that
contain references to other temporary expression objects.
Cheers!
SG
Hak...@gmail.com
> I could be wrong about this, but as far as I understand, this
> temporary (returned by get_temp()) will be destroyed at the end of the
> statement (unless directly assigned to a local const reference?).
I don't know what code to write to duplicate this behavior, so I can't
test this, but if assigning it to a const reference does the job, and
it's already a reference, would this work?
const auto x = get_temp() + other;
Unfortunately, whenever I compile with the word auto, gcc tells me x
can't be defined with no type. But, it doesn't add any extra
complaints when I put const there, so I wonder if it really IS ok.
SG
> On Dec 29, 7:12 pm, slavkop_not...@mailinator.com wrote:
> I don't know what code to write to duplicate this behavior
This thread is about a new C++ feature ("auto" as type replacement for
type deduction) that will most likely be present in the next version
of the language and a discussion about potential problems along with
an idea of how a solution might look like.
> Unfortunately, whenever I compile with the word auto, gcc tells me x
> can't be defined with no type.
GCC doesn't support that kind of use of "auto" yet. And if it did you
would have to use the option -std=c++0x.
I still like the OP's idea that
operator auto EvaluatedType() && {
/// ...
}
as a non-static member function would force a conversion right before
type deduction for "auto". It would be a method for providing more
transparency in the presence of expression templates. In case
expression templates are only used to speed up calculations (ie. for
vector or automatic differentiation expressions) it would be desirable
to make the following two lines equivalent:
vector result = 3.14 * (get_vect1() + get_vect2());
auto result = 3.14 * (get_vect1() + get_vect2());
The library author (of 'vector') should be able to transparently
include expression templates as optimization without affecting the
type of "result". Currently the use of expression templates makes
"result" deduced to be an expression object which might not be
desirable in all cases. Assuming that this expression object has a
member function "operator auto vector()" it would be invoked right
before type deduction thus making "result" of type "vector".
But full transparency (as in the user wouldn't know whether expression
templates are used) is not possible even with this "operator auto X"
proposal because the expression objects need to stay expression
objects when used as function parameters. Otherwise building
expression objects would be impossible.
I'm interested in opinions of others.
Cheers!
SG
Martin Eisenberg
> I still like the OP's idea that
>
> operator auto EvaluatedType() && {
> /// ...
> }
>
> as a non-static member function would force a conversion right
> before type deduction for "auto". It would be a method for
> providing more transparency in the presence of expression
> templates. In case expression templates are only used to speed
> up calculations (ie. for vector or automatic differentiation
> expressions) it would be desirable to make the following two
> lines equivalent:
>
> vector result = 3.14 * (get_vect1() + get_vect2());
>
> auto result = 3.14 * (get_vect1() + get_vect2());
>
> The library author (of 'vector') should be able to transparently
> include expression templates as optimization without affecting
> the type of "result".
I'm under the impression that the new sense of auto was introduced a)
to simplify handling unwieldy but knowable type names especially in
generic code; b) to enable use of unspecified, hence not legitimately
knowable, types as long as they either have the right "duck type" or
just get opaquely passed back to the source library.
At first blush both of those motivations may lead to different
assessments of the operator auto idea. Namely, case b) just fits the
scenario you describe above which does sound compelling. On the other
hand, in the alternative scenario where expression templates are an
explicit user facility, while b) still applies to some types involved
there's probably a holder type for any kind of expression whose name
-- vecexpr, say -- is just as readily at hand as the vector name.
Thus it might seem that the library writer's convenience according to
case a) carries more weight in this situation.
Then again, in this latter picture the library writer may simply not
provide operator auto vector(), effectively making auto and vecexpr
equivalent to the user. I think this means that adding operator auto
to the language would not hinder effective treatment of the second
scenario -- so let's forge ahead ;)
> Currently the use of expression templates
> makes "result" deduced to be an expression object which might
> not be desirable in all cases. Assuming that this expression
> object has a member function "operator auto vector()" it would
> be invoked right before type deduction thus making "result" of
> type "vector".
>
> But full transparency (as in the user wouldn't know whether
> expression templates are used) is not possible even with this
> "operator auto X" proposal because the expression objects need
> to stay expression objects when used as function parameters.
> Otherwise building expression objects would be impossible.
Martin
--
Quidquid latine scriptum est, altum videtur.