HDTenEightyP/NetNews huggingface dataset:
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: Return value for the constructors.
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Wed, 19 Aug 1992 16:35:45 GMT

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

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

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

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

*****>	This has nothing to do with the original question.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: Reid Ellis <rae@Alias.com>
Subject: Re: named loops
Organization: Alias Research, Inc., Toronto ON Canada
Date: Fri, 21 Aug 1992 14:36:53 GMT

Arlie Davis <aldavi01@starbase.spd.louisville.edu> writes:
|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

How about an int argument to "break", as supported in many scripting
languages?  Add a similar argument to "continue" while we're at it.
Then you can do things like this:

for(...) { // loop outer
    for(...) { // loop middle
        for(...) { // loop inner

            break; // breaks out of inner

            break 2; // breaks out of middle

            continue 2; // continues middle
        } // loop 3
    } // loop 2
} // loop 1

An argument of zero or one would cause the current, default behaviour.
Just a thought...

						Reid
--
Reid Ellis                                            
rae@utcs.utoronto.ca        ||           rae@Alias.com
CDA0610@applelink.apple.com ||  +1 416 362 9181 [work]
Newsgroups: comp.lang.c++
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: Object metamorphosis - can/should it be done?
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Tue, 18 Aug 92 17:49:16 GMT

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
: swillden@news.ccutah.edu (Shawn Willden) writes:
: 
: >I ran across some interesting Objective-C code the other day and I 
: >wondered if there is some way to implement it in C++.  Then I wondered
: >if it was a good idea to try.  Anyway, the concept is that an object
: >can be asked to mutate into an object of a different type.  Under
: >Objective-C's concept of an object, any object can mutate to essentially
: >any other type because all messages are resolved at run-time.  In C++'s
: >static system this is not possible, however, it seems to me that there 
: >is at least one case in which it might be possible in C++ and maybe even 
: >useful.  Given a base class pointer or reference to a derived class
: >object, it should be possible to replace the derived class object with
: >an object of another derived type.  
: 
: One major problem with your example code
: 
: >void Pupa::metamorphose() {
: >	Pupa* old_me = this;
: >	(Adult*)this = new Adult(*old_me);
: >	delete old_me;
: >}
: 
: is that "this" is passed by value, not by reference, so assignment to "this"
: is not going to have the desired effect.

That makes sense.  In order to do what I want to I would have to find the
original pointer and change it.  Thanks for your example.  It is essentially
what I suggested, except that I was going to place all the functionality in
the Butterfly class and use a flag to decide what the Butterfly currently
"is".  I like your method better.  I believe that there was one error
in your code, though, you derived Pupa and Adult from Butterfly rather
than ButterflyStage. 

: Aside: this is another example where we want to do smart references.
: A Butterfly is a smart reference to a ButterflyStage.
: I could post code to show how to do it using overloading of operator
: dot as per Jim Adcock's proposal, but since I am probably the ONLY
: person in possession of a compiler that implements his proposal (I have
: modified gcc 2.2.2 to do this) there isn't much point.

Would you mind making the diffs available?  I have considered modifying
gcc to do this and a few other tricks (tagged pointers among them, though
maybe I'll wait and let Max Skaller do that for me ;-> ).

: 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!

Shawn Willden
swillden@icarus.weber.edu
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Distribution: world
Subject: Re: Covariant Types in Derived Classes
X-Mailer: cppnews $Revision: 1.14 $
Organization: Trumphurst Ltd.
Date: Tue, 18 Aug 1992 20:00:17 +0000


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:
> > 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).
> 
> It is a conversion that is indicated syntactically by a cast.  
> 
> Why do you want a warning?  You asked for it explicitly and it lies
> within the type system.  There's an important principle here: for
> every construct that can produce a warning, there must be a way to
> write an equivalent construct that does _not_ produce the warning.
> This is part and parcel of the C/C++ philosophy that ``if you _really_
> want to do that, we'll take you at your word.''
> 
> The code fragment written _without_ the cast might very well merit a
> warning about value truncation.
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_ (e.g. 
to distinguish between multiple user-defined conversions). 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, because of some
additional knowledge I possess which the compiler can't see). 

What does the team think ?
---
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: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Reference counting for vectors, (Tony Hansen's book).
Date: 17 Aug 92 21:32:18 GMT
	<BRISTER.92Aug14170213@tirade.decwrl.dec.com>
	<1992Aug16.081316.27729@mole-end.matawan.nj.us>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: mat@mole-end.matawan.nj.us's message of 16 Aug 92 08:13:16 GMT

mat@mole-end.matawan.nj.us writes:

   One possibility, at least of some of them, is to make the management of
   the space a function of the `data structure.'  You may have some extra
   objects laying around, but they won't get lost, and there is at least an
   object (the interface object for the data structure as a whole) whose
   lifetime bounds the lifetime of the objects `within.'

   These value-is-the-only-thing-of-interest data structures (representation
   schemes) are precisely those for which GC is needed and for which it is
   well-suited.

   Meta-discussion:  This seems to me so awfully obvious that it hurts to
   write it every few months, yet it hasn't been refuted (at least not to
   my satisfaction), nor have the conclusions which seem to me obvious been
   accepted.  What am I not seeing?

You are not seeing that people may not have the memory for those "few
extra objects" because the lifetime of the containing object may be
much longer than the lifetime of all the bits and pieces that make it
up. In fact, often the "containing object" is simply the whole
program, and its lifetime is until it runs out of memory.

Also, you got it backwards. The need for true GC arises precisely when
object identies (pointers, addresses, aliasing) matter. If only the
value of an object matters, you can avoid the need for garbage
collection trivially via copying or reference counting on assignment
and initialization (although a real garbage collector is empirically
still more efficient in most cases).

					Thomas.
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Covariant Types in Derived Classes
Summary: (Open request to Bjarne, ARK, and other Gurus)
Organization: :
Date: Thu, 13 Aug 1992 16:29:56 GMT

I'm afraid we are victims of diverging terminology here.

Let's try to get some convergence:

		Conversion:  The creation of a value in one type
			corresponding _somehow_ to a value in
			another type.  (Exception, sort of:  A
			conversion to  void  in C or C++ creates a
			_lack of a value_ corresponding vacuously to
			a value in another type.  A zero-to-every
			mapping, so to speak.)

		Cast: A C and C++ construct that can demand either
			a conversion _within_ the type system
			(e.g.  (int) 3.14159 ) or a conversion that
			bypasses the type system (e.g  (char*) 0x30EA ).

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

Mercy even for Pooh-Bah!

	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.

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

It is a conversion that is indicated syntactically by a cast.  

Why do you want a warning?  You asked for it explicitly and it lies
within the type system.  There's an important principle here: for
every construct that can produce a warning, there must be a way to
write an equivalent construct that does _not_ produce the warning.
This is part and parcel of the C/C++ philosophy that ``if you _really_
want to do that, we'll take you at your word.''

The code fragment written _without_ the cast might very well merit a
warning about value truncation.
-- 
 (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: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Proposal: auto T&
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 21 Aug 1992 01:57:10 GMT

In article <1992Aug19.234913.622@tfs.com> eric@tfs.com (Eric Smith) writes:
>
>Much recent discussion about destruction of temporaries suggests a
>better way to solve the whole problem, and to allow returning references
>to temporaries from functions.
>
>auto String& stringfunction(const String& input)
>{
>   // Calculate/create a new temporary or named automatic String
>   // and return a reference to it.
>}
>
>The "auto" in the function return value type tells the compiler to allocate
>the space for that automatic in the stack frame of the caller, instead of
>the stack frame of the called function.
>

	But you can already do this:

	String f(...);

Just return a value instead of a reference.
Some compilers (Borland for example) pass the address of the return
memory to the procedure allowing direct construction without
copying in some cases.

The real problem is that the C 'return expr' syntax is faulty.
There is no 'handle' or 'name' like 'this' on which to
make the return value. The Pascal syntax does not have
this problem (the function name is used as a variable
representing the return value)

	function f(integer x):integer
	begin
		f=10;
	end

In C one could just use 'result':

	int f(int x){result=10;}

However this would not work properly if 'result' had to
be constructed as an object.



-- 
;----------------------------------------------------------------------
        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: mat@mole-end.matawan.nj.us
Subject: Re: destruction of temporaries
Summary: Not quite
Organization: :
Date: Thu, 20 Aug 1992 09:54:29 GMT

In article <1992Aug20.092752.29529@mole-end.matawan.nj.us>, mat@mole-end.matawan.nj.us writes:
> 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. ...
  
> > 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.
 . . .
> 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?

No, I'm wrong.  It's not quite enough because of the conditional
context.  We have to specify the scope of the `thing' to which that
value is bound in the conditional context.

I'm inclined to say that it's the conditional part itself, just as
in a function, the parameter is bound to something whose lifetime is
that of the function, and any temporary expression can be destroyed
thereafter.

That, by the way, is different from the object created by the
constructor here:

	int zot = Cthulu( 0 ).somefunc();

The object created is voided after the member function call, or after
that function call's value is bound to the initialization ...

(Of course, that messes up member functions that return  *this . ...)
-- 
 (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: swen@uni-paderborn.de (Swen Thuemmler)
Subject: Re: struct array question
Organization: Uni Paderborn FB 17 Informatik GERMANY
Distribution: comp
Date: Tue, 18 Aug 1992 15:38:51 GMT

>>>>> About struct array question, Dave Sherohman said:

[...] 

Dave> Compiling with Turbo C++, I'm told 'Type mismatch in
Dave> redeclaration of wintype'.  It is not declared anywhere else
Dave> (I've tried changing both occurrences of 'wintype' to
Dave> 'nwintype', and I get the redeclaration complaint about nwintype
Dave> (plus a lot of complaints about wintype not existing...)).
Dave> Ideas/explanations, anyone?

Your compiler is simply wrong in this case. It seems to handle structures
like C, where the name of a structure cannot be used as a type name
except when prefixed by the keyword struct. C++ doesn't require the
use of the struct keyword.

Greetings, Swen

--
  Swen Thmmler           *  "Wenn im Namen eines Ideals Menschen Schurkereien
  Sonnenberg 14           *  zugefgt werden mssen, so ist dieses Ideal
  4790 Paderborn-Dahl     *  einen Dreck wert."
  <swen@uni-paderborn.de> *                      -- A. und B. Strugatzki
From: jonas@ipcsun5.his.se (Jonas Mellin)
Newsgroups: comp.lang.c++
Subject: Re: Object What is an OODBMS?
Date: 22 Aug 92 10:33:25 GMT
Followup-To: comp.lang.c++
Organization: University of Skoevde, Skoevde
In-reply-to: bevan@cs.man.ac.uk's message of 12 Aug 92 14:21:27 GMT

In article <BEVAN.92Aug12152127@jaguar.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:

   In article <RCZ5NS@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
      When we create a new class we frequently want to use code or data 
      that already exist in another class.  For instance, if we have a class 
      called LinkedList we might choose to use this when implementing our 
      stack.  In fact, we might say that a Stack is a LinkedList which also 
      has the push() and pop() functions.  We can do this directly using a 
      mechanism called inheritence:

	  class Stack : public LinkedList
	  {
	  public:
	      void    push(int i);
	      int    pop();
	  };

      In this example we would call LinkedList the base class and Stack the 
      derived class.

   Is this generally considered good use/example of inheritance?
   I don't think a "Stack is a LinkedList" at all, rather a
   LinkedList is a possible implementation of a Stack.  I'd therefore use
   parametric rather than inclusion polymorphism to represent this (i.e.
   use a template in C++ speak).  Is my preference for parametric rather
   than inclusion polymorphism blinding me to some advantage in the
   above?

I too prefer the view of this that Bevan has, but who is to say that
Stack cannot be a LinkedList?
--
Disclaimer: Even a blind man may know how to C.
  	    Cynic is just my second name. Nihilist is my third.
    _____________________________________________
   /      /  /    /   /\  /    /      /| /|	|E-mail: jonas@his.se
  /      /--/	 /    \  /    /	     / |/ | 	|UUCP:   ...!sunic!his!jonas
 /      /  /	/    \/ / /  /      /     |	|Phone:  +46 500 77692
/______________________/  \_/ onas /      |ellin|Fax:    +46 500 16325
Snailmail: Jonas Mellin,Hogskolan i Skovde, Box 408, 541 28 Skovde, Sweden

			    			  
Newsgroups: comp.lang.c++
From: jmwojtal@vela.acs.oakland.edu (Wojo)
Subject: C++, how easy it to learn
Organization: Oakland University, Rochester MI.
Date: Wed, 19 Aug 1992 15:55:02 GMT

Our company is thinking of getting C++ for our DecWindows.  Can anyone give me
some comments on how well it works, and especially how easy (or difficult) it
is to learn it.  If we do get it, would take weeks to figure how it works?

Thank you




-- 
************************************************************************
Jeff Wojtalewicz (Wojo)  jmwojtal@vela.acs.oakland.edu
Oakland University		      Start Hacking
************************************************************************
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: using (...) question
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Sun, 16 Aug 1992 22:15:27 GMT

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.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Covariant Types in Derived Classes
Organization: :
Date: Sun, 16 Aug 1992 08:17:47 GMT

In article <1992Aug15.004037.1121@lucid.com>, jss@lucid.com (Jerry Schwarz) writes:
> 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 [the distinction between casts that
> |>    use the type system and those that demand it stand aside]?
> |> 	...  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".

Yes, and I'd forgotten ...  I like that, and I will try to use it
myself.  What's more, I commend it to everyone present.
-- 
 (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: mat@mole-end.matawan.nj.us
Subject: Re: Downcasting (was: Re: run-time type checking)
Keywords: polymorphism, RTTI, downcasts.
Organization: :
Date: Fri, 14 Aug 1992 16:54:32 GMT

In article <9222518.29381@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:
 
> >There are other ways than tagged pointers to make downcasting
> >sound. One might be to declare the derived classes that you want
> >to downcast to in the base class FROM which you want to downcast:

> >	class Base {
> >		....
> >		operator Derived1*() =0;
> >		operator Derived2*() =0;
> >	};

> This is a good idea.
> In particular, it seems that this technique much reduces the attraction of
> the current proposal to allow downcasting, because users can achieve virtually
> the same effect themselves - they just have to make the interface explicit.
 
> 	class Derived1() {
> 		...
> 		operator Derived1*() { return this; }
> 	};

The problem with this is that it requires explicit functions all over
the place.  It swells the interfaces (trust me, I've seen it used, even
suggested it as the best possible in C++ today), swells the vtables, may
thereby interefere with some language implementations, and makes the
code brittle.

But I like the idea of declarations in the derived type permitting or
blocking an RTTI-based conversion.
-- 
 (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: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: destruction of temporaries
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Fri, 21 Aug 92 14:54:20 GMT

: 
: >
: >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.
: 
: 	When is that?
: >
: >If you want to be able to implement anything more powerful, you need
: >(surprise!) garbage collection (as stated in the ARM, p. 268). 
: 
: 	In other words, if you cant define a sensible
: length of time for temporaries to hang around on a static basis,
: then dont--define it dynamically.
: 
: 
: -- 
: ;----------------------------------------------------------------------
:         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
: 	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
: ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------

--
Shawn Willden
swillden@icarus.weber.edu
Newsgroups: comp.lang.c++