Dear Nicolas,

  sorry for the late reply. Some other projects try to keep me busy.

  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.

  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.

  Let me explain this point using your "sum" example:

    concrete_value<int>  i(4), j(6);
    sum_value<int>  sum(i, j);  // sum now equal to 10

    i = 6;  // sum now equal to 12

  Yeah, right, sum is 12 now - but who cares? It might be 13 or 14
  or 2893457923 - you wouldn't notice the difference only until the
  value of sum is actually fetched. Oh wait, somebody did just that
  some lines later:

    sumsum = 2 * sum;

  Only here the value of sum gets visible to the outer world, and only
  here there is any need to re-calculate its value - a technique called
  "lazy evaluation" (for obvious reasons).

  If you intend to follow that path - lazy evaluated values - what
  you are really doing is symbolic math: forming expressions out
  of operators (+, -, ==) and variables (i, j, sum) which might or
  might *not* represent a numeric value.

  Most major mathematical software distributions work in just that
  way and allow you to do something like this:

    sum = i + j;  // sum evaluates to i + j, because neither i nor j are
                  //     yet bound to a numerical value

    i = 6;        // sum evaluates to 6 + j
    j = pi;       // sum evaluates to 6 + pi, or 9.14159.

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


  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.

  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.


  - Roland


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