Thread: inheritance and operator<<

  1. #31
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    It's still there, but the compiler can still refuse to inline even with the keyword. It will issue a warning instead.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #32
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    It's still there, but the compiler can still refuse to inline even with the keyword. It will issue a warning instead.
    Yes, of course. There are some types of functions that are "unsuitable" to inline - for example very large ones. I can't really think of any other scenarion where an ordinary function can't be inlined. Of course, virtual calls through the vtable won't ever be inlined, since the compiler don't know what is going on.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #33
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Any case where a pointer to the function is used can't be inlined.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  4. #34
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by King Mir View Post
    Any case where a pointer to the function is used can't be inlined.
    Yes, naturally.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #35
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    I've tested this fairly extensively with GCC 4.x. You can almost guarantee inlining by passing -finline-limit=9999999. The number refers to some unspecified "inline heuristic value", in other words, some goodness score the compiler computes when deciding whether to inline. By setting the value huge you can make it do it all the time.

    The definition of the heuristic value is not specified -- the man page describes it as an abstract measure of "function size," but I don't think it's quite that simple. It also seems to mix in certain complexity measures independently of function size. And the exact method probably changes from version to version of GCC.

    Of course, there are certain cases where the function simply can't be inlined no matter what you do.

    1. It's called through a pointer. In certain circumstances, the compiler can still optimize it away (if it's static, and the pointer call is stupidly trivial).
    2. It's recursive.
    3. It calls a function in some other module. The other module could potentially make a call back to the function itself, making it indirectly recursive and thus not inlineable.

  6. #36
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Quote Originally Posted by brewbuck View Post
    3. It calls a function in some other module. The other module could potentially make a call back to the function itself, making it indirectly recursive and thus not inlineable.
    Why does indirect recursion cause a problem?
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  7. #37
    Registered User
    Join Date
    May 2008
    Location
    Paris
    Posts
    248
    Why does indirect recursion cause a problem?
    Potentially excessive size of the object file?

  8. #38
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Why would the object file be bigger?

    As long as the other function isn't inline too, I don't see the problem. If the other function is in another module, then it can't be inline.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  9. #39
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by King Mir View Post
    Why would the object file be bigger?

    As long as the other function isn't inline too, I don't see the problem. If the other function is in another module, then it can't be inline.
    I think the compiler CAN inline a function that calls another (external) function, but it will need to keep the original function too, so if the function is also large, it's likely to NOT inline it.

    For recursion, I'm pretty sure it will inline constant level recursion (where at compile-time the compiler can decide the number of recursions), but it's obviously necessary to keep the original type of function around for the "don't know how many levels of recursion".

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #40
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Quote Originally Posted by matsp View Post
    I think the compiler CAN inline a function that calls another (external) function, but it will need to keep the original function too, so if the function is also large, it's likely to NOT inline it.
    Whether to inline a function is decided in each compilation unit independently. I don't see why a compilation unit would ever inline and also keep the original definition. It may mark in some way the inline expansion of a function, in case it needs to change it to non inline. But the definition would be used from a compilation unit that did not inline.
    For recursion, I'm pretty sure it will inline constant level recursion (where at compile-time the compiler can decide the number of recursions), but it's obviously necessary to keep the original type of function around for the "don't know how many levels of recursion".

    --
    Mats
    But it's indirect recursion. The number of recursions is determined by the non-inline function. For example:
    Code:
    inline int func1(int eg){
        return func2(eg);
    }
    
    int func2(eg){
        return eg?eg*func1(eg-1):1;
    }
    There should be no problem inlining func1, even though the number of recursions is unknown (as long as func2 is not inline too). A call to func1 would in this case simply be a call to func2. Func2 becomes directly recursive after inlining, but it's not inline itself, so that's not a problem.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. operator<< overload problem
    By stewie griffin in forum C++ Programming
    Replies: 5
    Last Post: 03-10-2009, 06:29 PM
  2. define operator<< for std::pair<string, int>
    By patiobarbecue in forum C++ Programming
    Replies: 2
    Last Post: 02-07-2009, 08:29 AM
  3. ostream operator<< () overload problems
    By jaybny in forum C++ Programming
    Replies: 2
    Last Post: 06-24-2006, 11:00 PM
  4. no match for 'operator<<' in.... Compile Problem!
    By njd in forum C++ Programming
    Replies: 5
    Last Post: 01-09-2006, 12:40 PM