Is this guaranteed to be correct?

[OReubens]

... and I have some doubts concerning the portability of the comparison of the so obtained void* in this case ... and even if the code were perfectly legal and guaranteed, I'd be not surprised to discover that some compilers/linkers doesn't like it anyway. So, yes, kind of risky without some further investigation ...

hmm. indeed...
if a function is empty. wouldn't a compiler/linker be allowed to merge all calls to the same "do nothing" function ?

while the standard does specify that INSTANCES of objects are required to be on unique addresses, so the address trick would work for a static object. I can't recall something similar being stated that the address of memberfunctions necessarily need to be unique.


ALso defining the function as inline, then expecting an address is counterproductive and confusing. You never call the function so it'll never be inlined, and the address requires there to be an actual function in the linker phase.

[OReubens]

Boost::Any is a bad idea from start to finish. If people cannot design without downcasting then they should be forced to do so explicitly so it can be detected and corrected at the next code review. So for the sake of your platform I hope you drop this malign "feature".

yes, let's drop Any, and Variant and all of the technology like COM, C# VBS, javascript that depend on it !!!

In a perfect utopic world, there is only 1 programming language, because there can be only one perfection. If there were two, than by it's very nature, one of the two would need to be less perfect and an abomination because of that. I don't know which language that perfect one is, but it definately won't be any in existance today.

The real world is dirty, harsh, needs to deal with alls sorts of nasty, and sometimes, less than ideal designs get the job done adequately. Imo, there are much bigger design failures you could commit than something like this.

[razzle]

Imo, there are much bigger design failures you could commit than something like this.

No! Trading away the type safety of C++ for reasons of programmer's convenience is a monumental blunder of almost biblical proportions. Static type checking is at the very foundation of C++. If you give it away the result is non-safe and inefficient code. It's not true C++ anymore.

There are many languages that offer weaker and more dynamic typing than C++ so why is everybody so hellbent on violating C++ on every occasion? Pick another language for scripting or duck typing purposes for heavens sake. Please leave C++ alone.

When ever you're downcasting, C++ puts a dunce cap on your head by forcing you to put in a dynamic_cast that stands out like a sore thumb. Hiding it in Boost::Any doesn't fool anyone. You're still wearing the dunce cap.

Fortunately there seems to be strong resistance in the C++ Standards Committee against stupidities like Boost::Any so there's hope.

[OReubens]

there are real life problems that can't be solved by any thing other than somethine like boost:any or MS's VARIANT approach.
good luck convincing even a small minority to get rid of this entirely.

the C++ standard comitee has issues with boost:Any, but that is about implementation details, not about the fact it's about dynamic typing.

[JohnW@Wessex]

No! Trading away the type safety of C++ for reasons of programmer's convenience is a monumental blunder of almost biblical proportions.

Part of the my personal design brief for my Variant class was to reduce any type safety issues to an absolute minimum. In this I think I've been pretty much successful. The main way to get around type safety would be to employ the same techniques you would use for any other type in C/C++; by brute force casting. Downcasting is completely unnecessary when using this class. In fact the internal mechanism employed only relies on upcasting to the base type. Any type of casting can be completely avoided by using the built-in type safe visitor base class.

[razzle]

there are real life problems that can't be solved by any thing other than somethine like boost:any

Please give me one such problem.

[razzle]

Part of the my personal design brief for my Variant class was to reduce any type safety issues to an absolute minimum.

Well that's fine. If your Variant class is a variation of the Visitor design pattern then type resolution will take place at compile time and it will be type safe.

But then on the other hand it's not similar to Boost.Any which is not typesafe.

[OReubens]

Please give me one such problem.

- supporting interafaces to a scripting language that doesn't have strict typing.
More and more applications are supporting built-in scripting languages, and there are good reasons to make those having dynamic types. Mainly because it's "easier to write" for people without a degree in software development.

- supporting dual interface COM

- supporting dynamically typed linkages to external data that isn't strict typed, such as ODBC interfaces (even though the SQL tables may be strictly typed, the interfaces to get/set typically aren't).
Or for processing structured data that has built in types, like a JSON/YAML stream.

Massive ORM uses dynamic typing and is 400 lines of code.
Dapper does more or less the same thing from a usability POV, it uses static typing and is 3000 lines of code
performance wise, they're very close. THey have different goals, but the advantage of dynamic types is Obvious, it can make for much more concise code by defering type decisions to run time. Sometimes that's an advantage, sometimes it isn't. The advantage of C++ is that you can have both, AND on top of that, you can even have type inference which has it's own area of possibilities. If you really hate dynamic types, you should hate type inference for the same reasons.



- there are a couple algorithms that would make little sense without a dynamic type. Typically those that would involve having overloads for every possible type your program supports. Which can become problematic if they need to support this for all possible combinations of parameters.

- you seem to be so excited about functional languages. Well, Haskell has dynamic types. And I believe (not entirely sure that ML and scala do too).


The above is not a carte blanche to use any/variant anywhere you feel like.
C++'s strict typing is there for a reason, make use of it... And opt out of it when there's a need for it.
even with a dynamic type, you can still embrace strict typing by employing static visitors to access them from your C++ code (where feasible).

Since both languages with dynamic types and languages with static types are turing complete, it should be possible to state that anything that can be done with dynamic types can be done with static types (and vice versa). But some things will be considerably easier with one or the other. dynamic types have their problems, but going through all sorts of hoops to adhere to strict typing just for the heck of it, when dynamic typing would have been "easier" and "more intuitive" isn't a good way to go either.

[2kaud]

when dynamic typing would have been "easier" and "more intuitive"

...and fewer problems picked up at compile time. Give me a compile time error rather than a run-time error any time

[JohnW@Wessex]

Give me a compile time error rather than a run-time error any time

[razzle]

The above is not a carte blanche to use any/variant anywhere you feel like.
C++'s strict typing is there for a reason, make use of it... And opt out of it when there's a need for it.

Your argumentation has two serious flaws.

You seem to think that certain kinds of external subsystems will infect C++ with dynamic typing and there's no cure against it, almost like a Zombie invasion. Nothing could be further from the truth. In fact using all kinds of subsystems where the interface cannot be statically type checked is a very common situation that certainly doesn't force you to use Boost.Any.

The second flaw is that you seem to think that Boost.Any and the likes will turn C++ into a dynamically typed language. It won't. Boost.Any will hold anything for you and pass it around but as soon as you need to manipulate it you must establish exactly what you're dealing with. It's like a garbage bin. You can throw anything in Boost.Any for sure but eventually you need to pick it up again and then it's even smellier than before.

What a statically typed language needs in order to manipulate dynamically typed external data is the equivalence of a reflection system that extends to include the external subsystem in question,

http://en.wikipedia.org/wiki/Reflect...r_programming)

Such a reflection system is usually refered to as a "binding".

A binding is what you need, not Boost.Any, not even in the case you're writing a binding.

[superbonzo]

I know it's pointless to argument with you but just FYI ( and for other readers )

nobody's advocating a "liberal" use of boost.any ( or the likes ), but you proabbly misread boost.any documentation because it nowhere allows non-type safe behavior. It's just a utility class used to store and retrieve "any" object; a type safe void*, say, mimicking dynamic_cast for non polymorphic types; indeed, it's just a polymorphic wrapper internally. So, at most, it shares the same level of "evilness" of dynamic_cast, or any other type-erased utility ( like std::function and many others ). Claiming these have categorically no legitimate use whatsoever is a rather silly position IMO.

[razzle]

I know it's pointless to argument with you but just FYI ( and for other readers )

It's pointless to argue with me only if you are wrong. And this time you're wrong at two levels.

First, you claim Boost.Any is type safe but it isn't because any_cast may fail at runtime. And by the way, if Boost.Any were type safe as you claim then why do you need to advice against its liberal use? Are there further problems you're aware of? Please feel free to explain.

Second, there is no C++ legislation so there is no notion of legitimate/illegitimate usage of C++. In short, you do what you like and it's legitimate if you say so.

Please feel free to give away the C++ type safety for Boost::Any convenience. I won't stop you from shooting yourself in the foot. Fortunately for you the C++ standards committee is more concerned with your health than I am. It has keep Boost.Any out for decades so at least it's not part of C++. And it probably never will. In the directives to the C++ 11 standard:

"Increase type safety by providing safer alternatives to earlier unsafe techniques"

My question remains. Why are so many programmers so hellbent on making C++ less type safe? Why is so much time and effort spent on making C++ more brittle and error-prone? That's what "other readers" should ask themselves.

[superbonzo]

ipse dixit, and I suppose it's hopeless pointing out what type safety means ...

Fortunately for you the C++ standards committee is more concerned with your health than I am. It has keep Boost.Any out for decades so at least it's not part of C++. And it probably never will.

any_cast won't "fail" in the UB sense, any_cast will return 0 if a wrong pointer is passed and will throw an exception in the reference case, exactly as dynamic_cast does, which is part of c++, ain't it ? the reason why boost::any is not in the standard has little to do with it being type safe or not; it's not there because it has not been considered sufficiently useful and safe to use especially if compared to more "sane" alternatives.

BTW, here is a quote from the std proposal n3804:

This paper proposes a type-safe container for single values of value types. The C++ standards committee is planning to include the proposal in a library Technical Specification (TS).

[razzle]

and I suppose it's hopeless pointing out what type safety means

If your main point is that you don't share my definition of type safety (which I've made perfectly clear throughout this thread) then stop mumbling and spit it out for heaven's sake.

Both dynamic_cast and any_cast are not type safe because they're not statically verifiable. They can only be checked at runtime, not at compile time.

I must confess I didn't know std::Any was so far in the standardization process. It's a disappointing development for C++. Educated programmers will know to avoid it while naive programmers will wellcome its convenience, littering their code with even more unsafe downcasts reaching new heights of crappiness.