Hallo Gem-devs!
I just made some things in GEM and noticed, that a lot of C++-style features are not possible, because in Base/cppExtern the operator new is defined as (correct me if I'm wrong): GEM_EXTERN void *operator new(size_t, void *location, void *dummy);
(e.g. I tried to use fstreams and strings for fileIO and there was always the compiler error: ... /usr/include/c++/3.3/bits/basic_string.tcc:555: error: no matching function for call to `operator new(unsigned int, void*&)' <internal>:555: error: candidates are: void* operator new(unsigned int) ../Base/CPPExtern.h:132: error: void* operator new(unsigned int, void*, void*) )
so I also defined:
//----------8<------Base/cppExtern.h--------8<------------ GEM_EXTERN void *operator new(size_t); GEM_EXTERN void *operator new[](size_t); GEM_EXTERN void *operator new(size_t, void *location); GEM_EXTERN void *operator new[](size_t, void *location); GEM_EXTERN void operator delete(void *base_ptr); GEM_EXTERN void operator delete[](void *base_ptr); //--------------->8----------------->8--------------------
//----------8<------Base/cppExtern.cpp--------8<---------- GEM_EXTERN void *operator new(size_t size) { return (::operator new( size )); }
GEM_EXTERN void *operator new[](size_t size) { return (::operator new( size )); }
GEM_EXTERN void *operator new(size_t size, void *location) { return (::operator new( size )); }
GEM_EXTERN void *operator new[](size_t size, void *location) { return (::operator new( size )); }
GEM_EXTERN void operator delete(void *base_ptr) { if(base_ptr) ::operator delete( base_ptr ); }
GEM_EXTERN void operator delete[](void *base_ptr) { if(base_ptr) ::operator delete( base_ptr ); } //--------------->8----------------->8--------------------
So my question: Has this implementation any other disadvantages that I am not thinking of at the moment (e.g. performance, because I ignored the location pointer?) ?
(I know I can also make all that stuff in C-style, but why?)
LG Georg