Inlining, second

It's interesting how extremely differently C and C++ handle their inline specifiers. In C++, if I remember correctly, I could inline everything and it got placed everywhere as I told it. In C you can only really inline inside the file where you defined inlined functions. You can try whatever you want, inlining only works well when doing it absolutely locally. The GCC manual mentions that inline definitions should be findable inside the same compilation unit where they should be used (I guess that means the same file after all include operations occured). You can't simply templateyfy a million of things you think are good for the program. In fact, your only option is to rely on GCC's optimization technology beeing smart enough enough to detect what would be better (aka functions calls vs. inline execution). After a while of playing with the assembler output, I noticed that almost all my functions ended up beeing inlined! Well, should I really worry about this stuff anymore? However, the two which GCC didn't inline were an allocation function (understandable, that's a hefty and not really lightweight process) and (strangely) a simple function for inserting a list element. I don't know exactly why, but it told me that it'd be too big in code and that it didn't inline it. Well, that's ok I think? I don't know know THAT much about how GCC detects it, but using the more direct approach and using functions to link list elements, it started not inlining those. It has probably something to do in in what translation unit this stuff was build. Inside the insertion function I use link too, so it probably inlined them cause they were in the same file. Can I somehow utilize that and mimic that all the time? Not sure... will probably test a bit around with it. However, I currently don't have a problem with that as it will mean I can simply put all critical things in a huge set of functions and here we go again. Let' see what GCC has to say more about it.

No comments: