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
