Boost logo

Boost :

From: Nicolas Fleury (nfleury_at_[hidden])
Date: 2003-06-21 13:00:29

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

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

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.


> 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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at