> Nevertheless, RTTI is still needed for C++ to do EH: exceptions are classes
inherited from one another.
It looks to be not a case. The standard says on the contrary: the rtti operations can rise exceptions. All the rest interdependance between RTTI and EH is an internal specific of a compiler. E.g. in the case of the MS C++ the EH work well even if you’ve RTTI turned off - the compiler still generates the type-descriptor tables concerned with types involved into the EH-process. And note those tables are not the complete RTTI type-describing structures.
Well, several years ago the gcc had a problem - when the RTTI was being turned off while compiling the EH became broken - that was a bug.
Anyway these are all kludges: the full and proper RTTI support can occur in
managed code only, like the WinRT-extended C++
On my opinion the C++ currently doesn’t pretend to be object-oriented in terms as do the C#, Java or ObjC. The C++ is just an instrument to build your own OO-framework, and the RTTI capability is good enough as a part of the language but certainly may not fulfil your framework requirements.
If you want developers to adopt use of your library you really should
support building within the MSFT defined tool-chain. As is this is a
non-starter for almost everyone building commercial products. You might
find this unreasonable, but it will be a barrier to adoption.
Agreed, working within the current MSFT defined tool-chain is a must.
Anything else is of no interest to me. Logo compliance is a must.
Ok, yes. I’ll consider to supply VC2012 solution with the project for convenience.
But the ‘/kernel’ compiler switch is a kind of a mutual exclusion - it just can not be used to build a driver using EH and RTTI -).
It hardly beleived this RTL can be considered as a part of some commercial product in some future. Let’s just look at the current state of the project:
- this is entirely a private investigative initiative;
- a whole bunch of undocumented or poorly-observed or reverse-engineered technologies is used,
- the officially unsupporetd or unrecommended facilities are used,
- initially released with the intention to be of an interest to the enthusiast of the C++ using in the NT kernel environment.
Although the license is permittive enough for the code to be used in a wide range of side projects including commercial, someone intending to involve this code in his buisness need to be strongly ensured what does he do, because all profits and risks are to be taken on his own. The RTL author is only competent to answer the questions about internal layout of the library and supplied tools.
And why are you talking about antiquated boost things?
We are approaching the year 2014 so get on board with
c++11 and std::bind, std::thread and don’t even
mention legacy things.
Oh, boost::bind and boost::function are never considred as antiquated IMO. Their std::-twins just resembles the experience of the corresponding boost facilities.
It is 100% true. My post gave a flavor of this; std::wstring,
std::list and std::thread are just the beginning of the
incredibly useful library features
that blow away code without them.
These are a kind of a good, but the great efforts are to be released for this to become real in the kernel.