Inline functions

I am not aware of this but i will tell you that in 99% of cases inlining a functions makes absoluteley no difference to anything.

I would just ignore them.

Dave

Without any proof that such is the case, and/or other reliable sources stating that as well, I would say to ignore it. I've never had any trouble with inline functions, enums, and any mix of the two, nor have I ever heard of people having trouble with them, before now apparently.

I know only of one such problem with inlined functions: Inlining could make problems when being exported from dynamic libraries.

E.g. if inlining is used to grant fast access to a member, its compilation produces dependencies to the memory layout of an object outside the compilation unit of the object. If this unit is integrated into a dynamic library, you could no longer change the memory layout of the object's class without breaking clients outside the library. (The same thing may happen w/ public members, of course.) This is a problem if you could not force the clients to become re-compiled, e.g. because you aren't the author.

True, but could you name a case of that happening? If such was the case in something I was working on, I'd either drop the inline, or change it so that it called other functions instead of messing with memory layouts directly. I'm partial to the former, for 2 major reasons.

Firstly, if you are going to have it calling a bunch of wrapper functions, it will almost certainly be at least as slow as with the preformance hit that a CALL takes. Note that while I say slow, that's relative. Secondly, I would hazard to guess that if you're exporting something that will be so preformance critical that it really needs to be inlined so as not to suffer noteworthy slowdown, you have bigger problems, such as design. At least, that's my opinion.

In general though, I just make a point to never have something exported or otherwise available to other applications/modules be inlined. It's worked for me so far.

@SirLuthor: JohnsonGPS has indirectly asked for pitfalls in using inlined functions, and the mentioned stuff is the one coming to my mind. I've said neither "inlining is evil" nor "there is no solution of this problem", but only "be aware of this".

I think it is worth to point out possible pitfalls so whoever doesn't know about could avoid being trapped!

I'm aware of that, and I think it's great that someone knows a lot about this and wants to share the info to help others, I'm not criticizing that, nor making it seem like it wasn't a problem, I was just interested in where that could possible occur, for my own enlightenment. I'm still interested, I'd love to see an example of where that would realistically happen [smile]

I don't think that this problem is theoretical only. Thinking back to the days when I made my first dynamic libs I wasn't aware of such things like "guarantee that the code of deleting a dynamically allocated object is located in where its allocation is", and it never comes to my mind that it would be a problem at all. I personally _have_ developed classes not in mind to add them to a dynamic lib one day; later I was busy in reworking them.

This was the answer from a "human" point of view where such problems occur. Now follows a technical point of view:

The problem with such is that it may work for a long time, at least for oneself where the IDE takes care of re-compilation when needed, and one is working with the same compiler all the day, and ... but what happens if releasing a dynamic lib (e.g. a plug-in) to the public, so that the framework it is bound into is a different one? Say, the problem may pop up later due to compiler mismatch, build version mismatch, or something similar.

As long as one programs for fun those situations are inconvenient only, but if you program commercially (I do so) it becomes more than inconvenient.

Here is a direct discussion of this on msdn:
http://msdn2.microsoft.com/en-us/library/feffc7b5.aspx

Quote
"You should exercise care when providing imported inline functions because they can create the possibility of version conflicts. An inline function gets expanded into the application code; therefore, if you later rewrite the function, it does not get updated unless the application itself is recompiled. (Normally, DLL functions can be updated without rebuilding the applications that use them.)"

Happy coding

By "out-of-sync" he probably means that the compiler might not recompile all of the source files that it should when certain changes are made. There are times with some compilers that you need to do a rebuild-all because it either incorrectly didn't think it needed to recompile certain files, or because you mucked it up somehow, e.g. saving during the build.

It looks to me like the problem posted on that forum was perhaps a compiler bug. (but don't hold me to that)

I would strongly encourage the "If it aint broke, don't fix it!" methodology here!
If you must change it, don't do it by making little modifications. Do it by first fully understanding what the code does (not how it does it) and rewriting it from scratch to do exactly what you understand it was doing. Your code will be simpler of course. Then do extensive side-by-side testing to ensure that your code functions no worse than the original. 'Better' is fine, of course!

JohnsonGPS, I'm not sure what he is talking about. The enums might get out of sync if the build system doesn't work perfectly (where some of the files that depend on the enum or the inline function aren't recompiled if the enum or the inline function change). That really is not a good reason for not using inline functions though.

Also, his next post about the order of the enumerations being wrong is questionable, so maybe he just doesn't understand how enums work.