Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Rants about auto

    C++ Gurus
    6
    25
    2706
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • jsulm
      jsulm Lifetime Qt Champion @J.Hilk last edited by

      @J.Hilk Hey, I don't like auto that much as well.
      This is a constant source of discussions in our team :-)
      In some cases it's OK, but some people overuse it and it becomes more difficult to understand the code.

      https://forum.qt.io/topic/113070/qt-code-of-conduct

      J.Hilk 1 Reply Last reply Reply Quote 1
      • J.Hilk
        J.Hilk Moderators @jsulm last edited by

        @jsulm

        if you have some ridiculously long Class names whom you need an instance of, lets say:

        auto agent = new QBluetoothDeviceDiscoveryAgent();
        

        I can see a justified use, you see the return type on the first glance and its really long class name, so it's more readable and it saves time (somewhat) so use it here.

        and than you have something along this line

        auto a = ConjureMagic();
        SetMagic(a);
        

        and I'm like, NO!

        Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct

        Qt Needs YOUR vote: https://bugreports.qt.io/browse/QTQAINFRA-4121


        Q: What's that?
        A: It's blue light.
        Q: What does it do?
        A: It turns blue.

        jsulm 1 Reply Last reply Reply Quote 2
        • jsulm
          jsulm Lifetime Qt Champion @J.Hilk last edited by

          @J.Hilk Sure.
          One example for what I don't like: you have a function/method returning something and when you write:

          auto ret = someFunction();
          

          What type is ret?

          https://forum.qt.io/topic/113070/qt-code-of-conduct

          J.Hilk kshegunov 2 Replies Last reply Reply Quote 1
          • J.Hilk
            J.Hilk Moderators @jsulm last edited by

            @jsulm very true,
            one spends why to much time in header files, looking stuff up, thanks to auto :-)

            Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct

            Qt Needs YOUR vote: https://bugreports.qt.io/browse/QTQAINFRA-4121


            Q: What's that?
            A: It's blue light.
            Q: What does it do?
            A: It turns blue.

            1 Reply Last reply Reply Quote 2
            • kshegunov
              kshegunov Moderators @jsulm last edited by kshegunov

              @jsulm @J-Hilk

              And there's the occasional case that you can actually get wrong behaviour using such nonsense:
              https://eigen.tuxfamily.org/dox/TopicPitfalls.html

              Read and abide by the Qt Code of Conduct

              1 Reply Last reply Reply Quote 2
              • V
                VRonin last edited by

                We are going a lot off topic here but auto is not as evil as everybody thinks.
                It does not prevent you from hard typing, you can always put it on the right side of the equal with no difference in the compiled code.
                It also prevent implicit conversion int ret = someFunction(); with somefunction returning a double introduces a truncation that would have been avoided with auto, this is also the reason why Eigen doesn't like auto, they rely on implicit conversions to delay the calculations to the last minute to increase efficiency.

                What I'm saying is that auto is a tool, a useful one. It shouldn't be hated and the usage proposed by the coding conventions of Qt is more than reasonable.

                In layman's terms: you can use a wrench to kill a man but that doesn't make the wrench dangerous or useless. Same goes for auto

                "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                ~Napoleon Bonaparte

                On a crusade to banish setIndexWidget() from the holy land of Qt

                kshegunov 1 Reply Last reply Reply Quote 3
                • kshegunov
                  kshegunov Moderators @VRonin last edited by

                  @VRonin said in Why no std::byte in qt?!!:

                  We are going a lot off topic here

                  Seeing as the topic is pretty much done, I'd say we are not that much into sin. You can fork it off if you think appropriate, though.

                  but auto is not as evil as everybody thinks.

                  Eh, okay. Defining it as just a little bit evil I can accept.

                  It does not prevent you from hard typing, you can always put it on the right side of the equal with no difference in the compiled code.

                  Yep, it's still hard typed only hidden hard typing, a.k.a. compiler deduced typing.

                  It also prevent implicit conversion int ret = someFunction(); with somefunction returning a double introduces a truncation that would have been avoided with auto

                  Which you should've caught by compiling with pedantic, as is (somewhat) customary for release builds, provided this is not what you intended to begin with.

                  this is also the reason why Eigen doesn't like auto, they rely on implicit conversions to delay the calculations to the last minute to increase efficiency.

                  Rather it relies on overloading and implicit constructors, which is completely valid thing to do. Also had been in the language long before they decided that C++ should behave like javascript but compiled.

                  What I'm saying is that auto is a tool, a useful one.

                  Sure! A cannon is a tool too, but you don't go around smashing bugs with it, right?

                  It shouldn't be hated and the usage proposed by the coding conventions of Qt is more than reasonable.

                  Agreed. Although that convention just says we can take a (safe) shortcut in some very specific places, and specifically warns against using it whenever there's a spec of doubt about readability. So all uses of the type:

                  auto IAmBothTooSmartToKnowDocsByHeartAndUtterlyLazyToWriteTheType = myObject.someFunctionThatReturnsGodKnowsWhat();
                  

                  is simply a no-no.

                  In layman's terms: you can use a wrench to kill a man but that doesn't make the wrench dangerous or useless. Same goes for auto

                  Indeed, there's also the gun, which you can use to kill a man, and it is dangerous and pretty much useless (beside it's primary purpose).

                  Read and abide by the Qt Code of Conduct

                  V 1 Reply Last reply Reply Quote 1
                  • V
                    VRonin @kshegunov last edited by VRonin

                    @kshegunov said in Why no std::byte in qt?!!:

                    Rather it relies on overloading and implicit constructors

                    Yes, I probably I over simplified my terminology, I was thinking at implicit constructors as well as implicit conversions.

                    Probably a better example is someFunction returns a QByteArray and people write QString ret = someFunction(); (I'm looking at you, QIODevice::readAll) even when they have no assurance the returned value is a UTF-8 encoded string. using auto would force ret to be QByteArray and it's also far more efficient.

                    I agree this is a corner case and I'm the first not to advocate a too libertine use of auto, just pointing out that it's a point of view.

                    Rather it relies on overloading and implicit constructors, which is completely valid thing to do.

                    I actually think it's a very smart way of handling and compressing intensive calculations, nevertheless now that auto is a thing users must be aware of this implementation detail more than ever

                    "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                    ~Napoleon Bonaparte

                    On a crusade to banish setIndexWidget() from the holy land of Qt

                    kshegunov 1 Reply Last reply Reply Quote 2
                    • kshegunov
                      kshegunov Moderators @VRonin last edited by kshegunov

                      @VRonin said in Why no std::byte in qt?!!:

                      Probably a better example is someFunction returns a QByteArray and people write QString ret = someFunction(); (I'm looking at you, QIODevice::readAll) even when they have no assurance the returned value is a UTF-8 encoded string. using auto would force ret to be QByteArray and it's also far more efficient.

                      I have only one thing to say here: QT_NO_CAST_FROM_ASCII ;)

                      @VRonin said in Why no std::byte in qt?!!:

                      I actually think it's a very smart way of handling and compressing intensive calculations, nevertheless now that auto is a thing users must be aware of this implementation detail more than ever

                      I agree on both counts.

                      Read and abide by the Qt Code of Conduct

                      1 Reply Last reply Reply Quote 1
                      • JonB
                        JonB last edited by JonB

                        My 2¢: when you have MyRidiculouslyLongClassNameWhichIDontWantToTypeInEachTimeSoIUseEvilAuto, try

                        typedef MyRidiculouslyLongClassNameWhichIDontWantToTypeInEachTimeSoIUseEvilAuto Z;
                        
                        Z abc;
                        

                        :)

                        V 1 Reply Last reply Reply Quote 0
                        • V
                          VRonin @JonB last edited by VRonin

                          @JonB First of all using Z = MyRidiculouslyLongClassNameWhichIDontWantToTypeInEachTimeSoIUseEvilAuto; because C++11 :)

                          "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                          ~Napoleon Bonaparte

                          On a crusade to banish setIndexWidget() from the holy land of Qt

                          JonB 1 Reply Last reply Reply Quote 0
                          • JonB
                            JonB @VRonin last edited by JonB

                            @VRonin
                            Sigh, looks like my C knowledge is increasingly invalid :( But I don't see what's wrong with typedef here, I'm not using a template.
                            BTW, I wouldn't really name it Z here, of course I'd use MRLCNWIDWTTIETSIUEA because it's much clearer what that means!

                            V 1 Reply Last reply Reply Quote 3
                            • V
                              VRonin @JonB last edited by

                              @JonB said in Rants about auto:

                              But I don't see what's wrong with typedef here

                              Nothing, I was just taking the piss. they are equivalent with the only difference that the Z type can be a template with using while it can't with typedef.

                              "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
                              ~Napoleon Bonaparte

                              On a crusade to banish setIndexWidget() from the holy land of Qt

                              JonB 1 Reply Last reply Reply Quote 1
                              • JonB
                                JonB @VRonin last edited by

                                @VRonin
                                Oh, lol! Once I started reading up about this new using I suspected that now I was supposed to use that every time....

                                With typedefs you can string them together for a nice extra level of confusion ;) So you write

                                typedef int I, *PI;
                                

                                which makes me wonder: without you looking it up, if I write:

                                typedef int *PI, T;
                                

                                is T type int or int *? :)

                                kshegunov 1 Reply Last reply Reply Quote 0
                                • kshegunov
                                  kshegunov Moderators @JonB last edited by

                                  @JonB said in Rants about auto:

                                  is T type int or int *?

                                  int.
                                  We are not JS devs, you know ... ;P

                                  Read and abide by the Qt Code of Conduct

                                  JonB 1 Reply Last reply Reply Quote 0
                                  • JonB
                                    JonB @kshegunov last edited by JonB

                                    @kshegunov
                                    Hmm. OK, then, could you please explain how the * binds in typedef int *PI, T;.

                                    Why is that typedef not int * for T? And if you wanted it to bind as int * for T (i.e. making it same as PI), how could you force that, e.g. something like (I'm sure it's not right):

                                    typedef (int *)PI, T
                                    

                                    P.S.

                                    We are not JS devs, you know

                                    Ummm, relevance? JS doesn't even have type declarations or pointers, so...?

                                    kshegunov 1 Reply Last reply Reply Quote 0
                                    • kshegunov
                                      kshegunov Moderators @JonB last edited by kshegunov

                                      @JonB said in Rants about auto:

                                      Why is that typedef not int * for T?

                                      Not 100% about the theory behind it, but it's like with initialization (I assume it's cause , has very low priority). Say you have:

                                      char * p, n;
                                      

                                      p is char *, but n is char.

                                      And if you wanted it to bind as int * for T (i.e. making it same as PI), how could you force that, e.g. something like (I'm sure it's not right):

                                      typedef int *PI, *T;
                                      

                                      Ummm, relevance? JS doesn't even have type declarations or pointers, so...?

                                      Simply an ill-concealed insult. :)

                                      PS:

                                      Simply an ill-concealed insult.

                                      https://www.destroyallsoftware.com/talks/wat

                                      Read and abide by the Qt Code of Conduct

                                      JonB ODБOï 2 Replies Last reply Reply Quote 4
                                      • JonB
                                        JonB @kshegunov last edited by

                                        @kshegunov

                                        typedef int *PI, *T;

                                        That is cheating! You know it. You know that I know it can be done that way, that wasn't the question. I want the *s to be included in the "base" part of the typedef I am declaring, so that I can write like:

                                        typedef (int **********) PI, PI2_same_as_PI, *PI3_one_extra_pointer;
                                        

                                        I don't want to repeat the *s, and I don't want to declare a separate, intermediate typedef to achieve it.

                                        As you say, thinking about the typedef just like a list-of-variables declaration, I guess it cannot be done? The *s just aren't a part of the "base" type being declared, they belong only to each type-name/variable being declared individually? And this is why we tend/are encouraged to write char *p and not char* p in C.

                                        As for the JS. I know I am a cheerleader for C compared to C++, but I have never said I am a fanboi for all the JS stuff I have had to write over the years.

                                        kshegunov 1 Reply Last reply Reply Quote 0
                                        • kshegunov
                                          kshegunov Moderators @JonB last edited by

                                          @JonB said in Rants about auto:

                                          I don't want to repeat the *s, and I don't want to declare a separate, intermediate typedef to achieve it.

                                          Then you're out of luck.

                                          And this is why we tend/are encouraged to write

                                          That's just style. I write spaces on both sides:

                                          char * p;
                                          char ** p;
                                          

                                          and so on.

                                          I know I am a cheerleader for C compared to C++

                                          That's like being cheerleader for FORTRAN against C. ;)

                                          but I have never said I am a fanboi for all the JS stuff I have had to write over the years.

                                          Granted. I was just making fun of JS devs. ;P

                                          Read and abide by the Qt Code of Conduct

                                          JonB 1 Reply Last reply Reply Quote 0
                                          • JonB
                                            JonB @kshegunov last edited by

                                            @kshegunov
                                            The declaration layout is just style, but I meant that char *p instead of char* p makes clear how C type declarations with * actually bind, relevant if you have a list of them (char *p, *q better than char* p, *q).

                                            1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post