and because it is an any he has no means of
knowing for sure if the contents are streamable at instantiation time.

Don't put an object into the any that can't be cout and then try and cout the any.


He
has to "trust to luck".

His code put the object into the any in the first place. No luck involved. Or it's someone elses code but he knows what someone elses code is giving.

There is more to an object than it's type. You can't just guess what to give a function based on only the information that it wants one unsigned integer.


The OP might not like the term "type-safe" but here
the downsides of non-type safety are showing themselves up!

I challenge you to make a lockup safe program as per my description of lockup safe that returns the sum of the first n integers. I would be interested if you came up with a solution but I don't think there is a lockup safe way of doing it (in summery lockup-safe is where the coder can't create a lock-up such as an infinite loop)

Programmer error and bad I/O documentation can't be avoided by putting rigid constraints on type, it's not about making other things safe in some other languages, it's just a type thing.

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.

Java is slightly more towards weekly typed as standard, there documentation is better (or at least more readable than that of MS visual C++) and the design has loads less inconsistencies than C++.

Perhaps where there is less type safety, bad design is more of an issue.


Of course a more advanced implementation might go down a has_operator_stream
metafunction route. But then you are getting well away from the spirit of
Any and towards that of Adobe.Poly as another posted mentioned.

As far as I can tell there is very little difference between the boost::any I have and adobe::poly except that adobe::polly is almost unheard of, it's difficult to Google information on it.

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.

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.


Either way it doesn't seem like a big deal, it's a better error vs a less descriptive error question not a fundamental problem with the significant improvement Peter made to the boost::any class.