Re: [boost] But it would Re: [gil] [announcement] New IO lib
Tom Brinkman wrote:
But it would introduce the dependency to boost::filesystem
That would be a show-stopper for shur. I definately could not use your IO library if it had a boost::filesystem dependency. PLEASE - keep it header only.
I have no interest in boost::filesystem or gil. Just trying to understand your requirement for being header-only: You *want* to compile the same code over and over rather than just once?
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>
and becouse the filesystem library is is not a header only library, it makes using it by other libraries very problematic.
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:
Tom Brinkman 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>
and becouse the filesystem library is is not a header only library, it makes using it by other libraries very problematic.
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.
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:
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.
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:
<JOHN.FEMIANI@asu.edu> 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.
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?
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:
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.
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
talking about thing like 'problems linking boost on XXXXX'. -- wait, you wont have to scroll far will you :) Somebody just posted a new one!
Yeah, shocking how many people don't know how to use their compiler+linker. ;-) Jon
Please scroll through this list and check out how many people are talking about things like 'problems linking boost on XXXXX'. -- wait, you wont have to scroll far will you :) Somebody just posted a new one!
Yeah, shocking how many people don't know how to use their compiler+linker. ;-)
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:
... 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 ;-)
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
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.
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 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 ...).
I agree. That would be quite silly, unless it really ought to have been that way in the first place. Jon
Jonathan Franklin wrote:
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.
Thanks, I definately did not intend to imply that at all, but I can see how it might be read that way (oops). -- John
participants (3)
-
John Femiani -
Jonathan Franklin -
Tom Brinkman