Difference between revisions of "C++ TODO"

From ReactOS Wiki
Jump to: navigation, search
(Start a page describing our C++ problems and possible solutions)
 
(New plan)
Line 1: Line 1:
 
= The problem =
 
= The problem =
* we have STLPort as our C++ standard library. Whether this is suitable is to be seen
+
* we have STLport as our C++ standard library. Whether this is suitable is to be seen
 
* for the C++ runtime, we rely on libsupc++ for GCC builds. The equivalent functions for MSVC are inside msvcrt.lib (our solution to the C pendant is msvcrtex)
 
* for the C++ runtime, we rely on libsupc++ for GCC builds. The equivalent functions for MSVC are inside msvcrt.lib (our solution to the C pendant is msvcrtex)
* thus, we have no C++ runtime library
+
* the C++ ABI differs between GCC and MSVC
 +
* Wine's C++ runtime is unable to support even the most basic programs
 
* additionally, explorer relies on non-standard library features, yet explorer_new is nowhere near ready
 
* additionally, explorer relies on non-standard library features, yet explorer_new is nowhere near ready
  
 
= The plan =
 
= The plan =
* import msvcp90 (or msvcp60?) from Wine into <code>lib\sdk\cpprt</code> akin to CRT (take HEAD, I'm already putting MSVC build fixes in there)
+
* in the new <code>[http://svn.reactos.org/svn/reactos/branches/c%2B%2B-bringup/ c++-bringup]</code> branch, create a new C++ runtime library that will support our goals
* link C++ applications statically with this new library (instead of -lsupc++)
+
* have a library in <code>lib\sdk\cpprt</code> or so (and corresponding headers somewhere in <code>include\c++</code>) that implements the runtime functions in native C++
* we can export the functions from msvcp90.dll at little extra cost, just like our msvcrt.dll
+
* export these functions to the appropriate DLLs (msvcp*, msvcirt, ...), using MSVC's ABI (that is, make wrappers if G++ is the compiler in use)
* import the tests along with it so we see if our runtime works like it should
+
* link our C++ apps to these DLLs
 +
* make a static library to link with all G++-built programs, which wraps the MSVC functions exported by these DLLs to be G++-compatible
 +
* this way, we provide a working runtime to MSVC-built programs, and ours depend only on MS's own runtime DLLs (or we have the option to link the C++ stuff completely statically)
 +
* a perfectly working <code>operator new</code> (with RTTI and exception) would be the first/most important step
 +
* back up everything by extensive tests
  
= Problems with the plan =
+
= TODO List =
* is it really msvcp90 we want? Do we want 90 or 100 depending on the compiler in use? Or do we want 60 for compatibility reasons of some sort? It should also work with GCC!
+
Here are some likely next steps:
* msvcp* has problems similar to those in CRT, where we'll likely need adjusted inline assembly code, some assembly wrappers etc.
+
* check how much of the below list is included in STLport or easily available from somewhere else
* STLPort's headers might be somewhat incompatible with that new runtime. We might need to override them (and Wine of course doesn't have C++ headers) or replace STLPort with something else
+
* create tests for RTTI basics
 +
* implement most of <code>type_info</code> (perhaps exceptions should be first?)
 +
* implement <code>dynamic_cast</code>, <code>std::bad_cast</code>, <code>std::__non_rtti_object</code>
 +
* create tests for <code>try</code>/<code>catch</code>/<code>finally</code>/<code>throw</code>
 +
* create tests for standard exceptions (<code>std::exception</code>, <code>std::bad_alloc</code>, ...)
 +
* implement <code>std::exception</code> and friends
 +
* create tests for <code>new</code>/<code>delete</code>
 +
* implement <code>operator new</code>, <code>operator delete</code>, <code>`eh vector constructor iterator`</code>, <code>`eh vector destructor iterator`</code> etc

Revision as of 10:54, 8 March 2012

The problem

  • we have STLport as our C++ standard library. Whether this is suitable is to be seen
  • for the C++ runtime, we rely on libsupc++ for GCC builds. The equivalent functions for MSVC are inside msvcrt.lib (our solution to the C pendant is msvcrtex)
  • the C++ ABI differs between GCC and MSVC
  • Wine's C++ runtime is unable to support even the most basic programs
  • additionally, explorer relies on non-standard library features, yet explorer_new is nowhere near ready

The plan

  • in the new c++-bringup branch, create a new C++ runtime library that will support our goals
  • have a library in lib\sdk\cpprt or so (and corresponding headers somewhere in include\c++) that implements the runtime functions in native C++
  • export these functions to the appropriate DLLs (msvcp*, msvcirt, ...), using MSVC's ABI (that is, make wrappers if G++ is the compiler in use)
  • link our C++ apps to these DLLs
  • make a static library to link with all G++-built programs, which wraps the MSVC functions exported by these DLLs to be G++-compatible
  • this way, we provide a working runtime to MSVC-built programs, and ours depend only on MS's own runtime DLLs (or we have the option to link the C++ stuff completely statically)
  • a perfectly working operator new (with RTTI and exception) would be the first/most important step
  • back up everything by extensive tests

TODO List

Here are some likely next steps:

  • check how much of the below list is included in STLport or easily available from somewhere else
  • create tests for RTTI basics
  • implement most of type_info (perhaps exceptions should be first?)
  • implement dynamic_cast, std::bad_cast, std::__non_rtti_object
  • create tests for try/catch/finally/throw
  • create tests for standard exceptions (std::exception, std::bad_alloc, ...)
  • implement std::exception and friends
  • create tests for new/delete
  • implement operator new, operator delete, `eh vector constructor iterator`, `eh vector destructor iterator` etc