[comp.lang.c++] More cfront -> ANSI C compiler problems

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.