Ideas for discussion topics with Bjarne Stroustrup - technical issues we have with C++
|
Table of Contents
|
Memory Management and Memory Layout
Memory arenas
- What about a New(arena_id/pointer) operator? [Rene]
- Arenas would be helpful for tweaking the lifetime of objects, against copy-on-write a full page even though only tiny bit is modifiable; also for thread-local memory on heap [Rene]
- Zebra like arenas / pools (with global cleanup -> no memory leaks) [Rene]
- Handles: required for garbage collection (see MS C++) [Rene]
- Concept of ownership in pointers (like the difference in Zebra between structural pointers and references). Ownership used by destructors and copy constructors (and of course I/O systems) [Rene]
- reference pointers with persistency in view, a la TRef but with ownership handling [Rene]
- fast look-up
- circularity
- Member-wise storage in STL collections (for vector computing and I/O) [Rene]
STL / templates
Code Bloat
- STL inlining and code bloat (code elimination in x.o, then x.so, then loader) [Rene]
- Templates and STL versus symbol count [Axel]:
A large fraction of symbols stems from templates, e.g. STL. Because of wrappers we instantiate tons of templated functions and classes. Could this be reduced e.g. by having a default implementation for vector<T*> for all T* with non-specialized allocator etc?
Thread Safety
- what about STL and thread-safety? New library?
Templates as API
- templates versus documentation / API clarity; also wrt 0x concepts
Misc
- TString::Format equivalent in string [Rene]
Doc
- No way to clarify what types the user can pass as template parameters. E.g. LorentzVector<COORD>, what am I supposed to pass as COORD? This could be solved by concepts, too.
Reflection
Exploration of dynamic structures [Rene]
- navigation in complex data structures for applications like I/O, visualization of large object collections with GL viewers, debuggers, statistics, etc.
- extended sizeof following dynamic structures, solving the circularity problem (c.f. ROOT I/O)
Introspection
We need to inspect an arbitrary object: members (also non-public), their offsets, its bases etc. The template + typeid + CPP macro things are a hack. We need to parse headers to extract the info, while the compilers have it anyway. Maybe:
- register user data (void*) with type_info, retrievable from object [Rene]
- that void* must be identical across shared libraries
Dynamic classes [Rene]
- creation of vtable for interpreted classes
Even limited forms of Reflection [Scott]
The following features would allow me to get rid of a few thousand lines of hacks:
bool is_base_of (const std::type_info& a, const std::type_info& b);
Is the type referenced by ‘a’ a base class of ‘b’?
void* convert (void* a_ptr, const::std::type_info& a_ti, const std::type_info& b_ti);
Convert ‘a_ptr’ which points at the type given by ‘a_ti’ to a pointer of type ‘b_ti’. Return 0 if the conversion is not possible.
Restricting this to polymorphic types would be acceptable.
I wouldn't think this would even be such a stretch to implement, since the runtime already needs to have the necessary information available in order to implement dynamic_cast.
Object creation, destruction from type_info [Axel]
Along Scott's lines, it would help the I/O to call the constructor or destructor given its type_info and a pointer to the address:
void* typeinfo::new_object(); void typeinfo::delete_object(void* obj);
We currently need to create new and delete (single, array, and with or without placement) stubs for performance reasons, for each type.
API for call setup [Axel]
We need to generate wrappers for each function, to normalize the calls, which then get compiled and loaded:
void wrap_func(void* ret, void* obj, vector<void*> args) { *(int*) ret = ((MyClass*)obj)->func((int)args[0], *(MyClass*) args[1]); }
We now want to switch to just-in-time compilation for that. Better ideas?
Threading
Threading Extensions [Matevz]
- applicable to static data members?
- Will there be some kind of class std::thread_context which would allow controlled creation of thread-local data? Will allocators be aware of the thread context?
- What will happen with memory management, is there any plan to support memory pools per thread?
- What does thread support mean for stuff like OpenMP and OpenCL?
Thread debugging
Symbols, Shared Libraries, Linking
- usage pattern at CERN: GB of binaries, use < 1/1000 of it
Dynamic Linker / Loader and C++ [Axel]
- dlopen takes long, symbols: amount and length
- not dynamic enough (c.f. plugins etc)
- versioning problems, matching use SOs with framework versions (yes we have solved that, but…)
Symbol Length [Axel]
The length of type names of C++ code is too large. We notice that in parsers, type databases etc.
Type name normalization [Axel]
The lack of a defined type name layout is really hurting us, think of
std::vector<const int32_t*>
vs
std::vector < int const *, allocator < int > >
It's flexible for coders but makes the type name / type mapping horribly difficult.
"Sociology"
- Experience with developers of gcc, icc, MSVC? When will they adopt to 0x? It is worth "waiting" for it? [Matevz]
- Is there any real hope to see C++ 0x or even thread local data supported before 2020? [Matevz]
- What kind of development / profiling environment does he use?
Possible other topics
Please expand if you find this interesting enough to discuss
- memory debugging supported by the language
