-2

I have studied auto and I know it deduces types from initialized values. If I tried to write some guidelines for usage of auto, can I put below statements as rules?

  1. Use auto && for all values (r-values and l-value, as it is an universal ref) that are modifiable,
  2. auto && even for read only values,
  3. Use auto wherever possible (individual preference for coding style).

EDIT

class Test
{
public:
    Test() = default;
    Test(const Test&) = default;
    Test(Test&&) = default;

    int i = 1;
};

Test getObj()
{
    return Test();
}

Test& getObjByRef()
{
    static Test tobj;
    return tobj;    
}

const Test getObjConst()
{
    return Test();
}

int main()
{
    auto && obj1 = getObj();
    obj1.i = 2;

    std::cout << " getObj returns: " << getObj().i << std::endl;

    auto&& obj2 = getObjByRef();
    obj2.i = 3;

    std::cout << " getObjByRef returns: " << getObjByRef().i << std::endl;

    auto && obj3 = getObjConst();

    //obj3.i = 4;  => //Error   C3490   'i' cannot be modified because it is being accessed through a const object

    return 0;
}

So in above example i used auto && for all three functions

  • getObj
  • getObjByRef
  • getObjConst

and it works as expected. Now can I conclude that:

  • auto && can be used to hold(initialize) any value, OR
  • We can use auto && every possible place.

Do you see any pitfall of this approach?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
gaurav bharadwaj
  • 1,669
  • 1
  • 12
  • 29
  • Don't use auto&&. Use either plain type or const reference. Unless you implement move ctor – user3104201 Jul 12 '16 at 09:09
  • 1
    http://stackoverflow.com/a/13242177/2352671 – 101010 Jul 12 '16 at 09:12
  • N.B. it's called a forwarding reference now, not a universal reference. – Jonathan Wakely Jul 12 '16 at 09:18
  • @user3104201 if we use plain type, it will invoke copy constructor. for const reference, it is always const. Even without move constructor we can have auto && isn't it? – gaurav bharadwaj Jul 12 '16 at 10:21
  • @JonathanWakely yeah standard says it like that way. – gaurav bharadwaj Jul 12 '16 at 10:22
  • good if ppl tell why they are down voting. It may be helpful for improvement. – gaurav bharadwaj Jul 12 '16 at 10:24
  • What makes you think r-value reference, move semantics, forwarding references etc. - have to do with `auto`, `const` and references ? – Ajay Jul 13 '16 at 05:01
  • @Ajay where he is saying that auto has to do something with rvalue reference or move semantics, he is just mentioning that auto&& is forwarding reference – PapaDiHatti Jul 13 '16 at 06:42
  • Now what we can debate is whether auto&& is good to use for all scenarios, one scenario where i find useful is we can use auto&& to iterate over locally declared vector(lvalue) or vector returned from function(rvalue) – PapaDiHatti Jul 13 '16 at 06:45
  • can anyone suggest scenario where auto&& will create problem – PapaDiHatti Jul 13 '16 at 06:45
  • Also apart from obvious auto advantages like you need to initialize variable,you don't need to use that verbose declaration for things like iterator there are other positives of auto also like portability, check this link where author is describing why we need to use auto for vector size https://herbsutter.com/2013/06/13/gotw-93-solution-auto-variables-part-2/ – PapaDiHatti Jul 13 '16 at 07:00

1 Answers1

-4

1) Yes 2) Yes 3) As you said, 'individual preference for coding style'

paweldac
  • 1,144
  • 6
  • 11
  • 1
    Could you explain your answers? I think the questioner is looking for an argumentation for or against his suggested guidelines. – jotrocken Jul 12 '16 at 10:30
  • @jotrocken 1) 'auto&&' is universal reference, can be bind to both l- and r- value. I wouldn't use it always, but it's certainly possible. 2) 'const auto&' is read only reference, you can only use const methods on such object. 3) it's up to developer if he/she wants to use auto and let compiler deduce type or write down type on your own. OP asked if those statements are true. – paweldac Jul 12 '16 at 10:38
  • @paweldac as for 1) you said, you would not use it always, so do u find any shortcoming which prevents it to be used *always* (except for un-modifiable elements) => It is fast then comparable to simple auto.. right? – gaurav bharadwaj Jul 12 '16 at 12:08