HDTenEightyP/NetNews huggingface dataset:
From: stan@sabaac.NoSubdomain.NoDomain (Andrew Staniszewski)
Subject: initializing static members in template classes
Reply-To: staniszewski@mayo.edu
Organization: Mayo Foundation
Date: Tue, 18 Aug 92 20:17:54 GMT

Does anyone know how to do this?

Lippman claims (see page 370 of the c++ primer) that using

template <class T> QueueItem<T> *QueueItem<T>::free_list =0;

will generate the define the freelist and assign it a value of 0 with each
instanciation of the QueueItem class. when I try to use this syntax for my own
class in an appropriate header file I get

ie:

template<class Type> ListLink<Type> * ListLink<Type>::freelist = 0;

the DEC cxx compiler calls it an invalid declerator.


Note I assumed that this sort of declration has to go into the header file,
because if it goes into a source file, then the compiler wouldn't see it for
every instantiation of the class.

Is my syntax bad or is this simply a feature DEC hasn't implimented yet ???
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Garbage Collection for C++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 15 Aug 1992 15:48:18 GMT

In article <1992Aug14.021547.15215@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
>
>In article <DAVEG.92Aug13025629@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
>
>This would accord with existing C++ philosophy, but I don't see how
>you could make a GC that's immune to dangling pointers. Anyone out
>there know otherwise?

	GC objects would be immune to dangling GC pointers.
If a GC pointer is rooted (exists non-circularly) then the object
wont get deleted when you say 'delete'. The pointer gets
zeroed out though.

>
>|> What if you have virtual base classes, and there are only references
>|> to the base part of an object?  The derived part of the object has
>|> a pointer to the base part but not the other way around, so the
>|> derived part might be collected in this case.  Can this ever be a
>|> problem?
>
>I don't think so, but I don't know the mechanics of inheritance (and in
>particular MI) well enough to say. Comments from those who know the
>dirty details of inheritance welcome!

	This is a major problem. Specifically, if an exact object
is GC, then all its accessible base classes must be too. INcluding
the abstract ones. This will tend to partition programs into
a GC part and a non-GC part. In particular, the GC mechanism
must be able to 'downcast' from a GC objects base to the actual
object like a virtual destructor can, and for the same reason.

	As far as I can see, all pointers to GC objects must
be GC pointers. And all pointers INTO them too. Otherwise
you can 'delete' via an ordinary pointer, and an ordinary
pointer could dangle.

	This makes the GC kernel secure, and allows outwards
references to non-GC objects. All inwards references have to be
GC pointers.

	In this system it is imperative that GC pointers in
ordinary objects be properly destroyed.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: Return values for constructors.
Organization: University of Illinois at Urbana-Champaign
Date: Wed, 19 Aug 1992 16:51:25 GMT

In <3474@unisql.UUCP> nandraj@unisql.UUCP (Nandraj Arni) writes:

[ stuff about ctors returning values ]

>   One way would be like this:

>   Foo *p;

>   int return_value = new p(...); // not allowing Foo *p = new Foo(...);
>				  // This could be invalid assingment...

*****>	Huh?  So where does the pointer to the object go?  You'll get
	your return-value, but lose the object you just created.  Not
	very useful.

>   And for others:
> 
>   float value;        // This does not have a value, even objects
>		       // should be like that.

>   So other way would be:

>   Foo p;

>   int return_value = p(...);

*****>	Similarly, this would create an unnamed object that would be
	destroyed immediately.  Again, not very useful.

	Anyway, functions, and ctors if ther were allowed to have return-
	types, are insufficient to distinguish when overloading is
	concerned.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: matt@centerline.com (Matt Landau)
Subject: Re: Overloading Parent Declaration: Bug or Feature?
Organization: CenterLine Software, Inc.
Date: Thu, 20 Aug 1992 15:50:07 GMT

In <1992Aug20.141830.3079@rhrk.uni-kl.de> kring@efes.physik.uni-kl.de (Jochen Voss) writes:
>It compiles without warnings (even with the -Wall flag set) and outputs
>	B::f(1)
>	D::f(hallo)
>when run.  But in Bjarne Stroustrup's Book `Die C++ Programmiersprache'
>(2. Auflage, 1992) in section R.13.1 he writes that the statement at the (*)
>is an error because D::f(char*) hides B::f(int). B::f(int) is not overloaded
>with D::f(char*) because the functions have different scopes.
>
>Is this a bug or a feature? Shouldn't I at least get a warning?

Both ATT cfront 2.1.12 and 3.0.1 issue error messages and refuse to compile 
this example.  Scanning the ARM just briefly, it looks like g++ is getting
this wrong.
Newsgroups: comp.lang.c++
From: ravi@seas.smu.edu (Ravi Gupta)
Subject: How to load complex.h?
Keywords: c++
Organization: School of Engineering and Applied Science
Date: Wed, 19 Aug 1992 22:08:24 GMT

I have the following program in C++, which
gives the unknown system msgs, when compiled
with g++(ver 2.2.2). Can any one tell me
how to properly link complex.h?
I would appreciate if you send me the mail
instead of putting on the net.
Thanks;
Ravi
Here is the code:
----------------------------------
/* a program that manipulates complex numbers */
#include <Complex.h>
main() {
  Complex x,y,a,b;
  Complex w = Complex(3.0,4.0);
  Complex z(9.0,10.0);
  const Complex k(5.0,6.0);
  x = Complex(4.0,5.0);
  y=x+w;
  z= Complex(2.0,0.0)*z;
  z= z*k;
  cout<<"\nEnter complex numbers\n";
  cin >> a;
  cout << "\nx= " <<x;
  cout << "\ny= " <<y;
  cout << "\nz= " <<z;
  b=2*a;
  cout << "\nb= " <<b;
  cout << "\nmagnitude b= " <<abs(b);
  cout << "angle b= " <<arg(b);
}



-- 
=================================(O)========================================

Ravi Gupta				INTERNET:ravi@csvax.seas.smu.edu
Grad.Student				YELLNET :(214)692-0433
Newsgroups: comp.lang.c++
From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: Return value for the constructors.
Organization: netmbx, Berlin, Germany
Distribution: usa
Date: Wed, 19 Aug 1992 06:52:12 GMT

pjl@sparc6.cs.uiuc.edu (Paul Lucas) writes:

>In <3462@unisql.UUCP> nandraj@unisql.UUCP (Nandraj Arni) writes:

>>   Why does C++ not let you have a return value for a constructor?
>>Is there any rationale behind this?

>*****>	Because there's nothing for it to return.  A c'tor is s'posed to
>	turn raw memory into an object.  Period.

But note this example from the ARM, page 62:

	complex* p = new complex(i++);
	if (p == 0)  // allocation failed!

On page 61 he also states that initialization will only be done if the
return from the new is nonzero.

So I think that it is safe to check the pointer to see if it is zero.


Jonathan

===========================================================================

Jonathan Robie		jrobie@netmbx.UUCP
Arnold-Zweig-Str. 44	jrobie@netmbx.in-berlin.de
O-1100 Berlin		
Deutschland		Phone:  +37 (2) 472 04 19  (Home, East Berlin)
				+49 (30) 342 30 66 (Work, West Berlin)


-- 
Jonathan

===========================================================================
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Language extension
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 15 Aug 1992 15:30:09 GMT

In article <memo.575428@cix.compulink.co.uk> vadim@cix.compulink.co.uk writes:
>
>While thinking about various RTTI, XRTTI and GC proposals
>for C++ i've stumbled on following idea:
>Many of the modern computer programs such as communication programs,
>word processors, CAD systems, e-mail systems provides a means to tailor
>them to match user needs by offering some kind of script language.
>It just occured that the same mechanism could be provided in the
>compiler.  A scripting language which could access and manipulate
>compiler data structures. Such a thing will give almost unlimited
>language extension possibilites and that WITHOUT need to change the
>language itself.
>
>With souch a feauture RTTI, EXCEPTION HANDLING, GC, PRE- and POST- 
>method conditions, class invariants, all become
>possible without modifying the language. The stadards commetee will
>simply have to agree on library interface to all these features.
>

	I started writing c++front translator last week.
Initialially it will translate C++ into C++ via hand written
parser (written in C++). It will be upgraded to support
tagged pointers, operator., etc by hand modification of the compiler
source. Extensions to translation to C may be interesting.
Bootstrapping to extended C++ will be tedious. But its impossible
to propose a major language extension without testing it
via an experimental compiler.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Tagged Pointers
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 13 Aug 1992 08:26:18 GMT

In article <1992Aug10.221849.19455@fcom.cc.utah.edu> swillden@news.ccutah.edu (Shawn Willden) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>: In article <memo.565692@cix.compulink.co.uk> vadim@cix.compulink.co.uk writes:
>: >[ deleted text]
>: >
>: >Ok, what about tagged references for ortogonality?
>: 
>: 	And tagged values, right?  (Also known as tagged unions).
>: 
>: 	I originally put 'and you have tagged references just like
>: tagged pointers (so I needn't describe them) execpt that the
>: syntax is different' in my post.
>: 
>: 	But now I don't think that you can HAVE tagged references.
>: Tagged pointers are VARIABLES, like pointers. References are not,
>: they cannot be changed. If you had tagged references you would not 
>: be able to use them where you could use a pointer:
>: 
>: 	[T1, T2]& r;
>: 	r.function();
>: 
>: Am I wrong on this, do tagged references make sense?
>
>Sure they make sense.  Are they necessary?  (Assuming tagged pointers
>are).  Look at the following.

	They're never *necessary*. But useful? and sound? and safe?

>
>    void foo(const [T1, T2, T3]& r)  // This idiom pops up now and then ;->
>	{ // do something with r }
>
>    void bar()
>	{
>	[T1, T2, T3]* r;
>	T1 t1;
>
>	r= &t1;
>	foo(*r);
>	}
>
>I can see three ways to make this work:
>	1)	Make foo a template function (void foo(T& r)).  If I
>		understood your proposal, dereferencing r would create
>		something like:
>			switch (r.tag) 
>				{
>				case T1:
>					foo(r.t1);
>				etc....
>		Assuming the template `exansion' occurs *after* the
>		tagged pointer `expansion', the correct code would
>		be generated.  I don't like heavy use of template 
>		functions because I can't control what types my 
>		template is called with.  Templates also don't allow
>		for automatic type conversion.

	Yes, your choice.

>	2)	Tighten the relationship between tagged pointers and 
>		tagged unions.  i.e. dereferencing a tagged pointer in
>		a context where a tagged union of like types is expected
>		yields a tagged union and taking the address of a tagged
>		union yields a tagged pointer.  Then foo could be declared
>		as taking a reference to a tagged union and foo(*r) would
>		be valid.  I think there are some things wrong with this 
>		idea, though I haven't thought it out.

	Pointer to tagged unions != tagged pointer. Have to think
about it.

>	3)	Allow tagged references.
>
>IMHO, 3 is the cleanest solution (besides which, for the sake of symmetry
>if we have tagged pointers we should have tagged references).

	Yes. Could be nice :-)

>
>Shawn Willden
>swillden@icarus.weber.edu


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: mathers@sibelius.trl.oz.au (Steven Mathers)
Newsgroups: comp.lang.c++
Subject: TURBO C and inline assembly
Date: 19 Aug 92 08:19:07 GMT
Reply-To: s.mathers@trl.oz.au
Organization: Telecom Research Labs, Melbourne, Australia

Hello, I am in need of help from someone familiar with the way
Turbo C++ handles inline assembly.

My problem is that I would like to be able to issue an
OUT ax,dx from inline assembly.  Currently I am using the 
OUTPORT command, which works fine, but generates a lot of needless
assembly instructions...something like 16 instructions, as opposed to
the 3 I would need for the OUT assembler command.

What I would like to know is:  Can I freely use AX and DX in an inline
assembly, without having to worry if Turbo was expecting the values of
these registers to be anything in particular, and thus throw things out
of kilter.  I tried it, and it worked fine, but I'm not sure if I was
just lucky, and I am reluctant to continue with this method unless I know it
will be A-OK.

Thanks for any replies.
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: A template question
Keywords: template, BC++ 3.1
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Wed, 19 Aug 1992 16:39:21 GMT

In <Bt84JC.En0@zorch.SF-Bay.ORG> pchi@zorch.SF-Bay.ORG (Eric Chi) writes:

>Hi, I am using Borland C++ 3.1 implementing 2 classes: vector and matrix.
>I have the Vector class defined as a template:

>	template <class Type>
>	class Vector
>	{
>	public:
>		Vector( int dim);
>	...
>	};

>Now I tried to define the matrix by utilizing the vector:

>	template <class Type>
>	class Matrix: public Vector< Vector< Type>>
>	{
>	....
>	};

>Is this a correct way? Borland C++ seems do not understand the syntax.

	class Matrix : public Vector< Vector< Type > >
						    ^
						    |
						space required

	Otherwise '>>' is the right-shift operator.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: pool@cs.utwente.nl (Sander Pool)
Subject: Re: Problem with 'automatic' destructors
Keywords: destructor
Organization: University of Twente, Dept. of Computer Science
Date: Wed, 19 Aug 1992 14:26:47 GMT

In article <1992Aug19.145847@cs.utwente.nl>, pool@cs.utwente.nl (Sander Pool) writes:
|> hello,
|> 
|> I'm having a 'little' problem with destructors which are called
|> automatically when 'exit()' is called. For some reason the object
|> has turned to garbadge (e.g. the attributes have illegal values)
|> before the destructor is called. This results in funny/disasterous
|> situations. xdbx doesn't help much, when I trap the call to the
|> destructor and try to examine attributes he won't even show them.
|> 
|> The class structure looks like this (where Problem is the problem class):
|> 
|> class Problem {
|> public:
|> 	~Problem(); // this gets called with a bogus object
|> };
|> 
|> class Super {
|> protected:
|> 	Problem problem;
|> };
|> 
|> class Action: public xview_class, public Super;
|> 
|> 
|> I create an automatic instance of Action like this
|> 
|> Action	action;		// obvious :-)
|> 
|> and the somewhere in an eventhandler I call 'exit(0)'.
|> 
|> 
|> I'm at a total loss and hope someone can help me out. I
|> use cfront 2.1 on a Sparc.
|> 
|> thanks in advance and regards,
|> 	
|> 	Sander
|> 
|> ******************************************************************
|> Sander O. Pool 		Twente University, 
|> 			department of Computer Science 
|> 			SETI group / TRESE project	H303
|> __________________________________________________________________
|> address:PO Box 217 		| misc.	phone 	+31-53-893715
|> 	7500 AE Enschede 	|	fax	+31-53-356531
|> 	The Netherlands 	|	email 	pool@cs.utwente.nl
|> ******************************************************************
|> 
|> 
|> 

OK, this seems a bit silly, replying to my own post, but I've got
some additional info. I added a destructor to class Action which doesn't
do anything but resetting it's attributes to 0. Now the destructor of
Problem gets called properly. This solves my problem but doesn't
explain why it occurs. Any clues?

thanks,
		sander
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: auto T&
Date: 21 Aug 1992 03:00:40 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <1992Aug20.213417.5690@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
>In <9223406.29682@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>What do you mean by "it's not reentrant"? Why not?
>
>*****>	Because the "slot" allocated in the caller would first receive
>	the temporary generated by "stringfunction( b )" then it would
>	be clobbered by "stringfunction( c )" 

I think the rest of us understood that enough temporaries would be
allocated so that there would be no clobbering.

>	The problem with that is, what does the compiler do if a
>	function returning an auto& calls itself?

That's what stack frames are for.  Each stack frame for the function would
contain space for all the temporaries that are returned.

The easiest way to understand this is to transform the program into a
version where the temporaries are explicit.  Thus,

	String a, b, c;			// also assume + has been overloaded
	// ...
	a = stringfunction( b ) + stringfunction( c );

is equivalent to:

	String a, b, c, temp1, temp2;
	// ...
	temp1 = stringfunction(b);
	temp2 = stringfunction(c);
	a = temp1 + temp2;

Your claim of non-reentrancy suggests that you think the temporaries would
be static, not automatic.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: av@kielo.uta.fi (Arto V. Viitanen)
Newsgroups: comp.lang.c++
Subject: Delegation in C++
Date: 18 Aug 92 07:15:41 GMT
Reply-To: av@uta.fi (Arto V. Viitanen)
Distribution: comp
Organization: University of Tampere, Finland

I am reading Bjarne Stroustrup's "The C++ Programming Language", 2nd edition.
In operator section he says that you can use operators to implement
delegation in C++. Does anybody have any examples on the subject ?
--
Arto V. Viitanen				               email: av@uta.fi
University Of Tampere,				   	           av@cs.uta.fi
Finland
Newsgroups: comp.lang.c++
From: wmm@world.std.com (William M Miller)
Subject: Re: error in Stroustrup text      (?)
Organization: Software Emancipation Technology, Inc.
Date: Wed, 12 Aug 1992 12:38:29 GMT

In article <46960007@hpscit.sc.hp.com>, Greg Weeks writes:
> Someone please correct me if I'm mistaken, but the following text from pg
> 216 of Stroustrup's 2nd edition C++ text seems to be wrong:
> 
>     If you want to supply an allocator/dealocator pair that works correctly
>     for derived classes, you must either supply a virtual destructor in the
>     base class or refrain from using the size_t argument in the
>     deallocator.
> 
> _Whenever_ a derived class object may be deleted through a pointer to base
> object, a virtual destructor is required.  It does not suffice to refrain
> from using the size_t argument in the deallocator.  The reason is that
> `delete' needs to know both the size _and_ the location of the thing to be
> deleted; and the location of the derived object may differ from the
> location of the base object.  (That is, it may be that (void*)pd is
> different from (void*)pb.)
> 
> Right?

True, but that's irrelevant to the point of the text you cited.  In
the code below, for instance, the derived-class object is deleted by
means of a derived-class pointer, but you can still get the wrong size
in operator delete():

	#include <stddef.h>
	#include <iostream.h>

	class base {
	public:
	   void* operator new(size_t sz) {
	      cout << "allocating " << sz << " bytes.\n";
	      return new char[sz];
	   }

	   void operator delete(void* p, size_t sz) {
	      cout << "freeing " << sz << " bytes.\n";
	      delete [] (char*) p;
	   }

	private:
	   int i;
	};

	class derived: public base {
	   int j;
	};

	int main() {
	   derived* d = new derived;
	   delete d;
	   return 0;
	}

The result of running this code (under cfront 2.1 on a Sun, at least)
is:

        allocating 8 bytes.
	freeing 4 bytes.

Adding a virtual destructor allows the correct size of the object to
be passed to operator delete().

-- William M. Miller, wmm@world.std.com
From: rct@fulcrum.bt.co.uk (Richard Taylor)
Newsgroups: comp.lang.c++
Subject: Libraries which depend on compiler (mangling).
Date: 19 Aug 92 10:56:26 GMT
Organization: Fulcrum Communications

Libraries which depend on compiler (mangling)
---------------------------------------------

I suspect this is probably an old chesnut, but I'm new to C++, and have just
come across the fact that different compilers mangle names in different
ways (g++ and cfront, in particular).
This means that when I purchase a library of objects (which happen to have
been compiled with cfront) I cannot compile my own code (with g++) and link
it together with the object library, without also purchasing cfront.  In a
world of releatively portable code, this is an incredible oversight.

Is there any way around this problem? Is there a way of getting g++ to
mangle using the same method as cfront, so the two can agree names?

Presumably this problem will be fixed by a consenus of deciding the 'best'
way to mangle a name? Will this be specified in some ANSI specification?

Thanks for any info/help.

============================================================================
Richard Taylor                 DoD #981               (rct@fulcrum.bt.co.uk)
"Gentlemen, starta your engines... 2 minutes, to the hills." Massimo Laverda
============================================================================
Fulcrum Communications Ltd., Fordrough Lane, Birmingham, B9 5LD, ENGLAND.
Newsgroups: comp.lang.c++
From: J.March@lut.ac.uk
Subject: Documentation ?
Keywords: documentation template
Reply-To: J.March@lut.ac.uk (Jon March)
Organization: Loughborough University, UK.
Date: Sat, 22 Aug 92 12:44:24 GMT

Does anyone know where I can ftp documentation about C++ from.

Especially to do with templates.

Please mail replies, I'll sumarise.
j.march@lut.ac.uk