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:43:53

>> The C part in graphics/HPC programming is the equivalent of the "inline Assembler" of earlier days.

Here is were we probably disagree.  "C' coding is always going to be
important in graphics programming.  Its always going to be around in
the backround.  Most will want to wrap it, though, as they always
have.

In the future, hardware acceleration will be even more of an issue
than it has been, so stay tuned.  Lots of cool stuff coming your way
very soon.

IMO, you should just play it loose between the two worlds, "C" and
"C++".  Pick and choose what works for you, but keep in eye on what
the "C" guys are up to because they are doing some cool as shit.

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
>