Re: [boost] Flow-based programming library for Boost?

Subject: Re: [boost] Flow-based programming library for Boost?
From: Marcus Tomlinson (themarcustomlinson_at_[hidden])
Date: 2012-12-09 02:33:42

Hi Joel, thanks for your time! (Again) :)

Funny story about safe pointers... I originally used safe pointers instead of standard pointers, but eventually removed them due to the performance hit was inducing. Admittedly though, I was using a reference counting pointer that was causing a bottle neck due to thread safety critical sections. I will definitely look into using another safe pointer implementation that comes closer to mirroring the performance of a standard pointer.

Components do store their own names, perhaps I didn't make this clear. The circuit requires the component to have a name before being added to the circuit, passing the name into the AddComponent() method invokes a just-in-time call to that component's SetName() method as to ensure it has a name on entering the component collection. I will try make this clearer in documentation.

In terms of why components should have names in a circuit: Where this becomes very useful is in serialization / deserialization. With this in place, you could serialize / deserialize an entire circuit to and from a single self-contained circuit object (e.g. Via a factory). Similarly, a circuit can be passed around by reference on its own, giving receivers access to all circuit components via their IDs rather than having to manage both circuit and component references everywhere.

By a static version of the system do you mean compile-time circuit configuration? I've mentioned before that I am interested to explore this avenue but run-time wiring was chosen by design. DSPatch is designed to be very run-time oriented, allowing manipulation of circuits while they're live. I saw a system like this as more useful personally, as you have a the choice of static / dynamic circuits via one interface.

Inheritance is a major part of how this library works, so I can't really tell you how I would do it without at the moment. But it is a valid point. Removing the need to inherit could make the system a more flexible. Inheritance is not uncommon though in a system like this, VST plugins are an example.

On 09 Dec 2012, at 2:52 AM, Klaim - Joël Lamotte <mjklaim_at_[hidden]> wrote:

> I took a second quick look before going to bed:
> 
> 4. why can't the component contain their id/name?
> 5. is it really necessary to have id/component name?
> 6. how do you plan to allow a static version of such system?
> 7. could it be done without inheritance? what would be the tradoff then?
> 
> Joel Lamotte
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost