HDTenEightyP/NetNews huggingface dataset:
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: destruction of temporaries
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Thu, 20 Aug 92 19:03:13 GMT

In article <TMB.92Aug20142610@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

|> Let me put in another vote for leaving things the way they are.
|

There may be some confusion about where we are now. The ARM (and the
x3j16 working paper) give compilers a lot of freedom about where
to destroy temporaries. 

This is generally considered unsatisfactory because it means
that programs frequently break when move between compilers with
different strategies.   If all compilers were making the same
or similar choices in this area x3j16 could just standardize that
decision. The reason this didn't happen is that there are good arguments
for a variety of different strategies. 

I have strong opinions about where that destruction of temporaries
should (or should not) take place, but think it is more
important that some place be specified than where that specific 
place is.


   -- Jerry Schwarz
Newsgroups: comp.lang.c++
From: alaybeyi@datsun.ece.cmu.edu (Murat Alaybeyi)
Subject: Unreasonable include nesting?? (AT&T cfront question)
Organization: VLSI CAD Center, Carnegie Mellon University
Distribution: comp.lang.c++
Date: Wed, 19 Aug 1992 07:40:46 GMT


When I compile a bunch of C++ files using AT&T cfront2 I get a cpp error.
The error message is as follows:

 /server/CenterLine/c++_1.1.0-r1.0/sun4-40/include/sys/resource.h : 8 :
 Unreasonable include nesting.
 CC: cpp failure : 2 
 *** Error code 1
 

I am pretty sure that all of my header files are protected against double inclusion.

I also used gcc to find the inclusion dependencies of the source files, I did
not get any cpp error in this case. (I still used the AT&T system header 
files; not the gnu header files)


However when I include osfcn.h right at the beginning of the C file that I am 
compiling the error is gone and everything is fine.

We have 7-8 level of include file nesting. 

This problem does not exist within objectcenter.

Is there a known bug in the cfront system header files or is it a cpp error or
something else that we are doing wrong.

                                                       Murat Alaybeyi
                                                       Vivek Raghavan


--
--
Murat Alaybeyi,                              ECE Department
Phone: (412) 268-5238                        Carnegie Mellon University
e-mail: alaybeyi@ece.cmu.edu                 Pittsburgh, PA. 15213   U.S.A.
From: epp@mala.bc.ca (Lorne Epp)
Newsgroups: comp.lang.c++
Subject: Re: Strange problem with Borland C++
Date: 21 Aug 92 15:38:32 -0700
Organization: Malaspina College

In article <15150008@hpdmd48.boi.hp.com>, ravinc@hpdmd48.boi.hp.com (Ravin Chauhan (temp)) writes:
> Can someone please help me with a strange problem in Borland C++?
> 
> Defining a class' constructor with arguments has affected compilation of
> operator overloading friend functions. In the following program, there
> are two class definitions for Header. The first one, (without argument
> to the constructor) compiles successfully. The second one, (with argument
> int i to the constructor) results in two errors at compile time, in
> overloaded operator function definitions ifstream& operator>>() and
> ofstream& operator<<().
> 
> 
> The following program was compiled using Borland C++ version 3.1.
> The source code has been edited for readability. Ignore the warnings
> and look out for the following 2 errors.
> 
> Error 1: Ambiguity between 'operator >>(ifstream &, Header &)' and
> 				'istream::operator >>(unsigned char &)'
> Error 2: Ambiguity between 'operator >>(ofstream &, Header &)' and
> 				'ostream::operator >>(unsigned char &)'
> 
Your constructor-with-an-argument defines a conversion from int to
Header.  What your compiler is telling you is that an expression such as

	unsigned char c;
	cout << ch;
	
is now ambiguous because the compiler can't tell whether ch should be
converted to a Header, and your friend function called, or left as
is and ostream's operator called.  You can rewrite your code
so that you explicitly call the appropriate operator function. This
takes all the fun out of overloading operators, though.
----------------------------------------------------------------------
Lorne Epp                                               epp@mala.bc.ca
From: davidm@consilium.com (David S. Masterson)
Newsgroups: comp.lang.c++
Subject: Re: Help: Looking for documentation on iostream library.
Date: 20 Aug 92 23:03:57 GMT
	<1992Aug19.150955.21600@ohrd.uucp>
Organization: Consilium Inc., Mountain View, California
In-reply-to: ohrd!twriter@cs.toronto.edu's message of 19 Aug 92 15:09:55 GMT
X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> On 19 Aug 92 15:09:55 GMT, ohrd!twriter@cs.toronto.edu (Timothy Writer)
>>>>> said:

> jss@lucid.com (Jerry Schwarz) writes:

>>More extensive documentation including man pages and a paper entitled
>>"Iostream Examples" (by myself) is shipped with most cfront ports. As far as
>>I know there are no ftpable documents.

> Short of buying cfront, is there any *complete* reference for the
> iostream library?  I am happy to spend money if my purchase gives me
> what I need.

"IOStreams Examples" that Jerry mentioned is not a reference per se, but it is
a good document on the intricacies of iostreams.  If you want to get into
iostreams, this is probably the thing to get until something better comes
along.  It's helped me on occassion, but you have to be careful in reading it
as it does have some misleading "typos" and assumes a level of understanding
in many areas that borders on having the source code for the library to refer
to for further ideas and verification.

This was part of the Library Manual for AT&T C++ 2.0 and I got a copy by
calling 1-800-CALLATT.  The select code that I have is probably no longer
correct now that they've come out with newer versions.  At the time, you could
order the manuals without ordering the source code.
--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
uunet!cimshop!davidm				Mtn. View, CA  94043
====================================================================
From: cyberman@toz.buffalo.ny.us (Cyberman)
Newsgroups: comp.lang.c++
Subject: using (...) question
Date: 15 Aug 92 23:28:42 GMT
Organization: The Tower of Zot - (716)691-3865

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!
Thanks
Cyberman  
 


************************************************************
* Cyberman@TOZ.BUFFALO.NY.US                               *
*   "Life is what you put into it" - Cyberman              *
* Optimistic - running through a barn of manure looking    *
* for the horse!  /\ [] ( )                                *
Newsgroups: comp.lang.c++
From: bmcphers@alias.com (Brent McPherson)
Subject: Re: Tiny proposal for named loops.
Organization: Alias Research Inc., Toronto ON Canada
Date: Fri, 21 Aug 1992 20:36:35 GMT

In article <TSOS.61.714395736@uni-duesseldorf.de> TSOS@uni-duesseldorf.de (Detlef Lannert) writes:
>In article <aldavi01.714376080@starbase.spd.louisville.edu> 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.  The syntax would not break any existing code at all.
>>An identifier would be placed just after the "for", "while", "do", or even
>>"if" keyword.  This keyword could be used just after "break" or "continue",
>>to specify exactly which loop to break or continue.
>>
>>Example: [deleted for bandwidth's sake]
>>
>>This would eliminate the need for some state variables used with switches,
>>which would make code more readable, and more block-oriented.
>
>I like your idea. It could certainly make C[++] code safer
>and more legible. There shouldn't be any syntactical problem
>with
>
>     if [<id>] (<expression>) <statement>
>     switch [<id>] (<expression>) <statement>
>     while [<id>] (<expression>) <statement>
>     do <statement> while [<id>] (<expression>) ;
>     for [<id>] (...;...;...) <statement>
>
>A "break <id>;" statement would be useful for the "switch"
>construct as well as for "while", "do...while", and "for",
>as would the "continue <id>;" for the repetitive statements.
>

This is a great idea!  I've always used goto's to jump out of
nested loops but this can cause problems.

1) Most people see the word goto and freak out!  Even when it
   is used to jump out of a nested block (which makes up for 
   not having named blocks in C/C++).

2) Most C++ compilers see the word goto and freak out!  Because, 
   the possibility of a backwards jump exists, most C++ compilers I've 
   seen disallow goto to be used in a block with constructors in it.
   Often, it is very hard to satisfy this condition in non-trivial
   cases or where temporary objects are involved. 

--
Brent McPherson  (bmcphers@alias.com)
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Covariant Types in Derived Classes
Summary: They are thinking about it ...
Organization: :
Date: Thu, 20 Aug 1992 09:38:37 GMT

In article <714193217snx@trmphrst.demon.co.uk>, nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
> In article <1992Aug13.162956.10279@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
> > In article <713504630snx@trmphrst.demon.co.uk>, nikki@trmphrst.demon.co.uk (Nikki Locke) writes:

> > Why do you want a warning?  You asked for it explicitly and it lies
> > within the type system.  ...
 
> You are quite right. In this case, it is legal to write
> x = z;		// Give me a warning please
> x = (int)z;	// I really mean it, don't warn me
 
> However, there are many cases where the cast syntax is _necessary_ ...  To
> have the compiler accept all such casts without warning (because cast means
> "I really mean it") is unfortunate - I might have typed the wrong thing.
 
> I think what I am asking for is some kind of language syntax which
> distinguishes between casts which I expect to be safe [conversions] (so I
> hope the compiler will warn me if they aren't), and those which I know
> aren't safe [coercions] (but I want to do it anyway, ...

> What does the team think ?

This is your lucky day!  (Well, OK, it's coming in '94 or '95 ...)  The
issue arose in Toronto as a side-effect of RTTI.  Look for a possible
solution in the RTTI stuff that will make it into the literature in the
fall.  (Notice, I'm not promising that there will *be* one; I'm just
telling you to *look* for it ...)
-- 
 (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++,comp.std.c++
From: chip@tct.com (Chip Salzenberg)
Subject: Re: run-time type checking, freezing, and thawing
Date: Mon, 17 Aug 1992 13:32:56 GMT
Organization: TC Telemanagement, Clearwater, FL

According to jrobie@netmbx.netmbx.de (Jonathan Robie):
>chip@tct.com (Chip Salzenberg) writes:
>>According to jrobie@netmbx.netmbx.de (Jonathan Robie):
>>>Well, the full polymorphic type should contain precisely the information
>>>found in the class declarations, no more and no less.
>
>>Yes, but is that the >>C++<< class declaration, or the >>POET<< class
>>declaration?
>
>The C++ class declaration, of course.

But a C++ doesn't provide enough information for persistence.  That's
why POET has the "transient" keyword, for example.  So the "complete
polymorphic type information" required for thawing an object is _not_
the C++ type information, but rather the POET type information (though
the latter is a superset of the former, to be sure).
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
   "Do Rush place weird subliminal backmasked messages in their songs to
 compel unwilling geeks to commit evil .sig atrocities?"  -- Dean Engelhardt
From: nandraj@unisql.UUCP (Nandraj Arni)
Newsgroups: comp.lang.c++
Subject: Return value for the constructors.
Date: 18 Aug 92 16:19:27 GMT
Reply-To: nandraj@unisql.UUCP (Nandraj Arni)
Organization: UniSQL, Inc., Austin, Texas, USA


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


-- 
*******************************************************************
Nandraj Arni

UniSQL, Inc.                           Voice: 512 343 7372 Ext. 107
9390 Research Blvd.                              Home: 512 794 9386
Kaliedo II			   	          FAX: 512 343 7383
Austin, TX 78759

Email: unisql!nandraj@cs.utexas.edu
*******************************************************************
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Distribution: world
Subject: Re: Reference counting for vectors, (Tony Hansen's book).
X-Mailer: cppnews $Revision: 1.14 $
Organization: Trumphurst Ltd.
Date: Wed, 19 Aug 1992 15:54:11 +0000


In article <TMB.92Aug16160535@arolla.idiap.ch> tmb@idiap.ch writes:

> Counted.h
> 
> #ifndef __COUNTED__
> #define __COUNTED__
> 
> template <class T>
> struct Counted {
>  private:
> 	int *count;
> 	T *object;
> 	void drop() {
> 		if(!count) return;
> 		(*count)--;
> 		if(*count<=0) {
> 			delete count;
> 			delete object;
> 			count=0;
> 			object=0;
> 		}
> 	}
> 	void acquire() {
> 		(*count)++;
> 	}
>  public:
> 	Counted() {
> 		count=0;
> 		object=0;
> 	}
> 	Counted(T *object):object(object) {
> 		count = new int(1);
> 	}
> 	~Counted() {
> 		drop();
> 	}
> 	Counted(Counted &other) {
> 		count=other.count;
> 		object=other.object;
> 		acquire();
> 	}
> 	Counted &operator=(Counted &other) {
> 		drop();
> 		count=other.count;
> 		object=other.object;
> 		acquire();
> 		return *this;
> 	}
I think this copy operator contains the classic copy operator bug - try 
assigning a Counted object to itself - the object will be deleted before 
copying. Try ...

	Counted &operator=(Counted &other) {
		other.acquire();
		drop();
		count=other.count;
		object=other.object;
		return *this;
	}
Mind you, there is still a bug here - try 

	Counted<Thing> a, b;

	a = b;		// core dump ?

The fix is for acquire to check count is not NULL before doing (*count)++;

> 
> 	T &operator*() {return *object;}
> 	T *operator->() {return object;}
> 	operator T() {return *object;}
> 	
> 
> 	// do _not_ provide "operator T*()"
> };
> 
> #endif
> 

The original author clearly stated that the program was not tested, but I 
thought I ought to point out these problems so that others didn't copy the
mistakes.

Mind you, I haven't even compiled the code, let alone tested it, so I am 
even more likely to be wrong ! 

[ Hobby horse of the week ... ]
However, if I am right, think about how useful code review is in picking 
up such obscure bugs, and how cheap compared to hours of testing !
---
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.
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Covariant Types in Derived Classes
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 12 Aug 1992 14:45:39 GMT

In article <713504630snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
>
>In article <1992Aug8.210716.14741@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>> In article <713221684snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:
>> >
>> >No - some casts are fine - e.g. ...
>> >
>> >Casting a built-in arithmetic type to a larger type to avoid arithmetic 
>> >  overflow.
>> 
>> 	This is NOT a cast (in my terminology), but a value producting
>> conversion. I assume you mean
>> 
>> 	int x,y;
>> 	long z;
>> 	z=(long)x*y; // conversion NOT cast
>> 	*(long*)&x=z; // cast--bad news here :-)
>Oh No, Humpty-Dumpty casts now :-)
>
>Sorry, I wasn't aware that the construct "(type)" was sometimes called a 
>cast, and sometimes a conversion. O.K., I want a compiler that warns me 
>about all casts, but not about conversions.

	Please excuse my prejudices. I think I'm being unnecessarily
argumentative about terminology here. :-)
>
>By the way, what is 
>	int x;
>	long z;
>	
>	x = (int)z;
>
>Is this a cast, or a conversion ? (I want a warning anyway, please).

	Its a conversion. An rvalue is converted to an rvalue of
a different type. Not the same as looking at a bit pattern
representing one type as another type that it actually isnt---thats
a cast. Usually done through pointers.

	Upcasts aren't casts really because the derived type 'isA'
base type (but I'm stretching it here :-)
>
>O.K. Max, old chum :-)


	I believe Bjarne has identified 5 different types of 'casts',
and plans syntax to discriminate them. Mm.

-- 
;----------------------------------------------------------------------
        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: jimad@microsoft.com (Jim Adcock)
Subject: Re: Garbage Collection for C++
Date: 18 Aug 92 00:10:51 GMT
Organization: Microsoft Corporation

In article <1992Aug13.102809.16803@mic.ucla.edu> iwelch@agsm.ucla.edu (Ivo Welch) writes:
|Most of all, I hope that someone with the proper  expertise will [1] implement
|a minimal GC in Gnu g++, and [2] approach  the ANSI standards committee with a
|GC proposal.

Suggest that you might want to get in touch with Eliot Moss who 1) has done
excellent work in GC, and 2) is writing a Gnu version of Modula-3 based on
Gnu C++.  

Newsgroups: comp.lang.c++
From: philc@ruby.aruba.UUCP (Phil Calvin)
Subject: Re: Return value for the constructors.
Date: Thu, 20 Aug 1992 12:26:56 GMT
Distribution: usa
Organization: Project Zed

In article <H575V1E@netmbx.netmbx.de>, jrobie@netmbx.netmbx.de (Jonathan Robie) writes:

|> 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.

Isn't a more secure method provided by implementing a _new_handler function
that deals with allocation failures??

That way, such pointer checks are unnecessary..

...Phil

--------------------------------------------------------------------------
Phil Calvin                      |Internet Style: aruba!philc@uu2.psi.com
Systems Programming, Project Zed |UUCP: ...!uunet!uu2.psi.com!aruba!philc
--------------------------------------------------------------------------
From: mi@starlab.UUCP (Michael Hoennig)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Keywords: temporaries,destruction,statements,block,early
Date: 19 Aug 92 06:36:38 GMT
Organization: StarDivision GmbH, D-2000 Hamburg, Germany

In article <23466@alice.att.com> ark@alice.UUCP () writes:
>
>	1. If I break a statement up into several, it may
>	   quietly change its meaning.  Thus, for example, if
>	   String::operator const char*() exists, and s and t are
>	   of class String, then
>
>		printf("%s\n", (const char*)(s+t));
>	
>	   might work but
>
>		const char* r = s + t;
>		printf("%s\n", r);
>	   
>	   might not.
In my opinion the result shouldn't be to destroy temporaries such early - 
and of cause not more early (before the end of the statement). 

>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? In this case everyone can exactly
recocnize when the temporaries will be destroyes - and of cause too you
can exactly determine the point of destruction, simply be creating 
additional blocks. As shown here:

int foo()
{
	Class a1, a2;
	{ cout << a1+a2; }	// immediately after using - destroy
	... /// do more stuff - without the temporary
}

I think - the earlier temporaries will be destroyed, the more silent bugs
will be in C++ programs. Of cause we can't destroy them too late, but there
must be coosen a safe and determinable rule.

Please, dont't destroy them immediatley. Many elegant constructions
in C++ programs (as shown in examples in this news thread) won't be
possible anymore.

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
From: rmartin@dirac.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Constructor arguments for template classes
Date: 21 Aug 92 22:20:08 GMT

srinivas@lgc.com (Manapragada Srinivas) writes:


|Hi,

|	I  have a question about templates -

|	Suppose I design a Vector template class as follows

|	template <class T>
|	class Vector
|	{
|	public:
|		Vector( int size );
|		// ... destructors, private members etc.

|	}

|	a. Does Vector< Vector<int> > make sense?

|	b. If so how do I initialize it?

|		g++ is not happy about
|			Vector< Vector<int> > vec(10);

|		nor does it accept
|			Vector< Vector<int> > vec(10, 10);

I think you need to supply a specific constructor for this class.  You
can do this by overiding the one produced by the template

Vector< Vector < int > > :: Vector< Vector < int > >
: /* now initialize your inner vector... */
{
   ...
}


--
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: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 20 Aug 92 21:16:28 GMT
Article-I.D.: alice.23507
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <TMB.92Aug20142610@arolla.idiap.ch> tmb@idiap.ch writes:

> You can avoid unexpected behavior involving temporaries by programming
> defensively. In particular, this means: do _not_ return a reference or
> pointer to an explicit or implicit argument or its contents (*this,
> call-by-value, call-by-reference). Furthermore, do _not_ define cast
> operators to pointer types in your classes (instead, make them normal
> member functions that you have to call explicitly).

I wish life were that simple.  The trouble comes with expressions like

	foo().bar().baz()

where bar returns *this.  If an implementation is allowed to delete the
result of foo() before calling baz, the roof can cave in even if your
defensive rules are followed.  That is enough to argue, at least for me,
that the current rule of allowing temporaries to be destroyed as soon as
they are fetched, is too liberal.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++