[Soc-2013-dev] Soc-2013-dev Digest, Vol 3, Issue 22

[Alexandr Kuznetsov]

Hi Peter,

Yes, C++ is only for the rendering code.
I created the dependency graph structure which is passed to the 
rendering engine.
The only problem is effect data:
A strip's DNA has different effects and we have specific functions and 
special code for reading/writing them.
As it is now, I created effect_cpp class during run time for easy 
function overload. I will probably change back to C function pointers 
for effects then.

>
> a) have a C API which is as thin as possible
> b) most probably shouldn't have to touch DNA at all
> c) use a memory allocator that uses Guarded Alloc internally
>

a) We pass only the whole render structure, so yes
b) Render engine only reads DNA (like movie path), doesn't alter it
c) Guarded Alloc has a nice macro for c++ classes


Thank you for pointing out the other C++ code.

Thank you,
Alex



On 7/20/2013 7:39 AM, Peter Schlaile wrote:
> Hi Alex,
>
>> == Questions ==
>> What is the best way to store C++ class in DNA? Do I just include a
>> single structure into the class and then dump it to/from DNA?
> simple answer: you don't.
>
> The C++ code should only(!) be limited to the render engine and not
> extend to the rest of the code (all the strip / DNA manipulation etc.).
>
> These should be kept strictly in C.
>
> Please consider the C++ part as a completely seperate unit which should
>
> a) have a C API which is as thin as possible
> b) most probably shouldn't have to touch DNA at all
> c) use a memory allocator that uses Guarded Alloc internally
>
> Take a look, how Joerg did it with audaspace: he build a completely
> seperate C++ engine and wrote an additional C API for it.
>
> Or take a look at the new compositor: the C++-code only uses small parts
> of DNA *read only*. Most of the time, it's only using the same constants
> and ignores the structures completely.
>
> Holding to these principles will lead to cleaner code through a strict
> module / problem seperation:
>
> The render engine does exactly *one* thing and does that properly.
>
> TL;DR: please *don't* write a C++ wrapper around DNA / DNA manipulation.
> That's definitely nothing you should do (or anyone else will do in the
> near future).
>
> Regards,
> Peter
>
>