Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. can one switch off the implicit inline rule?

can one switch off the implicit inline rule?

Scheduled Pinned Locked Moved C / C++ / MFC
question
18 Posts 6 Posters 0 Views 1 Watching
  • 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.
  • W WernerP

    Thank you. I'm not quite certain, whether this is, what I want. What I definitely do not want is to prevent the compiler from inlining. I think it knows best. What I actually want is to switch that implicit "inline" off, which is automatically associated with the function, although you don't see it, and which is a sweettalk to the compiler to inline the function whatever might be best. Werner

    R Offline
    R Offline
    Roger Stoltz
    wrote on last edited by
    #9

    WernerP wrote:

    What I definitely do not want is to prevent the compiler from inlining. I think it knows best. .......... What I actually want is to switch that implicit "inline" off, which is automatically associated with the function, although you don't see it, and which is a sweettalk to the compiler to inline the function whatever might be best.

    I find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... :confused: :~ It's probably the compiler option "/Ob1" you want, but you should also have a look at what happens when you're using the keywords for inlining here[^].

    "It's supposed to be hard, otherwise anybody could do it!" - selfquote
    "High speed never compensates for wrong direction!" - unknown

    W 1 Reply Last reply
    0
    • W WernerP

      Hi, Because dividing class function declaration from definition does make sense, if the interface is to be seen by other modules. If the interface is just for the imlementation namespace of a certain module, I would not even put it into a header. Why? Because I don't want to recompile other modules, if the private interface changes. And because splitting declaration from definition means more administration of code and higher cost. It's overhead, if I don't want to export the functions it declares to others. This I think is a common concern of software engineering, and does not have to do with loving either one programming language or the other. Look, C++ has been called a multiparadigmatic language by it's founder. It should make us free to implement whatever pattern makes sense to us. Werner

      D Offline
      D Offline
      David Crow
      wrote on last edited by
      #10

      WernerP wrote:

      This I think is a common concern of software engineering, and does not have to do with loving either one programming language or the other. Look, C++ has been called a multiparadigmatic language by it's founder. It should make us free to implement whatever pattern makes sense to us.

      Consider why Tox asked the question he did (and that English is not his native tongue). It was not to belittle you, but more to find out if you actually knew what you were doing and why, or were just doing it because a friend's cousin's boss said it was the way to go. You'd be surprised at the number of questions we see here that should not be asked. That doesn't mean that the poster did not have a legitimate concern; it just means that they did not understand the problem first.

      "Love people and use things, not love things and use people." - Unknown

      "The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch

      R W 2 Replies Last reply
      0
      • D David Crow

        WernerP wrote:

        This I think is a common concern of software engineering, and does not have to do with loving either one programming language or the other. Look, C++ has been called a multiparadigmatic language by it's founder. It should make us free to implement whatever pattern makes sense to us.

        Consider why Tox asked the question he did (and that English is not his native tongue). It was not to belittle you, but more to find out if you actually knew what you were doing and why, or were just doing it because a friend's cousin's boss said it was the way to go. You'd be surprised at the number of questions we see here that should not be asked. That doesn't mean that the poster did not have a legitimate concern; it just means that they did not understand the problem first.

        "Love people and use things, not love things and use people." - Unknown

        "The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch

        R Offline
        R Offline
        Roger Stoltz
        wrote on last edited by
        #11

        Well said David.

        "It's supposed to be hard, otherwise anybody could do it!" - selfquote
        "High speed never compensates for wrong direction!" - unknown

        1 Reply Last reply
        0
        • D David Crow

          WernerP wrote:

          This I think is a common concern of software engineering, and does not have to do with loving either one programming language or the other. Look, C++ has been called a multiparadigmatic language by it's founder. It should make us free to implement whatever pattern makes sense to us.

          Consider why Tox asked the question he did (and that English is not his native tongue). It was not to belittle you, but more to find out if you actually knew what you were doing and why, or were just doing it because a friend's cousin's boss said it was the way to go. You'd be surprised at the number of questions we see here that should not be asked. That doesn't mean that the poster did not have a legitimate concern; it just means that they did not understand the problem first.

          "Love people and use things, not love things and use people." - Unknown

          "The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch

          W Offline
          W Offline
          WernerP
          wrote on last edited by
          #12

          I do agree. Tox's question was the most interesting answer to mine I found, and so I was much interested in discussing it. I'm very sorry, if my message sounded unfriendly. It wasn't meant to be at all.

          1 Reply Last reply
          0
          • R Roger Stoltz

            WernerP wrote:

            What I definitely do not want is to prevent the compiler from inlining. I think it knows best. .......... What I actually want is to switch that implicit "inline" off, which is automatically associated with the function, although you don't see it, and which is a sweettalk to the compiler to inline the function whatever might be best.

            I find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... :confused: :~ It's probably the compiler option "/Ob1" you want, but you should also have a look at what happens when you're using the keywords for inlining here[^].

            "It's supposed to be hard, otherwise anybody could do it!" - selfquote
            "High speed never compensates for wrong direction!" - unknown

            W Offline
            W Offline
            WernerP
            wrote on last edited by
            #13

            Roger Stoltz wrote:

            find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... Confused Unsure

            In the second I *want* it to be automatic. That's my point. The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off. Regards Werner

            R R 2 Replies Last reply
            0
            • W WernerP

              Roger Stoltz wrote:

              find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... Confused Unsure

              In the second I *want* it to be automatic. That's my point. The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off. Regards Werner

              R Offline
              R Offline
              Roger Stoltz
              wrote on last edited by
              #14

              WernerP wrote:

              The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do.

              Read the link I provided in my previous post and you will find that you cannot force the compiler to do inline expansion, not even with __forceinline. The "implicit inline" your talking about must be the "/Ob2" compiler setting, thus if you're not compiling your code with that option, there won't be any "implicit inline".

              "It's supposed to be hard, otherwise anybody could do it!" - selfquote
              "High speed never compensates for wrong direction!" - unknown

              W 1 Reply Last reply
              0
              • R Roger Stoltz

                WernerP wrote:

                The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do.

                Read the link I provided in my previous post and you will find that you cannot force the compiler to do inline expansion, not even with __forceinline. The "implicit inline" your talking about must be the "/Ob2" compiler setting, thus if you're not compiling your code with that option, there won't be any "implicit inline".

                "It's supposed to be hard, otherwise anybody could do it!" - selfquote
                "High speed never compensates for wrong direction!" - unknown

                W Offline
                W Offline
                WernerP
                wrote on last edited by
                #15

                I will do that. Thank you. Maybe I misunderstood the definition of implicit inline? I understood, that if a function is defined like that

                class A
                {
                void someFunc()
                {
                // code
                }
                }

                this is equivalent to

                inline void A::someFunc()
                {
                // code
                }

                and I want it to be equivalent just to

                void A::someFunc()
                {
                // code
                }

                Best regards Werner

                1 Reply Last reply
                0
                • W WernerP

                  Roger Stoltz wrote:

                  find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... Confused Unsure

                  In the second I *want* it to be automatic. That's my point. The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off. Regards Werner

                  R Offline
                  R Offline
                  Rajesh R Subramanian
                  wrote on last edited by
                  #16

                  WernerP wrote:

                  The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off.

                  Marking something as inline (while you think it would be beneficial) may turn out to be expensive too (well, with certain cases). So, the best way is to let the compiler do the dirty work for you. I am believing that I can never outsmart the compiler on making such a decision. With the default settings, the compiler won't inline any function automatically. BTW - Instead of the switch, the #pragma directive would give you greater flexibility on where to impose the restriction, in case you need it. [Added] BTW - if that is you who has low-voted this post of mine, please do let me know what is that you feel so bad about it. :)

                  Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]

                  modified on Tuesday, October 14, 2008 11:29 AM

                  W 1 Reply Last reply
                  0
                  • R Rajesh R Subramanian

                    WernerP wrote:

                    The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off.

                    Marking something as inline (while you think it would be beneficial) may turn out to be expensive too (well, with certain cases). So, the best way is to let the compiler do the dirty work for you. I am believing that I can never outsmart the compiler on making such a decision. With the default settings, the compiler won't inline any function automatically. BTW - Instead of the switch, the #pragma directive would give you greater flexibility on where to impose the restriction, in case you need it. [Added] BTW - if that is you who has low-voted this post of mine, please do let me know what is that you feel so bad about it. :)

                    Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]

                    modified on Tuesday, October 14, 2008 11:29 AM

                    W Offline
                    W Offline
                    WernerP
                    wrote on last edited by
                    #17

                    Dear Rajesh, I am very sorry, this happened automatically because in Germany marks at school are like that 1 = best, 6 = worst. I still can't get rid of that. Thank you very much and best regards Werner

                    R 1 Reply Last reply
                    0
                    • W WernerP

                      Dear Rajesh, I am very sorry, this happened automatically because in Germany marks at school are like that 1 = best, 6 = worst. I still can't get rid of that. Thank you very much and best regards Werner

                      R Offline
                      R Offline
                      Rajesh R Subramanian
                      wrote on last edited by
                      #18

                      WernerP wrote:

                      I am very sorry, this happened automatically because in Germany marks at school are like that 1 = best, 6 = worst. I still can't get rid of that.

                      Thanks for the explanation. It is times like this when I realise CP is a truly global community. :)

                      Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche .·´¯`·->Rajesh<-·´¯`·. [Microsoft MVP - Visual C++]

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups