About using auto with class member functions

[JiiPee]

Is it a good idea to use auto -return value with all class member
function, or use the return type?

this:

class Render

    int getScreenWidth() const;
    int getScreenHeight() const;

    const std::vector<std::vector<T>>& getScreen();


or this:

class Render

    auto getScreenWidth() const;
    auto getScreenHeight() const;

    const auto& getScreen();

?

Or is some kind of mix best solution (like using auto only with
long/difficult return types)?

How do you do this?

[red floyd]

I would go for the first set, but that's me.

[Ian Collins]

You can't use auto if the function definition isn't visible?

I only ever use auto return form function local to a compilation unit
(basically those in the anonymous namespace) or those tiny functions
defined in the class declaration.

If you can't determine the type, neither can the compiler!

--
Ian.

[Melzzzzz]

On 2020-03-21, JiiPee <n...@notvalid.com> wrote:
> Is it a good idea to use auto -return value with all class member
> function, or use the return type?

No, auto is not good for that. In haskell, one writes
funtion signatures for all functions, only for local
functions signature is not needed. That's just convention
and makes better compiler errors.


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Paavo Helde]

This depends first on the scope and lifetime of the project, there are
no universal rules. In small and short-living projects one can obviously
use much more 'auto' than in an official interface meant to fix a
library public interface for decades.

Anyway, auto should be used only if the return type is obvious. With
things like getScreenWidth() it's not so obvious, there are some people
who believe widths and heights should be unsigned. So in order to use
the result in calculations, and to avoid various compilers' warnings
about signed-unsigned mix, one really needs to know if the return type
is signed or unsigned. The function declaration is the best place to
specify this, for both the users of the function and for the potential
future code maintainers.

Besides, 'auto' is more characters to type than 'int'.

With more complex types like in getScreen() the things are not so clear
any more, too much noise on the screen is no good either. If the
function itself is really trivial "return member_;" then I guess using
'auto' would be fine or even preferred.

For anything more complex than a trivial getter I would do without auto
and use some typedefs or aliases to reduce the clutter instead.

[Melzzzzz]

On 2020-03-22, Paavo Helde <myfir...@osa.pri.ee> wrote:
> For anything more complex than a trivial getter I would do without auto
> and use some typedefs or aliases to reduce the clutter instead.

This.

[David Brown]

For the public member functions in a class, you are providing an
interface for users - so it should be as clear as possible what the
function does, and that includes the return type. You can't use "auto"
return type unless the function is defined in the same unit (so that the
compiler can figure out the return type).

So if the function is so short that it is just a "return" statement
defined inline in the class definition, with an obvious type, then
"auto" would be okay. But in general you should have explicit types.

An exception could be for very complex return return types where the
exact type is not likely to be useful for the caller (though even then,
you might be better declaring the type explicitly in a "using"
statement). It's also necessary to use "auto" for types that can't be
given explicitly, like lambdas.

For private member functions, you can be more flexible, as users should
not care about the types.

[Alf P. Steinbach]

On 22.03.2020 05:10, Paavo Helde wrote:
> On 22.03.2020 1:17, JiiPee wrote:
>> Is it a good idea to use auto -return value with all class member
>> function, or use the return type?
>>
>> this:
>>
>> class Render
>>
>>      int getScreenWidth() const;
>>      int getScreenHeight() const;
>>
>>      const std::vector<std::vector<T>>& getScreen();
>>
>>
>> or this:
>>
>> class Render
>>
>>      auto getScreenWidth() const;
>>      auto getScreenHeight() const;
>>
>>      const auto& getScreen();
>>
>> ?
>>
>> Or is some kind of mix best solution (like using auto only with
>> long/difficult return types)?
>
> This depends first on the scope and lifetime of the project, there are
> no universal rules. In small and short-living projects one can obviously
> use much more 'auto' than in an official interface meant to fix a
> library public interface for decades.
>
> Anyway, auto should be used only if the return type is obvious.

When even experienced programmers use "auto" to refer to inferred return
type, then maybe it's time to give up the terminology struggle.

So, let's agree that henceforth "auto" means inferred return type.

We can use the term "modern syntax" for trailing return type. Or just
spell it out, "trailing return type".

> With
> things like getScreenWidth() it's not so obvious, there are some people
> who believe widths and heights should be unsigned.

Well, Mr. Flibble is in that group, as I recall. I think it's a kind of
group affinity madness akin to religion. Happily the leading voices of
the C++ community have now for some years argued against that idiocy,
and the core guidelines recommend against it, <url:
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-mix>.

> So in order to use
> the result in calculations, and to avoid various compilers' warnings
> about signed-unsigned mix, one really needs to know if the return type
> is signed or unsigned. The function declaration is the best place to
> specify this, for both the users of the function and for the potential
> future code maintainers.

Yep.

> Besides, 'auto' is more characters to type than 'int'.
>
> With more complex types like in getScreen() the things are not so clear
> any more, too much noise on the screen is no good either. If the
> function itself is really trivial "return member_;" then I guess using
> 'auto' would be fine or even preferred.
>
> For anything more complex than a trivial getter I would do without auto
> and use some typedefs or aliases to reduce the clutter instead.

- Alf

[JiiPee]

Ok so most answers say that better to type the type and not use auto. I
was also thinking that might be better, so I think I ll go with this as
well.