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.
begin:vcard fn:David Sugar n:Sugar;David org:GNU Telephony email;internet:[EMAIL PROTECTED] tel;work:+1 201 215 2609 url:http://www.gnutelephony.org version:2.1 end:vcard
_______________________________________________ Bug-commoncpp mailing list Bug-commoncpp@gnu.org http://lists.gnu.org/mailman/listinfo/bug-commoncpp