All valid points. I like Gil as well. Unfortunately, it hasnt been updatted or enhanced in a long time. (correctly if I'm wrong) Not saying that it needs to be. Its pretty solid. This unfortunately kinda relates to alot of the other points made here this morning Who owns GIL now? Does boost? Can we change it without talking to the adobe developers. Do we need to consult with them? I would say no, but thats my opinion. As I see it, the boost community now owns the code, and can modify as the community sees fit. See Johnothan's library. He should be able to add his enhacements with only mild consideration from the original developers. On Wed, Mar 24, 2010 at 2:17 PM, Fabio Fracassi <f.fracassi@gmx.net> wrote:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost