Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > auto for function return type is kind of useless, is it?

Reply
Thread Tools

auto for function return type is kind of useless, is it?

 
 
Juha Nieminen
Guest
Posts: n/a
 
      01-18-2012
Peter <(E-Mail Removed)> wrote:
> On Jan 17, 11:40*pm, Juha Nieminen <(E-Mail Removed)> wrote:
>> * Anyways, what I think you want is this:
>>
>> template<typename T0, typename T1>
>> auto getSomething(const T0& r0, const T1& r1)
>> -> std::common_type<T0, T1>::type
>> {
>> * * const auto a = r0 + r1;
>> * * const auto b = a * a;
>> * * return b * a;

>
>
> I don't see the code where you tell the compiler that the return type
> is decltype((_r0+_r1)*(_r0+_r1))*(_r0+_r1)).


std::common_type::type is the resulting type of any arithmetic
operations performed on the parameter types.
 
Reply With Quote
 
 
 
 
Peter
Guest
Posts: n/a
 
      01-18-2012
On Jan 17, 1:53*pm, Peter <(E-Mail Removed)> wrote:



Guys -- this is ridiculous.

Thanks for telling me, that the problem I'm facing does not exist!

I was posting here to publish the unnecessary restrictions in the new C
++ standard
and I may have hoped, that somebody may come up with a better method.

I was of the opinion, that my original post contained enough
information for all of this.
 
Reply With Quote
 
 
 
 
Peter
Guest
Posts: n/a
 
      01-18-2012
On Jan 18, 10:52*am, Peter <(E-Mail Removed)> wrote:
> On Jan 17, 1:53*pm, Peter <(E-Mail Removed)> wrote:
>
> Guys -- this is ridiculous.
>
> Thanks for telling me, that the problem I'm facing does not exist!
>
> I was posting here to publish the unnecessary restrictions in the new C
> ++ standard
> and I may have hoped, that somebody may come up with a better method.


I mean to say:


that somebody may come up with a better method than using macros the
way I did...


>
> I was of the opinion, that my original post contained enough
> information for all of this.


 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      01-19-2012
Peter <(E-Mail Removed)> wrote:
> Guys -- this is ridiculous.
>
> Thanks for telling me, that the problem I'm facing does not exist!
>
> I was posting here to publish the unnecessary restrictions in the new C
> ++ standard
> and I may have hoped, that somebody may come up with a better method.
>
> I was of the opinion, that my original post contained enough
> information for all of this.


What exactly is the problem with std::common_type?

It works with all basic types (for which arithmetic operators can be
applied to) and any other type if the types are the same (for example it
works with std::string just fine).

It might not work with different classes that can be inter-mixed with
the arithmetic operators. Haven't tested. OTOH, it's allowed for common_type
to be specialized.
 
Reply With Quote
 
SG
Guest
Posts: n/a
 
      01-19-2012
> On Jan 17, 1:53*pm, Peter <(E-Mail Removed)> wrote:
>
> > Guys -- this is ridiculous.


Peter, this is ridiculus. Your thread title includes a general
statement about the alleged uselessness of auto for functions and when
presented with counter examples you're not pleased. Sorry, I can't
give you a "Yes, you're right. auto sucks".

> Thanks for telling me, that the problem I'm facing does not exist!


Maybe it doesn't. I yet have to see sample code that looks like it
makes sense in some context or another. The "simpler" approach you
asked for would look -- given my AUTO_RETURN macro -- like this:

template<class T, class U>
auto func(T x, U y)
AUTO_RETURN( (x+y)*(x+y)*(x+y) )

or better yet

template<class T>
auto pow3(T z)
AUTO_RETURN( z*z*z )

:::
auto result = pow3(x+y);
:::

> I was posting here to publish the unnecessary restrictions in the new C
> C++ standard and I may have hoped, that somebody may come up with a
> better method.


The only thing I would consider an unnecessary is the restriction that
functions with a single return statement in their body still have to
define the return type manually because that's but lambdas already
allow. Beyond that, there might be good technical reasons why things
are the way they are w.r.t. deduction of return types (I dunno). But
it actually doesn't bother me that much and *maybe* you're just trying
to solve problems more complicated than necessary.

> I mean to say:
>
> that somebody may come up with a better method than using macros the
> way I did...


I did. My macrro wasn't as ugly as your macro collection. :-p


> I was of the opinion, that my original post contained enough
> information for all of this.


I expected you to be more appreciative of the feedback.
That's life.

Cheers!
SG
 
Reply With Quote
 
Marc
Guest
Posts: n/a
 
      01-19-2012
Juha Nieminen wrote:

> What exactly is the problem with std::common_type?


It only works for simple cases. Sure, for types short, unsigned int,
etc, the type of a-b will be common_type<A,B>::type. But already for
type char*, a-b has type ptrdiff_t but common_type is char*. If you
use expression template, every expression will have a different type
(OTOH, computing (a+b)*(a+b) with expression template instead of first
evaluating c=a+b then computing c*c is uncommon as it generally means
the addition is performed twice).

Since there is a better solution that is guaranteed to always yield
the right type...
 
Reply With Quote
 
Peter
Guest
Posts: n/a
 
      01-19-2012
On Jan 18, 10:48*pm, Juha Nieminen <(E-Mail Removed)> wrote:

> * What exactly is the problem with std::common_type?



see my earlier post:


On Jan 18, 9:46 am, Peter <(E-Mail Removed)> wrote:
> In my case
> decltype(_r0+_r1)
> maybe different than
> decltype((_r0+_r1)*(_r0+_r1))
> which in turn may be different than
> decltype(std::sin(_r0+_r1))
> So please tell me how I can avoid having to write the code twice?


 
Reply With Quote
 
Peter
Guest
Posts: n/a
 
      01-19-2012
On Jan 19, 1:02*am, SG <(E-Mail Removed)> wrote:
> > On Jan 17, 1:53*pm, Peter <(E-Mail Removed)> wrote:

>
> > > Guys -- this is ridiculous.

>
> Peter, this is ridiculus. *Your thread title includes a general
> statement about the alleged uselessness of auto for functions and when
> presented with counter examples you're not pleased. *Sorry, I can't
> give you a "Yes, you're right. auto sucks".



counter example?
The class I'm dealing with has a default constructor.
So I don't have any advantage in putting the declspec after the
function header compared to putting it in front and using types
instead variable names.



>
> > Thanks for telling me, that the problem I'm facing does not exist!

>
> Maybe it doesn't. *I yet have to see sample code that looks like it
> makes sense in some context or another. *The "simpler" approach you
> asked for would look -- given my AUTO_RETURN macro -- like this:
>
> * template<class T, class U>
> * auto func(T x, U y)
> * AUTO_RETURN( (x+y)*(x+y)*(x+y) )



The point is to avoid multiple calculation of identical expressions.
This is so basic that I did not imagine I would have to point it out.
This is what I'm using variables for.
So fine -- your "solution" works for trivial functions without
temporary variables.
My example problem contained temporary variables -- your solution does
not apply!


>
> or better yet
>
> * template<class T>
> * auto pow3(T z)
> * AUTO_RETURN( z*z*z )
>
> * :::
> * auto result = pow3(x+y);
> * :::
>
> > I was posting here to publish the unnecessary restrictions in the new C
> > C++ standard and I may have hoped, that somebody may come up with a
> > better method.

>
> The only thing I would consider an unnecessary is the restriction that
> functions with a single return statement in their body still have to
> define the return type manually because that's but lambdas already
> allow. *Beyond that, there might be good technical reasons why things



exactly


> are the way they are w.r.t. deduction of return types (I dunno). *But
> it actually doesn't bother me that much and *maybe* you're just trying
> to solve problems more complicated than necessary.



tell this to my customers!


>
> > I mean to say:

>
> > that somebody may come up with a better method than using macros the
> > way I did...

>
> I did. My macrro wasn't as ugly as your macro collection. :-p
>
>
> > I was of the opinion, that my original post contained enough
> > information for all of this.

>
> I expected you to be more appreciative of the feedback.
> That's life.
>
> Cheers!
> SG


 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      01-20-2012
Marc <(E-Mail Removed)> wrote:
> It only works for simple cases. Sure, for types short, unsigned int,
> etc, the type of a-b will be common_type<A,B>::type. But already for
> type char*, a-b has type ptrdiff_t but common_type is char*.


std::common_type is intended for combining the parameters using
arithmetic operations. Exactly what kind of arithmetic operation
would you combine two char*'s with?

std::common_type does work properly if the parameters are eg. of
type std::string or std::complex. I imagine (although I haven't tested)
the only situation where it won't work properly is when you have two
different classes (or one clas and one basic type) that can be combined
with arithmetic operators. OTOH, in these situations it is possible to
overload std::common_type to make it work.

 
Reply With Quote
 
Marc
Guest
Posts: n/a
 
      01-21-2012
Juha Nieminen wrote:

> Marc <(E-Mail Removed)> wrote:
>> It only works for simple cases. Sure, for types short, unsigned int,
>> etc, the type of a-b will be common_type<A,B>::type. But already for
>> type char*, a-b has type ptrdiff_t but common_type is char*.

>
> std::common_type is intended for combining the parameters using
> arithmetic operations.


In special cases, and among other things.

> Exactly what kind of arithmetic operation
> would you combine two char*'s with?


Ever heard of "pointer arithmetic"?

> std::common_type does work properly if the parameters are eg. of
> type std::string or std::complex. I imagine (although I haven't tested)
> the only situation where it won't work properly is when you have two
> different classes (or one clas and one basic type) that can be combined
> with arithmetic operators.


common_type works by looking at the result type of ?:, i.e. basically
looking at whether one type can be implicitly converted into the
other. It happens to be useful to determine the result type of
arithmetic operations on std::duration (and IIRC that was one of the
reasons why it was created), but note that even there scalar
multiplication doesn't directly define the result type as the
common_type of both arguments.

Now think of the multiplication of 2 matrices: do you expect each
matrix to be convertible to the result type? In general, do you always
expect +, -, * and / to return the same type?

common_type can also be useful in cases where there are no arithmetic
operations defined.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Auto Shipping Auto Shipping Scheduling:car moving auto transport linkswanted ASP .Net 1 11-22-2013 07:02 AM
incomplete return type in template function declaration; will c++0x'auto' work? m0shbear C++ 1 03-19-2011 04:01 AM
write a function such that when ever i call this function in some other function .it should give me tha data type and value of calling function parameter komal C++ 6 01-25-2005 11:13 AM



Advertisments