Jonathan Franklin wrote:
On Tue, Mar 23, 2010 at 10:06 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
Tom's observations are just that, observations. In my experience, they are correct. It doesn't mean that actionable proposals are practical or possible.
My experience turns out to be quite different. And that's fine. No single person represents the entire boost, let alone C/C++ developer community.
If no one has anything further to add that will actually benefit boost, then this thread should be ruthlessly abandoned. But thanks for sharing. ;-)
I think there is one thing. Tom charactarizes Libraries such as GIL or the aforementioned VSIPL++ as "just" a wrapper around C code. While in a certain sense this is true, IMVHO this also misses the point that Jonathan also raises, i.e. The C part in graphics/HPC programming is the equivalent of the "inline Assembler" of earlier days. That means that you use them when you have to, but wrap these code parts aggressively. Now to get the curve back to boost: I think that boosts great advantage is that it can help to develop *portable* wrappers of this kind. GIL is a great example btw, if I want to develop a wrapper around some OpenGL functionality I can use GIL as an abstraction for e.g. textures. I could of course develop my own abstraction (and have, too - but it would never get as good as a boost gil is) but I couldn't expect anyone outside my sphere of influence to use it. This is gets more important the higher I want to raise the abstraction, because there are more smaller abstractions I have to use (e.g. any, variant, shared_ptr, or ...) This is also why I disagree with point 3 of Toms observations, because IMVHO it is a great boon to know that I have *all* the small boost tools at my disposal, and that it becomes fairly automatic that programmers use the boost version instead of rolling their own, or even go hunting for something else. Regards, Fabio