HDTenEightyP/NetNews huggingface dataset:
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: Tagged Pointers
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Tue, 18 Aug 92 18:04:44 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: In article <1992Aug17.174931.1376@fcom.cc.utah.edu> swillden@news.ccutah.edu (Shawn Willden) writes:
: >
: >Hmmm.  It appears I didn't explain myself very well because that is
: >precisely what *I* was suggesting.  I suppose the difference lies in
: >my consideration of TP's and TU's as different types but (as I said)
: >
: >	1)	*TP yields a TU
: >	2)	&TU yields a TP
: >
: >whereas you suggested that they not be actual *types* but that we 
: >make them work like the above anyway.  Same effect, different words.
: >Have I got this right?
: 
: 	I'll have to think on this carefully, everytime I try
: to reply I get confused :-)

You're not alone... :-)

: >: 	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.
: >
: >I think your thinking is better :-)  TP couldn't be a proper type
: >anyway.  If anything, TP would be a *family* of types.
: > 
: >: 	Any comments?
: >
: >Actually, does it really matter whether we call [T1,T2,T3]& a ref to 
: >a tagged union or a tagged ref?
: >
: 
: 	Yes. The compiler has to know where to find the tag,
: next to the pointer, or where the pointer is pointing.
: The rule has to be next to the pointer. So taking the address
: or making a reference to a tagged union has to copy the tag.
: 
: 	To work out the exact rules I think in terms of the implementation.

Okay, we're thinking on different levels.  From the programmer's point of 
view it doesn't make any difference, but to the implementor it does.  In
that case I vote for whatever makes the implementor's job easiest.

: I'll have a go soon, perhaps while on holidays. 

You mean you're not on holidays?  With all the well-thought-out posts you
make in comp.lang.c++ I assumed you *were* on holidays!  I can't see how you
could possibly have time otherwise!  Thanks, by the way, for your 
contributions (though, since most of what you talk about is extending
C++, the ANSI Extensions WG may feel otherwise :-) ).

: ;----------------------------------------------------------------------
:         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++
From: obi@gumby.ocs.com (Kuryan "Obi" Thomas)
Subject: Re: Is C++ "for the rest of us" ?
Reply-To: obi@gumby.ocs.com
Organization: Online Computer Systems, Inc.
Date: Tue, 18 Aug 1992 22:12:19 GMT

In article <1355EN@netmbx.netmbx.de>, jrobie@netmbx.netmbx.de
(Jonathan Robie) writes:
> Should a programming team attempt a C++ project if they do
> not have any C++ gurus to fall back on?

I would advise that they do have "gurus" to fall back on, but these gurus
need not be their colleagues. Looking at code written by gurus and
learning elegant ways to do things is just as useful. For example, at
Online Computer Systems, two of us wrote a toolkit for building SunView
applications. After it was complete, we looked at Stanford InterViews and
then wrote an X/Motif toolkit using ideas we learned from there. The
difference in quality (maintainability, power, whatever) between the two
toolkits is astounding.
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Garbage Collection for C++
Date: 18 Aug 92 01:13:36 GMT
Organization: Microsoft Corporation

In article <1992Aug15.025613.4571@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
|There are plenty of reasons whey GC is genuinely more efficient than
|manual: it allows better-designed data structures, it eliminates the need to
|copy data which plagues large systems using manual recycling, and it reduces
|development and maintenance costs. But the idea that GC is inherently faster
|than manual is bogus.

Likewise the idea that manual is inherently faster than GC is bogus.  Likewise
the idea that any memory management scheme is inherently faster than some
other memory management scheme is bogus.  Its always possible to come up
with examples where one memory management scheme excels and the other 
memory management technique stinks.  Taken to the extreme, one creates an
example where one memory management scheme works, and the other technique
fails, thus "proving" the superiority of one's pet memory management scheme.
No memory management scheme wins uniformly.  But, if one must constantly write
custom allocators, then one has destroyed code reuse.  An example of this is
the problem of "dueling global news" or "dueling multiple inheritence news"

GC'ed vs non-GC are two major poles of memory management.  Both have advantages,
both should be supported, unfortunately they cannot be cleanly mixed.
From: stan@sabaac.NoSubdomain.NoDomain (Andrew Staniszewski)
Newsgroups: comp.lang.c++
Subject: help?? is their a method for solving dynamic allocation problemes in c++
Date: 19 Aug 92 20:38:38 GMT
Reply-To: staniszewski@mayo.edu
Organization: Mayo Foundation

The problem I am looking at is to track down where my dynamic memory problems are
using new and delete. I have a nice set of replacement routines for the alloc
routines and free routines which help tracking these problems. But, when it comes
to replaceing the new and delete oprator, this becomes a real problem. It seems
possible to do this for new, since the global operator can be overloaded, but
this is a little awkward. AND the global delete cannot be overloaded PERIOD.

first, can anyone give me suggestions on this problem??

second: SHOULD THERE BE A STANDARD METHOD OF APPROACHING THIS PROBLEM BUILT INTO
THE LANGUAGE???


staniszewski@mayo.edu
Newsgroups: comp.lang.c++
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: Thu, 20 Aug 1992 17:05:24 GMT

In <matt.714318343@centerline.com> matt@centerline.com (Matt Landau) writes:

>In <2273@devnull.mpd.tandem.com> rgp@mpd.tandem.com (Ramon Pantin) 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.  All the flag setting/checking by Josh's overloaded
>>new ends up being ignored for automatic objects (i.e. local variables).
>>The fact that an object wants to allocate memory thru new for its internal
>>use doesn't imply that the object itself will 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 (some some other delegated
>creation function).  Simply design that class so that it has no public
>constructors, and make the default constructor private.  The compiler
>will now refuse to let either application-level code or subclasses call
>any constructor for the class.  If you want subclasses to have direct
>access to the constructors, make them protected instead of private.

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

>Arrays are still a problem; if the default constructor for a class X is 
>non-public, it's not legal to say "X x_array[size];" or to dynamically 
>allocate an array of X with "X *xlist = new X[size];"  It's not that you
>get an array whose members have not gone through X::operator new, but
>rather that you can't get an array in the first place.

>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.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: joe@proto.com (Joe Huffman)
Subject: Re: Dumb questions about Borland C++
Organization: Prototronics @ Sandpoint, Idaho
Date: Sat, 15 Aug 1992 07:10:46 GMT

twbrown@PE-Nelson.COM (Tom W. Brown) writes:

>In article <1992Aug13.152405.16170@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>|> In article <q!3m8wf.sjk@netcom.com> sjk@netcom.com (Shel Kaphan) writes:
>|> >I've been trying to port some programs written for a Unix C compiler
>|> >to Borland C/C++, and have a few questions:
>|> >[...stuff deleted...]
>|> >- Is there no memory model on the PC in which the stack can occupy
>|> >more than 64K bytes?  (more wishful thinking, I know ... don't flame me.) 
>|> >Don't ask why I care.
>|> 
>|> 	No. Its only a 16 bit machine. And the 386 still
>|> runs 16 bit operating systems.

>Wait for NT and then wait for Borland to release their compiler support for
>it (better get a deck of cards or something while you're waiting :-)

Borland has announced the will support OS/2 2.0, which is a 32-bit system,
later this year.  That will almost certainly come out before the NT support.

If you want 32-bit DOS support, buy any one of the 32-bit DOS compilers
and their companion DOS extenders on the market.  For C++ there is
Metaware and Zortech.  For C you have the added choice of Watcom.  These
compilers will allow you to produce a 32-bit executable, complete with
virtual memory transparent to the progammer, and run it under 16-bit
DOS on '386 and above machines.  It's quite a thrill to be able to request
a memory allocation of 10 Mbytes under DOS and have it come back 
successful.  Your stack can could just as easily be quite large also...

-- 
netcom!proto!joe
joe@proto.com
From: armhold@action.rutgers.edu (George Armhold)
Newsgroups: comp.lang.c++
Subject: Stroustrup book - solutions to exercises?
Date: 18 Aug 92 17:38:17 GMT
Distribution: usa
Organization: DIMACS @ Rutgers University


Has anyone compiled a set of solutions to the exercises in the
Stroustrup text?  I'm dutifully working my way through the exercises
and it would be nice if there were some way I could double-check my
answers.

-George
-- 
		 Internet: armhold@dimacs.rutgers.edu
	       UUCP: {backbone}!rutgers!dimacs!armhold
		    BITNET: armhold@PISCES.BITNET
Newsgroups: comp.lang.c++,gnu.emacs.help
From: sharma@euler.Warren.MENTORG.COM (Sharma Kunapalli)
Subject: emacs tags for C++ source files.
Organization: Mentor Graphics Corp. - IC Group
Date: Mon, 17 Aug 1992 18:54:39 GMT

Hi All,

Is there a emacs tags program that will work with
C++ sources?

Thanks.

Sharma
-- 
The opinions expressed here are solely mine. My company has nothing
to do with these.

Email: sharma@euler.warren.mentorg.com
Xref: sparky comp.lang.c++:12400 comp.std.c++:1084
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: Garbage Collection for C++
Date: 16 Aug 92 18:34:45 GMT
Organization: I.E.C.C.

>I like the idea of GC so much that I a driven to consider
>how it might be implemented in C++.

Lots of people have already thought about this.  There's a running argument
currently going on in comp.compilers about GC strategies for C and C++.  Take
a look.

-- 
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 492 3869
johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl
Re-elect Vice President Potatoe-Head !
Newsgroups: comp.lang.c++
From: dsf@cray.com (Dan Frankowski)
Subject: Re: ? C++ FAQ where ?
Organization: Cray Research, Inc.
Date: 17 Aug 92 11:08:17 CDT

In article <92229.223754TOGE@SLACVM.SLAC.STANFORD.EDU> TOGE@SLACVM.SLAC.STANFORD.EDU (Nobukazu Toge) writes:
>Could someone plsese let me know where I can pull out the
>comp.lang.c++ FAQ list from?
>
>I have been watching clc++ recently, but all I see are some requests
>for C++ FAQ with no follow-up's, nor any resposting of FAQ.

I have been responding to those people via email so as not to take up
bandwidth.  I have answered often enough, however, that I feel another
post is warranted.  From the C++ FAQ:

	Availability:	This is available via anonymous ftp
			from: sun.soe.clarkson.edu [128.153.12.3]
			in the file: ~ftp/pub/C++/FAQ

	Without FTP:	You can also get it by sending electronic mail:
			|	To: archive-server@sun.soe.clarkson.edu
			|	Subject: send C++/FAQ
			This will help those who don't have ftp.

	See also:	comp.lang.c's FAQ appears at the beginning of every
			month in that newsgroup, and is maintained by
			Steve Summit (scs@adm.mit.edu).

	Author contact:	Marshall Cline
			Paradigm Shift, Inc
			65 N. Main St. / Norwood NY 13668-1121
			voice:315/353-4585, fax:315/353-6110
			email:cline@sun.soe.clarkson.edu

	Copyright:	Copyright (C), 1991,1992 Marshall P. Cline, Ph.D.

>* Nobu Toge, ex-employee at Stanford Linear Accelerator Center.
>* Neither my former (SLAC) or present (Nat'l Lab for High Energy
>* Physics, Japan) employers are not responsible for this question.
>* My question is only mine, unless shared by someone else.

DISCLAIMER: This ain't official Cray business.
-- 
Dan Frankowski            dsf@palm.cray.com     (612) 683-5099
From: daniel.edelson@inria.fr (Daniel R. Edelson)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 21 Aug 92 07:30:27 GMT
Reply-To: Daniel R. Edelson <daniel.edelson@inria.fr>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France

In article <DAVEG.92Aug20022559@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
|> In article <boehm.714158406@siria> boehm@parc.xerox.com (Hans Boehm) writes:
|> 
|> > Presumably you're really worried about pause times, and frequency of pauses.
|> > That's usually a valid concern, but in the presence of concurrent or
|> > incremental collection, things become less clear.  Even in the presence
|> > of generational collection, it may not buy you much if the short-lived
|> > objects are the ones that are being handled manually.
|> 
|> Do you really think incremental or generational collectors are
|> feasible in C++?  I've never looked in the guts of one of these
|> collectors, but as I understand it they tend to depend on the
|> ability to move data around, and other things that a C++ collector
|> might not be able to get away with.  (C++'s use of pointers is so
|> unrestricted that it's a minor miracle it's possible to do garbage
|> collection at all...)

Plain old non-relocating garbage collectors can be
generational and/or incremental. This is sometimes overlooked
because of how common copying collectors are, and because most of
the first generational and incremental collectors were copying collectors. 
Newsgroups: comp.lang.c++
From: osinski@HARRISON.CS.NYU.EDU (Ed Osinski)
Subject: Re: How to hack c++ into doing late binding ?
Reply-To: osinski@cs.nyu.edu
Organization: New York University
Date: Thu, 13 Aug 1992 19:16:58 GMT

In article <1992Aug11.000613.6607@leland.Stanford.EDU>, kocks@jessica.stanford.edu (Peter Kocks) writes:
|> Here's a qestion for all you c++ fanatics.
|> 
|> I want my application to support late binding.  By that I mean:
|> 
|> I want to write some code and compile and link it together so I have
|> my application.  At some later time, I want to be able to give the
|> user of my application a new version of an object (or should I say
|> virtual class) already in the excecutable code.  I want the user to be
|> able to simply add the new definition for that class of object to the
|> excutable without needing to recompile the thing.
|> 
|> [ ... stuff deleted ... ]

The book "Advanced C++ Programming Styles and Idioms", by James O. Coplien
describes how to do this in Chapter 9, and it gives some code that (he claims)
works on Sun workstations.  Be aware that, although it is possible, it requires
a different style of programming than many C++ programmers are accustomed to.

By the way, this book really does cover advanced C++, unlike the vast majority
of computer books with the word "advanced" in the title, which usually spend
several chapters covering topics such as bits, 2's complement integers and
assignment statements, and then go on to really 'advanced' topics like functions
and pointers :-)

|> --Peter Kocks
|>   kocks@chemistry.stanford.edu

-----------------------------------------------------------------------
 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: matt@centerline.com (Matt Landau)
Subject: Re: Return value for the constructors.
Organization: CenterLine Software, Inc.
Distribution: usa
Date: Thu, 20 Aug 1992 17:38:35 GMT

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 Pantin) 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.]
From: steck@dworkin.ccs.northeastern.edu (Paul Steckler)
Newsgroups: comp.windows.ms.programmer,comp.lang.c++
Subject: SetDlgItemText() in Borland C++ 2.0
Date: 16 Aug 92 04:56:35 GMT
Organization: College of Computer Science, Northeastern University
Originator: steck@dworkin.ccs.northeastern.edu

Since I only occasionally use C++, I'm still back at Borland C++
version 2.0.

I'm trying to modify the text in an edit control attached to
a dialog box.

Instead of seeing the new text, I just get a blank edit 
control.

The call I'm making looks like:

	SetDlgItemText(hDlg,FILENAME,lpstr);

just like in Petzold.  (If I don't make this call, the 
initial text DOES appear - the call blanks it out).

Could this be a compiler/library bug?  If not, what might I
be doing wrong?

-- Paul

 -----------------------------------------------------------------------
| Paul Steckler                       |  Were I Brittania,              |
| steck@dworkin.ccs.northeastern.edu  |    I'd waive the rules ...      |
 -----------------------------------------------------------------------
-- 
 -----------------------------------------------------------------------
| Paul Steckler                       |  Were I Brittania,              |
| steck@dworkin.ccs.northeastern.edu  |    I'd waive the rules ...      |
 -----------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: mendell@turing.toronto.edu (Mark Mendell)
Subject: Re: C++ 3.0 and exceptions
Organization: IBM Toronto Lab
Date: 21 Aug 92 02:44:33 GMT

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.
-- 
Mark Mendell
IBM Toronto Lab
mendell@torolab6.vnet.ibm.com
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: Dumb questions about Borland C++
Date: 19 Aug 92 01:54:53 GMT
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle

In article <q!3m8wf.sjk@netcom.com> sjk@netcom.com (Shel Kaphan) writes:
/I've been trying to port some programs written for a Unix C compiler
/to Borland C/C++, and have a few questions:
/- Isn't there some way to tell it that you want "int" and "unsigned int"
/to be 32 bits?   (just wishful thinking).
/- Is there no memory model on the PC in which the stack can occupy
/more than 64K bytes?  (more wishful thinking, I know ... don't flame me.) 

Both of these exist with DOS compilers that support 32 bit programming.
The current version of BC++ does not support 32 bit DOS programming.
Newsgroups: comp.lang.c++