Re: Rearranging source files

[David Sugar]

Originally we had no clear idea of precisely how we wanted to split the 
library, but we knew we wanted to do so.  This was because of experiances 
with other C++ class libraries that were very large, and distributed as a 
single library image, which meant, unless they were widely used over multiple 
applications, it was likely a huge amount of code being installed into shared 
memory would never be executed.  This seemed particularly wasteful on 
smaller/near embedded appliance applications targeted for machines that 
likely have no swap activated.

The current split was between core classes (libccgnu2 replaced libcc++) and 
libccext2 (which was ccstd & ccio).  The idea being that the more commonly or 
likely to be  used classes would be in ccgnu2, and the less commonly commonly 
used or highly specialized derived ones in ccext2 (kind of like util in 
java...).  

It is true that in some of my applications I do not use net classes at all.  
Hence, the idea of having a separate libccnet2 does make sense to me, and I 
could imagine other people also creating and distributing applications which 
do not use or have network operations; again why load code never to be 
executed?

I did not wish to split the core GNU Common C++ package into "many" separate 
tiny libraries simply because there are different inefficiencies in doing 
that.  But I think 3 (or at the very most 4) would be okay, especially if 
each is fairly large in itself.

On Friday 02 January 2004 10:36 am, Marc Boris Dürner wrote:
> Hi,
> The split is definatley material for a later version. I found an old
> common-c++ sourceforge
> website and there the library was even more modularised.
>
> http://cplusplus.sourceforge.net/
>
> There is says:
> libcc++
> libccstd
> libccio
>
> Dont know if this still makes sense. How would you like to do it?
>
> This is what I have right now(each.cpp complemented by a .h file of the
> same name):
>
> libccnet_la_SOURCES = BroadcastAddress.cpp \
>       InetAddress.cpp \
>       InetHostAddress.cpp \
>       InetMaskAddress.cpp \
>       InetMcastAddress.cpp \
>       NetworkDeviceInfo.cpp \
>       SimpleTCPStream.cpp \
>       Socket.cpp \
>       SocketPort.cpp \
>       SocketService.cpp \
>       TCPSession.cpp \
>       TCPSocket.cpp \
>       TCPStream.cpp \
>       UDPBroadcast.cpp \
>       UDPDuplex.cpp \
>       UDPReceive.cpp \
>       UDPSocket.cpp \
>       UDPTransmit.cpp \
>       URLStream.cpp \
>       UnixSession.cpp \
>       UnixSocket.cpp \
>       UnixStream.cpp \
>       UrlString.cpp \
>       WSA.cpp \
>       tcpstream.cpp \
>       unixstream.cpp
>
> All the other classes are in libccbase. But I havent split the source files
> yet(This is quite a
> bit of work...).
>
> hope I am useful,
> Marc
>
> > While it sounds like the right thing to do, this sounds like it should be
> > introduced in an active release after 1.1, perhaps for "1.2".  1.1 still
> > has fairly limited changes that don't break most peoples existing
>
> projects,
>
> > while this could...
> >
> > On Thursday 01 January 2004 08:08 pm, Marc Boris Dürner wrote:
> > > I have started (almost done actually) to separate the networking code
> > > from the base
> > > library to form a library called ccNet. Normally one class per .h/.cpp
> > > pair, except for
> > > exception classes or the validator classes.
> > >
> > > Is there anything else we can modularise?
> > >
> > > I wasnt sure what the extension library is, but it seemed pretty
> > > generic
> > >
> > > to me. I have put
> > > these classes in the base lib for now.
> > >
> > > Any thought on a naming scheme? ccNet seemed like the logical choice
> > > (ccAudio,
> > > ccScript... already exist). How shall we call the base lib? libccBase?
>
> or
>
> > > just libcc?
> > >
> > > How about the namespace Gnu::? after all this is an official gnu
>
> project,
>
> > > isnt it?
> > >
> > >
> > > Marc