HDTenEightyP/NetNews huggingface dataset:
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Garbage Collection for C++
Date: 25 Aug 92 18:29:43 GMT
Organization: Microsoft Corporation

In article <1992Aug19.180252.12942@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
|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.

These same thoughts could be equally applied to the lifetime of temporaries,
leading to the conclusion that the lifetimes of temporaries ought to be
the same as for named objects.  IE "end of block" [incl. implied block of
loops and conditionals], and reversed orders of constructing and destructing.

Newsgroups: comp.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: Proposal: static T& function argument
Date: Wed, 2 Sep 1992 04:06:40 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

eric@tfs.com (Eric Smith) writes:
|Here is another proposal that might simplify the issue about
|lifetime of temporaries.  If a function formal argument is
|specified as static T& the programmer doesn't want any calls
|using references to temporaries.  The "static" in the static T&
|in that context tells the compiler to issue an error message
|at compile time whenever anyone tries to call that function with
|a temporary.  This allows the function to safely return a
|reference or pointer to the static T& argument knowing it can't
|be a temporary.

I like this idea.

It doesn't solve all the problems, but it should solve quite a few.
Above all, it's simple.

Some comments, though:

1) One would only worry about arguments of the type 'const static T&',
   since a reference to non-const can't be bound to a temporary.

2) It should also be possible to apply this to member functions:

      class String {
      public:
         operator const char*() const static;
      };

   (This could also apply to non-const member functions.)

3) Some keyword other than static should be used, or perhaps a
   completely different syntax.  The static keyword already has
   too many meanings and although there's no syntactic problem
   in the use of static for String::operator const char*() above,
   it would be just too confusing to have two different meanings
   for "static member function".

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for named loops.
Date: 4 Sep 92 14:59:03 GMT

kers@hplb.hpl.hp.com (Chris Dollin) writes:

|In article ... rmartin@thor.Rational.COM (Bob Martin) writes:

|   You don't have to make up your own rules.  Some other guys, who have
|   thought about it alot, have put together a pretty well thought through
|   set of rules.  Moreover, the industry has, for the most part, accepted
|   those rules as valid.  Moreover, it has been proven that those rules
|   are always workable, and it has been shown that they help to make code
|   more readable and maintainable.  

|In what sense do you claim that ``these rules'' (by which I understand you to
|mean the usual rules of structured programming) have been ``proven'' to be
|``workable''? 

Only that it has been proven that gotos are unecessary.  That any
algorithm can be written in terms of sequence, selection and
repetition.

|It's certainly true that any procedure can be rewritten in structured style
|(ie, using only while, if, and sequencing as control structures). But the
|easiest proof of this -- turn it into a loop wrapped round a case (chained ifs,
|if you want to be picky) -- also shows that it's not necessarily a good idea,
|if what you want is *clear* code.

|And clearness is as much a matter of psychology as of mathematics. 

Yes, so lets forget the psychological part and focus on the
mathematical part.  Constructiong your algorithms based on SP causes
you to separate paths that you might otherwise combine (with gotos).
This separation decouples the paths from each other, so that changes
made in one path do not affect the other paths.

We don't use SP because it makes the code "prettier" or
psychologically more gratifying.  We use it because it separates the
code fragments and reduces coupling.  This makes the code easier to
maintain.

|There's a
|lot of empirical evidence to suggest that traditional SP ``works'', ie, that 
|for very many programming problems, they are an effective solution. [The
|evidence is the large number of programs written effectively in that style.]
|But there's also evidence that they're not *enough* -- that other control
|structures are needed for clarity -- consider

|    * procedures
|    * FOR-loops (of various kinds)
|    * N+1/2 times loops
|    * Scheme-style use of tail-call
|    * Co-routines
|    * Higher-order functions

|for example.

Agreed.
The last thing I advocate is a reduction of all code to one linear
stream of sequence, selection and repetition.  


--
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: dshaker@qualix.com (Doug Shaker)
Subject: Re: 3.0 for sun/sparc or apollo??
Reply-To: dshaker@qualix.com
Organization: QUALiX Group, Inc.
Date: Wed, 2 Sep 1992 19:13:52 GMT

In article 27589@bcrka451.bnr.ca, noye@bcrka378.bnr.ca (Janet Noye) writes:
>Does anyone know of any 3.0 compilers for the sun/sparc's or the Apollo's?
>Yeah I realize that asking about the Apollo is just opening myself up to 
>disappointment but I had to ask -);
>
>Thanks for your help!
>Janet
>
>-------------------------------------------------------------------------------
>Janet Noye : email : noye@bnr.ca                mail  : Dept. 5E22
>             phone : (613) 763-5985             Bell-Northern Research Ltd.
>             fax   : (613) 765-4845             P.O. Box 3511, Station C
>                                                Ottawa, Ontario K1Y 4H7
>                                                Canada
>-------------------------------------------------------------------------------
>
>
The only cfront 3.0 for Sparcs that I know about is Solbourne's cfront.  We
(Qualix) sell it.  Send email to info@qualix.com for more information.  If
there is a cfront 3.0 for Apollos, then HP would be the folks selling it
(at least that's my guess).





 - Doug Shaker

	voice:	415/572-0200
	fax:	415/572-1300
	email:	dshaker@qualix.com
	mail:	Qualix Group
		1900 S. Norfolk St., #224
		San Mateo, CA 94403


Newsgroups: comp.lang.c++
From: eric@tfs.com (Eric Smith)
Subject: Proposal: static T& function argument
Organization: TFS
Date: Sun, 30 Aug 1992 00:02:50 GMT


My earlier proposal of auto T& turns out to be unneeded because
good compilers can optimize to get the same effect if the
programmer uses T instead of T&.  Thanks to everyone who pointed
that out.

Here is another proposal that might simplify the issue about
lifetime of temporaries.  If a function formal argument is
specified as static T& the programmer doesn't want any calls
using references to temporaries.  The "static" in the static T&
in that context tells the compiler to issue an error message
at compile time whenever anyone tries to call that function with
a temporary.  This allows the function to safely return a
reference or pointer to the static T& argument knowing it can't
be a temporary.
Newsgroups: comp.lang.c++
From: sandy@garfield.cs.mun.ca (Sandy Walsh)
Subject: Re: Did I just shoot myself in the foot?
Organization: CS Dept., Memorial University of Newfoundland
Date: Tue, 1 Sep 1992 16:50:15 GMT

Get ready to shell out some ching for another meg at least.
(I'm in the same boat!)


---
Sandy Walsh - Memorial University of Newfoundland - CS Dept 

I've been carving you, to see what form you take. 
You were hiding in ivory, I just wanted to free your shape.
	- The Tragically Hip 	(sandy@garfield.cs.mun.ca)
Disclaimer? I don't even know her!
From: matt@physics16.berkeley.edu (Matt Austern)
Newsgroups: comp.lang.c++
Subject: Re: GOTO, was: Tiny proposal for na
Date: 26 Aug 92 12:24:22
Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
	<1992Aug26.130335.26725@hemlock.cray.com>
Reply-To: matt@physics.berkeley.edu
NNTP-Posting-Host: physics16.berkeley.edu
In-reply-to: dsf@cray.com's message of 26 Aug 92 13:03:35 CDT

In article <1992Aug26.130335.26725@hemlock.cray.com> dsf@cray.com (Dan Frankowski) writes:

> If one-entry-one-exit is part of a structured programming, then the
> goto is not "just another structured technique."  Note that I did not
> say gotos have no uses.  (I haven't made up my mind yet.  Maybe this
> thread will help me decide.  :-)

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.)
--
Matthew Austern                   Just keep yelling until you attract a
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: <stdio.h> and <iostream.h>
Organization: TauMetric Corporation
Date: Wed, 2 Sep 1992 16:43:51 GMT

tannerrj@cnsvax.uwec.edu (Power = 486 + HST Dual Standard) writes:

>I am trying to put a text windowing environment on a C++ program
>that I have created. The text windowing environment is DFLAT from 
>DDJ magazine. The problem is DFLAT is ANSI C using stdio.h and
>my program is a C++ program with iostream.h. I have read that there
>are potential dangers in mixing the two. Any suggestions? Thanks.

The potential problem in mixing iostreams and stdio on the same
file is the separate buffering.  For example, try this:
	#include <iostream.h>
	#include <stdio.h>
	main()
	{
	    cout << "Hello ";
	    printf("world\n");
	    return 0;
	}
On many systems, the output from printf appears first.

There are two solutions.

1.  Call the static member function ios::sync_with_stdio() before doing
    any I/O.  This forces all I/O using the standard streams to go
    via stdio calls.  This I/O is unbuffered and very inefficient.
    (It affects only I/O on cin, cout, cerr, and clog.)
	#include <iostream.h>
	#include <stdio.h>
	main()
	{
	    ios::sync_with_stdio(); // synchronize stdout and cout
	    cout << "Hello ";
	    printf("world\n");
	    return 0;
	}

2.  Use only stdio functions on the standard streams from the C++ code.
    This ensures you will not have any unnecessary inefficiencies and
    no synchronization problems.  You can use both stdio and iostreams
    safely, but on different files:
	#include <stdio.h>
	#include <fstream.h>
	main()
	{
	    ofstream outfile("myfile.dat");
	    printf("Hello world\n");		// to standard output
	    outfile << "Hello world" << endl;	// to iostream file
	    return 0;
	}

-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: (none)
Organization: TauMetric Corporation
Date: Fri, 4 Sep 1992 16:18:36 GMT

rollins@bart.ee.queensu.ca (Mark Rollins) writes:


>Using the syntax of Stroustrup's 1st edition, pg. 162
>and g++ version 2.2.2, libg++ version 2.1, and SunOS 4.2.2 I get
>correct results but a compiler warning:

>   g++ -o bin/junk badmem.cc -lg++ -lm
>   badmem.cc: In method `Vector::~Vector ()':
>   badmem.cc:9: warning: use of array size with vector delete is anachronistic

>If I omit the array size, the Vector does not get de-allocated
>properly using the destructor, and all virtual memory gets eaten up
>rather quickly. (It's probably just deleting the 1st one in the array).

>What is the proper syntax for deleting a vector of class objects ?

Don't use Stroustrup 1st edition as a language reference.  It is of
only historical interest now, as there have been many important
language changes since 1985.

Handling of arrays of classes is one area where the language has
changed, and it depends on the particular release of the C++
compiler you use.

With all modern compilers, an array of objects allocated as
	p = new T [count]; // T is some type
is deleted like this:
	delete [] p; // empty brackets

If a single object was allocated, not an array, you use
	delete p; // no brackets

If you use "delete p" for an array, or "delete [] p" for a single
object, the results are undefined.  The program may appear to work,
or you might get a runtime error message of some kind or a system crash.

Some compilers accept an expression in the delete brackets
	delete [count] p; // obsolete
but ignore or only warn about the expression.  Compilers which
require the count are obsolete and should be replaced.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: complex classes and temporary destruction.
Date: 27 Aug 92 14:46:42 GMT
Article-I.D.: alice.23563
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <MCGRANT.92Aug26232410@rascals.stanford.edu> mcgrant@rascals.stanford.edu (Michael C. Grant) writes:

> Oh, and that reminds me, if I can't do

> complex a,b,c,d;
> ...
> a = b + c*d

> when the ANSI committee finally settles on some temporary destruction
> standard, then I'm going to be really ticked.

Of course.

Don't worry, the issues under discussion will not affect well-behaved
programs such as this.  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.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: Destruction of temporaries
Date: Wed, 2 Sep 1992 04:49:37 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

ark@alice.UUCP () writes:
|In article <rmartin.715268992@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
|> These strategies should not supress the warnings.  ANY time an address
|> or reference to a temporary is taken, whether is is via implicit
|> conversion, or as the argument of a member function, a warning should
|> be issued.  No exceptions.
|
|> This will flag every instance where a long lived alias to a temporary
|> could be created.
|
|No, it will flag some instances.  For example:
|
|	struct A {
|		A& foo();
|	};
|
|	A a();
|
|	main()
|	{
|		A& b = a().foo();
|	}
|
|Should this give a warning or not?  It is impossible to tell without seeing the
|definition of A::foo.

As I understand Bob's suggestion, the compiler should give a warning
here, on the grounds that *this will be bound to a temporary when
foo() is called.  The point isn't that this is likely to cause a
problem, just that it _might_ cause a problem.  As I posted a few days
ago, I think this would cause far too many undeserved warnings.

[safe example deleted]


|in which case there is no problem, or it might be
|
|	A& A::foo() {
|		return *this;
|	}
|
|in which case there is.  Without seeing it, the compiler can't tell.
|
|But looking at A::foo without seeing main, it's impossible to tell either.
|Returning *this from a member function is completely innocent unless the
|member happens to be called on a temporary object.

Here Eric Smith's proposal, extended to member functions, would
be handy.  It would allow the programmer to write something like

   struct A {
      A& foo() no_temporaries;
   };

if foo() shouldn't be called on a temporary.


|				--Andrew Koenig
|				  ark@europa.att.com


-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Garbage Collection for C++
Date: 25 Aug 92 18:40:18 GMT
Organization: Microsoft Corporation

In article <1992Aug20.134554.9729@ericsson.se> jonas@beppe.ericsson.se writes:
|How do you handle C++ arrays without any extra book-keeping? Can arrays be
|handled by GC without extra book keeping?

No problem, just define singleton objects as being one element arrays...
1/2 ;-)
From: srikant@skorpio.usask.ca (Srikant Subramaniam)
Newsgroups: comp.lang.c++
Subject: What is "this" ...
Date: 2 Sep 92 23:38:13 GMT
Organization: University of Saskatchewan, Saskatoon, Canada

Hello Netters:

Could somebody out there help me find a solution ??


	Class Chore {
	....
	public: 
		Chore () { .....};
		...
		dec_reference_count() {
 			lock_reference_count();
                	num_possible_waiters--;

                	if ((num_possible_waiters <= 0) && !worker_reference){
                        	unlock_reference_count();
                        	delete this;		// offending line
                	}
                	else {
                        	unlock_reference_count();
                	}
        	}

File TC_Program.c
---------------


	Chore* userchore = new Chore (.........);
	userchore->dec_reference_count();		// this is line #65
	.........
	
So far so good, now comes the problem:

When I compile the above code, the compiler flags this error :

	accom: Error: TC_Program.c, line 65: left operand is void

I have located the problem to lie in the line labelled "offending line". When
this line is commented out, the compilation goes thru. Could somebody pl tell
me what is wrong ?

Thanks ...
-- 
----- 
 |\/\/\/|      Srikant Subramaniam.
 |      |      srikant@cs.usask.ca 
 |	|
 |      |      Disclaimer: This is not what really I look like. 	
 | (o)(o)      Disclaimer: I didn't do it, nobody saw me do it, 
 C      _)                  can't prove anything. 
  | ,___|             
  |   /     
  /---\    
Newsgroups: comp.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: break/continue (was: Re: Tiny proposal for named loops.)
Date: Wed, 26 Aug 1992 04:09:55 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

rmartin@thor.Rational.COM (Bob Martin) writes:

|No, exceptions do not violate structure (IMHO).  The function which
|throws an exception never returns!  The calling code preserves its
|invariants.  The exception is caught by code which expects it, so its
|invariants are not violated either.
|
|Nor do exceptions violate single entry single exit, since the
|exception is not an exit, it does not return to the caller.  Rather it
|is caught by a higher level catch which is itself written in a
|structured block.

An error function that stops your program alters the control flow
in a nice, simple way.  By contrast, exceptions can have somewhat
non-intuitive effects.  Consider this function:

   void foo() {
      char* p = new char[17];
      doSomething();
      delete [] p;
   };

If doSomething() can throw an exception, then foo() has a memory leak!
The same is true if doSomething() can call longjmp(), but when
exceptions become commonly available, I suspect they will be much more
widely used than longjmp().



Since I'm already posting, I'll take this opportunity to correct
a mistake in my earlier post...

||Ideally, the author and the reader share the same assumptions,
||but that's not often true.

That should have read "... but that's often not true."
A small typo, but one with a significant effect on the meaning.

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
From: niklas@appli.se (Niklas Hallqvist)
Newsgroups: comp.lang.c++
Subject: Re: GCC2.2 doesn't inline template class functions. Normal?
Date: 26 Aug 92 21:53:05 GMT
Distribution: comp.lang.c++
Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN

anstey@sun.soe.clarkson.edu (Charles Anstey) writes:

:While playing around with GCC2.2, I noticed that it does not inline
:template class member functions.  Is this typical of all compilers for
:reasons I do not know?  GCC2.2 will inline member functions of a
:non-template class.

:The examples was quite simple.
:template <class PT>
:class S {
:private:
:  PT length;
:public:
:  S (int size):length(size) {};
:  PT size () { return (length);};
:};

:S.size() is not inlined.  If I remove the template PT and change it to 'int'
:then it is inlined.

:Anyone know why?

This is from memory, I don't have access to my compiler for the moment
so I can't test it.  If you instantiate a template class inside a function,
the member functions gets queued up for compilation after the current one.
If you refer to these members in this function you will get out-of-line
calls, but calls in later functions will be inlined.  The reason for this
is simply compiler simplicity.  When someone has the time, GCC might be
changed to compile members directly during instantiation, pushing the
current function's context on some stack.  Example:

int foo()
{
  S<int> s(1);
  return s.size();	// Out of line
}

int bar()
{
  S<int> s(1);
  return s.size();	// Inline
}

If this is wrong, try the same example with an explicit inline keyword
on the size member function.  As I said, I don't remember the exact details,
I will check tomorrow.

Niklas
-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!seunet!appli!niklas
Newsgroups: comp.lang.c++
From: swillden@news.ccutah.edu (Shawn Willden)
Subject: "Recursive" template problem
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Wed, 2 Sep 92 15:06:11 GMT

To any of you who already saw my first post on this subject, I apologize.
However, given the resounding silence that post elicited (no one even
corrected my syntax errors!), I thought maybe I had better try again, 
with a different subject (specifically with one that doesn't include 
'BC' - since that was in my own kill file for quite some time).

The problem is this:  Given a template base class that contains pointers
to two of its derived classes, at least two compilers (gcc-2.2.2 and BC++
3.1) choke (the former dumps core, the latter reports an error).  The 
code looks something like this:

// Forward declarations of A1<T> and A2<T>
template<class T> class A1;
template<class T> class A2;

// Now we'll do the actual class definitions.
template<class T> class A {A1<T>* a; A1<T>* b;};
template<class T> class A1 : public A<T> {};
template<class T> class A2 : public A<T> {};

int main() {A1<int> myA1;}

What happens is, the compiler:
	begins to expand A1<int>, 
	realizes it needs A<int> first,
	begins to expand A<int>,
	*thinks* it needs to expand A2<int> (which it doesn't, because b is
		and A2<int>*),
	begins to expand A2<int>,
	realizes it needs A<int> first,
	notices that A<int> is partially expanded
	and pukes.

So, has anyone else seen this problem?  Come up with a work-around?  If I 
get some time I'm going to try to fix gcc but my archie server doesn't
seem to find anything under BC++3.1_source_code.tar.Z ;-) that one's going
to be a little tougher.  Are there any compilers that *do* handle this?
(I only have access to gcc 2.2.2, BC++ 3.1 and some version of Oregon C++
that doesn't support templates [The man page says the -Xv switch tells
Oregon C++ to report what version it is, but it doesn't work]).

--
Shawn Willden
swillden@icarus.weber.edu