pete@abccam.abcl.co.uk (Peter Cockerell) (07/19/90)
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
steve@lia (Stephen Williams) (07/23/90)
In article <511@pete.abccam.abcl.co.uk> pete@abccam.abcl.co.uk (Peter Cockerell) writes: >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. I have encountered a similar problem while using cfront 2.0 on a SUN sparc. My code involves a class that looks like this: struct pair { short a, b; }; class foo { public: foo(); private: int x; static pair y[]; }; The code for "y" looks like: struct mangled_pair y[]; which the "C" compiler rejects, claiming "unknown size." In a sense this is true. The code that is should generate should look like: extern struct mangled_pair y[]; Whose fault is this? A shar of the complete example follows. Can anyone tell me if this problem is universal? --Steve Williams #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh <file", e.g.. If this archive is complete, you # will see the following message at the end: # "End of shell archive." # Contents: Makefile foo.h foo.C bar.C # Wrapped by steve@ararat on Sun Jul 22 16:44:47 1990 PATH=/bin:/usr/bin:/usr/ucb ; export PATH if test -f Makefile -a "${1}" != "-c" ; then echo shar: Will not over-write existing file \"Makefile\" else echo shar: Extracting \"Makefile\" \(263 characters\) sed "s/^X//" >Makefile <<'END_OF_Makefile' X X# -- X# What is wrong with foo.h? When foo.C is compiled, all is X# as it should be. When bar.C is compiled, cc (not CC) X# reports an error. What gives? X# Xbar: bar.o foo.o X Xfoo.o: foo.C foo.h X CC -c $(CFLAGS) foo.C X Xbar.o: bar.C foo.h X CC -c $(CFLAGS) bar.C END_OF_Makefile if test 263 -ne `wc -c <Makefile`; then echo shar: \"Makefile\" unpacked with wrong size! fi # end of overwriting check fi if test -f foo.h -a "${1}" != "-c" ; then echo shar: Will not over-write existing file \"foo.h\" else echo shar: Extracting \"foo.h\" \(220 characters\) sed "s/^X//" >foo.h <<'END_OF_foo.h' X Xstruct pair { short a, b; }; X Xclass foo { X X public: X foo(); X X private: X int x; X X // This statement generates an error if the X // actual definition of foo::y's value is X // in another file. X static pair y[]; X}; END_OF_foo.h if test 220 -ne `wc -c <foo.h`; then echo shar: \"foo.h\" unpacked with wrong size! fi # end of overwriting check fi if test -f foo.C -a "${1}" != "-c" ; then echo shar: Will not over-write existing file \"foo.C\" else echo shar: Extracting \"foo.C\" \(61 characters\) sed "s/^X//" >foo.C <<'END_OF_foo.C' X X# include "foo.h" X Xpair foo::y[] = { {1,1}, {2,2}, {3,3} }; END_OF_foo.C if test 61 -ne `wc -c <foo.C`; then echo shar: \"foo.C\" unpacked with wrong size! fi # end of overwriting check fi if test -f bar.C -a "${1}" != "-c" ; then echo shar: Will not over-write existing file \"bar.C\" else echo shar: Extracting \"bar.C\" \(19 characters\) sed "s/^X//" >bar.C <<'END_OF_bar.C' X X# include "foo.h" END_OF_bar.C if test 19 -ne `wc -c <bar.C`; then echo shar: \"bar.C\" unpacked with wrong size! fi # end of overwriting check fi echo shar: End of shell archive. exit 0
steve@lia (Stephen Williams) (07/23/90)
In article <1990Jul22.234908.2820@lia> steve@lia.com (Stephen Williams) writes: >I have encountered a similar problem while using cfront 2.0 >on a SUN sparc. My code involves a class that looks like >this: > struct pair { short a, b; }; > > class foo { > public: > foo(); > > private: > int x; > static pair y[]; > }; > >The code for "y" looks like: > > struct mangled_pair y[]; > >which the "C" compiler rejects, claiming "unknown size." I ran more tests. Found that g++ also rejects this. However, if I give "y" a dimension (i.e. "y[3]") g++ is happy. This is almost sensible, but the SUN compiler message is unchanged. I am beginning to get annoyed. --Steve Williams.