Path: utzoo!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!uunet!mcsun!ukc!edcastle!cs.ed.ac.uk!arshad
From: arshad@cs.ed.ac.uk (Arshad Mahmood)
Newsgroups: comp.lang.c++
Subject: C++ and storage management
Message-ID: <7622@skye.cs.ed.ac.uk>
Date: 12 Mar 91 20:21:43 GMT
Sender: nnews@cs.ed.ac.uk
Reply-To: arshad@lfcs.ed.ac.uk (Arshad Mahmood)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
Lines: 24

I wonder if one of you out there know of a solution to the following
problem, I have only very recently started reading this group so please
accept my apologies if it's already be dealt with.	

I have been trying to implement a support tool for analysing concurrent 
systems, now I have a hierarchy of these (i.e a half dozen calculi, with some
subset relationships). I am using bison/lex to generate the parser, and
g++ as compiler. All the .o files of my code amount to some 100K of 
binaries, however after linking this jumps to a huge 350K of binaries.
I assumed that the code size would increase somewhat since I am using
streams, etc but certainly not to this extent. 

So I am wondering whether perhaps there are some guidelines for organising
the classes, and #includes to limit the code. All this is assuming of
course that there really is a problem, I am used to the nj-sml separate
compilation system which has several problems in this regard, but
since I am newcomer to C++ I wasn't aware of any such problems here.

Thanks.

A. Mahmood
LFCS
Edinburgh University
Scotland