Thanks a lot, you finally gave me, what I had been asking for.
That's a golden option. I love g++
Thanks a lot, you finally gave me, what I had been asking for.
That's a golden option. I love g++
Actually, matsp gave you several suggestions in post #5 ("The don't inline this way is to put the function in a different source file. Or call it through a function pointer. Or use some compiler option to say "don't inline".") and I elaborated on his last suggestion in post #9, but apparently you did not read the documentation I linked to.Thanks a lot, you finally gave me, what I had been asking for.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
laserlight: I would read that later, since i thought you were giving me information regarding optimizations. Thanks.
Mats: You are a programming master! How the hell you know everything?
Inlining _IS_ an optimization - it will reduce the overhead of calling the function by stuffing it inside the code.
I wish I _could_ know EVERYTHING. I don't think ANY person knows EVERYTHING about programming, although I know (of) a few people who know a huge amount.Mats: You are a programming master! How the hell you know everything?
--
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.
Why are you a Kernel Hacker?
Is kernel hacking fun? What exactly does it mean? Can you (or have done already) hack Vista also?
I use the term Hacker in it's original meaning - someone who understands and works inside the kernel of the OS (same meaning as for example Linus Torvalds would be considered a Kernel Hacker). I have worked on Windows graphics drivers, which are kernel drivers. I have worked on the Xen virtualization project, which is "super-kernel" (as in, manage multiple OS kernels running concurrently in the same machine - so you can have Windows and Linux running at exactly the same time on separate cores, or sharing the same core just like applications do inside Windows or Linux).
Edit: And yes, working on kernel code _IS_ fun - in the same way as riding a motorbike is more fun than driving a car - there's a bit more danger, but when you do it right, it's so much more rewarding.
--
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.
Don't use -fno-default-inline. Just use -Os, and let the compiler handle this stuff. Really. -Os means optimize for code size, so the compiler will not use optimizations that increase performance at the cost of code size. This includes the inlining heuristics - at -Os, newer GCCs will only make the early-inlining pass, the one that inlines functions smaller than the call overhead. (Older GCCs - pre 4.1, I think - don't have an early-inlining pass, but the effect is still similar, I think.)
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
This obviously depends on what you want to achieve. -Os produces the smallest possible code, which may well inline a fairly large function if it's only called once. -fno-default-inline does--Do not make member functions inline by default merely because they are defined inside the class scope (C++ only). Otherwise, when you specify -O, member functions defined inside class scope are compiled inline by default; i.e., you don't need to add `inline' in front of the member function name.
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.
Yes, indeed. Of course, making the smallest possible code is a sensible goal. Not inlining functions because you don't like inlining is not.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Thanks CornedBee. I should have been thinking on this track. Its better to use -Os.
Another golden option!
Agreed - there is one exception: When debugging optimized code [where the non-optimized code isn't showing the problem for some reason], and you want to set a breakpoint in some small function - the inliner will potentially inline this, which means that the breakpoint is non-functional.
--
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.
Depends on how well the debugger copes with compiler transformations, and how well the compiler documents them. In optimized code, there's more things to worry about, like split statements, coalesced statements, statements completely computed at compile time, and so on.
Or you have screwed-up behaviour even with debug builds. For example, if you set a breakpoint to a code line in gdb, and that code line is in a template implementation, the breakpoint is set for one of the instantiations, and you have neither clue nor control over which one that is.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Hi,
are you sure this is a good idea? AFAIK putting implementation in header files is a time bomb, because it may lead to linker errors in the future (if the header suddenly gets included in more than one compilation unit and this units gets linked together after compilation - or better don't get linked, because of multiple definition error). Of course it will work, if the function actually gets inlined (because then no definition is involved). But if the compiler decides it doesn't, the problem will emerge I guess.
A related question would be: Does the inline keyword even suggest the compiler to inline, if the implementation is given outside the header file? There do I have to put the keyword then, in the header/decleration, in the .cpp/implementation or both?
Thank you!
Most modern compilers (such as gcc and MS VC++) in default settings completely ignore "inline" as a keyword when it comes to what to inline and what to not inline. I know MSVC has a switch to say "inline by inline keyword only", but it's not the default setting.
However, if you put functions in a header file, they should be marked static, or part of a class.
--
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.