HDTenEightyP/NetNews huggingface dataset:
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Keywords: temporaries,destruction,statements,block,early
Date: 19 Aug 92 18:22:44 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <3920@starlab.UUCP> mi@starlab.UUCP (Michael Hoennig) writes:

> >For these reasons, I think a shorter lifetime than end of statement
> >is appropriate for temporaries.  Whether the committee will go that
> >way, however, remains to be seen.

> Why shorter, Andrew? Why not like all other automatic instances (those
> on the stack) at the end of the block?

Three reasons:

	1. strict end of block destruction creates problems for programs
	   like this:

		{
		loop:
			// do something that creates a temporary here
			if(cond) goto loop;
		}

	   If you'really serious about destroying temporaries at end of
	   block, that means you need a mechanism for allocating potentially
	   uncbounded stack space and keeping track of all the destructors
	   so as to be able to undo them all at the end.  This can be a
	   real pain, especially if you are trying to compile to C.

	2. Even if you don't want to handle things like the above, you
	   would still need flags that correspond to temporaries created
	   conditionally, particular in ?: expressions.  These flags
	   can potentially impose significant overhead even on people who
	   don't care about when the temporaries are destroyed.

	3. I have heard comments from users who really want temporaries
	   cleaned up early if possible.  Typically they are using linear
	   algrbra packages and write things like this:

		Matrix D = A * B * C;
	   
	   and do not want the intermediate result A * B to hang around
	   until the end of the block.  Of course they can't enclose this
	   in braces because then that would tear down D as well.  Moreover,

		Matrix D;
		{
			D = A * B * C;
		}

	   in addition to being ungainly, substitutes assignment for
	   initialization.  This can be significantly slower in some
	   implementations.

Destruction at end of block is far from a hopeless approach, but I
think it loses on balance.  Indeed, there's something to be said for
almost every approach, which is why this is a knotty problem.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: rjesse@netcom.Netcom.COM (Rick Jesse)
Subject: compiling nihcl
Date: Tue, 18 Aug 92 06:50:48 GMT
Organization: Netcom Online Communications Service
Distribution: comp.lang.c++

I'm having problems compling NIHCL.  I'm compiling version 3.0 using AT&T
cfont 2.1 on a Sun-4/110.  Compliation fails while making errorfacility.
I've edited the top-most Makefile so that the +p flag is not used and
set up the paths to where CC resides.  Other than that, I havn't modified
any files in lib.  Has any one else had similar problems?  Or, is there
a newer version available?

Thanks,

Rick Jesse



Newsgroups: comp.lang.c++
From: joe@proto.com (Joe Huffman)
Subject: Re: Allocating arrays larger than 64K with new?
Organization: Prototronics @ Sandpoint, Idaho
Date: Sat, 15 Aug 1992 07:02:00 GMT

ajb@winton.uucp (Arthur J. Butler) writes:

>In article <f94m37_.feustel@netcom.com> feustel@netcom.com (David Feustel) writes:
>>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.

>I just compiled this using Zortech and linking with x32v.lib.  I
>compiled it both as a C program and as a C++ program (minor note: i had to
>include stdlib.h).  I sucessfully ran it on my 486 with 8 meg of
>memory and about 80 meg of free disk space.  You are allocating three
>chunks of 12 Mbytes each.

>I believe your problem is that you compiled the program in small
>memory model and not X memory model.  It will link with x32 and not
>complain at all.  I did that by mistake and indeed running the program
>halted the system.

I know David uses OS/2 2.0 a lot.  I tried running the program under
OS/2 and first found I had to raise the virtual memory limit on the DPMI
host.  Then I ran out of disk swap space and OS/2 and I had a 'discussion'
about it.  It told me about the swap space problem and suggest I kill
the process, either I didn't know how (although it appeared to be
rather obvious) or it couldn't accomplish it.  It would run for a second
or two longer and give me the same message.  This happened about 10 times
and I finally tried a different option -- something about reporting the 
error to the application and continueing.  That locked up the machine...
I had to use the reset button.

As near as I could tell, the program, the compiler, and the DOS extender 
are working correctly.  I didn't track down a machine that had enough
disk space to run the program successfully (virtual memory is required
for most machines because of the 36 Mbyte memory allocation).  If someone
has tested this further and concluded (or is suspicious) that there is
a problem with the compiler or extender I will investigate further.

Let me know.

Joe Huffman
FlashTek, Inc.
804 Airport Way Suite D
Sandpoint, Idaho 83864
U.S.A.

FAX:    208-263-8772
Voice:  208-263-7311
Orders: 800-397-7310
-- 
netcom!proto!joe
joe@proto.com
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: C++ 3.0 and exceptions
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 21 Aug 1992 01:11:12 GMT

In article <MATTHEW.92Aug19105738@matthew.ntl02.decnet.nokia.fi> matthew@ntl02.decnet.nokia.fi (Matthew Faupel) writes:
>Could anyone please confirm or deny the fact that exceptions as described in
>Bjarne Stroustrup's 2nd edition of the C++ Programming Language are *not*
>supported by v3.0 of the language?
>
>Follow-up question: If they are not supported, when will they be?
>

	Exceptions as defined in the ARM require run-time type
information, and since no one has figured out how to do that,
exceptions will be on hold for a while I suspect. Maybe
the exception handling mechanism will have to be modified
to simplify the requirements for RTTI to a manageable level
(like requiring all 'thrown' objects to be 'derived' from
a fixed exception class)



-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.lang.c++
Subject: Re: Handling of operator . pro
Date: 14 Aug 92 23:53:19 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

In article <9222714.28203@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>Generally if a facility does provide a *large* reduction in the complexity
>of programs that need it, then it's not worth it.

	How about tagged pointers/unions/references?
	At the moment I think they warrant a whole extra chapter
in the ARM++, one on facilities for heterogeneity.
>
>If there's one thing that C++ does well, then that thing is making C obsolete.

	:-)

>For C++, the competition will come from languages that are more powerful
>yet less complex; as Bjarne has said, C compatability is C++'s biggest strength
>and also its biggest weakness.

	Which ones. Is Eiffel, for example, really less complex?
Scheme is probably less complex and more powerful, so why aren't
we all using Scheme? How about CLOS---is that more or less complex?

	The big fight here is to get static safety and dynmaic
power to cooperate to get dynamism and safety simultaneously
available. Then you can trade off safety for power. C/C++ already
allows another trade-off: safety/efficiency.

	IMHO C++ should err on the side of safety, since extensions
are hard to remove.


-- 
;----------------------------------------------------------------------
        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: dag@control.lth.se (Dag Bruck)
Subject: Re: destruction of temporaries
Organization: Department of Automatic Control, Lund, Sweden
Date: Fri, 21 Aug 1992 06:06:30 GMT

In <comp.lang.c++> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>In article <...> dag@control.lth.se (Dag Bruck) writes:
>>
>>Given the deliberations for and against different models [no details
>>given] I would probably prefer destruction at greatest enclosing
>>expression, 
>
>	Do you mean the next semicolon? I think thats what
>you just said isn't it?

Essentially yes, but my wording also applies to the initialization
list of a constructor, which does not have a semicolon.

This is a good example why "standardeeze" is often hard to read.

>>with the additional constraint that temporaries created in
>>one "arm" of a conditional expression are destroyed at the end of that
>>conditional expression.
>
>	As a matter of interest, what is the status of
>
>	(a<b ? a : b )=1;
                ^   ^
In my interpretation, any temporaries generated for the ?: expression
would be destroyed at either of the positions marked with ^.


		-- Dag
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: C++ 3.0 and exceptions
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 22 Aug 1992 16:30:22 GMT

In article <1992Aug20.224432.21822@jarvis.csri.toronto.edu> mendell@turing.toronto.edu (Mark Mendell) writes:
>IBM's xlC C++ compiler for the RS/6000 has been supporting C++ exception
>handling since May.  It isn't all that hard to do (harder if you have to
>generate C), and can be done without full runtime type information.  The
>compiler always knows the types being thrown and caught at compile time.

	How does the compiler know that? I am baffled.
If I have some catch statments, call a routine in a try block,
and that routine is separately compiled, it could literally
throw ANY object. Thats why RTTI is required I thought.
Can someone correct me?

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.lang.c++
Subject: TVision Help
Date: 16 Aug 92 15:30:46 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

Help! BC3.1 Turbo Vision Help system (TVHC etc) appears to fail
with an error in TV's new.cpp. The TVDEMO project does not work.
I have a production program that is stopped because of this
(oh, why did I use TV!) I'd prefer not to have to reinstall
BC3.0. Anyone know anything about this?

-- 
;----------------------------------------------------------------------
        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: using (...) question
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Tue, 18 Aug 1992 04:28:09 GMT

In <1992Aug16.221527.4992@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:

>In <J3mkPB8w165w@toz.buffalo.ny.us> cyberman@toz.buffalo.ny.us (Cyberman) writes:

>>I am making a function that will not have set number of 
>>parameters passed to it except 1.  Now how do I ACCESS these parameters?
>>I know printf is prototyped as
>>int printf(char *,...);
>>I would like to know how from within the function to access the 
>>remaing parameters!

>*****>	By using <varargs.h>  Stroustrup, 2nd. edition, has an example as
>	does my book.

*****>	I meant <stdarg.h>; old habits die hard.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 14 Aug 92 23:08:50 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

In article <46140@sunquest.UUCP> bill@sunquest.UUCP (Bill Raves) writes:
>know the details of the implementation.  What *specific* guidelines
>would you suggest for avoiding potential problems with unnamed tem-
>poraries?
>

	Name them. Take control of their lifetime. 
	This is not always possible, of course.

	f(a+b)--> {T c=a+b; f(c);}


-- 
;----------------------------------------------------------------------
        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@sparc6.cs.uiuc.edu (Paul Lucas)
Subject: Re: Return value for the constructors.
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Tue, 18 Aug 1992 21:04:26 GMT

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.

	Anyway, where would the return value _go_?

	class Foo {
		int Foo( ... ) { ... return expr; }	// hypothetical
	};

	Foo x(...);			// no use for a return-value here
	Foo *p = new Foo(...);		// nor here; the address is returned
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: rjesse@netcom.Netcom.COM (Rick Jesse)
Subject: Re: Trouble compiling NIH classes
Date: Sat, 22 Aug 92 22:40:49 GMT
Organization: Netcom Online Communications Service

In article <1992Aug19.181622.12608@tcsi.com> sriram@tcs.com (Sriram Srinivasah) writes:

   Newsgroups: comp.lang.c++
Path: netcom.com!csus.edu!wupost!uunet!tcsi.com!sriram
   From: sriram@tcs.com (Sriram Srinivasah)
   Sender: news@tcsi.com
   Organization: Teknekron Communications, Inc
   Date: Wed, 19 Aug 1992 18:16:22 GMT
   Lines: 20



   I used Sun's C++ compiler, and also Centerline's cfront 2.1 compatible compiler, 
   and get the following error on compiling the NIH classes (the SUN CC version,
   from alw.nih.gov)

   CC    -DNESTED_TYPES   -c -I../nihincl Arraychar.c
   ./nihclconfig.h: 31: sparc redefined
   "./nihclconfig.h", line 279: error: two exact matches for ENV_PC(): unsigned
		  int (const JMP_BUF &) and unsigned int &(JMP_BUF )
   "./nihclconfig.h", line 280: error: two exact matches for ENV_SP(): unsigned 
		  int (const JMP_BUF &) and unsigned int &(JMP_BUF )
   "./nihclconfig.h", line 281: error: two exact matches for ENV_FP(): unsigned 
		  int (const JMP_BUF &) and unsigned int &(JMP_BUF )
   Compilation failed

   Can anyone give me some tips on this?

   Sriram,

   I'm getting the same errors using Sun's cfront 2.1 on a 4/110.  The
   problem looks like the ENV_ functions are being overloaded at the
   end of nihclconfig.h but the arguments from the previous defintions
   of ENV_ in nihclconfig.h (the platform specific ones) have the
   same arguments.  I haven't found a solution yet, but I'm posting
   to K. Gorlen.  I'll let you know what happens.

   Rick Jesse

 
















































Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Garbage Collection for C++
Organization: :
Date: Sun, 16 Aug 1992 07:58:04 GMT

In article <TMB.92Aug14130323@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
> 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:
>    |> Couldn't we get away with having a garbage collector that didn't
>    |> need pointers to be declared `GC'?
 
>    I can't see that this is viable given the basic constraints on C++: among
>    other things, those who don't want GC shouldn't have to suffer the hits.
> 
> What "hits"? In all the cases that I have looked at, the GC overhead
> has been _smaller_ than the overhead of explicit memory management in
> C++.  ...
 
> Based on my experience, I would turn your statement around and say:
> "those of us who want GC shouldn't have to suffer the inefficiencies
> of not having it".

The real problem with GC is that it is based on a particular model of
how a programming language represents something.  That model states
that the _value_ of something is all that matters; once the value
disappears, the identity means nothing.  On the other hand, C++, with
defined lifetimes for objects, declares that the object identity is
part of the model of computation.

To put it differently, when does the destructor for a GC'd object get
called?  What happens if the GC'd object's destructor makes a call that
has an effect outside the system?  In other words, what happens to
relationships between the objects in the system and the world outside?

A great deal of a program's information is stored in the relationships
between things, and not just in their values.  A GC'able language has
a certain semantic restriction: you will never use the actual object
(i.e. object-in-memory as C and C++ define the word) identity to represent
something.  If you have a reference to another object, it is because you
are interested in the value stored there, not in the object identity
itself.  Once the value is no longer accessible, the object identity is 
worthless.

C++ doesn't make this assumption.  Some data structures that are written
in C++ may, and GC may be suitable for those data structures.  But the
suitability of those data structures to GC shouldn't be mistaken for
the suitability of C++ for GC.  C++ doesn't assume or demand GC'able
semantics in its representations.  In fact, it assumes _and_ demands
semantics that are contrary to GC (management of object lifetime)--but
it doesn't force these semantics on every representation.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 19 Aug 92 15:36:57 GMT
	<1992Aug17.211508.6634@lucid.com>
	<1992Aug18.205211.16789@Warren.MENTORG.COM>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: adk@Warren.MENTORG.COM's message of 18 Aug 92 20:52:11 GMT

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.

The properties of temporaries are no different (and no worse) than the
properties of automatic variables: pointers to them become invalid
when the object disappears.

If you want to be able to implement anything more powerful, you need
(surprise!) garbage collection (as stated in the ARM, p. 268). In the
presence of GC, you would then actually have a choice of destroying
the temporary yourself (the current situation, safe if no pointers to
it have been handed out), or of not destroying it at the end of the
expression and letting the GC take care of it.

					Thomas.
From: mi@starlab.UUCP (Michael Hoennig)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Keywords: temporaries,destruction,constructor,initialization
Date: 19 Aug 92 06:44:49 GMT
Organization: StarDivision GmbH, D-2000 Hamburg, Germany

Hi Net-World,

there is another problem too:

Class::Class()
	ParentClass( Resource( 1000 ) ),
	aMember1( SubResource( 10 ) ),
	aMember2( SubResource( 20 ) )
{}

When should be called the destructor of Resource(1000)? Microsoft C++ 7.0 
will never call it - this of cause is a bug. Borland C++ 3.0 too. Borland
C++ 3.1 calls it immediatly after the expression - at the comma. Zortech
C++ 3.0 Release 4 calls it at the obening brace ({)and cfronts (as I 
remember correctly) at the closing brace (}).

Adios
-- 
Michael Hoennig                                  FAX:   +49 40 23 646 550
StarDivision GmbH                                Phone: +49 40 23 646 500
Sachsenfeld 4                                    uucp: ...!unido!starlab!mi
D-W-2000 Hamburg 1                               domain: mi@starlab.uucp
Newsgroups: comp.lang.c++
From: wright@epx.cis.umn.edu (Mark Wright)
Newsgroups: comp.lang.c++
Subject: Binary Stream IO
Date: 17 Aug 92 18:21:48 GMT
Organization: University of Minnesota

Is there a way to do Binary i/o with the stream classes?  In other words, can I
do "oFile << double_value" in such a way that double_value is stored using its
binary representation rather than as an ascii string?

Mark Wright
wright@epx.cis.umn.edu
Newsgroups: comp.lang.c++
From: eric@tfs.com (Eric Smith)
Subject: Re: PD C++ => C translator wanted
Organization: TFS
Date: Wed, 19 Aug 1992 21:52:26 GMT

In article <1992Aug19.034324.16189@sinkhole.unf.edu> shite@sinkhole.unf.edu (Stephen Hite) writes:
>In article <92224.080629WJCMS@CUNYVM.BITNET> WJCMS@CUNYVM.BITNET writes:
>>FAQ tells me that there are many C++ => C translators. Can anyone point to me
>>a public domain one? I'd like to start doing C++, but since I'm not sure yet
>>what will be the programming platform, I don't want to spend too much money
>>in the beginning. I'd rather get C++ => C translator and have a littlemore
>>freedom of choice.
>>
>>
>>Thank You,
>>Janne Ravantti
>
>  The g++ compiler, that's your only freely available choice.
>You will not find a PD C++ -> C "translator."  
>
>Steve Hite
>shite@sinkhole.unf.edu
>  


A C++ to C translator would not be very useful as a stand-alone product.
It would not have access to the right libraries, and/or it would not know
what libraries it did have access to.  For example, how would you implement
iostreams?  Features such as that depend on the presence of the appropriate
header files and libraries that come with a complete C++ compiler product.
From: mittle@watson.ibm.com (Josh Mittleman)
Newsgroups: comp.lang.c++
Subject: Re: Return value for the constructors.
Date: 19 Aug 92 17:58:52 GMT
Distribution: usa
Organization: IBM T.J. Watson Research Center
Disclaimer: This posting represents the poster's views, not necessarily those of IBM

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

*****>	No; the allocator new() is returning zero, not the constructor.
> 	Also, if the ctor further allocates it's own stuff, there is 
> 	currently no clean way of returning that fact to the caller--
> 	new() will return success, i.e., non-zero.

Sure there is: Overload operator new().  For example, give your class a
static status flag.  operator new() sets it to 1, then calls ::new() to
allocate the object.  Your constructors make whatever internal checks they
need, and set status to 0 if there is a problem.  Then, operator new()
returns a pointer to the new object or 0, depending on the success of the
process.  From the users point-of-view, it simply looks like a normal call
to new().

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.lang.c++