[LV2] Thoughts on a clearer atom forge API

[David Robillard]

On Sun, 2014-01-12 at 19:10 -0500, David Robillard wrote:
> However, a more fundamental problem is that I don't think it could work
> for nested containers, since the child parameter would be evaluated
> before the parent, and thus be appended before the parent.

Turns out a nested solution can work with C++11 variadic templates.  It
requires building objects on the stack rather than writing directly to
the forge, so this approach is less efficient than the forge.  However,
I think it should be possible to write code like:

forge.object(uris.my_Message,
             uris.my_intensity, 9000,
             uris.my_list, forge.list(1, 2, 3, 4));

=>

[]
    a my:Message ;
    my:intensity 9000 ;
    my:list (1, 2, 3, 4) .

The slightly odd thing here is that it invents an in-memory
representation for atoms that isn't actually atoms, and then you write
that object in one go.

I believe this is the only way to do a single-function API and support
nesting.  Without nesting, a direct-to-buffer approach could be used.
So, there's some overhead, but this is about as pretty as it gets.

Attached for the curious is some proof-of-concept code that implements
just a (heterogeneous) list, and printing.  The print_elem() function at
the top is analogous to writing to the port buffer (or wherever).  The
point is in main(), the rest is gory details.

-- 
dr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: atom.cpp
Type: text/x-c++src
Size: 1215 bytes
Desc: not available
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20140112/346e4676/attachment-0002.cpp>