HDTenEightyP/NetNews huggingface dataset:
From: boehm@parc.xerox.com (Hans Boehm)
Subject: Re: Garbage Collection for C++
Organization: Xerox PARC
Date: 28 Aug 92 16:58:25 GMT

daveg@synaptics.com (Dave Gillespie) writes:
>This all reminds me of the idea of "finalizations" in Lisp, a
>simple-sounding and very useful concept that turns out to be a
>horrible quagmire of complications when it is implemented.

>Basically, a finalization is a property that can be attached to
>any allocated object, which is a function to be called to clean up
>when that object is garbage-collected.  In other words, it's a
>destructor.

...


>If you made a linked list of N things each of which had destructors,
>it would still take N GC's to delete the list, but the idea is that
>destructors (finalizations) would only be used for the kinds of
>things that are not used in big lists.  For example, a finalization
>might close a file that was held open by the object; rarely would
>you have a linked list of 1000 objects each holding open a file!
>(And where the links are in the objects themselves; a conventional
>Lisp list of pointers to finalizable objects would have no problem,
>because the cons cells themselves have no finalizations and so can
>be collected all at once.)

Cedar does something similar.  (So does the latest version of
our conservative stand-alone collector.) Empirically only on the order of
100 objects (in a 15 MB or so heap) are finalizable at any given point,
and there tends not to be a lot of connectivity between them, for
precisely the reasons you describe.  The most serious (but not
unsolvable) problem is dealing with cycles of finalizable objects.

PARCPlace Smalltalk uses a different approach in which a proxy
object is notified of the death of the object it watches.  That's
also quite reasonable.  But it also doesn't suffice to deal with the
circularity issue.

Another issue is that at least Cedar finalization allows finalization
to be reenabled on resurrected objects.  This argues perhaps that
finalization and destructors aren't exactly the same.  (My
impression is that C++ destructors also get used instead of
something like the Modula-3 try ... finally construct to perform
an action on any exit from a block.  This use also seems
orthogonal to finalization, which I view as reclaiming nonmemory
resources, and doing only that.)

Hans-J. Boehm
(boehm@parc.xerox.com)
From: cyberman@toz.buffalo.ny.us (Cyberman)
Newsgroups: comp.lang.c++
Subject: a question about '[ as an operator
Date: 26 Aug 92 02:51:30 GMT
Organization: The Tower of Zot - (716)691-3865

1: is it possible to specify the '[ as an operator?
2: HOW?  I'm confused about this
3: if so can they be doubled scripted ie  [X][Y]
Cyberman  
 


************************************************************
* Cyberman@TOZ.BUFFALO.NY.US                               *
*   "Life is what you put into it" - Cyberman              *
* Optimistic - running through a barn of manure looking    *
* for the horse!  /\ [] ( )                                *
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: Inherited nested classes?
Date: 30 Aug 92 11:35:00 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

pete@genghis.borland.com (Pete Becker) writes:
: In article <1992Aug28.164813.51739@evolving.com> jcm@evolving.com (Jack Morrison) writes:
: >
: >	class C {
: >	private:
: >		struct A { int x; };
: >		struct B { A a1; };
: >		A a2;
: >	};
: >
: >The AIX 3.2 xlC compiler complains about the struct B declaration, saying
: >it can't access private type C::A. I guess I understand this, since B is
: >basically a (nested) class. [...]  Making A *public* works, but I 
: >didn't really want to bother anyone outside the class with the struct type.
: 
: [...]
: The name of a private member "can be used only by member
: functions and friends of the class in which it is declared."
: [...] Since struct B is neither a member function
: nor a friend of class C, it cannot use the name of struct A.

Can struct B use its own name?  After all it is a private name to which
it has no access (access control applies uniformly to all names,
including nested types)...

Are private nested types useful at all, given the current language definition?

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| jbn@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490              |
--------------------------------------------------------------------------
Newsgroups: comp.lang.c++
From: anstey@sun.soe.clarkson.edu (Charles Anstey)
Subject: GCC2.2 doesn't inline template member functions FIX (ugly)
Organization: Clarkson University, Potsdam NY
Distribution: comp.lang.c++
Date: Thu, 27 Aug 1992 06:38:35 GMT

I previously posted that GCC2.2 does not inline template member functions.
Thanks to a posted reply from someone (sorry, forgot to save who it was), it
was suggested that GCC would inline the function in all functions following
the first one so...
int foo (){ } // Not inlined
int bar (){ } // inlined
int bar2 () { } // inlined

After testing the theory, I found it to be true which led me to a fix which
is rather ugly but the results are correct.

Original example
template <class PT>
class S {
private:
  PT length;
public:
  S (int size): length(size) {};
  ~S () {};
  PT size () { return (length);};
};


Modified version to make GCC do what it should have done in the first place.
#pragma interface  // Needed to prevent duplicate information

template <class PT>
class S {
private:
  PT length;
public:
  inline S (int size): length(size) {};
  inline ~S () {};
  inline PT size () { return (length);};
};
// 'inline' keyword required or GCC will make an external reference

// Now create a dummy inline function which calls all the class' functions.
// Only works for S<int>.  If you also use S<double> you need another
// inline function.
inline PT s_dummy (void) { S<int> s(2); return (s.size()); }

Main program
#include <iostream.h>
#include "S.h"

int main ()
{
  S<int> s(4);
  int x;

  x = s.size ();
  cout << x << "\n";
}

Now GCC will produce the desired result with no extra output overhead.
The trick is to create the inline dummy function which will call every 
member function.  However you must make an inline dummy function for
each type used.  I really hope this gets fixed in the next release.

Despite this, I still believe GCC is the best compiler for the money.
  
-Charles Anstey


Newsgroups: comp.lang.c++
From: chris@frcs.Alt.ZA (Chris Old)
Subject: iostreams with g++ 2.2.2
Organization: Free Range Computer Systems CC
Date: Fri, 4 Sep 92 08:13:19 GMT

The hardware is a 486, the software Dell SVR4.

I'm trying to get g++ 2.2.2 running with iostream.  I compiled gcc and
g++ with no trauma.

The Gnu iostream has a copyright Per Bothner 1991.  I briefly checked
out the Makefile and then typed make.  The compiler gives about 15
warnings when compiling streambuf.C, stuff like:
-type specifier ommited for paramter
-implicit declaration
Then the assembler gets a turn and gives me four syntax errors and gives
up. This is /usr/ccs/bin/as (the AT&T assembler I think).

Now the questions:
Do I need gas to compile iostream?
If so, will I also need to compile binutils and glib?
The g++ shell script originally tried to link with some library called
g++ (library=-lg++) until I told it not to.  What is in this library, and
where does one get it?

If someone has binaries for iostream that would work on Dell and g++
2.2.2, and is prepared to let me ftp them, then I'd be most appreciative.

chris
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 27 Aug 92 15:35:24 GMT

matt@physics16.berkeley.edu (Matt Austern) writes:

>The classic situation where gotos are generally believed to be useful
>is writing a finite-state machine.

>It seems to me that you could probably do better, though, by defining
>some abstract class State, and then deriving the actual states of the
>finite-state machine from it; this seems like it might be a more
>elegant technique.  (I haven't tried this, though; I'm just
>speculating.)

Get the C++ report, Vol 3, Number 1, January 1991.  The banner article
provides a detailed description of your speculation.

I have since used that techinque in dozens of applications, and have
even written a yacc/lex parser which takes a traditional State
transition table and converts it into the necessary C++ code.  (I'll
send it to you if you like).

------

Goto has never been a "good" way to implement FSMs.  Nested
switch/case statements which use a State variable and transition codes
are more traditional, easier to maintain, and do not use goto.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Garbage Collection for C++
Date: Tue, 25 Aug 1992 19:10:44 GMT
Organization: Security APL, Inc.

In article <TMB.92Aug18165833@arolla.idiap.ch> tmb@idiap.ch writes:
>(*) What this means is implementation dependent. On virtual memory
>machines, a sensible default notion of "no more memory" would be "no
>more real memory", since for most programs, performace becomes
>extremely once you start paging anyway. Under DOS, I think it's pretty
>clear what "no more memory" means.

This is an aside, but it really isn't clear.  Many DOS C compilers these
days support access to expanded and extended memory, not to mention various
DOS extenders and swapping or virtual memory schemes.  Probably most
existing large DOS applications would have to turn/leave GC off.
From: good@drinking.Eng.Sun.COM (David Cannon [SVR4 Project Coordinator])
Newsgroups: comp.lang.c++
Subject: Is Turbo C++ a entry level package
Date: 26 Aug 1992 21:57:28 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: good@drinking.Eng.Sun.COM
NNTP-Posting-Host: drinking
Keywords: borland c c++ software

I purchased Turbo C++ for Windows and found it a little difficult to
jump into.  I also could not find a suitable book to help get acquanted
with the package.  I though perhaps the Turbo C++ for Dos may be easier or
maybe get the large Borland C++ for long term growth reasons.

What would you recommend I purchase for entry level programming?  And
what books would compliment the package?


---

    _/_/      ___/  _/   _/ _____/	David T. Cannon
   _/  _/  _/   _/ _/   _/ _/		Sun Microsystems Inc.
  _/   _/ _/__/_/ _/   _/ ___/		good@drinking.eng.sun.com
 _/  _/  _/   _/  _/ _/  _/		129.144.14.42
_/_/    _/   _/    _/   ______/		"My comments are plagiarized"
Newsgroups: comp.lang.c++
From: mendell@turing.toronto.edu (Mark Mendell)
Subject: Re: Syntactic Ambiguity Resolution in C++
Organization: IBM Toronto Lab
Date: 1 Sep 92 02:19:37 GMT

I have been told that xlC on the RS/6000 passes all the posted tests.
-- 
Mark Mendell
IBM Toronto Lab
mendell@torolab6.vnet.ibm.com
Newsgroups: comp.lang.c++
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: destruction of temporaries
Date: Fri, 28 Aug 1992 22:18:41 GMT
Organization: Security APL, Inc.

I don't claim to have a complete solution to the problem.  However, for the
specific case   c ? a+b : a   where a+b creates a temporary, I would be
tempted (as a compiler writer) to always return a temporary: a+b if c is
true, and a copy of a otherwise.  This solves the problem of not knowing
whether a temporary has been created.

Is this legal under the proposed C++ specification?
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: Destruction of temporaries
Date: 28 Aug 92 12:21:20 GMT

ark@alice.att.com (Andrew Koenig) writes:

|The real problems come about when, say, a String
|class has operator const char() that returns a pointer to the internal
|representation of the String.  That then raises the problem:

|	String s, t;

|	// ...

|	const char* p = s + t;

|and now, the question is when the temporary representing `s + t' is
|destroyed.  The point is that destroying that temporary invalidates p,
|so it suddenly becomes an issue of great concern.

It is in these cases where I would be perfectly happy if the compiler
issued a warning, or even an error.  I don't think, in the absence of
GC, that the compiler should be responsible for tracking the
disposition of such pointers.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: complex classes and temporary destruction.
Date: 28 Aug 92 15:33:09 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <64821@cup.portal.com> Aurelius@cup.portal.com (Mark Christian Barnes) writes:

>  Have the temporary "inherit" (for lack of a better word) the
> storage class of p. If p is an auto variable then 's+t' should
> be auto too. Destroy p and 's+t' together. If p is static, then
> perhaps have 's+t' be static as well, onc instance of 's+t'
> gets re-used each time the statement is executed.

I'm afraid that wouldn't work.  Consider this:

	char* I(char* x) { return x; }

The function I (for identity) just returns its argument, but to make things
difficult, it is compiled separately.  Now, you would like

	char* p = s+t;

to cause the temporary for s+t to stick around as long as p does,
but what are you going to do about this?

	char* p = I(s+t);

There's no way to know what I() does, so what basis do you have for
letting the lifetime of p affect that of s+t?
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: casadei@verona.mit.edu (Stefano Casadei)
Subject: Re: constructor call during initialization of same class
Organization: Massachusetts Institute of Technology
Date: Sun, 23 Aug 1992 19:19:38 GMT

In article <1992Aug23.154530.1131@taumet.com> steve@taumet.com (Steve Clamage) writes:
>casadei@verona.mit.edu (Stefano Casadei) writes:
>
>>Is it possible to define a class constructor which invokes another
>>constructor of the same class during the initialization phase (i.e. between
>>the : and the body) ? If not, why is such a simple feature not implemented
>>in the language ?

.....
>I am guessing that you want to share some code by having several
>constructors call a "basic" constructor.  You can't do that with
>a construcutor.  You can write an initialization function which all
>constructors call.  This is equivalent to what I think you want:
>	class foo {
>	public:
>	    foo();
>	    foo(int);
>	    foo(char*);
>	private:
>	    init();
>	}
>	foo::foo() { ... init(); ... }
>	foo::foo(int i) { ... init(); ... }
>	foo::foo(char* p) { ... init(); ... }
>-- 
>
>Steve Clamage, TauMetric Corp, steve@taumet.com
>Vice Chair, ANSI C++ Committee, X3J16


Thanks for your reply. (I tried to reply you by mail but my your machine
was unknown to mine).

I thought that by constructing the object during the assignement phase 
(i.e. within the body of the constructor) is less time-inefficient than
by doing so during the initialization phase (right after the ':').
For instance in my particular case, if I do the following:

----------------- cut here ------------------

class picture { ... picture(pic,wid,hei,row,col) ... }

class lmodel {
public:
    lmodel (picture);
    lmodel (picture pic, int row, int col, int wid, int hei); 
private:
    ....many member objects.........
};

lmodel::lmodel(picture) {...}
lmodel::lmodel(picture pic, int row, int col, int wid, int hei)) {  *this=lmodel(picture(pic,wid,hei,row,col)); }


----------------- cut here ------------------


then I would expect that the source line:

lmodel::lmodel(picture pic, int row, int col, int wid, int hei)) {  *this=lmodel(picture(pic,wid,hei,row,col)); }

requires three initialization of the member objects of the class lmodel: 
one for the initialization proper;
another for the construction of the RHS of the assignment;
and another for the assignment.

On the other hand, if the following line were accepted:

lmodel::lmodel(picture pic, int row, int col, int wid, int hei)) :  (*this)(picture(pic,wid,hei,row,col)) {}

then only one 'scan' would suffice. 
I saw an argument like this in Lippman's book, I don't remember where exactly.
Is it right ?

Thanks.

Stefano
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: copy ctor and inheritance
Date: 4 Sep 92 13:57:36 GMT

skip@taygeta.oc.nps.navy.mil (Skip Carter) writes:


|	How do I get the copy constructor of a base class to get invoked
|	when I use a copy constructor for a base class ?

|	In the following example I get the behaviour I want (AT&T 2.1)
|	if I leave it up to the compiler to create the copy constructor for B,
|	but if I write my own, the copy constructor for the base class A never
|	gets invoked.  (It does not matter whether or not I define the copy constructor
|	for the base class, A).


You invoke the base class copy constructor in the initialization list
of the derived class.  See the modification that I made to your code
sample below.  And remember, never use gotos.

|#include <iostream.h>

|class A
|{
|	private:
|	  int val;
|	public:
|	  A() : val(0) { cout << "A() invoked\n"; }
|	  A(const A& a) { val = a.val; cout << "A(&A) invoked,  val = " << val << '\n'; }
|	 ~A() { cout << "A.val = " << val << " going away\n"; }
|	  void set_val(const int v) { val = v; }
|	  int get_val() const { return val; }
|};

|class B : public A
|{
|	private:
|	   int vv;
|	public:
|	  B() : vv(0) { cout << "B() invoked\n"; }

|	  B(const B& b) : A(b) { vv = b.vv; cout << "B(&B) invoked\n"; }
                        ^^^^^^
------------------------------

|	 ~B() { cout << "B.val = " << vv << '\t' << get_val() << " going away\n"; }
|	  void set_v(const int v) { vv = v; }
|	  int get_v() const { return vv; }
|};



--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Newsgroups: comp.lang.c++
From: shirleyk@qualix.com 
Subject: Re: where can I find cfront?
Followup-To: info@qualix.com
Keywords: cfront c++
Reply-To: info@qualix.com
Organization: QUALiX Group, Inc.
Date: Tue, 1 Sep 1992 23:17:00 GMT

In article 26927@sunb10.cs.uiuc.edu, pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
> In <1992Aug26.202501.589@unixg.ubc.ca> martin@ucs.ubc.ca (Marilyn Martin) writes:
> 
> >I am in urgent need of cfront.  Can anybody please point to a
> >public domain or commercial product?  Thanks for your help.
> 


cfront 3.0 (commercial product) is available from the Qualix Group.
For more information, contact:

Qualix Group
1900 S. Norfolk St. Suite 224
San Mateo, CA 94403-1151
voice: (415) 572-0200
fax:   (415) 572-1300
email: info@qualix.com
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for named loops.
Date: 28 Aug 92 02:52:27 GMT
	<1992Aug26.130335.26725@hemlock.cray.com>
	<MATT.92Aug26122422@physics16.berkele
	<KERS.92Aug27082828@cdollin.hpl.hp.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: kers@hplb.hpl.hp.com's message of 27 Aug 92 07:28:28 GMT

In article <KERS.92Aug27082828@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:

   In article ... matt@physics16.berkeley.edu (Matt Austern) writes:

      The classic situation where gotos are generally believed to be useful
      is writing a finite-state machine.

   Use mutually recursive procedures, and lean on your language designers and
   compiler-writers until they're as efficient as the goto's would have been.

Actually, since your C implementation is unlikely to support tail
recursion optimization, it's probably a more practical idea to use
what is now commonly known as "continuations" (the casts are necessary
because the C type system can't handle the "correct" declarations):

	typedef void (*fpointer_help)();
	typedef fpointer_help (*fpointer)();

	void driver(fpointer state) {
		while(state) {
			state = (fpointer)state();
		}
	}

	fpointer some_state();

	fpointer some_other_state() {
		/* ... do something ... */
		return (fpointer)some_state;
	}

	fpointer some_state() {
		/* ... do something ... */
		return (fpointer)some_other_state;
	}

But the different ways of expressing state machines in C (table-based,
recursive, using goto, and using continuations) have different
applications and different tradeoffs. In a Lisp interpreter that I
wrote a long time ago, I was using continuations for the main
interpreter (it needed lots of states, with source code scattered
across lots of source files), and "goto" for the state machine inside
the compacting, single-space garbage collector (for efficiency).

				Thomas.
From: rgp@mpd.tandem.com (Ramon Pantin)
Newsgroups: comp.lang.c++
Subject: Re: Destructors and exit()
Date: 4 Sep 92 19:08:12 GMT
Organization: Tandem Computers, Micro-Products Division

In article <rmartin.715615353@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
>main()
>{
>  MyClass A;
>  static MyClass B;
>
>  exit();
>}
>
>
>The destructor for B should be invoked.  But the destructor for A
>probably will not.  I say probably, because a clever compiler might be
>able to figure out that, upon exit, the enclosing stack frames should
>be destroyed.

IMHO, it would be incorrect for a compiler to "know" anything about
exit (exit is part of the C library, not part of the language, "exit"
is not a keyword).  A call to the exit function has never triggered
destructions of automatic objects and should never do.  The block where
the object was constructed is not being exited when the exit function
is called so it is incorrect to destroy the object.  Doing so would
invalidate valid code such as:

	#include <stdlib.h>
	class A {
		A() { ... };
		~A() { ... };
	};
	A	*ap;
	cleanup()
	{
		if (ap)
			ap->cleanup();
	}
	main()
	{
		A	a;
		atexit(cleanup);
		if (...)
			exit(1);
		...
		ap = &a;
		...
		exit(1);
	}

Or some other code where the destruction of the automaitc object has side
effects that are observable from outside the process.  It is also possible
in a standalone environment to have a user defined version of exit that
doesn't cause program termination but some other behaviour (and also being
extern "C" void exit(int); ).

>And remember, never use gotos.

Use breaks, continues, mid-function returns and gotos if you want to.

Ramon Pantin
From: Aurelius@cup.portal.com (Mark Christian Barnes)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: Fri, 28 Aug 92 21:13:32 PDT
Organization: The Portal System (TM)
Distribution: world
  <6800007@tisdec.tis.tandy.com><1992Aug26.130335.26725@hemlock.cray.com><MA
 TT.92Aug26122422@physics16.berkeley.edu> <rmartin.714929724@thor>
  <TMB.92Aug28192826@arolla.idiap.ch>

my $0.02

 If discussions like this didn't keep happening, I would have
forgotton a couple of C-ism entirely by now:

1) C has a goto statement.
2) Labels exist separately from the switch construct.
3) ditto with the break statement.

 I do use mid-function returns, i.e. "found it!, get out, done"
( my functions are almost always less than one page, or else! ).
I usually have my if conditions succeed for the expected
execution path (usually more efficient not to branch), so my
exceptional code is in an else block, perhaps with a return.
This also allows me to declare auto variables at the beginning
of the conditional block, instead of at the top of the function.
Many C dialects (VAX C for one) still don't allow variable
declarations just anywhere.

			Regards, Aurelius@cup.portal.com
Newsgroups: comp.lang.c++