HDTenEightyP/NetNews huggingface dataset:
From: eh@astbe.UUCP (H.Dr.Ehling)
Subject: gcc-2.2.2, core in expmed.c
Reply-To: astbe!eh@risbe.ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 16 Oct 1992 11:55:52 GMT

When compiling something in groff (gtbl, gtroff ??) I encountered a
core dump. Cause was "comparison == 0" in expmed.c.  Apparent fix was to
test that beforehand, didn't look for reason, but had no bad effects
after.

Best Regards -- H.J. Ehling

-- 
Hans-Juergen Ehling | eh@astbe.uucp
                    | Voice:  +49 30/828-2497 Fax: +49 30/828-2483
AEG Softwaretechnik, Hohenzollerndamm 150,   D1000 Berlin 33, Germany

---------- Diffs -----------------
This ChangeLog diff is corrupted, because other entries have been
removed:
*** gcc-2.2.2/ChangeLog	Mon Jun 15 15:28:03 1992
--- ../gcc-2.2.2a/ChangeLog	Thu Oct 15 18:34:20 1992
***************
*** 1,3 ****
--- 1,19 ----
+ Thu Oct 15 12:43:41 1992  H.Dr.Ehling  (eh at risbe)
+ 
+         * expmed.c: checked "comparison" non-null, before doing
+         GET_CODE (comparison)
+ 
  Sun Jun 14 16:30:07 1992  Richard Stallman  (rms@mole.gnu.ai.mit.edu)
  
          * Version 2.2.2 released.
*** gcc-2.2.2/expmed.c	Wed May 27 22:52:20 1992
--- ../gcc-2.2.2a/expmed.c	Wed Sep  2 16:52:09 1992
***************
*** 2743,2749 ****
        last = get_last_insn ();
  
        comparison = compare_from_rtx (op0, op1, code, unsignedp, mode, 0, 0);
!       if (GET_CODE (comparison) == CONST_INT)
          return (comparison == const0_rtx ? const0_rtx
                  : normalizep == 1 ? const1_rtx
                  : normalizep == -1 ? constm1_rtx
--- 2743,2749 ----
        last = get_last_insn ();
  
        comparison = compare_from_rtx (op0, op1, code, unsignedp, mode, 0, 0);
!       if (comparison && GET_CODE (comparison) == CONST_INT)
          return (comparison == const0_rtx ? const0_rtx
                  : normalizep == 1 ? const1_rtx
                  : normalizep == -1 ? constm1_rtx

Newsgroups: gnu.g++.bug
From: gb@cs.purdue.edu (Gerald Baumgartner)
Subject: GCC 2.2.2: internal compiler error 116
Organization: Department of Computer Science, Purdue University
Distribution: gnu
Date: Sun, 11 Oct 1992 17:42:53 GMT

GCC told me to report this error:

	test.cc: In method `int  c::bar ()':
	test.cc:6: internal compiler error 116, please report

Here's the test file:

	class c
	  {
	   public:
	    int (c::*fptr) (void);
	    int foo (void) { return 0; };
            int bar (void) { fptr = &c::foo; return fptr (this); };
	  };

--Gerald

Newsgroups: gnu.g++.bug
From: mano@arch04.acri.FR (S Manoharan)
Subject: gcc 2.2.2 bug (for C++)
Reply-To: mano@arch04.acri.fr
Organization: Advanced Computer Research Institute
Distribution: gnu
Date: Fri, 9 Oct 1992 11:19:52 GMT

class Foo {
protected:
   int foo()	{ return 1; }
};

class Bar : public Foo {
public:
   int bar()	{ return (Foo::foo()); }
};

does not work. Should it or should it not?


---
S Manoharan                                 Email    : mano@acri.fr
Advanced Computer Research Institute        Fax      : +33 72 35 84 10
1 Boulevard Marius Vivier-Merle             Voice    : +33 72 35 84 00
69443 Lyon Cedex 03 France                  

Newsgroups: gnu.g++.bug
From: coactive@netcom.com (Coactive Aesthetics)
Subject: Re: et2.2 and g++
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Wed, 7 Oct 1992 11:11:17 GMT

Aaron T. Smith (ats@lems.brown.edu) wrote:
: Has anyone been able to compile et2.2 using gcc-2.2.2?  

I was able to compile et2.2 using gcc2.2.2 with a few modifications on
Sun and NeXT machines (I seem to remember that you need to redefine the
MetaImpl macros and a few Class implementations to declare the static
members). However, you will find that et3.0-alpha will compile and work
much better.

Given that 3.0 is an alpha, there are a few bugs that need to be worked out.
But, the awesome number of features in the new release (switchable Mac
and Motif look-n-feel, automatic selection of filters for importing
documentation, etc.) offset the drawbacks. I have to say, this software
really shows the potential of using the C++ programming language. Hopefully
a beta or full release of 3.0 will soon be forthcoming.

Otto

P.S.	Is there a mailing list for ET++?

---
Otto Lind                  Coactive Aesthetics
otto@coactive.com          P.O. Box 425967, San Francisco, CA 94142
netcom!coactive!otto       voice:(415)626-5152    fax:(415)626-6320


Newsgroups: gnu.g++.bug
From: jbuck@forney.berkeley.edu (Joe Buck)
Subject: Re: delete[] on g++-1.42
Organization: U. C. Berkeley
Distribution: gnu
Date: Tue, 13 Oct 1992 19:07:13 GMT

In article <9210121347.AAdurin08489@durin.uio.no> h.b.furuseth@usit.uio.NO writes:
>It would be nice if `g++-1.42 -Wall' either accepted `delete[] x;' or
>did not warn about `delete[size] x;'.

No one is fixing language problems in 1.42, as best I can tell; the only
changes that have been made to it are to make it compile with gcc-1.42.
If you want a compiler that accepts delete [] x and templates, and that
can do multiple inheritance correctly most of the time, get g++-2.2.2.



--
Joe Buck	jbuck@ohm.berkeley.edu

Newsgroups: gnu.g++.bug
From: fredr@raven.bu.edu (Fred Richardson)
Subject: Bug in g++?
Organization: I can do that too !!!
Distribution: gnu
Date: Fri, 9 Oct 1992 21:18:59 GMT

I think I've found a bug which occurs when virtual functions are
overriden and called by the construction routine.  It looks like if a
virtual function is over riden by a derived class and it is called in the
base classes constructor then only the base classes implementation of the
virtual function will be called.  But this only happens in the base classes
constructor routine.

Here's a long example
(sorry, I could think of a shorter one):

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
/******************************************************************************
This is a test of virtual function overriding.


******************************************************************************/

#include <stdlib.h>
#include <String.h>
#include <string.h>

class base
{
  public:
    base(char* astr);
    virtual char* testVirtual();
    void test();
  protected:
    char* theStr= NULL;
};

class derived : public base
{
  public:
    derived(char* astr);
    char* testVirtual();  // Over-ridden virtual function
};

 base::base(char* astr)
{
    theStr = strdup(astr);
    test();  // call during initialization
}

char* base::testVirtual()
{
    String s = theStr;
    s = "base class: " + s + "\n";
    return(s);
}

void base::test()
{
    cout << testVirtual();
}

 derived::derived(char* astr) : base(astr)
{
}

char* derived::testVirtual()
{
    String s = theStr;
    s = "derived class: " + s + "\n";
    return(s);
}

int main(int argc, char *argv[])
{
    if (argc < 2)
	return(0);
    
    cout << "Here's the output during construction:\n";
    derived d(argv[1]);
    cout << "Here's the output after construction:\n";
    d.test();
    
    return(0);
}

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Here's the ouput from the shell when running the programming:

mynah:54> test_virt "Hello World"
Here's the output during construction:
base class: Hello World
Here's the output after construction:
derived class: Hello World
mynah:55> 

So as you can see, the derived classes virtual function is called during
initialization.  This is a serious limitation, especially if one wants to
allocate things differently during construction.


Newsgroups: gnu.g++.bug
From: jbuck@ohm.berkeley.edu (Joe Buck)
Subject: Re: make problem
Organization: U. C. Berkeley
Distribution: gnu
Date: Fri, 9 Oct 1992 20:05:52 GMT

hal@mpl.ucsd.edu writes:
>I'm having a bear of a time making g++ (either version 1.40.3 or 1.42.0)

Don't bother.  Use g++-2.2.2 (it is included in the gcc-2.2.2
distribution).  1.x has no templates and lots more bugs. 2.2.2 is
also much easier to install and works on more platforms.



-- 
Joe Buck	jbuck@ohm.berkeley.edu

Newsgroups: gnu.g++.bug
From: johns@haggis.ccsf.caltech.edu (John Salmon)
Subject: __builtin_args_info not built in
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 02:34:04 GMT

>>Date: Fri, 2 Oct 1992 10:25:28 -0700
>>From: Mike Warren <msw@sampson.ccsf.caltech.edu>
>>To: johns@haggis.ccsf.caltech.edu
>>In-Reply-To: John Salmon's message of Fri, 2 Oct 1992 10:20:04 -0700 <199210021720.AA23787@haggis.ccsf.caltech.edu>
>>Subject: cp-decl bug report
>>
>>
>>gcc-delta  -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include `if [ -f ../../gcc/gcc ] ; then echo -I./../../gcc/include ; else echo ; fi` -c CursesW.cc
>>CursesW.cc: In method `int  CursesWindow::scanw (const char *, ...)':
>>CursesW.cc:49: warning: implicit declaration of function `__builtin_args_info'
>>
>>The end result is that nothing will link to the unresoved symbol
>>__builtin_args_info
>>
>>Mike

I believe this patch repairs the bug (in generic gcc-2.2.2 sources):

*** cp-decl.c	Fri Oct  2 10:18:07 1992
--- cp-decl.c.orig	Wed Jun 10 21:14:00 1992
***************
*** 4045,4056 ****
    builtin_function ("__builtin_next_arg",
  		    build_function_type (ptr_type_node, endlink),
  		    BUILT_IN_NEXT_ARG, 0);
-   builtin_function ("__builtin_args_info",
- 		    build_function_type (integer_type_node,
- 					 tree_cons (NULL_TREE,
- 						    integer_type_node,
- 						    endlink)),
- 		    BUILT_IN_ARGS_INFO, 0);
  
    /* Currently under experimentation.  */
    builtin_function ("__builtin_memcpy", memcpy_ftype,
--- 4045,4050 ----



Newsgroups: gnu.g++.bug
From: daney@mermaid.micro.umn.edu (Dave Daney)
Subject: Template problem with -g on ISC
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 03:21:40 GMT

Some one on this group had the same problem I did.  I am reposting my patch
here because I can't remember their address.

The Problem:
gcc-2.2.2 running on Interactive Unix 2.2.1 (Sysv/386 R3.2) compiling
c++ with templates creates illegal assembler code with -g option.
Here is an example of the problem, the assembler does not like the '<,'
or the '>'.

	.def	tree_element<int>;	.scl	10;	.type	010;\
	.size	28;	.endef


My solution:
I changed it to this:
	.def	tree_element_int_;	.scl	10;	.type	010;\
	.size	28;	.endef

It might make some things look a bit strange in gdb, not sure about
this though.

I put this in i386isc.h, but I think perhaps att386.h is where it should
go.

/*----------------------------------------------------------*/
/* Assembler does not like '<' or '>' in labels (from template's
in c++) so we change them to '_'.  */
#undef ASM_OUTPUT_LABELREF
#define ASM_OUTPUT_LABELREF(FILE,NAME)  \
  do{                                   \
    char *p = &((NAME)[0]);             \
    while(*p)                           \
      {                                 \
	if('<' == *p || '>' == *p)      \
	  putc('_', (FILE));            \
	else                            \
	  putc(*p, (FILE));             \
	p++;                            \
      }                                 \
  } while(0)
/*----------------------------------------------------------*/
Dave Daney    daney@mermaid.micro.umn.edu

Newsgroups: gnu.g++.bug
From: mrhagger@athena.mit.edu
Subject: Compiler error 62 on typedef within base class
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 22:35:13 GMT

I am using the emx port of gcc 2.2.2 under OS/2 2.0.  The system was
downloaded from ftp-os2.nmsu.edu in compiled form a couple of weeks 
ago and is used without modification.
 
The following file triggers an "internal compiler error 62".  The
session and gcc's output follow the program text.
 
===========================================================================
class A
{
  public:
    typedef void (*void_fn)();
};
 
class B : public A
{
  public:
    void func(void_fn f);
};
---------------------------------------------------------------------------
[c:\emx\gnu\bugs]gcc -v -c bug2.cc
gcc version 2.2.2
 cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__32BIT__ -D_
_EMX__ -Di386 -D__32BIT__ -D__EMX__ -D__i386__ -D__32BIT__ -D__EMX__ -D__i386 bu
g2.cc ./cca00153.i
GNU CPP version 2.2.2 (80386, BSD syntax)
 cc1plus ./cca00153.i -quiet -dumpbase bug2.cc -version -o ./cca00153.s
GNU C++ version 2.2.2 (80386, BSD syntax) compiled by GNU C version 2.2.2.
bug2.cc:10: internal compiler error 62, please report
 
[c:\emx\gnu\bugs]
===========================================================================
 
A workaround is to use the scope-resolution operator in front of
the typedef name usage, as follows (now it compiles fine):
 
===========================================================================
class A
{
  public:
    typedef void (*void_fn)();
};
 
class B : public A
{
  public:
    void func(A::void_fn f);
};
===========================================================================
 
Michael Haggerty
mrhagger@athena.mit.edu

Newsgroups: gnu.g++.help
From: karsten@pegasus.inf-technik.th-ilmenau.de (Karsten Pahnke)
Subject: global operator<< for templates
Organization: TH Ilmenau/MSS, Germany
Date: Fri, 09 Oct 92 16:01:26 GMT

/*
Hallo,

it seems to be there is an error in g++ 2.2.2

it is not possible to implement global(not friend)
ostream operators for template classes

the following is a shorthand example of the problem

I thank for your efforts

Karsten

karsten@Inf-Technik.TH-Ilmenau.DE

-----------------------------------------------------------
*/

#include <iostream.h>

template <class T>
class Array {
	T* _arr;
	int _len;
public:
	Array(int len) { _arr = new T[_len = len]; }
	int	len() const { return _len; }
	T&	operator[](int i) {return _arr[i]; }
	void	print(ostream& s) const 
	{
		for ( int i = 0; i < _len; i++ ) {
			s << _arr[i] << " ";
		}
	}

	/* version 1 works properly, but friend is not necesssary */
	/* thats why version 2 */
	/*
	friend ostream& operator<<(ostream& s, const Array& a) 
	{ a.print(s); return s; }
	*/
};

/* works properly */
template <class T>
inline int empty(const Array<T>& a)
{
	return (a.len() == 0);
}

/* version 2 works with cfront, but not with gnu */
/*
/space/localtmp/gnu/bin/g++  -B/space/localtmp/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.2.2/
-I/space/local/gnu/lib/g++-include -g -DPRECOND -DYYDEBUG -DDEBUG \
-I/home/usr/omsi/work/inc \
        -c comp_out.cc
comp_out.cc: In function `int  main ()':
comp_out.cc:42: warning: dbx info for template class methods not yet supported
/space/localtmp/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11
*** Error code 1
make: Fatal error: Command failed for target `comp_out.o'
*/

template <class T>
inline ostream& operator<<(ostream& s, const Array<T>& a)
{
	a.print(s); return s;
}

main()
{
	Array<int> a(10);
	cerr << empty(a) << endl;
	cerr << a << endl;
}

-- 

 -----------------------------------------------------------
| Dipl.-Ing. Karsten Pahnke     | Telefon : 0037 672 691167 | 
| Technische Hochschule Ilmenau |           0037 672 691168 |       
| PSF 327, O-6300 Ilmenau       | Telefax : 0037 672 691517 | 
|-----------------------------------------------------------| 
| E-Mail : Pahnke@Inf-Technik.TH-Ilmenau.DE                 |
 -----------------------------------------------------------
Newsgroups: gnu.g++.help
From: stanton@cs.curtin.edu.au (Wayne Stanton)
Subject: G++ and Templates???
Summary: G++ and templates???
Keywords: Template
Organization: Curtin University of Technology
Date: Mon, 12 Oct 1992 08:10:36 GMT

I can't seem to find any documentation on templates with
g++, does it actually support them?  If so can someone
please point me in the direction of some documentation.

Also, is there any other documentation on g++ other than 
that supplied with the compiler?

Any help would be greatly appreciated.

Wayne Stanton
Curtin University
Western Australia
email: stanton@marsh.cs.curtin.edu.au
Newsgroups: gnu.g++.help
From: zoo@cygnus.com (david d 'zoo' zuhn)
Subject: Re: Installing g++ (2.2.2) and the g++-include directory
Organization: Cygnus Support -- +1 415 322 3811
Date: Thu, 8 Oct 1992 05:35:43 GMT


   This puzzled me for a while too.  The trouble is that, despite the fact that
   gcc is a C++ as well as a c compiler, it only comes with c libraries.  

This isn't true.  GCC comes with neither a C library nor a C++ library.
Your system probably has a C library however, and that's what GCC is using.
GCC installs some header files which are compiler specific, such as the
<stdarg.h> and the <limits.h> files.  

There are GNU C and C++ libraries available for those who don't wish to use
the native system libraries.  The biggest difference is that most systems
don't come standard with any sort of C++ library.


  david d 'zoo' zuhn |    The problem with politics is that it puts you in
    cygnus support   |    contact with the sort of people that you'd really
    zoo@cygnus.com   |    rather try to avoid.
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.help
Subject: Re: Dispatching bug in g++?
Date: 16 Oct 1992 22:24:22 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Oct16.204850.3311@lucpum.it.luc.edu> laufer@math.luc.edu
submits the program

#include <stream.h>

class P {
public:
  virtual void hello() { cout << "hello\n"; }
  void callhello() { hello(); }
};

class C : public P {
public:
  virtual void hello() { cout << "hullo\n"; }
};

void g(P x) { x.callhello(); }	// should call P::hello()

int main() {
  C z;
  z.hello();			// calls C::hello()
  g(z);				// results in an erroneous call to C::hello()!
}

and writes:

>When compiled with g++ 2.2.2 under SunOS 4.1.2, this program produces
>the erroneous output
>	hullo
>	hullo
>
>This is incorrect, since the x is a value parameter, whence
>dispatching should be static.
>
>Compilation with AT&T CC correctly results in
>	hullo
>	hello

This looks like a fundamental bug in the default copy constructors
generated by g++ (determined by looking at the assembly language output).
They copy everything, including the pointer to the virtual function table.
This is wrong; the first word of the destination object should always be
the virtual function table for that object, regardless of what is copied
into it.

That is, when z is passed by value, its virtual function table pointer
is copied into x, the formal parameter for g(P), so that x is not
really a P at all, but rather a C.



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: gnu.g++.help
From: brendan@cygnus.com (Brendan Kehoe)
Subject: Re: COOL
Reply-To: brendan@cygnus.com
Organization: Cygnus Support, Palo Alto, CA
Distribution: usa
Date: Tue, 13 Oct 1992 17:46:28 GMT
	<1b7ji2INNgpu@agate.berkeley.edu> <1992Oct11.213038.398@sunova.ssc.gov>

In article <1992Oct11.213038.398@sunova.ssc.gov> bush@fremont.ssc.gov
(Joe Bush) writes:

   Anyone know about the likelyhood of getting some version of TI's
   (or GE's simplified version) of COOL compiled with gcc2.2.2?

You need a special pre-processor for it; I tried and gave up.

It does wild things like this:

	#define foo##bar baz

and expects foobar to be a defined identifier.  Yow.

--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Palo Alto, CA                                  +1 415 322 3811
                                                 Re-elect Clinton/Gore in '96!
From: ezix@troi.ucr.edu (edward j. zix)
Newsgroups: gnu.g++.help
Subject: GCC Symbol Demangler Wanted
Date: 9 Oct 92 23:12:49 GMT
Distribution: usa
Organization: University of California, Riverside


Is there a Name demangler available on the net?
It is kind of a pain to do it by hand.
i.e. Given something like "Q25Outer5Inner", return "Outer::Inner"
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.help
Subject: Re: GCC Symbol Demangler Wanted
Date: 10 Oct 1992 21:56:18 GMT
Organization: U. C. Berkeley
Distribution: usa
NNTP-Posting-Host: forney.berkeley.edu

In article <22836@galaxy.ucr.edu> ezix@troi.ucr.edu (edward j. zix) writes:
>>Is there a Name demangler available on the net?
>>It is kind of a pain to do it by hand.
>>i.e. Given something like "Q25Outer5Inner", return "Outer::Inner"

In article <1992Oct10.065727.27305@muddcs.claremont.edu> jason@jarthur.claremont.edu (Jason Merrill) writes:
>Try cp-dem.c from the gcc distribution.  You need to write your own
>front-end, or use mine:

You could also use the "demangle" program included in the gdb-4.6
distribution.
--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: gnu.g++.help
From: wchoe@iss.nus.sg (winston choe)
Subject: Re: gcc 2.2.2 failing to compile libg++
Reply-To: wchoe@iss.nus.sg
Organization: Institute Of Systems Science, NUS.
Date: Thu, 8 Oct 1992 12:09:34 GMT

Does anyone know whether g++ version 1.37.1 supports Sun shared libraries?

It's linker gcc-ld++ keeps complaining that a GLOBAL_OFFSET_TABLE produced in
position independant code for shared libraries, is undefined.

It's definition is contained in iob.o which is automatically linked in by ld.


Regards, Winston Choe.

Newsgroups: gnu.g++.help
From: subiaagb@w350zrz.zrz.tu-berlin.de (Andre Pareis)
Subject: Trouble with templates in GNU C++
Reply-To: pareis@cs.tu-berlin.de
Organization: Dept. of CS, Techn. University Berlin
Date: Fri, 16 Oct 1992 16:36:16 GMT



Hi C++ users,


I have to implement a generic list class within a class library.
Therefore I want to use templates instead of deriving from on
base class. But my gcc (2.2.2 PL3) does not seem to work correct with it.
(Atari-ST version of G++)

I wrote a little test program (template.cc):


// BEGIN //

template<class T> class A
{
private:
	T a;
public:
	A( T aa ): a(aa) {}
	
	T Get( void );
};



int main( void )
{
	A<int>	a1(2):

	return a1.Get();
}


template<class T> T A<T>::Get( void )
{
	return a;
}

// END //


The compiler works fine, but the linker aborts with a message like:

template.o: A<int>::Get  - symbol not found     ( or the like )


But, if I put the definition of Get directly below the class A
declaration, it works. I want to know: Is it a problem of the C++
language or the compiler or the linker (which is PL31)?



It seems to me, it is a bug (or something else) of either the GNU compiler
or the linker. ( An earlier version of G++ (2.1) gave the same results )
I tried these lines on a Sparc with G++ 2.2.2, and got this message:

	ld: Undefined symbol 
	   _Get__t1A1Zi 

After, I made A( T aa ) non-inline, i.e., put it's definition at the end
of the file and got the same messages for A(T).
Then I put both non-inline functions between the class declaration and
main() and (surprisingly) IT WORKED?



Is there somebody in this group who had the same problems with templates
and G++? Or do I have simply to turn on a compiler or linker switch?
Until a resolution is found, I have to write all the list code in one
file List.h, which will be included by other modules, then all works
correct, except that I have to wait a very long time for every compilation.


Another question is:
In the infos about libg++ I found a description of generic list,
stack and queue classes, but my g++ lib doesn't contain such things.
Is it impossible to implement it with G++?



				Thanks in advance

				+-----------------------------------------------+
				| Andr'e Pareis |  Techn. University of Berlin	|
				|-----------------------------------------------|
				| e-mail:    pareis@cs.tu-berlin.de		|
				|	     subiaagb@w350zrz.zrz.tu-berlin.de	|
				| NeXT-mail: subiaagb@w271zrz.zrz.tu-berlin.de  |
				+-----------------------------------------------+