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@bergmangupta.com> 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