Incidentally, you may be interested in the Constrained Value library (http://student.agh.edu.pl/~kawulak/constrained_value/index.html)
I like that idea.
I quite like the idea of things like an 8bit number that stores values between 0 and 1.
I like the idea of a number type, that can store numbers in all sorts of forms, an example could be a "8bit integer / 8bit integer" or "4bit float" or whatever, you could instruct it with methods to do things such as. Have a scale defining it's limits and possibly also set limits, store 2 numbers in 3 bits. Store a value in a number of forms so that it is always quick to access for different uses or have it store it in the most specially efficient form for the value, have a number that expanded until a certain number of decimal places was reached, or forever, or all sorts of other related things.
I have some idea about a possible way to represent the expandable number in binary as well.
At least in C++ I would expect this to have such a performance overhead as to make it not worth it even trying to implement though, I guess I don't much like lexical casting automatically or using the cast syntax, prefer .toString() type methods, but especially between numerical types where it seems like it's always about fundamentally the same thing, a number.
> I do appreciate there are different views here, however if one has
> chosen boost::any already then they already know what they want,
> especially given the stuff in std. Suggesting that because you can
> cause an error an error could unexpectedly occur when you pass
> unknown objects into an unknown method in a non sensible example
> that wouldn't happen isn't helpful.
You have to appreciate where we are coming from. Your original post had code where you tried to pass the result of a runtime method as a template parameter.
This suggests you are not hugely familiar with C++ and perhaps Boost.Any, so people naturally ponder whether Boost.Any really is the right choice (often it isn't) and try to help by making sure the OP has heard about the alternatives.
Your right, I am fairly new to C++.
> The documentation says that for boost::any a program doesn't crash
> if you try and cast an any into a type it was not set as, it gives a
> null instead.
Actually, If try to retrieve a pointer to the type, it would return a null, if you tried to retrieve a value, it would throw bad_any_cast.
Thanks.
> For crashing on stream insertion when it's contents can't be
> inserted vs giving an error that will stop the program more safely
> and tell the coder what went wrong, I think the latter is more
> desirable, unless there is a significant performance difference in
> which case either one is valid.
Right, if you went down a has_operator_stream route, you could throw an exception instead of blowing the stack.
Feel free to offer a patch along those lines if you want, but it opens up a can worms. If operator<<, why not operator+, or member foo() etc... I am sceptical that the maintainer would accept it.
Does adobe::polly offer a way to call methods on the anys content without unwrapping it? Could this be done generically for any method (I know there would be type/method safety issues)?
I'm using Peters version. My stuff is ambitious but higher level, I can't write things like this.
It would possibly make a good case to have two versions of boost::any if the generic methods could be implemented, would also close the can of worms, nothing would ever need to be added to it again.
Maybe I have overlooked that a stream and other such things are probably not proper methods at any level and so there are a few worms, but a finite number.