Results 1 to 10 of 10

Thread: inlining and optimations when instantiating templates

  1. #1

    Thread Starter
    transcendental analytic kedaman's Avatar
    Join Date
    Mar 2000
    Location
    0x002F2EA8
    Posts
    7,221

    inlining and optimations when instantiating templates

    will
    Code:
    if (0)
      do stuff a;
    else
      do stuff b;
    compile to
    Code:
      do stuff b;
    ?

    also, as this is in a template, will the instance have to support functions specified in "do stuff b", in case 0 is evaluated above, as a result of the template parameters, by calling an inline function on them, say:
    Code:
    if (GetVal())
      do stuff a;
    else
      do stuff b;
    for:
    Code:
    template <class x, class y>
    class Stick{
    public:
      inline bool GetVal(){return a.GetVal() || b.GetVal();}
      .
      .
      .
    private:
      x a;
      y b;
    }
    Stick template is used recursively, upto about 8 times, but will that be a problem for inlining?
    Use
    writing software in C++ is like driving rivets into steel beam with a toothpick.
    writing haskell makes your life easier:
    reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
    To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.

  2. #2
    Frenzied Member HarryW's Avatar
    Join Date
    Jan 2000
    Location
    Heiho no michi
    Posts
    1,827
    Any instances of templates 'things' (classes, functions, structs, whatever you can make a template of) are translated early on in compilation into a set of equivalent 'things', one for each different use of the template you have specified. So if you want to consider optimisations, you should remember that your template class will be split up into several normal classes, one for each different combination of the classes x and y you use.

    Anything that is done recursively will probably not get inlined, whether you specify it as inline or not. Some compilers are very fussy about what they will and will not inline, particularly Microsoft's VC++ compiler, which likes to think it knows better than you. Just like all their other products....

    There are some preprocessor directives you can use to help enforce your will on different compilers, usually using the #pragma directive which is compiler-specific.

    AFAIK anything that always evaluates to false will just get treated as a constant value of false if/when the compiler optimises it, but they're strange things, compilers, so I couldn't say for sure.
    Harry.

    "From one thing, know ten thousand things."

  3. #3

    Thread Starter
    transcendental analytic kedaman's Avatar
    Join Date
    Mar 2000
    Location
    0x002F2EA8
    Posts
    7,221

    Not that kind of recursion

    I was thinking more like template recursion:
    Stick<a,Stick<b,Stick<c> > >
    I saw an article on flipcode.com which mentioned three pragma's you could add to prevent VC++ to get fussy about inlining, but would this form of recursion prevent it?

    The thing is that i can't put precompiler #ifdefs to determine what the instances should contain, but they are templates right, and they don't instantiate what isn't unneeded? The problem I have is that for a class to be a valid template parameter, it has to have the methods used on it in the template, but i have methods both in "do stuff a" and "do stuff b" that should not be together in the same instance. Will the compiler be smart enough to remove the code of either a or b and not complain about the class parameter not fitting the way it is used?
    Use
    writing software in C++ is like driving rivets into steel beam with a toothpick.
    writing haskell makes your life easier:
    reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
    To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.

  4. #4
    Monday Morning Lunatic parksie's Avatar
    Join Date
    Mar 2000
    Location
    Mashin' on the motorway
    Posts
    8,169
    Methods that aren't required by a specific instantiation are not provided with code.
    I refuse to tie my hands behind my back and hear somebody say "Bend Over, Boy, Because You Have It Coming To You".
    -- Linus Torvalds

  5. #5
    Frenzied Member HarryW's Avatar
    Join Date
    Jan 2000
    Location
    Heiho no michi
    Posts
    1,827
    Uhm.... Maybe they could inherit from a base class that had trivial definitions of the unnecessary functions (just return 0 or something), and the subclasses could override them with more useful local definitions of the functions that would be needed.

    Stick<a,Stick<b,Stick<c> > > isn't really what I would call recursion, but I see what you mean. I think maybe the best way to find out if your compiler is optimising it the way you would like would be to write a simple example (I mean really simple) and look at the assembly code that it produces. You'd have to look at a non-Windows app though to avoid all the console code.

    There was a good article on templates and optimisations at Flipcode a while ago, aimed at efficient matrix calculations. That might be the one you were thinking of earlier, but if not check it out.
    Harry.

    "From one thing, know ten thousand things."

  6. #6

    Thread Starter
    transcendental analytic kedaman's Avatar
    Join Date
    Mar 2000
    Location
    0x002F2EA8
    Posts
    7,221
    Uhm.... Maybe they could inherit from a base class that had trivial definitions of the unnecessary functions (just return 0 or something), and the subclasses could override them with more useful local definitions of the functions that would be needed.
    virtual functions would ruin it all, or would it? I'm almost certain the methods won't inline if they are virtual.

    The page i was talking about was about vector math calculations, so i might have a look at the matrix one as well.

    I'll try testing some really simple templates, how do I get the asembly listings in VC++6?
    Use
    writing software in C++ is like driving rivets into steel beam with a toothpick.
    writing haskell makes your life easier:
    reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
    To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.

  7. #7
    Frenzied Member HarryW's Avatar
    Join Date
    Jan 2000
    Location
    Heiho no michi
    Posts
    1,827
    Well you can look at the source using any kind of disassembler. A lot of hex editors have built-in disassemblers. I expect you can view the assembly code in the VC++6 IDE if you try it.

    The only problem with that is that you might get lots of unwanted Windows code messing things up, making it unclear.

    Do the functions really need to be virtual? Been a while since I used C++ now, I'm more into Python at the moment.
    Harry.

    "From one thing, know ten thousand things."

  8. #8

    Thread Starter
    transcendental analytic kedaman's Avatar
    Join Date
    Mar 2000
    Location
    0x002F2EA8
    Posts
    7,221
    Do you have a hex editor with built in disasembler since that would be nice?
    if i want to override a function from a base class, i need the function to be virtual, if it's suppose to be called. I'm not quite sure but some compilers will inline and some not, if the base object pointer is known to be of the specific derived class under design time. In any case, I don't think that would help much, the functions i use for the different cases are not suppose to be in the same parameter class.

    of interest, what can you do with Python? I have a mapeditor for quake, halflife and some other similar games called quark (quake army knife) that runs on Python.
    Use
    writing software in C++ is like driving rivets into steel beam with a toothpick.
    writing haskell makes your life easier:
    reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
    To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.

  9. #9
    Frenzied Member HarryW's Avatar
    Join Date
    Jan 2000
    Location
    Heiho no michi
    Posts
    1,827
    Python is an object-oriented scripting language. I use it with Zope (www.zope.org , it's a dynamic webpage delivery type thing, open source and with lots of extendability) to make Zope Products at the moment. It's pretty cool. You can compile it to Java bytecode with the right compiler too

    Some games are scripted in Python, such as Severance. If you know Python you can add your own mods to the game using calls to the game engine, which is in a load of dlls I think.

    I don't have a hex editor that does it here, but a lot of supposed 'hacking tools' (or 'toolz' I guess) are actually just hex editors with a disassembler attached. SO you might want to search for them on www.astalavista.com or somewhere like that.
    Harry.

    "From one thing, know ten thousand things."

  10. #10

    Thread Starter
    transcendental analytic kedaman's Avatar
    Join Date
    Mar 2000
    Location
    0x002F2EA8
    Posts
    7,221
    ok, thanks for the suggestions Harry I'll have a look at Python sooner or later. If you develope a game using Python, does it mean everything runs on script? I mean, can I have the core implemented in C++ and then use Python so that the user can make mods to it?
    Use
    writing software in C++ is like driving rivets into steel beam with a toothpick.
    writing haskell makes your life easier:
    reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
    To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width