Re: [boost] 5 Observations - My experience with the boost libraries

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Tom Brinkman (reportbase2007_at_[hidden])
Date: 2010-03-24 17:38:05

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_at_[hidden]> wrote:
> Jonathan Franklin wrote:
>>
>> On Tue, Mar 23, 2010 at 10:06 PM, Emil Dotchevski
>> <emildotchevski_at_[hidden]> 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
>