Roland Richter wrote:
>  Dear Nicolas,
>  
>   sorry for the late reply. Some other projects try to keep me busy.

And sorry for the late answer, I was in vacation

>   First, I'd like to mention that in German-speaking countries, EDV
>   is a very common acronym for "Elektronische Datenverarbeitung"
>   ("electronic data processing"), hence the library name might be
>   somewhat confusing.

Noted.  I'm rewriting the library with a much simpler interface and 
overloading operators instead of all these sum_, diff_, etc. values and 
I expect the name to make less sense in the end.

>   I think that your ideas lead into two rather different directions,
>   depending on whether these "event-driven" values
>     (a) actively update their related values whenever changed, or
>     (b) are passive and do nothing until their value is fetched.

Agree.  I'm interested in the a) for my part, since I want the use of 
these values in widgets, for example, to be passive.  I mean to never 
check for a change in a value, but instead connect a signal to a 
callback for each change.  With my (modest) experience, it's far less 
resource-consuming.

However, I think there's a place for the b) case, and the complicity 
between the two ways should be maximised.

>   [...]

I totalle agree with your examples, and that's the syntax I realized was 
the best few weeks after my post.

>   For a symbolic math package in C++, I'd point you to http://www.ginac.de

I'll take a look.  Thx.

>   I guess, however, that your main interest lies in variant (a),
>   "event-driven" (opposed to "lazy evaluated") values, that is, in
>   implementing some special form of the Subject/Observer pattern,
>   based on boost::signals.

Exactly.

>   For reasons I pointed out above, this would just make sense if your
>   main focus is *not* on updating other values, but on triggering some
>   action, like this:
>  
>     void print_me( int i )
>     {
>       std::cout << i << std::endl;
>     }
>  
>     value<int> i( 6, print_me );
>     i = 42;  // Prints 42 to stdout.
>  
>   In other words, value<Type> would be some type where construction,
>   assignment, and maybe destruction would call some signals. This might
>   include, but is not limited to, updating other values.

The current version have a signal for value change and destruction.  I 
could also add a signal for "redefinition" (or assignment).  The 
value-change signal minimizes the updates (I assume we are talking about 
the non-lazy values).  The shortcut of passing a callback directly in 
the constructor could be a good idea.

>   Such a class might indeed be helpful, because notifications often occur
>   if a value has changed; so this would simplify things. However, I doubt
>   whether it pays off to invent all those sum_, diff_, sync_, 
>  and_so_on_value's
>   in an "event-triggers-update-of-values" way.

I agree.  Some "stuff"_value remains for now, but could be removed also. 
  For example, the ostringstream_value:

ostringstream_value<std::string>  str;
value<int>  i(4), j(6);
str << i << " << " << j << " =>  " << (i << j) << '\n';

For now, it's simpler for me to have a subtype, but partial 
specializations or policies could also be used.

Regards,

Nicolas


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost