|
Boost : |
From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-09 03:19:48
In message <LPBBLOEIMCKBCMMHJMGAKEOOCGAA.jeff_at_[hidden]>,
Jeff Garland <jeff_at_[hidden]> writes
>Congrats for solving a recurring problem in C++ in a simple and elegant
>fashion. This will be a nice addition to boost (no voting now...it's a
>landslide).
Thanks!
>I have 3 minor suggestions:
>1) Add a throw specification to any_cast.
Unfortunately this would not be wise: Although it clearly throws
bad_any_cast in the event of a failed conversion, it might also throw on
copy construction of the result -- we cannot know in advance of time
what it might throw (eg std::string could throw bad_alloc and foo could
throw bar).
>2) A section on performance in the documentation. You hint at this in the
>write-up, but some explicit notes would be nice.
Not even sure I hint at it! Yes, a brief mention of complexities and
memory usage wouldn't go amiss.
>3) I agree with the removal of operator void*. It is evil....
The road to hell is paved with good (goofed?) intentions. I am normally
dead against UDCs because of the many issues they raise. In this case I
thought I had the issues covered... I thought wrong :->
>Here's a rather obvious alternative to your property example.
>
> std::map<std::string, boost::any> properties;
>
> int i = 10;
> double d = 100.1;
> std::string s = "mystring";
>
> properties["prop1"] = boost::any(i);
> properties["prop2"] = boost::any(d);
> properties["prop3"] = boost::any(std::string("some_string"));
>
> boost::any aProperty = properties.find("prop1")->second;
Thanks. This is more involved (and less rushed :->) than the rather
declarative property example I currently have. However, I will drop the
explicit conversions.
Kevlin
____________________________________________________________
Kevlin Henney phone: +44 117 942 2990
Curbralan Limited mobile: +44 7801 073 508
mailto:kevlin_at_[hidden] fax: +44 870 052 2289
http://www.curbralan.com
____________________________________________________________
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk