Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!ukc!acorn!abccam!pete
From: pete@abccam.abcl.co.uk (Peter Cockerell)
Newsgroups: comp.lang.c++
Subject: More cfront -> ANSI C compiler problems
Keywords: cfront ANSI
Message-ID: <511@pete.abccam.abcl.co.uk>
Date: 19 Jul 90 11:14:46 GMT
Organization: Active Book Company Limited, Cambridge, UK
Lines: 40

Yo dudes!

Well, my last posting about porting cfront 1.2.1 to an ANSI C compiler
didn't exactly elicit a flood of responses (is this getting outside of
the UK?), just an email saying 'if I wanted to get to there, I wouldn't
start from here if I were you.' Cheers mano!

Still, here's another problem, which this time isn't, I think,
cfront-version-specific, so maybe it'll generate more interest. 

It's like this. When you have a static class member, eg

class fred {
	static int jim;
	...
};


it gets ouput in the ..c file as

int _fred_jim;

ie an uninitialized extern variable.  When this is compiled by pcc, it
gives the variable type C (as printed by nm), ie common.  All occurences
of this definition are coalesced by the linker to provide the common
entity that we want. 

But...  our ANSI compiler gives the variable type D, ie defined.  When
you come to link all the files that include the class declaration, you
have lots of definitions of _fred_jim, which produces error messages and
no executable. 

So, what do we do, assuming we don't have access to the ANSI cc compiler
source, so can't revert to C type for definitions of the type discussed
above? Do later cfronts produce the same type of definitions for static
members (I can't see what else they could do)?

Thanks in advance, he says hopefully

	--Pete