
Roshan wrote:
On Mon, 03 May 2010 22:10:21 -0600, OvermindDL1
What kind of users do you want to preserv with a standalone library that will not use your library if it depends on Boost?
I agree, the size of the library matters not to me (as long as it compiles into very tight assembly, I do not care about compile times
As a library author, I deeply care when imposing such requirements on users. There was an earlier post of an existing user who expressed the desire to have it standalone. http://old.nabble.com/Re%3A--castor--Interest-in-Logic-Paradigm-for-C%2B%2B-...
Concern that Boost has become a giant hair ball of intertwined libraries is not limited to a few people. Bjarne mentioned this as the reason for not introducing Boost libraries to his students during a casual conversation at a conference. Introducing a massive library collection (for the sake of a tiny library) into a sophisticated source control/build environments of large corporations is a big deal. I am OK with introducing such coupling between libraries provided the benefits outweigh the costs to consumers of the library.
So it's a good idea to repeat functionality in more than one place? That is it's a good idea for castor to include equivalent functionality that already exists in boost. This effectively increases the total amount of code being dealt with rather than decreasing it. If a library (or any code) is simpler and smaller because it includes a lot of code all ready existent then shouldn't ALL code (including boost) copy in the functionality from all the libaries it uses. Basically, the idea that a library is simpler because it doesn't include other libraries doesn't make sense when carried to it's logical conclusion. If you really believe this, then you'll have to conclude that no one will want to use your library either. Of course if there is a specific problem with some boost libraries or boost libraries in particular, that's another issue entirely. And an interesting one. In my professional life, I often come accross programmers who shy away from boost libraries. They'll spend weeks (of their employer's time and money) to re-create some small functionality which is already in some library and could be included with just 2 days of study. Which is the problem. Boost libraries aspire to be more generic and that means a higher level of abstraction. This means that it takes a lot more effort to use the library than it first appears. The idea of a library makes it sound like "just drop it in" but then it turns out one has to spend a couple of days figuring it out and it seems easier just to "roll your own". Of course it isn't but that's not apparent even after the fact. Anyway. I'm very intrigued with this library idea. Robert Ramey