Inline code in C++
Author
Hi All,
I've been working on a C++ library for some time, and have many inlined methods, often in their own *.inl files. One of our licensing models doesn't include sourcecode, but such inline methods ARE effectively sourcecode and would seem necessary for the distribution.
Is there any way I can avoid re-engineering the project if I do not want a library-only release to include such inlined information?
Best wishes,
Graham
If you want them to be inlined then the library user will need the code. I think your two options are:
1) Change the license to allow for the inlined code.
2) Disable inline for the restricted license. I would probably do this by #defining a PUBLIC_INLINE (or something) that would be 'inline' in your open licenses, and nothing for the closed license.
1) Change the license to allow for the inlined code.
2) Disable inline for the restricted license. I would probably do this by #defining a PUBLIC_INLINE (or something) that would be 'inline' in your open licenses, and nothing for the closed license.
No. You'll have to make them non-inline (inline is only a compiler hint anyway). Create an additional header with the function declarations and do compile your .inl file as if it were a normal C++ file (may require telling your compiler it really is a C++ file), using the preprocessor to eliminate the inline keywords (having an INLINE macro might help).
It can be considered 're-engineering', but as far as such things go, it shouldn't be a major problem.
Foo.h
Foo.inl
Your code should include "Foo.h" and never explicitely include "Foo.inl". If USE_INLINE_FUNCTIONS is not defined (or some other conditional compilation trick), "Foo.inl" won't be included and will have to be compiled separately. Add a suitable target to your project (or makefile) so that they do get compiled in. It should be possible to have the project also take care of #defineing USE_INLINE_FUNCTIONS when the suitable target is selected.
It can be considered 're-engineering', but as far as such things go, it shouldn't be a major problem.
Foo.h
int Foo();#ifdef USE_INLINE_FUNCTIONS# include "Foo.inl"#endifFoo.inl
#ifdef USE_INLINE_FUNCTIONS# define INLINE inline#else# define INLINE#endifINLINE int Foo(){ return 0;}#undef INLINEYour code should include "Foo.h" and never explicitely include "Foo.inl". If USE_INLINE_FUNCTIONS is not defined (or some other conditional compilation trick), "Foo.inl" won't be included and will have to be compiled separately. Add a suitable target to your project (or makefile) so that they do get compiled in. It should be possible to have the project also take care of #defineing USE_INLINE_FUNCTIONS when the suitable target is selected.
Quote:Original post by Graham11
Hi All,
I've been working on a C++ library for some time, and have many inlined methods, often in their own *.inl files. One of our licensing models doesn't include sourcecode, but such inline methods ARE effectively sourcecode and would seem necessary for the distribution.
Is there any way I can avoid re-engineering the project if I do not want a library-only release to include such inlined information?
Best wishes,
Graham
I assume it's an SDK and you deliver dll's; you still need the header files, isn't that technically source code? Can the .inl stuff be considered part of the headers then?
If you are putting so much stuff as inline that you are worried about people stealing it, you probably need to reconsider what functions *should* be inlined! Remember you end up losing benefit quickly as your inline functions grow. A good rule of thumb is that a function should only be inline if it is very short (dozen lines or less), and does not call other functions.
And if you are worried about someone figuring out how you do a vector add or whatever, then you are just being silly.
And if you are worried about someone figuring out how you do a vector add or whatever, then you are just being silly.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
