Signals and slots requiring linkage
Will boost signals and slots be moved to header files in the future? Isn't it a policy to keep libraries in header files, if possible, or is it up to the library authors? In http://lists.boost.org/Archives/boost/2003/08/50815.php, the possibility of adding a macro to boost/config.hpp, which basically would result in including .cpp-files from headers, is mentioned. Are there any plans of adding such a macro or is it a bad idea? Best Regards, Johan Torp
On May 18, 2007, at 6:02 AM, Johan Torp wrote:
Will boost signals and slots be moved to header files in the future?
I have no plans to do this. There is quite a bit of non-template code, and it would be a shame to inline it all. Binaries would get significantly bigger, I think.
Isn't it a policy to keep libraries in header files, if possible, or is it up to the library authors?
No, this isn't a Boost policy. Many Boost libraries are entirely template libraries, so all of their code goes into headers anyway.
In http://lists.boost.org/Archives/boost/2003/08/50815.php, the possibility of adding a macro to boost/config.hpp, which basically would result in including .cpp-files from headers, is mentioned. Are there any plans of adding such a macro or is it a bad idea?
I think it's a bad idea, because of the binary size issue above. Is there any particular reason why you'd like Signals to live entirely in headers? - Doug
On Friday 18 May 2007 14:02:18 Johan Torp wrote:
Will boost signals and slots be moved to header files in the future?
Isn't it a policy to keep libraries in header files, if possible, or is it up to the library authors?
In http://lists.boost.org/Archives/boost/2003/08/50815.php, the possibility of adding a macro to boost/config.hpp, which basically would result in including .cpp-files from headers, is mentioned. Are there any plans of adding such a macro or is it a bad idea?
Doing that would effectively declare all code inline, possibly causing massive code bloat and compile time increase. I don't think its a good idea. Attached is a file. Copy it to the boost/signals folder and include it from exactly one translation unit of your program. All it does is make an on-demand compiled, statically linked library. BTW: I have the same for Boost.Thread here, though it requires a patch to one file, and intend to attempt the same for other libraries requiring linking, too. HTH Uli
Ulrich Eckhardt wrote:
Doing that would effectively declare all code inline, possibly causing massive code bloat and compile time increase. I don't think its a good idea.
Attached is a file. Copy it to the boost/signals folder and include it from exactly one translation unit of your program. All it does is make an on-demand compiled, statically linked library.
BTW: I have the same for Boost.Thread here, though it requires a patch to one file, and intend to attempt the same for other libraries requiring linking, too.
HTH
Uli
Please excuse what must be my ignorance. Why are people so opposed to using the linker and static libraries? Best regards - -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Friday 18 May 2007 22:39:49 Michael Caisse wrote:
Ulrich Eckhardt wrote:
Doing that would effectively declare all code inline, possibly causing massive code bloat and compile time increase. I don't think its a good idea.
Attached is a file. Copy it to the boost/signals folder and include it from exactly one translation unit of your program. All it does is make an on-demand compiled, statically linked library.
BTW: I have the same for Boost.Thread here, though it requires a patch to one file, and intend to attempt the same for other libraries requiring linking, too.
HTH
Uli
Please excuse what must be my ignorance. Why are people so opposed to using the linker and static libraries?
I'm not opposed to it, but it presents additional overhead. Consider my case, I'm developing STLport and using it, so that makes one stable version and a development version and for each a debug, a release and a diagnostic build. Then, I might have the same case with Boost. Further, I have a handful of targets/compilers. Lastly, I might be playing with different compiler settings. All these variations are multipliers(!!!) for the number of e.g. Boost libraries I would have to compile, and that is enough reason for me to use above way of linking. As far as your specific mentioning of static libraries is concerned, I'd say this method has the advantage of automatically adapting to the compile environment. When put into a seldom-changed file, the recompilation overhead is negligible. BTW: I also use compiled DLLs in released binaries. However, compiling in-place is way easier if you have nonstandard variations or just want to hack a quick example on a computer that doesnt't have any libraries installed. All ways have their advantages and disadvantages, this one just offers another choice. Uli
On 5/18/07, Ulrich Eckhardt <doomster@knuut.de> wrote:
Attached is a file. Copy it to the boost/signals folder and include it from exactly one translation unit of your program. All it does is make an on-demand compiled, statically linked library.
<link_inplace.hpp>
That's an interesting solution. Better than having boost optionally include code into the headers via #ifdefs (which I've heard suggested). IMO, at least. Now, why not just make it a cpp that I build directly (or drop into my IDE project directly) instead of an hpp that I need to #include into a (probably) otherwise blank cpp of my own? like signal_inplace_all.cpp or something like that. Not sure if that's any better, but it might avoid the concerns about including link_inplace.hpp twice. Tony
On Friday 18 May 2007 23:27:21 Gottlob Frege wrote:
On 5/18/07, Ulrich Eckhardt <doomster@knuut.de> wrote:
Attached is a file. Copy it to the boost/signals folder and include it from exactly one translation unit of your program. All it does is make an on-demand compiled, statically linked library.
<link_inplace.hpp>
That's an interesting solution. Better than having boost optionally include code into the headers via #ifdefs (which I've heard suggested). IMO, at least.
Now, why not just make it a cpp that I build directly (or drop into my IDE project directly) instead of an hpp that I need to #include into a (probably) otherwise blank cpp of my own?
It's a controversial thing. For one thing, I'd like to name it link_inplace.cpp, but it might feel strange to some people to #include a .cpp file. On the other hand, including code by including a .hpp file and only being allowed to do that once is also strange. I'm also thinking about naming it compile_inplace.cpp/hpp, I'm not yet sure how to name this technique. Now, as far as including it in your project goes, I'd say go ahead. I guess naming it .cpp would make that easier though... point is noted. However: if you create a dedicated file that only includes it that would be even better. The reason is that this file doesn't have to be adapted if you switch to a new Boost version, all you need to do is switch the include path you give your compiler. Uli
participants (5)
-
Douglas Gregor -
Gottlob Frege -
Johan Torp -
Michael Caisse -
Ulrich Eckhardt