Boost logo

Boost :

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: David Bergman (David.Bergman_at_[hidden])
Date: 2010-03-23 21:38:23


On Mar 23, 2010, at 9:22 PM, Tom Brinkman wrote:

>>> but does that force us to constantly send that raw pointer around?
>
> Yes, and it also has to be aligned. The buffer must be carefully crafted
> with considerable attention to caching issues.
>
> I kid you not, but I have seen some wild stuff.
>
> I've worked on the Larabee platform, which is the next generation discrete
> graphics card from intel. It has a 512K buffer, which means that you will
> be able to simultaneously process 16 floats. When you combine this with the
> parallelism possibilities on the next Nahalem processor (8 cores, 16
> threads), you will be able to achieve processing speeds thousands of times
> faster then non-hardware optimized code.
>
> Unfortunately, to take advantage of this, you will need to manage the memory
> yourself, which requires lots of old fashioned straight "C" style coding.

Really? One can do a lot of C++-neat things with POD's. And, just ridding the virtual table goes pretty far.

As someone else pointed out, with C++ and proper meta-programming tricks, one can even achieve optimal structure alignments for differing platforms with *one* codebase, which is pretty hard to do in C.

Well, this is definitely leading away from the initial problem, where you think that (at least certain) Boost libraries should have a C interface. Would be cool to get back on topic (partly my bad...) and see what libraries you want to change to a more Cish appearance and how that would look. We have heard about (s)printf, but that function already exists to a C++ developer ;-)

/David

>
>
>
> On Tue, Mar 23, 2010 at 4:54 PM, David Bergman <
> David.Bergman_at_[hidden]> wrote:
>
>> On Mar 23, 2010, at 7:40 PM, Tom Brinkman wrote:
>>
>>>>> To you. There are many graphics shops that make extensive use of c++
>>> *and* boost.
>>>
>>> Not true. Sure, we use C++ around the edges. The actual graphics code
>> is
>>> all done in C. There are no popular C++ graphics libraries. Sorry. Its
>>> not possible, graphics libraries require hardware acceleartion.
>>
>> I never understood this idea that some libraries were not possible to build
>> in C++. And, specifically, what graphics hardware acceleration has to do
>> with C++(-specific) constructs. Are there intrinsic inefficiencies of C++
>> constructs (beside one indirection by virtual functions where they are
>> used)? Is it something else? Yes, most low-level API's require a pointer to
>> a memory area in the end, but does that force us to constantly send that raw
>> pointer around?
>>
>> /David
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk