Re: [boost] But it would Re: [gil] [announcement] New IO lib
No, he's probably using a pre-compiled header. :-)
No, we generally dont use pre-compiled headers on UNIX. If at all. You must be using dev-studio on windows. The trend is for all "new" libraries to be header only, unless there is an overwhelming, and I mean absolutely overwhelming reason not too. Also, you should not have unecessary dependencies. The filesystem library is not a necessity in this case, and becouse the filesystem library is is not a header only library, it makes using it by other libraries very problematic.
On Sat, Apr 26, 2008 at 3:27 PM, Tom Brinkman <reportbase@gmail.com> wrote:
The trend is for all "new" libraries to be header only, unless there is an overwhelming, and I mean absolutely overwhelming reason not too.
<snip>
Can you please elaborate on what makes a non-header-only library so very problematic? Not to throw gas on the fire, but simply 'Not being "trendy"' is not a cogent argument. Thanks, Jon
Jon wrote:
I dont know about Tom, but I personally don't want to wast time building, linking, and then figuring out why the ABI's were not compatible if it is not necessary. Especially in boost code that often has to be 99% inlined because it is generic. (Hence no significant build-time speedups would be obtained anyhow) If all files were header only pages like this: http://www.boost.org/doc/libs/1_35_0/more/getting_started/unix-variants. html http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html would be a lot shorter :) BTW - I think pch is supported in g++ too, and I heard #pragma once is ok now too.. -- John -- John
On Sat, Apr 26, 2008 at 3:52 PM, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
So, is the crux of the argument then, that it just takes too much time for you to build boost for your platform(s) when a new version is released or you upgrade compilers? Jon
Jonathan Franklin wrote:
Unnecessarily spent time is only part of the issue. The other has a lot to do with configuration. It can be hard to get separately compiled libraries to play nice together, if one is compiled with different settings you can get some unexpected behavior or worse. If the library is all-headers then it is always compiled the same way as the rest of my code, and I like that. Please scroll through this list and check out how many people are talking about thing like 'problems linking boost on XXXXX'. -- wait, you wont have to scroll far will you :) Somebody just posted a new one! Cheers, -- John
On Sat, Apr 26, 2008 at 4:16 PM, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
So honestly, if I add up all the time that I spend building boost and configuring my various build environments (Solaris 10, Ubunty Gutsy, and Windows+vc8), and compare that to the amount of time I spend building my own code, I spend *way* more time compiling my own code. For me, the amount of time spent re-compiling things that could have gone into a pre-built library becomes very significant. I still much prefer pre-building code up front where possible. Please scroll through this list and check out how many people are
Yeah, shocking how many people don't know how to use their compiler+linker. ;-) Jon
Yeah, maybe, but boost should at least _try_ to be easy to for newbies as well as experts right? That would also help you by reducing the number of times you have to say RTFM ;-) I think that Tom's point was that gil is a 'generic' library and is all-headers (it must be, it is generic), so adding a feature that would require a _new_ depency on _another_ library, particularly one that has to be compiled, would be a big hassle. The feature had better be REAL important, or it should be ommitted. Expert or not, you have to agree that adding a new build dependancy is more of a hassle than not doing so. I dont think that the comment had to do with moving chunks of code from a '.cpp' file into a '.hpp' file, I think that would be silly (except maybe for the way Boost.Test does it optionally ...). -- John
On Sat, Apr 26, 2008 at 5:22 PM, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
Yes, of course. At least to the extent that other aspects of a library do not suffer unduly. Must always strike that balance, and this *is* a set of c++ libraries after all. I think that Tom's point was that gil is a 'generic' library and is
I think we're trying to agree on the meaning of 'big' and 'hassle' in this context. At least that was my goal. I hear people asserting that libs should be "header-only" to avoid major hassles, and was wondering why. Also, I'm not so bold as to assert that a generic piece of code should not use any other code that is not also generic. I'm also not suggesting that you were implying that either.
The feature had better be REAL important, or it should be ommitted.
This is of course totally subjective, based on your definition of 'big' and 'hassle' above. Expert or not, you have to agree
that adding a new build dependancy is more of a hassle than not doing so.
It certainly adds a new build dependency. ;-) I honestly don't personally consider adding -lboost_date_time<blah> to my link line to be a hassle of any magnitude. But that's me. I already have that lib built and in place. It may be much more of a "hassle" for others.
I agree. That would be quite silly, unless it really ought to have been that way in the first place. Jon
participants (3)
-
John Femiani -
Jonathan Franklin -
Tom Brinkman