HDTenEightyP/NetNews huggingface dataset:
From: mnykanen@cs.Helsinki.FI (Matti Nykanen)
Newsgroups: comp.lang.c++
Subject: Re: Is C++ "for the rest of us" ?
Date: 18 Aug 92 09:12:11 GMT
Organization: University of Helsinki, Finland

In <1992Aug17.145413.9278@sunb10.cs.uiuc.edu> pjl@sparc6.cs.uiuc.edu (Paul Lucas) writes:

>In <1355EN@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
>>.. But it does require a new way of thinking, and it
>>has some rather obscure aspects...

>*****>	Yes, it does require a new way of thinking; but what's wrong
>	with that?  After OOP has trickled down into universities for
>	programming classes, OOP will then become "the way" of thinking
>	and non-OOP will be considered to be the "old way" of thinking.

Objectively speaking, there is a difference between claiming something
as "a new way" and "the new way"..
-- 

Internet: Matti.Nykanen@Helsinki.FI  Department of Computer Science
Phone   : +358 0 708 4207            University of Helsinki,Finland
Newsgroups: comp.lang.c++
From: dag@control.lth.se (Dag Bruck)
Subject: Re: con/destruction of fundamental type
Organization: Department of Automatic Control, Lund, Sweden
Date: Fri, 21 Aug 1992 06:14:57 GMT

In <comp.lang.c++> jonas@beppe.ericsson.se writes:
>
>I have tried this small example with both HP and Sun CC but both claim
>than con/destruction as defined is illegal.
>
>main(){
>  int i, *p = &i;
>
>  p->int::int(1);
>  p->int::~int();
>}

Explicit destruction of a built-in type is legal, see ARM 12.4, page
280.  I didn't find any example for the constructor, but I'm cretain
it's legal.

Conclusion: the compilers are wrong.

		-- Dag
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Reference counting for vectors, (Tony Hansen's book).
Summary: Who is in charge ...
Organization: :
Date: Sun, 16 Aug 1992 08:13:16 GMT

In article <BRISTER.92Aug14170213@tirade.decwrl.dec.com>, brister@decwrl.dec.com (James Brister) writes:
> On 15 Aug 92 03:22:08 GMT, tmb@arolla.idiap.ch (Thomas M. Breuel) said:
> > In article <BRISTER.92Aug14110706@tirade.decwrl.dec.com> brister@decwrl.dec.com (James Brister) writes:
 
> > Using reference counting to get reference semantics on parameter
> > passing is very confusing indeed (sadly, this bad idea seems to
> > pervade the C++ literature).
 
> Perhaps if it's so pervasive then it's not such a bad idea.
 
> parameter passing was only a simple example, there are lots of cases where
> multiple objects need to keep track of a piece of data, and unless you're
> very sure about who is supposed to delete the data and when (non-trivial
> when the system gets complex), you can get yourself into a lot of trouble.
> Reference counting can save the day.

This is really the problem.  There exist many data structures (representation
schemes) which deal with values that have to be stored in objects, but that
don't provide for management of the objects.

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?
-- 
 (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: pat@frumious.uucp (Patrick Smith)
Subject: Re: Proposal: auto T&
Date: Thu, 20 Aug 1992 02:40:59 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

eric@tfs.com (Eric Smith) writes:
|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.

How is this different from

   String stringfunction(const String& input) { /*...*/ }

in the current language?  Here I would (naively?) expect the calling
function to pass the address of a space where the called function
should construct the result, and that that space will probably be
in the stack frame of the caller (certainly not in the stack frame
of the called function, since it must live past the moment when the
called function returns).

I also don't see how this would make it any easier for the compiler
to decide when to destroy the object created by the called function
(if that object is a temporary).

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Newsgroups: comp.lang.c++
From: mittle@watson.ibm.com (Josh Mittleman)
Subject: Re: Return value for the constructors.
Date: Wed, 19 Aug 1992 17:36:19 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

Discussing why it would be useful for a constructor to have a return value,
Nandraj Arni wrote:

>   The reason I think it is a important feature the constructor should
> return whether it was a success or not?

This is a real concern, but a return value is not the right solution.  As
has been noted, the best solution is the still-pending exception handling
system: The constructor throws an exception which is caught by the
surrounding code.  Until that system is in place in the language, there are
several ways to model it.  One is to include a status flag in the object.
In some cases it is appropriate for this to be a member of the object, in
others it would be better as a static class member.  In either case, you
can test the status flag after construction.

Note that actually having the constructor return its status value would
mess up the language pretty badly.  Consider:

	class Thing;

	cout << Thing(7, "a", 1.5);

This second statement is correct and meaningful, since the right-hand-side
is a Thing.  If the constructor returned an int, then it would be
impossible to use a temporary class object without declaring a variable for
it. 

===========================================================================
Josh Mittleman (mittle@watson.ibm.com)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY  10598
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: Proposal: auto T&
Organization: University of Illinois at Urbana-Champaign
Date: Thu, 20 Aug 1992 17:13:42 GMT

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

*****>	It's not reentrant.

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

>The compiler can also do the same kind of thing implicitly within a function.
>That is, allocate the space for each temporary in the outermost stack frame
>containing references to it.  It doesn't need an explicit "auto" for that
>because it can derive it during the compile.

>Costs/benefits:  The compiler needs to do a little more work to handle auto T& 
>and the auto might need to be accessed via a pointer because it might not be
>possible for the compiler to know its stack offset at compile time.  The
>benefits to the programmer might be a lot bigger than the obvious benefits
>seem at first.  Beginning C++ programmers almost aways complain about the
>problems caused by lack of this functionality, which they almost always
>intuitively assume without even thinking about the implications.  A lot of
>function interfaces would become much neater.  A lot of the complaints about
>lack of garbage collection are really motivated by lack of this functionality.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: SunOS conflicts with g++
Date: 18 Aug 1992 00:45:21 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu
Keywords: size_t, ptrdiff_t, flock

In article <5421@naucse.cse.nau.edu> jdc@naucse.cse.nau.edu (John Campbell) writes:
>It appears each of these is a conflict between files in g++-include and
> /usr/include/sys:

My previous message, telling you to run "fixincludes", won't fix your
problem; it appears that you have an old version of libg++ that isn't
compatible with SunOS 4.1 or later.  Get the latest version, libg++
version 2.2.  And always report which version when you report a problem
with g++ or any other program; otherwise people can't tell if it's a
problem with the current version or a really old one.



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.lang.c++
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: Tagged Pointers
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Thu, 13 Aug 92 17:34:01 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: In article <1992Aug10.221849.19455@fcom.cc.utah.edu> swillden@news.ccutah.edu (Shawn Willden) writes:
: >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: >: 
: >: Am I wrong on this, do tagged references make sense?
: >
: >Sure they make sense.  Are they necessary?  (Assuming tagged pointers
: >are).  Look at the following.
: 
: 	They're never *necessary*. But useful? and sound? and safe?

Right.  I was using 'necessary' in a little looser sense than you are.

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

That's what I understood from your previous posts (TU*!=TP) and I was
suggesting that maybe there is a good argument for making this so.
What are the arguments against it?

Shawn Willden
swillden@icarus.weber.edu
From: bytor@grumpy.bellcore.com (Ross Huitt)
Subject: Re: OOD and Inheritance question
Organization: Bellcore
Date: Fri, 21 Aug 92 19:18:16 GMT

Article: 29649 of comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: Unix commands from C++
Organization: University of Illinois at Urbana-Champaign
Date: Sun, 16 Aug 1992 22:08:39 GMT

In <713567392.F00001@fast.fido.de> Oliver.Otto@ossi.fido.de (Oliver Otto) writes:

>Hello All!

>is there a way to tell my C++ proggi (compiled with GNU) to open a shell
>and to run another program and than to return to the main C++ prog???

	system( "<name-of-executable>" );
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: run-time type checking, freezing, and thawing
Date: 17 Aug 92 23:22:15 GMT
Organization: Microsoft Corporation

In article <WNZ5RGC@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:
|We could take that even one step further, and grovel over debugging info
|placed in the .EXEs.  In fact, we could develop a general purpose library
|for accessing this information.  And we could standardize this for all
|vendors.  We have now rederived the concept of extended run time type
|information....

Exactly.  The advantage being that if you can figure out how to do the job
without requiring keyword changes, then you can bypass the ANSI-C++
committee, and just develop a libraries standard.  Which can be decoupled
from the C++ standardization effort.

For example, rather than having a "persistent" keyword, maybe you can just
require that all persistent classes inherit from "Persistent."  This way you
can avoid introducing a keyword, and can avoid dealing with the committee.
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.lang.c++
Subject: Re: Tagged Pointers
Date: 14 Aug 92 23:42:42 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

In article <1992Aug13.173401.14944@fcom.cc.utah.edu> swillden@news.ccutah.edu (Shawn Willden) writes:
>maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>: >	2)	Tighten the relationship between tagged pointers and 
>: >		tagged unions.  i.e. dereferencing a tagged pointer in
>: >		a context where a tagged union of like types is expected
>: >		yields a tagged union and taking the address of a tagged
>: >		union yields a tagged pointer.  Then foo could be declared
>: >		as taking a reference to a tagged union and foo(*r) would
>: >		be valid.  I think there are some things wrong with this 
>: >		idea, though I haven't thought it out.
>: 
>: 	Pointer to tagged unions != tagged pointer. Have to think
>: about it.
>
>That's what I understood from your previous posts (TU*!=TP) and I was
>suggesting that maybe there is a good argument for making this so.
>What are the arguments against it?
>

	There's not so much an argument against it as a simple fact
that th're different. The tagged pointer has the tag in the pointer
(conceptually at least). It is a pointer that can point to one
of several types.

	A tagged union has the tag in the union.  It is an object
of one of several types.  A pointer to
a tagged union is an *ordinary* pointer.

	Tagged pointers are a special case of tagged unions.
You can of course have a pointer to a tagged pointer, etc.
You wouldnt want that to be a tagged pointer would you?
Or perhaps you would?

	It all depends on whether tagged pointers are a genuine
type or not. If it is, all the above things must be distinct.
If not (I suggested not in my post) then maybe we can make
a pointer to a tagged union work as if it were a tagged
pointer. This would homogenise the interface. More work
for the compiler, less for the programmmer. Less control
for the programmer too.

	So the issue is whether a tagged pointer is a proper type
or just a sort of syntactic sugaring that supports a new 
mechanism for genericity. My thinking was the latter.

	Any comments?

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: matt@centerline.com (Matt Landau)
Newsgroups: comp.lang.c++
Subject: Re: Return value for the constructors.
Date: 20 Aug 92 17:38:35 GMT
Distribution: usa
Organization: CenterLine Software, Inc.

In <1992Aug20.170524.3452@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
>In <matt.714318343@centerline.com> matt@centerline.com (Matt Landau) writes:
>>In <2273@devnull.mpd.tandem.com> rgp@mpd.tandem.com (Ramon Pantine writes:
>>>>>Sure there is: Overload operator new()...
>>>>
>>>>*****>	Clever...but it's not reentrant.

>>>Paul, that is a moot point given that the object might not always be
>>>created thru new ...

>>Of course it's fairly straightforward to FORCE all objects of a given
>>class to be created via the class operator new ...

>*****>	And this is supposed to be clean and simple??  Anyway, not
>	allowing auto objects to too high a price to pay.

No, I never said it was clean and simple, just that it was possible.  

In fact, I think it's a bad idea in most cases, although without a widely
available implementation of exception handling, most of the alternatives 
for handling constructor failure are also pretty gross.  

My own style has evolved to one in which I try very hard to write ctors 
that CANNOT fail, and put failure-prone operatations into a secondary
initialization member function that's called after construction.  (I'm well 
aware that this technique also makes it difficult or impossible to write 
certain kinds of classes; for those, we just use a different kludge :-)

This is ungraceful, and the kind of thing that ctors were supposed to 
avoid in the first place by ensuring that an object will be initialized 
before it can be used, but the pragmatics seem to be that without any
exception handling, ctors fall short of the goal.  

>>Arrays are still a problem...

>>Presumably this limitation would go away if X3J16 actually designed an
>>operator new[] and someone actually implemented it :-)

>*****>	Or better, when exception-handling gets here.

Yes, but from all recent accounts, it sounds like it will be at least
a year before an ANSI standard exception handling extension is approved
and implemented in enough C++ compilers to make it worthwhile.  Not that 
operator new[] is likely to be approved and widely implemented in less 
than a year, either.  

The point is just that implementation all of these "good" mechanisms for 
handling the more egregious shortcomings in C++ are a long way off, and 
there's an awful lot of code being written in the meantime for which 
SOME error avoidance or handling conventions and idioms would be useful.

[Also, having worked on a large software system that used exceptions as
a primary means of error reporting and recovery, I'm not convinced that 
it's the panacea some people seem to think it will be.  Dealing with
exceptions correctly in large systems rapidly becomes tedious and error
prone itself.]
Newsgroups: comp.lang.c++
From: jonas@beppe.ericsson.se (Jonas Nygren)
Subject: con/destruction of fundamental type
Reply-To: jonas@beppe.ericsson.se
Organization: Ericsson Telecom AB
Date: Thu, 20 Aug 1992 16:19:21 GMT


I am trying to manage memory allocation, con- and destruction in my own code.
I also want these operations to work for struct/classes as well as fundamental
types, int, char aso. 

I have tried this small example with both HP and Sun CC but both claim
than con/destruction as defined is illegal.

main(){
  int i, *p = &i;

  p->int::int(1);
  p->int::~int();
}

How do you do this in C++?

/jonas

H
Newsgroups: comp.lang.c++
From: esper@cs35b.cs.umn.edu (Dave Sherohman)
Subject: struct array question
Organization: University of Minnesota
Distribution: comp
Date: Fri, 14 Aug 1992 19:33:25 GMT

Howdy, folks...  Got a question here for you of the 'why doesn't this work?'
variety...  The code is:

struct wintype {
        char buf[4000];
        short curx;
        short cury;
        short initialized;
};
 
wintype win[5];

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

esper@ima.umn.edu
Newsgroups: comp.lang.c++
From: pkturner@world.std.com (Prescott K Turner)
Subject: Re: Temporary variables and unnamed objects
Keywords: Constructors,temporary,unnamed
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 14 Aug 1992 15:43:15 GMT

Rene Tio writes:
> On one hand, the ARM says the only operations allowed on temporaries are
> assignments and binding of references, on the other hand, code such as:
> 
>   class Object {
>       Object(int) { ... }
>       void doSomething(void) { ... }
>   };
> 
>   Object a(2), b(3);
>   Object c = a + b / 2
> 
> where the temporary created by (a + b) is operated on by "/".

That's an omission in the ARM.

> In addition the ARM does not make clear whether
> 
>   Object(1)
> 
> is a temporary, but only says it is an "unnamed object".

When Object(1) is an unnamed object, it is a temporary.

> Finally, the ARM says that the constructor is not true a callable function
> which has no return type, yet cfront allows:
> 
>   Object(3).doSomething()
> 
> which implies that constructors *DO* return values (i.e., the object being
> constructed,) and that it returns an lvalue.

Here, you've made the common error of mistaking Object(3) for a function
call, when it's actually an explicit conversion (ARM 5.2.3).
--
Prescott K. Turner, Jr.
13 Burning Tree Rd., Natick, Massachusetts USA
Internet: pkturner@world.std.com
Newsgroups: comp.lang.c++
From: osinski@HARRISON.CS.NYU.EDU (Ed Osinski)
Subject: Re: 'virtual' static members
Reply-To: osinski@cs.nyu.edu
Organization: New York University
Date: Thu, 13 Aug 1992 21:15:47 GMT

In article <1992Aug12.201004.1257@CSD-NewsHost.Stanford.EDU>, ralph@Xenon.Stanford.EDU (Ralph Melton) writes:
|> 
|> I am trying to write a general enumeration class that can do output
|> of itself.  If I was doing it as a single class, part of it might
|> look like
|> 
|> class myEnum
|> {
|>   int value;
|>   static int names;
|> friend ostream& operator<< (ostream&, myEnum&);
|> //...
|> }
|> 
|> ostream& operator<< (ostream& os, myEnum& e);
|> { return ( os << e.names[e.value] ); }
|> 
|> 
|> This is all well and good, but I would like to make this into an
|> abstract base class, so that for a specific type of MyEnum, you subclass
|> myEnum, and give the subclass its own static "names" array.
|> I would like to leave the operator<< function the same, if possible.
|> 
|> Ideally, I would like to be able to define a fully functional
|> subclass of myEnum in just one or two lines.
|> 
|> Can this be done?  If I don't declare the array in myEnum, this
|> operator<< function can't see it; if I do declare it, I can't
|> override it in subclasses.
|> 
|> I think I can see more or less skanky ways around this problem using
|> macros or specialized constructors; I am curious as to whether there
|> is any way to declare a static member that is different for every
|> subclass.

No there isn't, but you can get the same effect by declaring static data
members in each class to hold the table, and defining a virtual member function
that returns that class's table.  In your print function, instead of referring
to "names", you would refer to "enum_obj.get_names()".  This will require each
class to have:

	- a new static data member for the table (the variable name can be
          the same in each class)
        - an initialization of that static data member (which must be done
	  outside the class)
	- a redefinition of the "get_names" function which simply returns the
          static data member specifying the table of that class

|> 
|> 
|> Ralph Melton
|> -- 
|> Ralph Melton			ralph@cs.stanford.edu
|> "Then ye shall know the truth, and the truth shall make you free."

-----------------------------------------------------------------------
 Ed Osinski                  |
 Computer Science Department |
 New York University         |           This space for rent
 E-mail:  osinski@cs.nyu.edu |
 Voice:   (212) 998-3515     |
 Fax:     (212) 995-4123     |
-----------------------------------------------------------------------
From: rogers@eagle (Bill Rogers)
Newsgroups: comp.lang.c++
Subject: Help? TV streamable obj creation
Date: 19 Aug 92 19:59:34 GMT
Article-I.D.: news.Bt8y7B.Dv4
Organization: Sangamon State University
X-Newsreader: Tin 1.1 PL4



--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> Bill Rogers, Assistant Director for Academic Computing Services          <>
<>              Sangamon State University, HSB-115                          <>
<>              Springfield, Il 62794-9243     fax:217-786-7188             <>  
<> Internet:rogers@eagle.sangamon.edu        voice:217-786-7352(Mon.->Thur.)<>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>