HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Garbage Collection for C++
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 16 Aug 1992 05:58:43 GMT

In article <1992Aug15.015237.17711@tfs.com> eric@tfs.com (Eric Smith) writes:
>
>Explicit memory management functions have traditionally favored memory
>economy over speed.  That was because memory was very expensive.  But
>now that memory prices have fallen through the floor, e.g. from $4000
>per megabyte in 1983 to $25 per megabyte in 1992, it no longer makes
>much sense to waste cpu time to save memory.

	Unfortunately, people now manage bigger objects. 
My 8M PC is just a constrained on user memory (even with 16M VM added)
as the first 16K Apple II. And the 20G Unix machine runs out of
RAM just as often because it has 2000 users instead of only 4.
I now fiddle with megabyte sized pictures, try doing animation
without compression. And AI people surely have massive
memory requirements.

	There is some law about this surely---the amount
of RAM your computer has is ALWAYS about half what you need.
>that advantage?
>
>One answer would be that modern programming languages, using OOP and
>genericity, make complexity so much easier to manage that the complexity
>of non-GC memory management is no longer anywhere near as big a problem
>as it was with older languages.  OOP and genericity have almost unlimited
>potential to simplify complex software, to the point where the additional
>simplification provided by GC might become superfluous.

	But now we can manage complex systems so easily, we're
bored with them and are writing super-complex ones :-)
We start taking C++ classes for granted, and after a while
it seems we're STILL repeating the same old formulas over and
over again---that is, not achieving the sort of reusability that
we would like to.

	IMHO the proportion of software projects that will fail
is a constant. Supply better tools, and we push them up to that
limit rapidly. Of course the projects that succeed do more ...
but NOT relative to the competition.

	Example: Word processors for DOS based machines
were plagued by being supplied with vendor specific
printer drivers and fonts. Along comes Windows, which
supplies the drives and fonts in a device independent way.
Have WP programs got smaller then? :-)


-- 
;----------------------------------------------------------------------
        TIM (TAL) LISTER,         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: sriram@tcs.com (Sriram Srinivasah)
Subject: Trouble compiling NIH classes
Organization: Teknekron Communications, Inc
Date: Wed, 19 Aug 1992 18:16:22 GMT



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

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

Can anyone give me some tips on this?

Sriram
(sriram@tcs.com)
From: aldavi01@starbase.spd.louisville.edu (Arlie Davis)
Newsgroups: comp.lang.c++
Subject: Re: Any guarantees on initialization order?
Date: 20 Aug 92 03:02:58 GMT
Organization: University of Louisville

In <aldavi01.714267602@starbase.spd.louisville.edu> aldavi01@orion.spd.louisville.edu (Arlie Davis) writes:

> During the construction of a class with members which have constructors that take
> more than zero arguments, is there any guarantee on the order in which members
> are initialized?

Someone has already replied.  Thanks anyway.

-- 
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null
From: baldwin@cps.msu.edu (Reid A Baldwin)
Newsgroups: comp.lang.c++
Subject: Virtual Functions and Shared Memory
Date: 17 Aug 92 18:24:23 GMT
Organization: Dept. of Computer Science, Michigan State University

I am developing an application in which multiple processes communicate
via shared memory (UNIX). Unfortunately, virtual functions don't work for
objects in shared memory. The process that creates an object gets the
correct results, but other processes execute the function for the
base class instead of the derived class (using the pointer type instead
of the object type). I am not familiar with the implementation of virtual
functions. Is it possible to use virtual functions on objects that are
created by other processes and accessed via shared memory?

Thanks for your help,
Reid Baldwin

P.S. I will post a summary of responses if they are interesting.
From: rw@frito.Rational.COM (Bob Weissman)
Newsgroups: comp.lang.c++
Subject: Re: Tiny proposal for named loops.
Date: 21 Aug 92 22:55:49 GMT

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

rmartin@dirac.Rational.COM (Bob Martin) responds:

|IMHO breaks and continues should be avoided, not improved.  As you
|say, they are a form of goto.  Don't use them, except in case
|statements where you must :-( use break.
|
|State variables are preferable to breaks and continues.  Judicious use
|of them allows all loops and blocks to be exited at the same place.
|This benefit outweighs the disadvantage of using a flag.

I disagree.  I generally prefer a multi-level break to cluttering
my code with extraneous state variables.

Use of named loops as in the original proposal is (IMHO as always)
clearer in intent than having a slew of flags.

On the other hand, I'm not sure C++ needs *any* new features.  It's
starting to resemble PL/I... :-)

--
-- Bob Weissman
-- Internet: rw@rational.com
-- UUCP:     uunet!igor!rw
--
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Downcasting (was: Re: run-time type checking)
Date: 14 Aug 92 10:32:18 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
: jbn@lulea.trab.se (Johan Bengtsson) writes:
: 
: >maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
: >:
: >:	class Base { //....
: 		virtual operator Derived1*() { return 0; }
: 		virtual operator Derived2*() { return 0; }
: >:	};
: >:Now what does this do? Well, it preserved th open/closed principle
: >:and encapsulation and the explicit interfaces principle.
: >
: >What if someone using your classes decides to add a Derived3 class
: >to which downcasting should be possible?  He must modifiy your
: >class Base, for which he may not have source code.
: 
: Yes, but that would be a change to the interface!

	I get your point.  I also agree that the above technique
	is best (most efficient) when you have a limited set
	of known derived classes.

: 
: The whole point is that the ability to downcast a Base to a derived class
: SHOULD be part of the interface. If you want to change the interface, then
: of course you are going to need to modify the source code - this does not
: violate the open/closed principle.

	I agree that unrestricted typecasting provides the ability to
	cleanly extend the interface of a base class, into the interface
	of any derived class.  Although I admit that in a way this does
	break the "closedness" of the Base class interface, I don't think
	it does so in a "bad" way.

	After all, inheritance allows us to break the "closedness"
	of a base class' behaviour, by overriding virtual functions.

	The importance is that in neither case do you have to
	intervene with the source or compiled code of the base
	class to do what you want.  This is considered good
	for behaviour (overriding virtuals), so why not also
	for interfaces (unrestricted but safe downcasting)?

	To conclude:

	A base class intended for future inheritance (even by
	other programmers) should support overriding behaviour
	using virtual member functions, and should support
	interface extension by runtime-checked, safe downcasting.

	This lessens the risk that future users without access to the
	source code will get stuck when deriving from the base class.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
--------------------------------------------------------------------------
From: noble@sj.ate.slb.com (Alan Noble)
Newsgroups: gnu.gdb.bugs,comp.lang.c++
Subject: How to print locals in GDB with Sun CC?
Date: 21 Aug 92 22:02:39 GMT
Reply-To: noble@sj.ate.slb.com ()
Organization: Schlumberger Technologies, San Jose, CA.

I'm using GDB 4.6 on SUN CC SC2.0.1beta code and "info locals" doesn't
work.  How can I print my (mangled) local variables?

Alan Noble
-------------------------------------------------------------------------------
DOMAIN: noble@sj.ate.slb.com
UUCP:   {amdahl,decwrl,uunet}!sjsca4!noble
PHONE:  408-437-5331
MAIL:   Alan Noble, MS-930, Schlumberger Technologies, ATE Division,
	1601 Technology Drive, San Jose, CA 95110
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: Garbage Collection for C++
Summary: Reliability
Organization: :
Date: Wed, 19 Aug 1992 18:02:52 GMT

In article <DAVEG.92Aug17231725@synaptx.synaptics.com>, daveg@synaptics.com (Dave Gillespie) writes:
> In article <1992Aug16.075804.27511@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
 
> Suppose you have an existing C++ program.  Suppose there is an object
> in that program's memory that has been allocated and which no longer
> has any references to it of any sort, and which has not been deleted
> explicitly.  Most people would consider that a bug; ...  your program
> is not planning on deleting the object because it no longer has any
> references to it.  Is there really so much harm in allowing the C++
> runtime system to delete the object in that circumstance?  If you left
> the object dangling and it had a destructor that had a noticeable
> effect on the rest of the program, you almost certainly had a bug anyhow.

	Is there really so much harm in allowing the C++ runtime
	system to delete the object in that circumstance?

You've answered your own question in the negative.  If the destructor
has an effect on the program's output, and it is accidentally called
by the GC instead of by its proper deletion, the program's output will
depend on the exact properties of the GC system and the exact sequencing
of internal states of the program and of the program's runtime internals'
states.  It might work correctly by accident in testing, and fail
disastrously in service.

Allowing GC to operate destructors is not safe.

Not allowing GC to operate destructors does not suit C++'s model of
execution.

Think about 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++
From: hons@rkw-risc.cs.up.ac.za (Honneurs Studente)
Subject: pointer to member functions question
Date: 18 Aug 92 02:11:50 GMT
Organization: University of Pretoria, South Africa


Is it possible to cast a pointer to a member function for a specific object 
to a function pointer. The reason I ask is that sometimes operating systems expect function pointers as event handlers. Let us say for example that an 
object sets a timer and wants to give the system routine that sets the timer a 
pointer to a function to call when the timer expires. It would be nice if that
function pointer could in fact be a member function of the class of which
the object in question is an instance. I'm using a GLOCKENSPIEL C++ on VMS.
If anyone can help please reply by e-mail to 

      9180486@cs.up.ac.za

Thanx
Newsgroups: comp.lang.c++
From: davep@paladin.corp.sgi.com (David Packer)
Subject: NIH & IRIX 4.0 
Reply-To: davep@corp.sgi.com
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 19 Aug 1992 17:38:18 GMT

Anyone been successful installing NIH v3.1.2 on an IRIX based machine??
If so could you explain how you did it? I'm having some problems with
the IMAKE file....

Dave

davep@corp.sgi.com
From: wgh@ubbpc.tredydev.Unisys.COM (Bill Hutchison)
Newsgroups: comp.lang.c++
Subject: Re: COOL C++ class library
Summary: need include files
Date: 14 Aug 92 14:42:28 GMT
Organization: Unisys UNIX Portation Center, Blue Bell, PA

In article <1992Aug3.201631.29743@crd.ge.com>, nguyen@crd.ge.com (van-duc nguyen) writes:
> Correction on the ftp place of COOL:
> 
> 2. Cfront2.1 version modified by General Electric:
>    at cs.utexas.edu, get pub/COOL/GE_COOL2.1.tar.Z
  I obtained this file     ^^^^^^^^^^^^^^^^^^^^^^^^^
(thanks to DECWRL for ftpmail!)

  It looks pretty good, but the cool/include/* files are all symbolic links
into your personal directory, so they are not actually included in the tar.Z
file.

> Van-Duc Nguyen, nguyen@crd.ge.com

  Would you please make a version of GE_COOL2.1.tar.Z which contains the 
include/cool/*.h files, then post a message when it is ready?  You probably
should also make a separate tar.Z file for people like me who already have
the mail file (to save bandwidth).

  Thanks.

-- 
Bill Hutchison, DP Consultant	wgh@ubbpc.TredyDev.Unisys.COM (work)
Unisys UNIX Portation Center	uunet!eidolon!wgh (home)
P.O. Box 500, M.S. B121         "At the moment I feel more like arguing than
Blue Bell, PA 19424		being good" Raymond Smullyan _The Tao is Silent_
From: daveg@synaptics.com (Dave Gillespie)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 20 Aug 92 11:31:56 GMT
	<DAVEG.92Aug17231725@synaptx.synaptics.com>
	<1992Aug19.180252.12942@mole-end.matawan.nj.us>
Organization: Synaptics, Inc., San Jose, CA
In-reply-to: mat@mole-end.matawan.nj.us's message of 19 Aug 92 18:02:52 GMT

In article <1992Aug19.180252.12942@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:

>>   Is there really so much harm in allowing the C++ runtime
>>   system to delete the object in that circumstance?

> You've answered your own question in the negative.  If the destructor
> has an effect on the program's output, and it is accidentally called
> by the GC instead of by its proper deletion, the program's output will
> depend on the exact properties of the GC system and the exact sequencing
> of internal states of the program and of the program's runtime internals'
> states.  It might work correctly by accident in testing, and fail
> disastrously in service.

Sorry, I didn't make myself clear.  I realize that allowing GC to call
a destructor would add one more case where destructors with side effects
could surprise the C++ programmer.  My question was, is that potential
for surprise enough to kill the idea of garbage collection in C++?

My answer is no, it just means C++ programmers who use garbage collection
have to be a little careful about what they put in their destructors.

> Allowing GC to operate destructors is not safe.

Only if "new" statements in existing programs create collectable objects.
If you have to do something special, like say "GCnew" (admittedly not the
most pleasing notation), then existing programs won't break, and the
chapter on garbage collection just has to include a caveat that if you
allocate an GC-able object with a destructor that has side effects, you'd
better watch out because you can't know when those side effects will
occur.

> Not allowing GC to operate destructors does not suit C++'s model of
> execution.

Agreed.  For example, an object giving access to a file wants to close
the file when it's collected.  A class might want to keep statistics
on how many instances of the class are currently allocated, etc.

> Think about it.

I did; as far as I can tell, the GC has to call destructors, and it's
acceptable for it to do so as long as it doesn't break existing code,
which can be done by introducing something like "GCnew".  Simple as that.

								-- Dave
--
Dave Gillespie
  daveg@synaptics.com, uunet!synaptx!daveg
  or: daveg@csvax.cs.caltech.edu
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 21 Aug 92 18:25:55 GMT
	<23466@alice.att.com> <3920@starlab.UUCP> <23487@alice.att.com>
	<TMB.92Aug20142610@arolla.idiap.ch> <23507@alice.att.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: ark@alice.att.com's message of 20 Aug 92 21:16:28 GMT

In article <23507@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

   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.

Read my paragraph again. I explicitly stated you shouldn't return a
reference to "*this".

   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.

All I can say is that I disagree.

					Thomas.
From: wardrb@cs.utexas.edu (Richard Byron Ward)
Newsgroups: comp.lang.c++
Subject: "Reverse-engineering" C++
Date: 13 Aug 1992 14:36:17 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: cs.utexas.edu

Has anyone had any experience with packages to "reverse-engineer"
C++?  I am looking for packages that can summarize the design of
a C++ program from the source code.  Class diagrams would be
great.

I saw a reference to ObjectMaker in a magazine, is this the
type of program that I am looking for?  Also, I think
ParcPlace has a product that sounds suitable.

Rick
From: bmassey@cathedral.cerc.wvu.wvnet.edu (James Brian Massey)
Newsgroups: comp.lang.c++
Subject: help with virtual functions
Date: 19 Aug 92 12:56:39 GMT

I would like to know more about virtual functions, I use them but have
never really understood them.  If someone could send information, or a 
good reference for information, I would be most appreciative.

Thank you
Brian Massey

bmassey@cerc.wvu.wvnet.edu
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Best solution for this problem?
Date: 17 Aug 92 23:17:22 GMT
Organization: Microsoft Corporation

In article <aldavi01.713596256@starbase.spd.louisville.edu> aldavi01@starbase.spd.louisville.edu (Arlie Davis) writes:
|I am designing a class which must decide during its construction how it should
|behave.  "How it should behave" is normally decided through virtual methods
|in the class, with different behavior in different derived children.
|However, that solution is only applicable when the behavior of the class is
|decided *before* its construction.  However, this class *must* be able to
|decide which kind of child it wants to be during its construction.

Conceptually, what you want to do is inherit from a reference.  Unfortunately,
C++ does not permit that.  So, one does the next best thing, one writes a
class that acts like a reference, and then you inherit from that.  IE a 
"smart reference class."  Unfortunately, C++ also makes writing "smart
reference classes" a pain as has been noted many times.  [support operator.()]

Below find a simple example of inheriting from a "smart reference class."
"designated_parent" is the "smart reference class" that one inherits from.
Male_offspring then inherits from the "smart reference class" so that its
behavoir can be selected at construction time.  Just for fun, I use this
feature to demonstrate objects inheriting runtime behavoir from themselves ;-)

In a more practical approach, people have used these kinds of approaches where
one program runs transparently under more than one kind of GUI system, automa-
gically adjusting its runtime behavior to the GUI system currently in use.

// 

extern "C" void printf(const char*, ...);

class parent
{
public:
	virtual void parentage() { printf("parent "); }
};

class b : public parent
{
public:
	virtual void parentage() { printf("b "); }	
};

class designated_parent : public parent
{
protected:
	parent& designate;
public:
	designated_parent(parent& p) : designate(p) { }
	designated_parent(designated_parent& dp) : designate(dp)
	{ }
// in general, with reference classes like this you either need overloadable
// operator dot, or you have to write a forwarding function for each
// member function as follows:
	virtual void parentage() { designate.parentage(); }
};

class male_offspring : public designated_parent
{
public:
	male_offspring(parent& p) : designated_parent(p) { }
	virtual void parentage() { printf("son of a "); 
		designate.parentage(); }
};

main()
{
	b fifi; fifi.parentage(); printf("\n");
	male_offspring foofoo(fifi); foofoo.parentage(); printf("\n");
	male_offspring barbar(foofoo); barbar.parentage(); printf("\n");
#ifdef OPTIONAL
	male_offspring wickywoo = wickywoo; wickywoo.parentage(); printf("\n");
	// Oh, I'm my own grandpa....
#endif
}
From: etse@soda.Berkeley.EDU (Eric Tse)
Newsgroups: comp.lang.c++
Subject: Help! C++ for AIX 3.2 NEEDED
Date: 17 Aug 92 23:59:14 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
NNTP-Posting-Host: soda.berkeley.edu

Newsgroups: comp.unix.aix
Subject: Help! C++ for AIX 3.2!!!!!
Summary: 
Followup-To: 
Distribution: world
Organization: U.C. Berkeley, CS Undergraduate Association
Keywords: 


Hi,
	Desperately seeking C++ 3.0 or 3.1 compatible compiler on
AIX 3.2, excluding xlC. We are in a danger having to degrade our
system back to AIX 3.1 becasuse we already have ATT C++ 3.0 for
AIX 3.1. Any suggestions?
	We need this info before end of this week if possible.
Thanks.


Eric Tse
--------
etse@soda.berkeley.edu
Newsgroups: comp.lang.c++
From: J.March@lut.ac.uk
Subject: Differences between versions of C++ ?
Keywords: version
Reply-To: J.March@lut.ac.uk (Jon March)
Organization: Loughborough University, UK.
Date: Sat, 22 Aug 92 12:29:40 GMT

What is the difference between different versions of C++ ?

A short summary would be OK, as a very detailed answer is likely to be over
my head.

The most recent version that I have availible to me is 2.1, and I am trying
to have something more up to date installed.

Please mail replies, I'll summarise on the 27th of August.
j.march@lut.ac.uk

Newsgroups: comp.lang.c++