Ideas for Common C++ 2.0...

[David Sugar]

This seemed like a good time to discuss some current ideas for common
c++ 2.0...

First, I have wanted to make object management smarter, and borrow a
little from objective-c.  Hence, we will have a new commonly used
virtual base class, "Object", which will include a release() virtual.
This can be used to form self refcounted objects (ala objective-c),
among other nice things.

More important, it will be used with two helper classes, auto_delete and
auto_release.  Auto_release is meant to be used to contain Object
pointers often created by the "new" operation (or a refcounted copy) for
an object that most often is generated in the thread's constructor, but
in any case is to be "released" when a thread terminates or is canceled.
 This provides a simple scheme for automatic management of threaded heap
resources.  A second helper, auto_delete, is meant to be used for stack
frame pointers that are to be released when a member function returns.

auto_release and auto_delete will be wrapped in (and most often used by)
a couple of templates that will use them as base classes and only offer
light inline type conversion methods, including pointer (like
auto/smart_ptr) and release (thread released pointer).  Hence, you might
have something like:

        pointer<mytype> myptr = new mytype...

How this differs from boost shared_ptr or std::auto_ptr is that we will
use a concrete base class for the actual implementation code rather than
carry it in the template, and the object being referenced will have a
common base also, and hence the template is only used as a wrapper for
implementing inline type safety and cast conversions.  Unlike in boost,
the behavior (deletion method, ref counting, etc) is not a part of the
pointer object which might be commonly instanciated, but rather the base
class of the object being pointed to.   This means that the pointer<xxx>
instance only has a single pointer, and not additional details like
refcount objects, delete methods, etc. The release (auto_release object)
only has the pointer and a linked list for releasables on the thread
base.  A file descriptor (or w32 Handle) could also be described through
a "releasable" object that invokes ::close (or CloseHandle).

We also would not have the overhead traditionally involved in templates
with complex inline/embedded methods that also often lead to large code
blocks generated both for each specific type invocation and in each
object module since where implementation is instantiated is not defined
for a template.  These templates may even work in broken Microsoft
compilers, such as the latest one, which cannot seem to embed
traditional templates (such as stl) in dll's at all.  This kind of
methodology of using a common base and a concrete helper class wrapped
in a typecasing template might also be useful to apply to building a
full and stl-like library that can be used successfully without template
bloat and compiler issues.

Another change will be in mutex/semaphore/rwlock locking.  These will
also be managed by two stack auto-functions, exclusive and shared, and
the Mutex/Semaphore/RWLock classes will also be constructed from
"virtual abstracts" for ExclusiveLock, SharedLock, and ReleaseLock so
they can be used with the generic shared/exclusive objects.  Hence, to
have a method lock like the java sync keyword, with an embedded Mutex in
the base:

        void myclass::mymethod(void) {
                int somevar = 0;
                exlusive lock(this);
                ...

This will put an instance of lock on the stack frame, will lock the
mutex in the constructor of lock, and release it when ~lock() is called,
which happens on a return...A special macro, EXCLUSIVE, and SHARED, may
be added for simplicity when refercing mutexes/rwlocks/semaphores that
are constructed in the base class...

Hence, a Semaphore is a "shared" lock, a mutex an "exclusive" one, and a
rwlock is both, depending on whether your using the read or write lock
method...

Other changes I am considering include dropping of CCXX_NAMESPACE
wrapper, and just assuming any useful compiler has namespace.  Perhaps
with 1.6 we will add the new gcc visibility flag support.  With 2.0, we
will likely switch to the "gnu" namespace.   Also, I have looked at the
redhat "pthread library for win32".  This might be a better answer than
using native w32 threading we now use because we could better focus on
just the pthread coding model and reduce complexity in the thread class.

I have also looked at producing am experimental variant of common c++,
perhaps to be called "embedded common c++", which basically builds
around the notion of -nostdlib and hence no c++ standard library.  We
often have embedded projects which would greatly benefit from c++ for
design, but rely exclusively on c coded libraries, and perhaps are on
targets which cannot support the huge and duplicative stdc++ library and
it's template generated code, exceptions, etc.  The idea is to have a
object oriented framework for developing embedded services which adds no
real overhead to support compared to using pure C.

We will likely not break most existing common c++ based code, since many
of the existing classes and behaviors will still also exist.  Some
things will disappear however, including the current Pointer template (a
new RefPointer that behaves the same but is constructed like the new
pointer will be used instead) and the current objxxx templates which I
do not believe anyone uses.  If we consolidate around the pthread
threading model, the thread suspend/resume support will be eliminated,
since there was no real way to simulate this on most pthread platforms
anyway.  Cancelable threads based designs will in any case benefit from
the new auto_release mechanism.

One area I might restructure is the dso support, perhaps introducing a
dlfcn compatibility wrapper for w32 and using the posix shared object
support functions directly rather than a class wrapper.  Some of the
crufty file classes may also be killed or cleaned up.

One area with a very large potential for change is Socket.   Perhaps it
would be better if "Address" became a struct sockaddr rather than a base
IPV4 socket address (and separate AddressIPV6 classes/methods).  This I
know would break a lot of existing things, but would simplify many as well.

dyfet.vcf
Description: Vcard