Re: [Boost-users] boost any questions and praise

Subject: Re: [Boost-users] boost any questions and praise
From: Alan Tennant (alan2here_at_[hidden])
Date: 2010-02-02 20:28:22

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