HDTenEightyP/NetNews huggingface dataset:
From: djd@uk.ac.reading.CS.CSg (David J Dawkins)
Subject: Bug in overloading new?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 11:39:49 GMT

G++2.2.2 does not seem to be able to handle overloading of the new operator
where arrays are concerned.

I am not sure whether this is a 
  - bug,
  - 'sorry, not implemented' or
  - misunderstanding on my part

Example :

------------------------------------->8------------------------------
#include "stdlib.h"

class Segment;

void *
operator new( size_t sz, Segment * )
{
	return malloc(sz);
}

main()
{
	Segment *s = 0;

	char *c = new {s} char;
	char *b = new {s} char[4];
}
------------------------------------->8------------------------------

Compilation gives:

valhalla% g++ c.c  
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 c.c /usr/tmp/cca16258.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca16258.i -quiet -dumpbase c.cc -version -o /usr/tmp/cca16258.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
c.c: In function `int  main ()':
c.c:16: placement syntax invalid for arrays

valhalla% uname -a
SunOS valhalla 4.1.1 1 sun4c

Do I have the syntax wrong? (This compiles OK under cfront3.0.1, but with
round brackets instead of braces). 

[ If I have the syntax wrong, this is because I have no docs later than 
October 19th 1991 (for version 1.40.3). Can someone _please_ let me know
where more up-to-date docs are. ]

I looked up the relevant code in cp-init.c 

    File: "cp-init.c" [Read only] line 2947 of 4019 --73%-- 
Function: tree build_tree( tree, tree, tree, int)

  if (has_array) 
    {
      if (placement)
        {
          error ("placement syntax invalid for arrays");
          return error_mark_node;
        }

It looks like it should be a 'sorry, not implemented'. What gives?

Dave Dawkins
--
djd@csg.cs.rdg.ac.uk
djd@csug.cs.rdg.ac.uk
davidd@integ.uucp



Newsgroups: gnu.g++.bug
From: gb@cs.purdue.edu (Gerald Baumgartner)
Subject: GCC-2.2.2: cp-decl.c (grok_reference_init): no type conversion done
Organization: Department of Computer Science, Purdue University
Distribution: gnu
Date: Sat, 3 Oct 1992 19:01:29 GMT

For the following two lines of input (from ARM, p. 154, bottom)

	double& rd2 = 1;
	const double& rcd2 = 1;

GCC-2.2.2 produces the error messages

	stdin:1: invalid type conversion for reference 
	stdin:2: invalid type conversion for reference 

After applying the bug fix below, we get the correct error message

	stdin:1: type mismatch in initialization of `rd2' (use `const') 

and the assembly output (for a Sparc)

	.data 
	        .align 8 
	__$tmp_0: 
	        .double 0r1 
	        .global _rcd2 
	        .align 4 
	_rcd2: 
	        .word __$tmp_0 

Here's the bug fix:

--Gerald


*** cp-decl.c~	Fri May 22 15:42:16 1992
--- cp-decl.c	Sat Oct  3 13:55:06 1992
*************** grok_reference_init()
*** 4923,4929 ****
  	      && TREE_THIS_VOLATILE (init))
  	    errstr = "cannot initialize a reference to T with a volatile T";
  	}
!       else if (TREE_CODE (TREE_TYPE (type)) == TREE_CODE (TREE_TYPE (init)))
  	{
  	  init = convert (TREE_TYPE (type), init);
  	}
--- 4923,4929 ----
  	      && TREE_THIS_VOLATILE (init))
  	    errstr = "cannot initialize a reference to T with a volatile T";
  	}
!       else if (TREE_CODE (TREE_TYPE (type)) != TREE_CODE (TREE_TYPE (init)))
  	{
  	  init = convert (TREE_TYPE (type), init);
  	}

Newsgroups: gnu.g++.bug
From: mschedlb@world.std.com (Martin J Schedlbauer)
Subject: undefined symbol error
Organization: The World Public Access UNIX, Brookline, MA
Distribution: gnu
Date: Fri, 25 Sep 1992 19:25:12 GMT

Platform: Esix SYSvR4.0.4
Version: gcc-2.2.2 and libg++-2.2

When compiling a C++ program (RichText widget) I get the following loader
errors:

Undefined                       first referenced
 symbol                             in file
__builtin_delete                    ../libXc.a(xtextview.o)
__builtin_new                       ../libXc.a(xtextview.o)
ld: rt_test: fatal error: Symbol referencing errors. No output written to
rt_test
*** Error code 1 (bu21)


I tried to grep for these symbols in the library and the source and can't
find them anywhere.

What is causing these undefined symbol errors?

	thanks,
	...Martin

	martin@mjs486.uucp
	mschedlb@world.std.com



Newsgroups: gnu.g++.bug
From: ro@techfak.uni-bielefeld.DE (Rainer Orth)
Subject: g++ 2.2.2 ss-920925 bug: cannot call private method
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 08:30:17 GMT

g++ 2.2.2 ss-920925 on a SPARCstation ELC running Solaris 2.0 failed to
compile two source files from groff 1.06 which used to work fine with the
2.2.2 distribution on SunOS 4.

The problem can be reduced to the following minimal test case:

----- privbug.ii -------------------------------------------------------------
class reference {
private:
  void contains_field() const;
public:
  void classify();
};
void reference::contains_field() const
{
}
void reference::classify()
{
  contains_field();
}
------------------------------------------------------------------------------

g++ produces the following error message:

ro@efeu 1275 > gcc -v -c privbug.ii
Reading specs from /vol/gnu/lib/gcc-lib/sparc-sun-solaris2.0/2.2.2/specs
gcc version 2.2.2
 /vol/gnu/lib/gcc-lib/sparc-sun-solaris2.0/2.2.2/cc1plus privbug.ii -quiet -version -o /tmp/cca0042A.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
privbug.ii: In method `void reference::classify ()':
privbug.ii:8: the method void reference::contains_field ()const  is private
privbug.ii:12: within this context

This seems to be wrong; it should always be possible for a public method to
call a private method.

Omitting the `const' specifier corrects the problem.

-----------------------------------------------------------------------------
Rainer Orth, Technical Computer Science, University of Bielefeld

Internet: ro@TechFak.Uni-Bielefeld.DE


Newsgroups: gnu.g++.bug
From: sullivan@csn.org (Steve Sullivan)
Subject: template function def error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 15:07:15 GMT

It appears that the function definition:
   template<type> func() {...}
is not handled correctly by g++.

The following program doesn't compile under g++ (gcc) 2.2.2
on a Sparc 2, SunOs 4.1.  Yet it seems to me it should.
Is there a fix for this?

===== begin program =================
template <class T>
class QI {
public:
  QI();
  void print();
private:
  T item;
  QI *next;
  };



template <class T>
QI<T>::QI() {}


template <class T>
void QI<T>::print();

// **** following line is line 21, and causes error:
QI<int> afunc() {
   QI<int> alpha;
   return alpha;
   }

main () {
   QI<int> beta;
   }
=============== end program ===================

diagnostics printed by g++:

> g++ -c testc.cc
testc.cc:21: semicolon missing after declaration of `QI<int>'
testc.cc: In function `int  afunc ()':
testc.cc:23: aggregate value used where an integer was expected
Exit 1


Newsgroups: gnu.g++.bug
From: solomon@cs.wisc.edu (Marvin Solomon)
Subject: g++ 2.2.2 core dumps with templates
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 4 Oct 1992 09:12:56 GMT

Script started on Sun Oct  4 14:11:14 1992
% cat bug.c
class C { };

template <class T> class Ref { };

template <class T> C &operator<<(C &, Ref<T> &);

void f() {
        C c;
        char *p;
        c<<p;
}
% g++ -v -c bug.c
Reading specs from /usr/gnu/lib/gcc-lib/decstation/2.2.2/specs
gcc version 2.2.2
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__ANSI_COMPAT -DMIPSEL -DR3000 -DSYSTYPE_BSD -D_SYSTYPE_BSD -Dbsd4_2 -Dhost_mips -Dmips -Dultrix -Dunix -D__ANSI_COMPAT -D__MIPSEL__ -D__R3000__ -D__SYSTYPE_BSD__ -D___SYSTYPE_BSD__ -D__bsd4_2__ -D__host_mips__ -D__mips__ -D__ultrix__ -D__unix__ -D__ANSI_COMPAT -D__MIPSEL -D__R3000 -D__SYSTYPE_BSD -D___SYSTYPE_BSD -D__bsd4_2 -D__host_mips -D__mips -D__ultrix -D__unix -D__LANGUAGE_C__ -D__LANGUAGE_C -DLA
NGUAGE_C bug.c /usr/tmp/cca03107.i
GNU CPP version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/cc1plus /usr/tmp/cca03107.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca03107.s
GNU C++ version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix compiled by GNU C version 2.2.2.
/usr/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11
% exit
exit

script done on Sun Oct  4 14:11:36 1992

Newsgroups: gnu.g++.bug
From: jj00@etherm.co.UK (John Juer)
Subject: Apparent g++ problem
Organization: Eurotherm Controls Limited.
Distribution: gnu
Date: Thu, 1 Oct 1992 14:04:24 GMT

gcc version 2.2.2, on Interactive version 3.0

It seems that when compiling without the optimiser and with debug on
in-line functions do not get in-lined, resulting in undefined symbols
on the final link.

(jay)$ g++ -c -O -I../include -Di386ix prctxt.C
(jay)$ nm prctxt.o | fgrep _12symbol_stacki
the final link worked fine

(jay)$ g++ -c -g -I../include -Di386ix prctxt.C
(jay)$ nm prctxt.o | fgrep _12symbol_stacki
__12symbol_stacki   |       0|extern|                  |      |     |

__12symbol_stacki was undefined on the final link.

This was an in-line function, here is an extract from the header file.

#pragma interface
class symbol_stack
{
.....
public:
  symbol_stack(int sz = 20 ) 
  {
    top = s = new symbol*[size = sz];
  }
.....
};



Since you can run with -O and -g its not really a problem once you
know what is going on!


Newsgroups: gnu.g++.bug
From: fjh@munta.cs.mu.oz.au (Fergus James HENDERSON)
Subject: Re: g++2's vector memory allocation and malloc.o
Organization: Computer Science, University of Melbourne, Australia
Distribution: gnu
Date: Tue, 29 Sep 1992 10:09:19 GMT

hacrat@catfish.lcs.mit.edu (Nate Osgood) writes:

>Hi.  I'm using g++ 2.2.2 on Sun4 hardware, running SunOS release
>4.1.2.  I've noticed something that I believe is not a bug in g++ but
>rather an incompatibility between g++ 2.2.2 and the standard
> routines for use in debugging heap-based allocation problems.  i'm
>wondering whether other people on this group might have encountered
>this problem before and/or would be able to describe how to get around
>it or be able confirm its character (as a NON bug)

You are right: this is NOT a bug.

>  in particular, after hacking around at the assembly language level
>i've noticed that g++ 2.2.2's memory layout for vectors of objects
>differs substantially from its layout for single objects
[...]
>g++ 2.2.2 seems to have a somewhat "trickier" strategy.  for
>non-vector objects, the format seems to be the same.  for at least some vector
>objects, it seems that another format is used:

Yes. The objects in question are those with destructors.
When you invoke vector operator delete on a vector of objects with destructors,
the destructor is called for each object. For this reason, the compiler needs
to save the number of elements, etc.

>class Foo 
>{
> public:
>  Foo() {}
>  ~Foo() {}
>};
> 
>main()
>{
>  Foo *p = new Foo[1];
> 
>  delete p; 
That should be
   delete[] p;

(or with some old compilers, "delete[1] p;" )

>}

You would be best advised to read an up-to-date C++ book which discusses
dynamically allocating and deallocating arrays.

If changing the "delete p" to "delete[] p" doesn't fix your problem, then
you will probably need a new version of malloc.o for g++.
-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

Newsgroups: gnu.g++.bug
From: gs4t@kelvin.seas.virginia.edu (Gnanasekaran  Swaminathan)
Subject: g++2.2.2 generates incorrect RS6000 assembly code
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 4 Oct 1992 12:00:05 GMT

g++ 2.2.2 generates incorrect RS6000 assembly code for
the following program. The error goes away if one 
of the following are true:
	1: if the file name has only one '.' instead of two as in A.B.cc
	2: if there are no #pragma's
-Sekar

cd /tmp/z/
c++ -g -c A.B.cc -I. -v
Reading specs from /tmp/z/lib/gcc-lib/rs6000/2.2.2/specs
gcc version 2.2.2
 /tmp/z/lib/gcc-lib/rs6000/2.2.2/cpp -lang-c++ -v -I. -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D_IBMR2 -D_AIX -D___IBMR2__ -D___AIX__ -D___IBMR2 -D___AIX -D__CHAR_UNSIGNED__ -g A.B.cc /tmp/ccfesD0V.i
GNU CPP version 2.2.2
 /tmp/z/lib/gcc-lib/rs6000/2.2.2/cc1plus /tmp/ccfesD0V.i -quiet -dumpbase A.B.cc -g -version -o /tmp/ccfesD0V.s
GNU C++ version 2.2.2 compiled by GNU C version 2.2.2.
 as -o A.B.o /tmp/ccfesD0V.s
Assembler:
/tmp/ccfesD0V.s: line 12: Error In Syntax 
/tmp/z/bin/gcc: A.B.o: No such file or directory

Compilation exited abnormally with code 1 at Sun Oct  4 16:51:05

// file A.B.cc 
#pragma implementation
#pragma interface
extern void (*fp)(const char*, const char*);

struct A
{
  void                  f(const char* msg);
};

void A::f(const char* msg)
{
   (*fp)("test", msg);
}


Newsgroups: gnu.g++.bug
From: klamer@mi.el.utwente.NL (Klamer Schutte)
Subject: Re: open g++ bugs
Organization: University of Twente, BSC-El
Distribution: gnu
Date: Fri, 25 Sep 1992 11:25:33 GMT

In <9209232143.AA22193@cygnus.com:> mrs@cygnus.com (Mike Stump) writes:

:>You can find them in:

:>        mizar.docs.uu.se:/ftp/pub/incomming/g++.bugs

:>or in a little while permanently in:

:>        mizar.docs.uu.se:/ftp/pub/gnu/g++.bugs


:>It has 777 bug reports totaling 6.7 megs.

This is a bit big :-). Perhaps it is a good idea to have the groupings
which are present in the file available as seperate files?

And is this list kept up-to-date, or just a snapshot of the current status?

Klamer


--
Klamer Schutte			Tel: +31-53-892778	Fax: +31-53-340045
Faculty of electrical engineering -- University of Twente, The Netherlands
preferred: klamer@mi.el.utwente.nl     SMTP: klamer@utelmi01.el.utwente.nl

Xref: sparky gnu.g++.help:1309 gnu.gcc.help:2264 comp.lang.c++:14640
From: mcs@wet.UUCP (Gil Nardo)
Newsgroups: gnu.g++.help,gnu.gcc.help,comp.lang.c++
Subject: Re: Problem with gcc(++) 2.2.2
Date: 7 Oct 92 03:22:35 GMT
Followup-To: gnu.g++.help
Organization: Wetware Diversions, San Francisco

fred@gna.axis-design.fr (Frederic Cirera) writes:
[c++ source code deleted]
> 
> mess.h: In method `Message::~Message ()':
> In file included from dbtools.C:19:
> mess.h:16: too few arguments for method `operator delete'
> 

Try defining your delete function with a void, i.e.,

    ~Message(void) {};

This may appease your compiler beast - 8Q.
-- 
Gil Nardo                  | mcs@wet.com
Migrant Computing Services | (415)664-1032
1032 Irving Street, #435   |-----------------
San Francisco, 94122       | Supernova = *!
Newsgroups: gnu.g++.bugs,gnu.g++.help
From: skdutta@ucs.att.com (Saumen Dutta)
Subject: gcc2.2.2 problem / bug ?
Organization: AT&T Universal Card Services, Jacksonville FL
Date: Mon, 5 Oct 1992 03:48:47 GMT


I have following problems with gcc.

While compiling the following program ( actually part of a big program
but shortened for convinience) it does'nt complain anything but while executing
it gives a BUS error. However if I interchange the position of xdisp and coord
in the definition of xwin, (i.e. class xwin: virtual public coord, virtual
public xdisp{.... ) it works fine!. Can somebody tell me what is going on.
I could not find anything from the gdb. I am using gcc2.2.2. I understand
that I didn't have to use virtual classes, but I guess it is syntactically okay!
Any feedback will be appreciated!!

 
class coord{
 public:
    double ctm[6]; 
    coord();
};

//--------------------------------------------------------

class xdisp{
  
public:
  xdisp();
};

//------------------------------------------------------------

class xwin: virtual public xdisp, virtual public coord{

public:
  xwin();

};

//----------------------------------------------------------



main()
{
	xwin tryme;
}


xwin::xwin():xdisp(), coord()
{

}


xdisp::xdisp()
{
}


coord::coord(){
	ctm[0] = (double)1.0;
	ctm[1] = ctm[2] = (double)0.0;
	ctm[4] = (double)1.0;
	ctm[5] = (double)0.0;
} 



If you decide to post the reply please send a e-mail too.
From: sjm@merlin.anu.edu.au (Stephen Meatheringham)
Newsgroups: gnu.g++.help
Subject: Installing g++ (2.2.2) and the g++-include directory
Date: 6 Oct 92 05:49:02 GMT
Organization: Mt. Stromlo and Siding Spring Observatories

Hi All,
   I am trying to install gcc and g++ (2.2.2) on our Sun Sparcstations running
SunOS4.1.2.    Everything seems to go fine - no errors or crashing out during 
the making and installation.  But ... when we try to compile a C++ program I
get the following :
sjm@moggie> g++ -c sjm.c
sjm.c:2: iostream.h: No such file or directory

Further digging around in the man page suggests there should be a directory
such as /usr/local/lib/g++-includes which contains the include files.   I'm
afraid there's no such beastie to be found, all the other include files for
gcc look okay in /usr/local/lib/gcc-lib/...

We do have the Sun supplied C++ compiler and that works fine, when you specify
-I/lusr/lang/SC1.0.1/include.   Do we have to specify the same for g++?  If so
why the discussion about g++-include in the man page?

-- 

				Stephen Meatheringham
				Mt. Stromlo Observatory
				Private Bag, Weston Creek P.O.
				ACT 2611, AUSTRALIA
				email : sjm@moggie.anu.edu.au
Xref: sparky gnu.g++.help:1305 gnu.gcc.help:2260 comp.lang.c++:14575
From: fred@gna.axis-design.fr (Frederic Cirera)
Newsgroups: gnu.g++.help,gnu.gcc.help,comp.lang.c++
Subject: Problem with gcc(++) 2.2.2
Date: 6 Oct 92 00:07:55 GMT
Organization: GNA c/o Axis Design 119 rue de Flandre 75019 Paris


Hy network friends.


gcc-2.2.2 dosen't work when I compile this code.

// This may look like C code, but it is really -*- C++ -*-

#ifndef _MESSAGE_H_
#define _MESSAGE_H_

#include "window.h"
#include "event.h"

enum MsgType{ normal = 0, error, work, help};

class Message : public Window {
public:
	Message( char *, MsgType = normal, char * = 0);
	Message( int, int, MsgType = normal, char * = 0);

	~Message() { ; }

	ProcessCode Process( Event *);
};

#endif /* _MESSAGE_H_ */



Produce this error.

mess.h: In method `Message::~Message ()':
In file included from dbtools.C:19:
mess.h:16: too few arguments for method `operator delete'



All ideas are welcome on my e-mail box. Thanks.

Fred.
-- 
   +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
   | Frederic CIRERA             |  E-mail : fred@gna.axis-design.fr        |
   | Av de la republique         |  Home   : 42 05 17 66                    |
   | 91374 Verrieres le buisson  |  Office : 69 20 45 05                    |
Newsgroups: gnu.g++.help,gnu.emacs.help
From: aed@netcom.com (Andrew Davidson)
Subject: Re: TAGS FIles for g++
Date: Mon, 28 Sep 92 17:13:59 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)

In article <1992Sep26.192221.16508@jack.sns.com> steve@jack.sns.com (J. Steven Harrison) writes:
>Okay I new at this....
>
>I do I generate a TAGS for for G++. 
>
>If I use ctags+ from USL then I get from emacs: not a valid TAG file.
>
>Any help is appreciated.
>

you probably want to pick up a version of tags++. it is a modified
version of the tags stuff from emacs that has been inhanced to better
support c++. Sorry I do not know where you can find it

Andy


-- 
----------------------------------------------------------------
                 "Oh mighty warrior of fine fighting stock, may
			I inquire; what's up Doc?" 
				Bugs Bunny in
				What's Opera Doc	
Andrew E. Davidson
andy@cats.com
aed@netcom.COM
-----------------------------------------------------------------
Xref: sparky gnu.g++.help:1304 comp.lang.c++:14561
From: heiko@uwesa.hanse.de (Heiko Weber)
Newsgroups: gnu.g++.help,comp.lang.c++
Subject: undefined symbols with gcc2.2.2
Date: 5 Oct 92 19:34:53 GMT

Hello !

I've tried to compile some C++ files with the gcc2.2.2 - but the
I am unable to link the stuff together:

g++ -IMx Hello.o HelloApp.o -L /usr/X/lib -LMx -lMx -lXm -lXt -lX11 -lsocket -lnsl -o HelloApp
Undefined			first referenced
 symbol  			    in file
.L_f22_e                            Mx/libMx.a(MxAppl.o)
.L_B5_e                             Mx/libMx.a(MxUIComp.o)
.L_B5                               Mx/libMx.a(MxUIComp.o)
.L_f19_e                            Mx/libMx.a(MxMainW.o)
.L_f13_e                            Mx/libMx.a(Main.o)
ld: HelloApp: fatal error: Symbol referencing errors. No output written to HelloApp
*** Error code 1 (bu21)

make: fatal error.

The library libMx.a is my own, simple collection of C++ classes. The
same files compiles and links (and run) without any problem under
HP Unix 8.05 with the HP C++ develop. environment. Viewing to the
undefined symbols of the listed object-files with 'nm -u' results
into the same undefined symbols, for example '.L_f19e' ...

Why does the gcc produce these symbols, is there a workaround ?

Thanks in advance

   Heiko
-- 
| Heiko Weber jun. | heiko@uwesa.hanse.de | carrier: 049-4169-448 |
| D-2151 Sauensiek | Loehe 5 |  Germany   | voice:  049-4169-1366 | 
+------------------+----------------------+-----------------------+
Newsgroups: gnu.g++.help,comp.lang.c++
From: pwang@mcs.kent.edu
Subject: conversion and void *
Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu
Date: Sat, 3 Oct 1992 03:21:27 GMT


It is an error to assign a void * type to int * say.
But it is O.K to pass a void * argument to an int * formal argument.

Any comments?
Thanks
Newsgroups: gnu.g++.help,comp.lang.c++
From: tootill@sde.mdso.vf.ge.COM (Tootill Ed)
Subject: g++ install
Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu
Date: Tue, 6 Oct 1992 19:55:19 GMT

I need expanded installation instructions for g++ compiler.

The README file directs me to read the comments at the top of the Makefile for flags to use during install, but the Makefile does not contain comments about flags. 

The README directs me to make several links.  Is this necessary or just the programmers style. 

Also, do I need to load g++ at the same directory level as gcc?

Rhetorical comment: Why is "free" synonymous with "who needs documentation, let them figure it out the hard way".
 
Ed Tootill - tootill@sde.mdso.vf.ge.com

Xref: sparky gnu.g++.help:1308 comp.lang.c++:14636