| T O P I C R E V I E W |
| MrDoomMaster |
Posted - Jan 29 2007 : 6:06:43 PM
Right now if I type an inline function prototype in a class and use "Create Implementation", the definition will be placed in the CPP file instead of the header.
It would be nice if visual assist would check for the "inline" keyword in the prototype and place the definition in the header file (just like it does with templates), and if it doesn't exist then it can be placed in the CPP file. |
| 9 L A T E S T R E P L I E S (Newest First) |
| sl@sh |
Posted - Feb 05 2007 : 04:20:10 AM
Interesting, I'm sure I read this, but maybe the documentation is out of date ;) |
| nikb |
Posted - Feb 04 2007 : 6:31:29 PM
quote:
Originally posted by sl@sh
Technically you're correct, but apparently - and I admit I wasn't aware of that myself until recently - the VS compiler is unable to inline a function whose implementation is not visible to the compilation unit.
Actually, that's not entirely accurate. The two last versions of the compiler can and do aggressively inline functions across compilations units when compiling with "Whole Program Optimization" enabled. |
| feline |
Posted - Jan 30 2007 : 2:23:04 PM
On a different front, #include "foo.cpp", I agree, a horrible idea, but it came up once when I was trying to work out why someone was using Move Implementation to Source File on a template function, and I was trying to work out how they got the code to compile.
You see some strange things if you hang around here long enough  |
| feline |
Posted - Jan 30 2007 : 2:21:21 PM
quote:
Originally posted by sl@sh
Technically you're correct, but apparently - and I admit I wasn't aware of that myself until recently - the VS compiler is unable to inline a function whose implementation is not visible to the compilation unit.
I did not know that, but it makes some sense once you have said it.
I have put in case for this:
case=4813 |
| MrDoomMaster |
Posted - Jan 30 2007 : 12:08:01 PM
Quite frankly I have to admit, I had no idea you were allowed to #include implementation files. This is quite disturbing and I agree with sl@sh- this makes my toenails curl as well. I don't agree that this is a suitable work around (my personal opinion).
I'm confident that most C++ programmers would agree that placing inline implementations in another compilation unit is wrong. Of course, it may *compile*, but this is in no way a valid excuse. Just because something compiles doesn't make it appropriate or correct; we all know this.
As for the INL files, you could go a little bit further with VAX to make it give the user a choice as to where inline function implementations are placed. In the options dialog, give the user the option of telling VAX to search for a corresponding .INL file and place the implementation there, or give them the option of placing it in the header. This would be a most desired solution and is most definitely possible.
I'm not very experienced in many compilers or platforms, but from my experience I know that inline functions have a 100% chance of *not* becoming inlined if they are not within the compilation unit of the prototype. Having said this, VAX not following this rule seems more like a BUG than a feature request. |
| sl@sh |
Posted - Jan 30 2007 : 08:29:34 AM
Technically you're correct, but apparently - and I admit I wasn't aware of that myself until recently - the VS compiler is unable to inline a function whose implementation is not visible to the compilation unit.
So yes, the compiler may inline functions that are implemented within the compilation unit itself.
But no, the compiler cannot inline a function that is implemented within another compilation unit and thus not visible to the unit you are compiling.
Since usually the purpose of defining a function inside a header is to share it with other compilation units, it is rarely (if ever) useful to put an inline function implementation into an implementation file, unless you intend to include it within the header.
You could of course #include the .cpp file in such cases, and in fact I have seen this done before - but if you ask me, whenever I see something like this, my toenails curl up.
I'd rather not have VA X ask the users to maintain such a practice. |
| feline |
Posted - Jan 30 2007 : 07:41:00 AM
Correct me if I am wrong here, but my understanding is as follows:
* an inline function can have its implementation placed into the cpp file and it will still compile quite happily
* the "inline" keyword is a suggestion to the compiler, which it is free to ignore if it wants to
* the compiler is free to "inline" functions that are not flagged as inline if it chooses to, as an optimisation technique
In contrast with template functions your program simply fails to compile once you actually use the template. You can get around this problem by using #include "foo.cpp" |
| sl@sh |
Posted - Jan 30 2007 : 07:27:30 AM
The suggestion still has merit: an inline function implementation inside a .cpp file will *not* compile the way it is intended to, so it will *always* have to be moved. If the Implementation is generated inside the header at least it will compile as intended, even though it might not be at the 'perfect' place in the eyes of some developers.
Better have a solution that is sometimes right than one that is always wrong. |
| feline |
Posted - Jan 30 2007 : 07:02:42 AM
I am slightly wary of this, since where you place your inline functions is a personal preference. Some people put these implementations into .inl files.
With template functions the code tends not to compile if the implementations are not available when the template is instantiated. |
