ccrtp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ccrtp-devel] Common C++ 1.4.0, CAPE 1.4.0, ccRTP 1.4.0, and other oddit


From: David Sugar
Subject: [Ccrtp-devel] Common C++ 1.4.0, CAPE 1.4.0, ccRTP 1.4.0, and other oddities...
Date: Thu, 27 Apr 2006 13:47:15 -0400
User-agent: Thunderbird 1.5 (X11/20060313)

I have relatively few changes in mind for Common C++ 1.4.0 itself,
unless others have some additional suggestions.

One thing I am thinking of adding is a RefObject base and RefPointer
class to do "smart" pointers without having to use the Pointer template
class.  Basically, you would create a managed object as a subclass of
RefObject with a virtual destructor and virtual void *getObject(void)
method to get a pointer to the real underlying object (manual recasting
required).  RefPointer would then manage reference counted instances of
the derived object.  This will be useful where it's not desirable to use
the pointer template for overhead reasons, particularly if you have a
lot of different types being managed, since the pointer management code
is now common code rather than inline code re-derived for each type.

Similarly, I may introduce a MapTable and MapObject class to do
non-template based hash indexing of objects in Common C++ (assoc does
this also, but not in a manner that allows for node deletion.).

I would like to also introduce some extensions to the network classes
for zeroconf, ident, and stun support.

To better support the broken native Microsoft C++ compilers, the Common
C++ template classes will no longer include dll interface definitions
for use in building .dll's with templates.  It is instead recommended
that the target .dll include dll interface instantiation of the
template, as this gets rid of both linker errors on their newer broken
compilers and warnings on the older ones.  For example, to use the
Pointer template, as ccrtp does in queuebase.h, it is suggested to do
something like the following:

class __EXPORT AppDataUnit
{
...
private:
#ifdef  _MSC_VER
        template class __EXPORT Pointer<const IncomingRTPPkt>;
#endif

Maybe I will add a special __TEMPLATE_EXPORT macro to 1.4.0 to do this
type of binding in headers for .dll native targets but otherwise strips
this for compilers that do work correctly, to remove the need for
conditional blocks in user code.

This method unfortunately does not work for embedding most of the STL
containers from Microsoft's runtime library because their STL stuff is
broken and includes internal classes that cannot be re-exported.  It may
be possible to work with the excellent SGI STLPORT for native .dll
targets though.  I may also look at including STLport in future CAPE
builds...

The largest changes in 1.4.0 will actually be in the Cape distribution
of GNU Common C++ libraries for building native Windows targets, as all
the .dll libraries will be renamed in a more consistent manner and to
reduce the likelihood of filename collision with other instances of
bundled dll's from other origins.

Along with Common C++ 1.4.0, I plan to do a 1.4.0 release of ccrtp,
which will use whatever fixes I do for templates, including the
__EXPORT_TEMPLATE(x) macro system if I add that.

Ideally, I have thought about changing the current ccrtp stack templates
to use string based "addresses" for connect and other methods, rather
the the IPVxAddress objects.  This would make it possible to directly
collapse the new IPV6 templates directly with the old IPV4 ones, rather
than having two templates as we do now.

There will also be a 0.10.0 release of ccAudio2.  This will include a
new virtual for getting file length to make sure header rewrites on
close are correct.  It will also no longer include libgsm inside the
ccaudio2 distribution.  For Debian GNU/Linux systems, you will need to
apt-get install libgsm-devel to use the gsm codec.  The GNU Telephony
RPM repository will have a gsm rpm build for RPM based GNU/Linux
distros.  Under CAPE 1.4.0, we will provide a separate gsm dll.

Attachment: dyfet.vcf
Description: Vcard


reply via email to

[Prev in Thread] Current Thread [Next in Thread]