HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 14 Aug 92 23:30:26 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

In article <rmartin.713716434@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>
>Whenever you provide a regular copy constructor, you are granting
>permission to the compiler to make temporaries.  This must be a
>conscious choice, and must be supported by construction and
>destruction semantics which are valid in any context.
>

	Obvious but I'd never thought of it this way before.
Interestingly my originating post on GC was stimulated by the idea
that the lifetime of temporaries problem can be solved by garbage
collecting them. Then they last as long as necessary.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 18 Aug 92 00:48:54 GMT
	<DAVEG.92Aug13025629@synaptx.synaptics.com>
	<1992Aug14.021547.15215@news.mentorg.com>
	<DAVEG.92Aug14194411@synaptx.synaptics.com> <2009@appli.se>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: niklas@appli.se's message of 16 Aug 92 01:10:05 GMT

niklas@appli.se (Niklas Hallqvist) writes:

   I just wanted to say that conservative GC won't really help in all
   situations.  Jonathan Shapiro taught me this useful trick once.
   When you want to do a doubly linked list to the cost of a singly
   linked one (i.e. in mem. space).  Instead of having two pointers
   for the link in each node, take the "previous" and "next" pointers
   and XOR them, and store the result!

   Now you just need to store two entry consecutive points into the
   list, and make an iterator intelligent enough to work things out.
   This is of course a very special trick, but it IS useful, and it
   shows NO GC strategy always wins unless the programmer explicitly
   can tell what objects are live/dead, but then again, we're back to
   explicit memory management.

You didn't take that seriously, did you? In any case, it's an old hat
and it's unportable (*).

Incidentally, there is a widely used, simple, efficient, more general,
and completely portable technique for getting the same kinds of
storage savings as with the XOR trick.

					Thomas.

(*) In C++, there is no guarantee that there exists an integral type
large enough to hold a pointer; ARM p.67-68.
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Garbage Collection for C++
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 20 Aug 1992 18:02:47 GMT

tmb@arolla.idiap.ch (Thomas M. Breuel) writes about whether GC should
call destructors:

>I think the answer is simpler than that. Delete should continue to
>work as it does (including returning memory to the system).
>
>In addition to that, there may be facilities to allow the programmer
>to specify finalization of heap objects that are about to be collected
>but have not been "deleted". Such a facility would not require any
>language changes; something like "gc_set_finalization_hook(void*,void
>(*f)(void*))" might do the trick. Some people may prefer to use such a
>facility simply to detect memory leaks in existing programs, while
>others might want to use it, for example, to release external
>resources.

It seems quite clear (to me :-) that objects must be destroyed before
their storage can be reclaimed. The idea that we should have a separate
finalization function that is called instead of the destructor seems to
be a step backwards. I cannot imagine any situation in which the
finalization function would do anything different from the destructor.

Exactly the same difficulties with quasi-non-deterministic execution
order apply to a finalization function called during gc as apply to the
destructor being called during gc.
Unspecified order of execution of destructors for GC'ed objects does
not appear to be much of a problem to me; we already have unspecified
order of execution for arguments to a function call, etc., and
destructors generally don't have side-effects apart from resource
de-allocation, so they are generally don't interact with each other.

The only advantage of having a finalization function instead of calling
the destructor seems to be that for optimization purposes, it is may be
desireable to optimize the common case when the destructor is empty
(does nothing). However this should not be too difficult for any but
the most naive implementations.

Furthermore, for MY code, the finalization function version would
result in LESS efficient code, because if the destructor version wasn't
in the language, then I would have to simulate it manually, by having
the finalization function explicitly call the destructor. This is very
messy as well as being less efficient. Having a finalization function
which I have to remember to install every time I call gc_new is both
tedious and error-prone.

	void f (iostream &);
	f(*gc_new fstream(...));	
	// Oops! Forgot to write and install a finalization function
	// for the fstream allocated with gc_new.
	// The file may never get closed.
						
-- 
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: comp.lang.c++
From: eric@tfs.com (Eric Smith)
Subject: Re: pointer to constant object violation
Organization: TFS
Date: Sat, 15 Aug 1992 16:08:38 GMT

In article <1992Aug15.133926@iti.gov.sg> nicholas@iti.gov.sg (Nicholas Tan) writes:
>typedef char*		STR;
>//#define STR		char*
>
>
>class String
>{
>	private:
>		STR str;
>
>	public:
>		String(STR = "");
>		const STR value() const;
		^^^^^^^^^
That is equivalent to char * const, not const char *

i.e., it's parsed as (const (char *)) for the typedef, vs ((const char) *)
for the #define.
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: destruction of temporaries
Summary: operator void() ???
Organization: :
Date: Thu, 20 Aug 1992 09:27:52 GMT

In article <TMB.92Aug19113657@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
> In article <1992Aug18.205211.16789@Warren.MENTORG.COM> adk@Warren.MENTORG.COM (Ajay Kamdar) writes:
> 
>    So why would the ARM consider the example with a temporary sufficient
>    reason to reject the "end of function" approach? To me it appears that
>    the "end of function" approach for temporaries would not cause any more
>    difficulties or program bugs than those that can already occur even without
>    temporaries. So why not reconsider that approach?
 
> I don't want my temporaries to hang around until the end of the
> function. I often use large temporaries (megabytes), and I see no
> reason why they should stick around any longer than I need them.
 
> Temporaries should get destroyed as soon as their value has been used.
> To make call-by-reference a little more convenient, there is a special
> rule for binding references to temporaries, and I guess that's OK.

Thomas, you're not alone.  Others feel the same way, not for hairy AI
data structures but for big matrices.  The issue is being examined.

Here's a thought.  There was, at one time, a suggestion for an `operator
void()' that describes the action of throwing away a value.  It gets used
for anything except the intialization of an object.  Would the `operator
void()' concept describe the point at which the temporary must be
discarded?
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: feustel@netcom.com (David Feustel)
Subject: Re: Allocating arrays larger than 64K with new?
Date: Wed, 12 Aug 92 23:34:17 GMT
Organization: DAFCO: OS/2 Software Support & Consulting

The following program compiles and links successfully with the ZTC
-mx option. Running the program crashes the system. The program was
linked and run under Flashtek's x32 dos extender.

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

#include <stdio.h>

#define AS 3000000

long * getspace(unsigned int amount)
{	long * a;
	printf("malloc %d ",amount);
	if(a=(long *) malloc(sizeof(long)*amount))
	{	printf("succeeded\n");

	else

	{	printf("failed\n");

	}

	return a;

}

	

 

void main(int argc,char **argv)

{	long i,imax=AS;

	double sum=0;

	long *a, *b, *c;

	printf("Hello, World\n");

	for(i=0;i<argc;++i)

	{	printf("%s\n",argv[i]);

	}

	a=getspace(AS);

	b=getspace(AS);

	c=getspace(AS);

	if (a==0|b==0|c==0) exit(-1);

	for(i=0;i<imax;++i)

	{	

		a[i]=i*i;

		b[i]=i;

		c[i]=i*i*i;

		sum+=a[i]+b[i]+c[i];

	}

	free(a); free(b); free(c);

	printf("sum: %e\n",sum);

	exit(0);

}


-- 
Dave Feustel N9MYI <feustel@netcom.com>
---
Given Civil Seizure, from the DEA's point of view, winning the War on
Drugs would be killing the Goose that lays golden eggs.
Newsgroups: comp.lang.c++
From: cpchou@ohpspd.com (Paul Choudhury)
Subject: Sparse Matrices
Organization: Ontario Hydro Power System Planning Division
Date: Thu, 13 Aug 1992 12:22:09 GMT

Hi, I'm new to c++ and was wondering if anyone
had any experience in working with matrices that 
are highly sparse, ie. storing and manipulating them.
I've seen class libraries for handling matrices - are 
there any for hanling sparse matrices?

Thanks in advance.


Paul Choudhury, Transmission System Planning, Ontario Hydro
700 University Ave., Ontario, Canada M5G 1X6
Tel (416) 592 8807  Standard disclaimers apply 
Internet: cpchou@ohpspd.com
From: jeff@kuhub.cc.ukans.edu (Jeff Bangert)
Newsgroups: comp.lang.c++
Subject: Precompiled headers in Turbo C++ 3.0
Date: 15 Aug 92 04:50:15 CDT
Organization: University of Kansas Academic Computing Services

If you are currently using Turbo C++ 3.0 for DOS ( or maybe Borland
C++ 3.1 ) and precompiled headers work EXACTLY the way you want them
to, I would like to correspond.

What I know so far: include files must be in DECREASING order of size.

But, when I build a library, with my own .h file, and my own .h file
includes some .h files, then precompiled headers may or may not work.

Since precompiled headers speed up compiles quite a bit, I really like
them, and it's frustrating when they don't work.

If you have a suggestion, thanks.

-- 
Jeff Bangert			jeff@kuhub.cc.ukans.edu
Computer Center			jeff@ukanvax.bitnet
University of Kansas
Lawrence, KS 66045
(913)864-0466
Newsgroups: comp.lang.c++
From: roihar@cc4.crl.aecl.ca
Subject: OOP introductory tutorial
Organization: AECL RESEARCH
Date: Wed, 19 Aug 1992 18:26:45 GMT

Anybody know of a reasonably painless introduction to OOP
out there that would cover the philosophy and most of the
important concepts involved? Please e-mail roihar@crl.aecl.ca
on Internet directly since I seldom have time to read news
groups but make a point of reading my mail...
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Distribution: world
Subject: Re: help!!!
X-Mailer: cppnews $Revision: 1.14 $
Organization: Trumphurst Ltd.
Date: Thu, 20 Aug 1992 16:29:08 +0000


In article <1992Aug18.063338.21333@debbie.cc.nctu.edu.tw> cp79111@csie.nctu.edu.tw (Kuo-Ping Hsu) writes:

>          setvect(com_irq,&comm::NewIRQ);
>                          ^^^^^^^^^^^^^
>     But the compiler reports a following error :
> 
>          Error : Connot convert 'void (far interrupt comm::*)()'
>                  to 'void (interrupt far *)(...)'
If I had a dollar for every time I had seen this question asked (AND 
answered) on the net, I'd be a rich man.

I take it you do not have access to any textbooks on the C++ language, or 
to the excellent C++ FAQ (which is available for public ftp from such 
sites as uu.net). If you have, I suggest you try reading them !

They will tell you (much more clearly than I am about to) that a member 
function is an entirely different thing to a regular function. A member 
function can only be called for a particular object ...

class Base {
	int i;
public:
	Base(int j = 0) : i(j) {}
	void bFunction();
	};

void Base::bFunction()
{
	cout << "Base::bFunction " << i << "\n";
}

void gFunction()
{
	cout << "gFunction\n";
}

main()
{
	Base b;
	
	b.bFunction();		// call bFunction for object b
	gFunction();		// regular function doesn't need an object
	bFunction();		// ERROR - no Base object supplied
				// How is bFunction going to print this->i
				// when it doesn't have a this ?
	return 0;
}

So, obviously, your interrupt handler can't call a member function, 
because it doesn't have an object to call it for.

The usual solution to this problem is to make the callback function either
global (like you would have done in good ole C) or a static member of your
class (a static member does not need an object).
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 21 Aug 92 21:45:18 GMT

rgp@mpd.tandem.com (Ramon Pantin) writes:

>I've got a simple (poor man's?) solution to this problem:

>	Let the compiler destroy temporaries as soon as it wishes
>	to do so, with the exception of objects for which a member function
>	that has been declared with a new keyword (say "longlived")
>	_might_ have been executed, in which case the object persist
>	until the end of the function (or some other convenient
>	place for destruction).

[...]

>What do you think? 


I don't favor any technique which makes the destruction of temporaries
dependent upon decisions made by the programmer.  The language is
already complex enough without that. 

In my opinion, temporaries should be deleted as soon as possible.  The
compiler should issue warnings in any situation where a pointer or
reference to a temporary is stored (and thus may be dangling after the
destruction of the temporary).  I think this is sufficient.  


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Newsgroups: comp.lang.c++
From: dan@BofA.com (Dan Brockman)
Subject: Re: run-time type checking, freezing, and thawing
Keywords: DAG RTTI
Organization: Bank of America, Capital Products, RMTG #5906
Date: Wed, 12 Aug 92 17:04:50 GMT


What is a DAG ?  What is a RTTI ?

-- 
 ------------------------------------------------------
 Daniel Brockman                       tel 415-953-0406, fax 415-622-2892
 Bank of America, Dept 5906, 555 Calif St
 San Francisco 94104 USA              email uunet!odinba!dan dan@BofA.COM
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 13 Aug 92 14:33:54 GMT

bill@sunquest.UUCP (Bill Raves) writes:

|We have encountered some widely different behavior in compilers (e.g.
|DEC C++ and cfront) with respect to the destruction of unnamed temporaries
|[...] We also realize that the manifestations of this
|behavior may introduce subtle bugs in code. The question is "How can
|we prevent these problems from getting into production code?".

The main thing is to avoid mixing complex construction and destruction
semantics with complex copy semantics.  i.e. if a class cannot be
safely constructed and destructed by the compiler as a temporary, then
don't give the compiler access to its copy constructor or assignment
operator.  (make them private)

If you need copy semantics, then you can hide them from the compiler
by adding extra arguments to the copy constructor...

Giving the compiler access to the copy semantics of a class is a
design decision which must be made carefully.  It should not be done
in every case.  Many so called "cannonical forms" recommend the
unquestioned inclusion of copy constructors and assigment operators.
I disagree with this approach.  Copy semantics are often too complex
to be allowed into general use.  

Whenever you provide a regular copy constructor, you are granting
permission to the compiler to make temporaries.  This must be a
conscious choice, and must be supported by construction and
destruction semantics which are valid in any context.



--
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
| rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
|     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |
Newsgroups: comp.lang.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Covariant Types in Derived Classes
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Sat, 15 Aug 92 00:40:37 GMT

In article <1992Aug13.162956.10279@mole-end.matawan.nj.us>, mat@mole-end.matawan.nj.us writes:

|> 
|> 	Open letter to the Gurus of C++:  Is there a preferred
|> 	terminology for expressing `this stuff'?  Can one be
|> 	created for the present need?  There's been more than one
|> 	discussion locked in violent agreement for want of it.
|> 

At the last X3J16 meeting people were using "conversion" vs. "coercion".
In the past I've used "conversion" vs. "(bitwise)reinterpretation",
Any nomenclature seems ok as long as it is clear.

I use "cast" solely to refer to the syntactic construct.  That
is, both conversions and coercions are casts.  You can use it
for coercions if you want, but you're just begging to be
misunderstood if you do so.

   -- Jerry Schwarz
From: TOGE@SLACVM.SLAC.STANFORD.EDU (Nobukazu Toge)
Newsgroups: comp.lang.c++,comp.sys.mac.programmer
Subject: ? C++ FAQ where ?
Date: 17 Aug 92 06:37:54 GMT
Organization: Stanford Linear Accelerator Center

Could someone plsese let me know where I can pull out the
comp.lang.c++ FAQ list from?

I have been watching clc++ recently, but all I see are some requests
for C++ FAQ with no follow-up's, nor any resposting of FAQ.

I am cross posting this on comp.lang.c++ and comp.sys.mac.programmer.
Thanks for your help!

* Nobu Toge, ex-employee at Stanford Linear Accelerator Center.
* Neither my former (SLAC) or present (Nat'l Lab for High Energy
* Physics, Japan) employers are not responsible for this question.
* My question is only mine, unless shared by someone else.
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: Sun, 16 Aug 1992 05:45:19 GMT

In article <DAVEG.92Aug14194411@synaptx.synaptics.com> daveg@synaptics.com (Dave Gillespie) writes:
>In article <1992Aug14.021547.15215@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:

>I still think declaring pointers to be GC would be too much of a
>hassle for the programmer, so we're left having to assume all
>pointers may point to GC-allocated objects.  

	Thats why GC on a class basis. A pointer to a GC class
IS a GC pointer, there's no need for the programmer to 'declare'
it as such.

	GC class X { .... // GC collectable class
	X* p;	// GC pointer because X is GC, no special syntax


>Without adding lots of
>tags in places that make C compatiblity awkward, we're left with a
>completely "conservative", i.e., brute-force GC algorithm.  We scan
>every word on the stack, every word in static storage, and every
>word on the non-GC heap for things that look like GC pointers.

	It wont work under Windows.
There is no stack, except temporarily on member function calls.
The objects are rooted directly in the window memory, and the're
looked after by the OS, not the stack.

	The C memory model is defunct. This is the biggest flaw
in C/C++. C memory model assumes three segments: code, data, stack.
(Pascal assume two, code and stack). We can tack on the heap for
C++ because it has a built in 'new' operator. To implement
persistence, dynamic linkage, multi-tasking with shared memory,
ROM, hardware ports, etc, requires language support. 
(Oh, C has register too)

	If you look at the Windows memory model you will see what I mean.
It requires truly awful C to manage, and C++ cant help much.
Windows uses handles, and you have to lock them to get out a pointer.
The memory can be moved when the handle is not locked. And you had
better unlock them after you're finished.

	Smart pointers can be used to do the lock automatically,
but I cant see how the unlock can be done, operator-> just
isn't smart enough. Basically, the C/C++ memory model doesn't
support handles, and so NO amount of cleverness can convince
the system to support handles. You have to do it by hand.

	Anyhow, looking GC certainly raises some interesting 
questions. It generally get implemented in systems with a controlled
run-time environment, which definitely isnt C++.

-- 
;----------------------------------------------------------------------
        TIM (TAL) LISTER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: rmartin@dirac.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Tiny proposal for named loops.
Date: 21 Aug 92 22:25:42 GMT

aldavi01@starbase.spd.louisville.edu (Arlie Davis) writes:

|Since the language is still open to improvements, even those which relate to
|the more C-oriented personality of C++, I'd like to suggest the addition
|of named loops.


|Example:

|for main_loop (...)
|  // ...
|  for inner_loop (...)
|    // ... complex mess of loops ...
|          break main_loop;       // somewhere deep inside the loops
|    // ...
|          continue inner_loop;   // similarly, deep inside loops


|This would eliminate the need for some state variables used with switches,
|which would make code more readable, and more block-oriented.

|Yes, it's a structured goto.  But so are break and continue in the first place
|-- this is an improvement of them.

IMHO breaks and continues should be avoided, not improved.  As you
say, they are a form of goto.  Don't use them, except in case
statements where you must :-( use break.

State variables are preferable to breaks and continues.  Judicious use
of them allows all loops and blocks to be exited at the same place.
This benefit outweighs the disadvantage of using a flag.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: References as class members
Organization: University of Illinois at Urbana-Champaign
Date: Sun, 16 Aug 1992 22:13:28 GMT

In <LVI.92Aug14161521@aste27.ida.liu.se> lvi@ida.liu.se (Lars Viklund) writes:


>Is the following class declaration legal?

>class X {
>    X& r;
>};

*****>	Yes.

>According to ARM it should be OK, but the ObjectCenter 1.1 compiler
>and Sun CC 2.1 claims that the reference must have a constructor.

*****>	And they're both correct.

>GCC compiles it without complaining.

*****>	Then GCC has a bug.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++