At Sunday 2005-04-17 11:09, you wrote:
In-Reply-To: <6.2.0.14.2.20050417091210.0840a328@mail.rudbek.com> vawjr@rudbek.com (Victor A. Wagner Jr.) wrote (abridged):
The shear size of boost bothers me in that I don't want to burden my source code control system unnecessarily.
21 meg isn't that much (for the headers)
Actually it's quite a lot. This is a "new tool" issue - once any new tool is incorporated into the code, we have to keep it around for ever, even if it proves useless and we stop using it 6 months later. It's a barrier to entry, and it would be a lower barrier if boost took 1 meg or 10k.
do you keep all versions of your compiler around forever?
Basically I am supporting the idea of splitting boost into a collection of small, independent packages.
I don't see how that will help, but if you do, feel free to do so, I'll regression test anything.
I don't know how big the subset I selected was, but it was probably nearer 10k. From memory it was operator.hpp, smart_ptr.hpp and static_assert.hpp, plus whatever they depend on (which I discovered by repeatedly attempting to compile).
I have no idea how much (size or number of files) of the boost library I use in any (or even all) of my projects that use boost. It's completely irrelevant to me and I'm not sure I see the relevance to anyone.
I didn't want to include anything I couldn't see an immediate use for.
a true forward looking point of view.
Instead I encouraged my colleagues to view the website and add anything they wanted from it. Nobody has yet done so, which I suppose weakens the claim that a small subset will lead to a bigger one.
The dependency issue bothers me too.
You'd seriously rather that people copy/paste code to reduce dependencies?
There's a trade-off. It depends on the size and complexity of the library code. For example, I once experimented with using operators.hpp to generate != from ==. The benefit seemed borderline. There is a hump involved in using 3rd party code, and for a one-line routine:
inline bool operator!=( const MyType &a, const MyType &b ) { return !(a == b); }
it hardly seems worth it. Operators.hpp has over 900 lines of code, full of #ifdef's for various compilers, templates and inheritance. To understand it you need to know about subtle language issues: for example how the inline "friend" generate non-member functions, or the nuances of the empty base class optimisation. The documentation is long and complicated. None of this can be understood at a glance, where-as the hand-written version above can.
actually you don't need to "understand it" to use it, anymore than you need to understand the workings of the transmission in the auto you drive.
I've had code break because a boost header somewhere redefined min and max.
where? when?
A few weeks ago. Probably using boost 1.31 - I'm not at work to check. I don't recall which header I #included. Probably shared_ptr.hpp.
I find it difficult to believe that min and or max got "redefined" such that they became unusable (I'm pretty sure it would have shown up in the regression testing. I recall no such incident).
the real problem is that MicroSloth [...] #define min and max as a result of using windows.h !!!!
I know. The point remains. Experienced programmers know that using any 3rd partly library can introduce problems. Boost is no exception.
Experienced programmers know that using any code can introduce problems. This belief that "we're better than everyone else" is folly.
-- Dave Harris, Nottingham, UK.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"