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;
}
valueint i( 6, print_me );
i = 42; // Prints 42 to stdout.
In other words, valueType 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_valuestd::string str;
valueint 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
