HDTenEightyP/NetNews huggingface dataset:
From: alfs@ifi.uio.no (Alf Salte)
Subject: oops
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 23 Jul 1992 00:08:10 GMT

I mailed my bug report from wrong account, the report was sent from
account 'gjermuns@ifi.uio.no', if you plan to send any response, please send
the response to alfs@ifi.uio.no as indicated in the E-mail address at the
end of the mail.

Thank you in advance.

Alf

Newsgroups: gnu.g++.bug
From: Sm@cerberus.bhpese.oz.AU (Scott Merrilees)
Subject: looking for g++ patch
Organization: BHP, Newcastle, Australia
Distribution: gnu
Date: Thu, 23 Jul 1992 01:55:48 GMT

I'm looking for the patch that was posted to fix the following problem
when compiling groff.

Thanks, Sm
--
$ gcc -c -I. -xc++ -g1 -O1 -DHAVE_MMAP -DHAVE_RENAME -DWAIT_COREDUMP_0200 -DNO_SYS_WAIT_H errarg.c
errarg.c: In method `errarg::errarg (const char *)':
errarg.c:26: assignment between incompatible pointer types

$ sed -n 26p errarg.c
errarg::errarg(const char *p) : s(p == 0 ? "(null)" : p), type(STRING)
-- 
Scott Merrilees, BHP Information Technology, Newcastle, Australia
Internet: Sm@bhpese.oz.au   Phone: +61 49 40 2132   Fax: ... 2165

Xref: sparky gnu.g++.bug:1222 comp.unix.ultrix:5886
From: ken@tifsim.pac.sc.ti.com (Ken Costilow)
Newsgroups: gnu.g++.bug,comp.unix.ultrix,ti.lang.c++
Subject: Static member doesn't link
Keywords: GCC,Gnu,VAX,Ultrix,Bug
Date: 23 Jul 92 16:43:09 GMT
Reply-To: kenneth@lobby.ti.com (Ken Costilow)
Followup-To: poster
Organization: Texas Instruments Process Automation Center
Apparently-To: uunet!gnu-g++-bug

Hello everyone.

I can`t compile classes with static data members. I was hoping this
was simply one of gcc's many switches, but if so I have been unable
to find it. 

I'm using: Vax3800/Ultrix4.2, gcc 2.1, gas 1.38, binutils 1.9
I have tried the standard ld, gnu ld, as, gas, using l
Newsgroups: gnu.g++.bug
From: lupe@ukw.UUCP (Lupe Christoph)
Subject: Strange .stabs bug in g++ 2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 23:04:41 GMT

I sent this bug report on 20. July. As I have not seen it in the newsgroup,
I take liberty to send it again. Apologies if I just missed it.

I have not seen this bug reported as here. Only the consequences
to libg++ when compiled in this way have been reported.

Environment:
	SPARCstation IPC
	SunOS 4.1.2 with ld-patch (100170-07)
	g++ 2.2.2 without gas (1.38)

Circumstances:
	I'm trying to get UITV2 (patchlevel 8) running with
	g++, as a shared library. I can't use gas, as it does
	not support PIC. UIT compiles PIC code with Sun's
	C++ compiler, both for the static and for the
	dynamic library.

Problem:
	g++ (not gcc) generates erroneous .stabs.
	These .stabs lead to undefined symbols.
	In this example it only happens	when doing static linking.
	In UIT it also happens when linking with the dynamic
	library.

Reproduce with:
	g++ -c -g -V 2.2.2-nogas c.cc
	g++ -static -o x -g -V 2.2.2-nogas c.o

Source (not preprocessed):
#include <stdarg.h>
 
void
x (char *msg, ...)
{
  va_list      ap;
  char        *arg;
  
  /* While the arg is not NULL... */
  while (arg) {
    /* Get the next argument from the  arg list */
    arg = va_arg (ap, char *);
  }
}

main()
{
    x("Hello, World!", 0);
}

Source (preprocessed, empty lines compressed):

# 1 "c.c"
# 1 "/usr/local/lib-sun4/g++-include/stdarg.h" 1 3
extern "C" {
# 1 "/usr/local/lib-sun4/gcc-lib/sun4-sunos4.1/2.2.2/include/stdarg.h" 1 3

# 1 "/usr/local/lib-sun4/gcc-lib/sun4-sunos4.1/2.2.2/include/va-sparc.h" 1

typedef char * __va___list;

# 65 "/usr/local/lib-sun4/gcc-lib/sun4-sunos4.1/2.2.2/include/va-sparc.h"
# 26 "/usr/local/lib-sun4/gcc-lib/sun4-sunos4.1/2.2.2/include/stdarg.h" 2 3

# 67 "/usr/local/lib-sun4/gcc-lib/sun4-sunos4.1/2.2.2/include/stdarg.h" 3

# 2 "/usr/local/lib-sun4/g++-include/stdarg.h" 2 3

}
# 1 "c.c" 2

void
x (char *msg, ...)
{
  __va___list       ap;
  char        *arg;
  
  while (arg) {
     
    arg = __extension__	({  char * __va_temp;	((__builtin_classify_type (__va_temp) >= 12)	? ((ap) += (((sizeof ( char * *) + sizeof (int) - 1) / sizeof (int)) * sizeof (int)) ,	**( char * **) ((ap) - (((sizeof ( char * *) + sizeof (int) - 1) / sizeof (int)) * sizeof (int)) ))	: (((sizeof ( char *) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))  == 8	? ({ union { char * d; int i[2];} u;	u.i[0] = ((int *) (ap))[0];	u.i[1] = ((int *) (ap))[1];	(ap) += 8;	u.d; })	: ((ap) += (((sizeof ( char *) + sizeof (

int) - 1) / sizeof (int)) * sizeof (int)) ,	*(( char * *) ((ap) - (((sizeof ( char *) + sizeof (int) - 1) / sizeof (int)) * sizeof (int)) ))));}) ;
  }
}

main()
{
    x("Hello, World!", 0);
}


----- End Included Message -----


Newsgroups: gnu.g++.bug
From: jac@moonshine.llnl.gov (James A. Crotinger)
Subject: Problems porting code to g++ 2.2.2
Organization: Magnetic Fusion Energy - LLNL
Distribution: gnu
Date: Tue, 28 Jul 1992 19:11:55 GMT

  I recently built and installed gcc 2.2.2 on a SparcStation and I'm
having some problems porting some code which works fine using Sun C++
(and numerous other CFRONT implementations).

  Problem #1: 
    g++ doesn't appear to support the "placement" syntax for operator
    new():

                 new(addr) T;

    where "addr" is supposed to specify the address at which the
    resulting object(s) will be located. I seem to recall that older
    versions of g++ had a different syntax for doing this, but I can't
    recall what it is. What is the rationale for not supporting the
    above anyway?

  Problem #2:
    We have a "generic" matrix class for which we defined a
    variable argument list constructor of the form

       Matrix(TYPE)::Matrix(TYPE)(int i, int j, TYPE first, ...)

    which uses stdarg.h to initialize the matrix from the values
    passed in. gcc will not compile this if TYPE has a constructor.
    For instance, when TYPE == SCLComplex (which has a constructor),
    it gives the following messages:

      ComplexMat.cc:137: \
        warning: cannot pass objects of type `SCLComplex' through `...'
      ComplexMat.cc:137: \
        member `d' with constructor or destructor not allowed in union

    Is what we're trying to do illegal? Or is this just a limitation
    of g++?

  Problem #3:
    We compile the GNU regular expression code with C++.  When I try
    to do this with g++, it gets a segmentation violation in cc1plus.
    If I rename the file from GNURegex.cc to GNURegex.c, so that it
    compiles with the C compiler, it compiles fine (although it does
    give three warnings about prototypes for strlen, abort, and exit
    not being consistent with the "builtin" ones).  Thus I can get by,
    but it bothers me that g++ can't compile this file.

  Jim

--
-------------------------------------------------/\--------------------------
James A. Crotinger     Lawrence Livermore N'Lab // \ The above views are mine
jac@moonshine.llnl.gov P.O. Box 808;  L-630 \\ //---\  and are not neces-
(510) 422-0259         Livermore CA  94550   \\/Amiga\  sarily those of LLNL.

Newsgroups: gnu.g++.bug
From: jf@stan.mit.edu (J. Frisbie)
Subject: g++ 2.2.2 Nested class destructors
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 12:34:43 GMT

On an DECstation 5000 running Ultrix 4.2A, with a generically
installed gcc 2.2.2, compiling the program listed below causes
the following error message:

gcc: Internal compiler error: program cc1plus got fatal signal 11

Constructors and other member functions for the nested class do
not generate the error.  If the destructor is defined inside the
class (as in the second program) it also seems to work.

The program that fails:

class A {
protected:
  class B {
  public:
    ~B();
  private:
    float _datum;
  };
private:
  B *_b;
};

A::B::~B()
{
  _datum = 8.0;
}

A program that compiles:

class A {
protected:
  class B {
  public:
    ~B() { _datum = 8.0; }
  private:
    float _datum;
  };
private:
  B *_b;
};


Newsgroups: gnu.g++.bug
From: rob@cs.man.ac.UK (Robert Marshall)
Subject: recursive inheritance structure provokes compiler loop
Reply-To: rajm@cs.man.ac.uk
Organization: Department of Computer Science, University of Manchester
Distribution: gnu
Date: Tue, 28 Jul 1992 08:09:00 GMT

gcc-new -v recur.cc
Reading specs from /usr/local/gcc/gcc-lib/sparc-sun-sunos4/2.2.2/specs
gcc version 2.2.2
 /usr/local/gcc/gcc-lib/sparc-sun-sunos4/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix recur.cc /usr/tmp/cca02009.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/gcc/gcc-lib/sparc-sun-sunos4/2.2.2/cc1plus /usr/tmp/cca02009.i -quiet -dumpbase recur.cc -version -o /usr/tmp/cca02009.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
recur.cc:4: base class `c' has incomplete type
gcc-new: Internal compiler error: program cc1plus got fatal signal 11

This is recur.cc:
//------------------------------------------------------------
class a {};
class c;
class d : /*virtual */ c, /*virtual */ a {};
class b : /*virtual */ a {};
class c : /*virtual */ a, /*virtual */ d {};
class d : /*virtual */ c, /*virtual */ a {};
--
------------------------------------------------------------------
Robert A.J.Marshall,		EMAIL: rmarshall@cs.man.ac.uk
Room 3.08, IT Building, Department of Computer Science,
University of Manchester, Oxford Road, Manchester, M13 9PL, U.K.
Tel: (+44) 61-275 6269          Fax: (+44) 61-275 6280
------------------------------------------------------------------

Newsgroups: gnu.g++.bug
From: garp@isy.liu.se (Johan Garpendahl)
Subject: "Weird" bug in g++-2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 17:26:05 GMT

Found this bug while compiling InterViews 3.1-beta.
I don't know if it is a multiple inheritance bug or a bug related to 
enums in classes, remove the enum and it compiles, remove the multiple
inheritance and it compiles. At least it won't complain.

I have g++-2.2.2 on a Sun SS1+ with SunOS 4.1.1
Happy hunting ...

	Johan


Example

---------------------------8<-----------------------------
class EnumClass  {
public:
    enum { no_break, pre_break, in_break, post_break };
};

struct PointerA;

class Parent1 {
private:
    PointerA* p1;
};

class  PointerB;

class Parent2 : public EnumClass   {
private:
    PointerB* p1;
};

class PointerC  ;

class Child : public Parent2 , public Parent1 {
protected:
    PointerC* p1; // Complain here
};

main(){}
---------------------------8<-----------------------------

Compile:
lin(garp)127)> g++ -v tt.cc
Reading specs from /usr/local/gnu/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /usr/local/gnu/lib/gcc-lib/sun4/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix tt.cc /usr/tmp/cca02685.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/gnu/lib/gcc-lib/sun4/2.2.2/cc1plus /usr/tmp/cca02685.i -quiet -dumpbase tt.cc -version -o /usr/tmp/cca02685.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
tt.cc:24: request for member `p1' is ambiguous




Newsgroups: gnu.g++.bug
From: h.b.furuseth@usit.uio.NO
Subject: Unwanted warning in g++-1.40.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 23 Jul 1992 04:40:04 GMT

g++ version 1.40.3 (based on GCC 1.40) on sparc.

foo.cc:
	struct foox
	{
	   int foo;
	};
	
	struct barx : virtual foox
	{
	   int bar;
	};

foo.cc: In method barx::~barx ():
foo.cc:9: warning: statement with no effect


Newsgroups: gnu.g++.bug
From: gs4t@virginia.edu (Gnanasekaran  Swaminathan)
Subject: Re: simpler example of previous g++ bug report - unresolved static member
Reply-To: gs4t@virginia.edu (Gnanasekaran  Swaminathan)
Organization: University of Virginia
Distribution: gnu
Date: Wed, 29 Jul 1992 22:45:14 GMT

eric@cathaus.utcs.utoronto.ca (Eric M. Carroll) wonders why he his getting
undefined symbol errors for static member variables in his
programs.

You need a definition for your static variables somewhere in your
program. The static variables must be defined in the file scope and
only once in your program.

|class A {
| public:
|    void test() ;
|
| private:
|    static int value ;
|} ;
|
|void A::test() {
|    value = 0 ;
|}

int A::value = 10; // definition for the static variable A::value

|main() {
|
|    return 0 ;
|}

-Sekar

Newsgroups: gnu.g++.bug
From: jmg@inference.COM (Jeff Greif)
Subject: external C linkage bug in g++ for gcc-2.2.2
Organization: Inference Corporation
Distribution: gnu
Date: Wed, 22 Jul 1992 18:02:16 GMT

I've tried this out on Sparc SunOS 4.1.1 and DG-Aviion-dgux5.4.1.

The attached file foo.cc gets an error "uninitialized constant xxxxx"
when compiled with gcc -g.  None of the other extern "C" lines give
an error.

According to the ARM, p. 118, first annotation, 
extern "C" int a2;
is supposed to be a declaration, not a definition, while
extern "C" { int a1; } 
is a definition, and can only be made a declaration using
extern "C" {extern int a1;}

G++ seems to be confused about this distinction when an aggregate
is involved.  

The actual case that caused the original problem was in dgux5.4.1,
/usr/include/limits.h, which includes various stuff boiling down to
#if defined(__cplusplus)
#define _EXTERN extern "C"
#else
#define _EXTERN extern
#endif
typedef union { unsigned long i[2]; double d; } h_val;
_EXTERN const h_val xxxxx;


---------------------------------------------------------------------
/* Begin foo.cc */

#include <stdio.h>
typedef union { unsigned long i[2]; double d; } zork;
extern "C" const zork xxxxx;
extern "C" const int aaaaa;
extern "C" int bbbbb;
extern const zork yyyyy;


main()
{
    printf("Hello world.\n");
    exit(0);
}
From: joseph@iac.UUCP ( Joseph )
Newsgroups: gnu.g++.bug
Subject: gcc 2.2.2 bug
Date: 25 Jul 92 01:57:02 GMT
Distribution: gnu
Organization: GNUs Not Usenet

The following code fragment produced:
	b3.cc:12: internal compiler error 116, please report

--------------------------------------------
class X {
public: 
  void y(int i);
  
  typedef void
    (X::*IterateFunc)(int k);

  void f(IterateFunc itf);
};
  
void X::f(IterateFunc itf) {
  itf(4);
}
-------------------------------------------------
 

g++ -v -o b3 b3.cc
Reading specs from /lusr/local/lib/gcc-lib/sparc-sunos4/2.2.2/specs
gcc version 2.2.2
 /lusr/local/lib/gcc-lib/sparc-sunos4/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix b3.cc /usr/tmp/cca11205.i
GNU CPP version 2.2.2 (sparc)
 /lusr/local/lib/gcc-lib/sparc-sunos4/2.2.2/cc1plus /usr/tmp/cca11205.i -quiet -dumpbase b3.cc -version -o /usr/tmp/cca11205.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
b3.cc: In method `void  X::f (auto void (class X::*)(int ))':
b3.cc:12: internal compiler error 116, please report

Compilation exited abnormally with code 1 at Fri Jul 24 18:46:51


by the way, this works.

void X::f(IterateFunc itf) {
  (*itf)(4);
}

-pepe
Newsgroups: gnu.g++.bug
From: vbl@z.eecs.umich.edu (Vic Lortz)
Subject: oops, sorry, please ignore previous bug report
Organization: Gnus Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 12:18:43 GMT

Well, nothing like noticing a typo ten seconds after sending off a mail
message... 

class myc {
public:
    myc() { }
    containter<int> fp;
};

should have been:
class myc {
public:
    myc() { }
    container<int> fp;
};

which works :-)

Vic Lortz
Newsgroups: gnu.g++.help
From: colin@eecg.toronto.edu (Colin Plumb)
Subject: Re: generating source code
Organization: University of Toronto
Distribution: usa
Date: 23 Jul 92 03:44:48 GMT

In article <1992Jul21.234225.1664@tc.fluke.COM> mehr@fluke.tc.fluke.com (Manooch Mehr) writes:
>      I am using g++ version 2.1 . Is there an easy way to get the compiler
> to generate C source codes.

There isn't even a hard way.  There's a Very Hard Way Indeed, but I don't want
to even think about tackling it.
-- 
	-Colin
Newsgroups: gnu.g++.help,comp.lang.c++
From: reema@emc.COM (Reema Gupta)
Subject: installing g++ on the sun4-os4
Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu
Date: Tue, 21 Jul 1992 17:12:30 GMT

Hi,

I have been trying to install the g++ compiler on
my sun station using the instructions given in the
README file. But whenever I run the "make" command
I keep getting thie error....

emc1% make
/home7/gcc/bin/gcc -g -DGATHER_STATISTICS -DNO_DYNAMIC_LIBS -O -B../gcc-1.40/ -I. -I. -I./config -g -o ccrt0.o -DOLD_FORMAT -c ccrt0.c
/usr/tmp/cca21410.s:31:Unknown pseudo-op:  '.global'
/usr/tmp/cca21410.s:31:Rest of line ignored. 1st junk character valued 95 ().
*** Error code 1
make: Fatal error: Command failed for target `ccrt0.o'

Can you please help me in locationg the error. I haven't changed 
any of the files except the paths in the Makefile.

Gratefully,

Reema.
From: helz@ecn.purdue.edu (Randall A Helzerman)
Newsgroups: gnu.g++.help
Subject: g++ exception handling
Date: 28 Jul 92 04:02:01 GMT
Organization: Purdue University Engineering Computer Network

I was hacking around in the bison files for gcc 2.2.2 and came 
across the comment which said that gcc 2.2.2 supports ANSI
exception handling syntax, but use at your own risk.

Has anyone had any trouble with them?  Are they pretty robust?

Could someone explain to me the syntax and how they work?  I'm
familier with lispish exception handling--is it similar in
concept?

Thank-you kindly, in advance.
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.help
Subject: Re: g++ executable size
Date: 29 Jul 1992 20:05:01 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <EB.92Jul29092745@ascent.ascent.com> eb@ascent.com (Ed Barton) writes:
>As has often been noted, g++ 2.2.2 on the IBM RS/6000 produces
>enormous executables.  This appears to result from the generation of
>multiple local copies of various method functions.  Are there any
>tricks for reducing this effect, such as by turning on some linker
>flag in the second link phase only that would allow the linker to
>garbage-collect most of the local copies?  Are there any undocumented
>flags that allow greater control over the generation of these possibly
>duplicated copies, as is possible in many PC products?

Read the "man page", g++.1 in the distribution.  The most effective
technique is to use #pragma interface and #pragma implementation.
This will result, if done right, in only one copy of each class's
virtual function table and only one copy of each inline function that
has to be "outlined".  Their use is explained in the man page.




--
Joe Buck	jbuck@ohm.berkeley.edu
From: jacob@informix.com (Jacob Salomon)
Newsgroups: gnu.g++.help
Subject: Re: generating source code
Summary: So g++ 2.1 really is available? Where?
Keywords: 2.1
Date: 23 Jul 92 16:18:09 GMT
Expires: 12/31/92
Distribution: usa
Organization: Informix Software, Inc.

In article <1992Jul21.234225.1664@tc.fluke.COM>
  mehr@fluke.tc.fluke.com (Manooch Mehr) writes:
>
> hi :
>
> I am using g++ version 2.1 . Is there an easy way to get the
> compiler to generate C source codes.
>      Please, email your response.
>
>	Manooch

Hello manooch and other interested parties.

Everyone I have asked, including info from FSF, indicates that the
highest version available for g++ is 1.40 or so, while the highest
version for the g++ library is 2.2.2 or so.

How are so many folks talking about g++ 2.1?  Since I am not on the
internet (a long story unto itself) I cannot do anonymous FTP's even
if I am handed the addresses on a silver LCD screen.  Would someone
_please!_ e-mail to me or post info about where I can get the sources
via e-mail?

Also, the postings I have seen in this newsgroup leave me confused:
Do I need gcc to compile g++?  Or can I do it with my native C
compiler?  (My target is an HP 9000/800 series machine.)

If you reply by e-mail, please reply to one of:

jacob@informix.com
uunet!informix.com!jacob

Thanks much.

		-- Jake
-- 
----------------Obligatory smart-$$$ remark:---------------------
| There's two kinds of people: Those who categorize people into |
| two groups and those who don't.   (Barth's Aging proverb.)    |
-----------------------------------------------jacob@informix.com
Newsgroups: gnu.g++.help
From: hacrat@CATFISH.LCS.MIT.EDU (Nate Osgood)
Subject: Mutually recursive class references
Organization: MIT Laboratory for Computer Science
Date: Mon, 27 Jul 1992 19:40:51 GMT


I'm hoping to switch from g++ version 1.40 to gcc 2.2.2 as my primary
development platform.  Unfortunately, it seems that gcc 2.2.2 has a difficulty
with some of the code I've been compiling with 1.40.  I'm hoping that perhaps
someone on this newsgroup might be able to suggest a  simple solution to the
incompatibility.

The problem occurs when a method of a given class has a prototype that refers
to a class that has not yet been declared, but the method is used AFTER that
other class is declared.  As the GNU info documentation for gcc 2.2.2 notes,
for an arbitrary function the function prototype can be moved so that it also
occurs AFTER the structure (or class) definition, rather than before it.  But
if the function is a METHOD, one wants to put the declaration immediately
inside the class definition.  In this case, the code indicates mthe problem
more clearly than prose:

class first
{
 public:
  foo(class second);  /*  Reference to class that does not yet exist.
			Note that the declaration of class first cannot
			FOLLOW that of class second, since class second
			contains an OBJECT of type first
			*/
};

class second
{
  first f;		/*  Here is the reference to class first -- the need 
			for this reference forces class second to textually 
			follow class first in the program */

 public:
  
  bar(class second s) { return(f.foo(s)); }
			/*  Since class second has now been defined, gcc 2.2.2
			thinks that we are calling method foo of class first
			with a different type than it is expecting as a method
			argument.  It gives the complaint:


			 bad argument 0 for function `first::foo 
			(class first::second)' (type was class second)

			*/
};



	Would anyone happen to know if there an obvious workaround to this
problem that would not require removing the method from the class first
definition or converting the parameter to a "class second *"?
	
	Any help greatly appreciated!

	Nate Osgood

-- 
-------------------------------------------------------------------------------
Nate Osgood			| ARPA: hacrat@catfish.lcs.mit.edu
CS Graduate Student		| 
MIT LCS Room NE43-636		| UUCP: ...!uunet!catfish.lcs.mit.edu!hacrat
Newsgroups: gnu.g++.help
From: grunwald@tile.cs.colorado.edu (Dirk Grunwald)
Subject: Re: generating source code
Followup-To: gnu.g++.help
Reply-To: grunwald@foobar.cs.colorado.edu
Organization: University of Colorado at Boulder
	<5378@lhdsy1.lahabra.chevron.com>
Date: Fri, 24 Jul 1992 04:59:39 GMT


I would hasten to disagree with all of your points.

+ I find GCC produces equivilent or better code than the supplied compiler
  on the machines I use (Sequent i386, SPARC, DECstation,.

+ Most of the errors in g++ appear to stem from incorrect implementation
  in the g++ front-end, vague C++ language semantics (``moving target'').
  Since gcc uses the same back-end, the backend tends to be very robust
  and stable.

+ You can not debug cfront-produced C code. That's a major reason for
  using a real compiler (or having a way to pass this information through
  your C compiler).

+ Cfront can't do somethings G++ can do, because it must translate to C
  (i.e. it has restrictions on 'inline' functions).

All this said and done, I still think it's useful to have a C backend
to gcc/g++ -- in part, because I want to use g++ on a particular
machine (KSR-1) for which I don't want to build a backend (it's a pain
to debug, and secondary to my immediate goals).
From: garbett@utkvx4.utk.edu (Garbett, Shawn)
Newsgroups: gnu.g++.help
Subject: Inline
Date: 23 Jul 92 17:56:00 GMT
Organization: University of Tennessee Computing Center
News-Software: VAX/VMS VNEWS 1.41

What's the proper way to declare an inline function in a .h file?
I prefixed a function with inline and got all kinds of errors when
I put the .o into an archive. Just a small example would be great,
especially one that would be compatible with an archive (.a) .

Garbett@utkvx.utk.edu
.
Newsgroups: gnu.g++.help