HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.lang.c++
From: goldberg@turing.toronto.edu (Jody Goldberg)
Subject: Cfront, GCC and Global Constructors
Summary: gcc suplants need for patch/munch
Keywords: cfront gcc patch
Organization: CSRI, University of Toronto
Date: 12 Aug 92 13:54:40 GMT

I recently posted asking why a trivial example with global constructors
was executing the constructors twice.  What I didn't mention was that
we are using 'gcc' as the backend to cfront 3.0 with patch.  The suggested
solution was that 'nm' must be spitting out names multiple times.

The reality was that gcc is smarter than cc and had already patched the
global constructors BEFORE patch ever got run.  The net result is that
we are quite happily running now without patch or munch.

	Thanks for your help
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jody Goldberg
goldberg@turing.toronto.edu		|	 "I Row ... What else Matters ?"
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Reference counting for vectors, (Tony Hansen's book).
Date: 20 Aug 92 19:24:00 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: nikki@trmphrst.demon.co.uk's message of 19 Aug 92 15:54:11 GMT

In article <714264851snx@trmphrst.demon.co.uk> nikki@trmphrst.demon.co.uk (Nikki Locke) writes:

   [quoting a template class to do reference counting that I posted]

   I think this copy operator contains the classic copy operator bug - try 
   assigning a Counted object to itself - the object will be deleted before 
   copying. Try ...

	   Counted &operator=(Counted &other) {
		   other.acquire();
		   drop();
		   count=other.count;
		   object=other.object;
		   return *this;
	   }

You are right; this is a better definition (the last reference counted
class that I wrote, about 5 years ago, got this right...).

   Mind you, there is still a bug here - try 

	   Counted<Thing> a, b;

	   a = b;		// core dump ?

   The fix is for acquire to check count is not NULL before doing (*count)++;

I don't think this is necessarily a bug. Assigning an uninitialized
reference counted object is not necessarily guaranteed to work...

   The original author clearly stated that the program was not tested, but I 
   thought I ought to point out these problems so that others didn't copy the
   mistakes.

   Mind you, I haven't even compiled the code, let alone tested it, so I am 
   even more likely to be wrong ! 

   [ Hobby horse of the week ... ]
   However, if I am right, think about how useful code review is in picking 
   up such obscure bugs, and how cheap compared to hours of testing !

It also shows the value of defensive programming: because I was
careful to zero out various fields in the structure upon destruction,
any of these problems would have been caught on the machine I'm using.
Such practices have saved my neck more than once (I can't afford the
luxury of code review, unless someone volunteers...).

Anyway, this was mainly a toy that I typed in to show that you can use
template classes, to a limited degree, to implement reference
counting. I don't recommend actually using it. The overhead of
reference counting is significant (in particular, when implemented as
a template class). I have not used it in years...

It turns out that if you could distinguish stack from heap objects,
you could even implement mark-and-sweep garbage collection as a
template class--albeit at a runtime cost (in both time and space) that
is probably even higher than that of reference counting.

					Thomas.
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: TVision Help
Summary: get BC++ 3.1 patch for 'new' bug
Date: 19 Aug 92 01:57:01 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <1992Aug16.153046.4242@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>Help! BC3.1 Turbo Vision Help system (TVHC etc) appears to fail
>with an error in TV's new.cpp. The TVDEMO project does not work.
>I have a production program that is stopped because of this
>(oh, why did I use TV!) I'd prefer not to have to reinstall
>BC3.0. Anyone know anything about this?

I encountered similar problems that were fixed by:

Directory PD1:<MSDOS.BORLAND>
 Filename   Type Length   Date    Description
==============================================
BC31P1.ZIP    B   11132  920720  Patch for Borland C++ 3.1 - fixes NEW operator

It's available at Simtel WSMR-SIMTEL20.ARMY.MIL or its mirror sites.
Borland has also recently released BC31P2.ZIP that ups a TLINK table
limit if you're getting a "Table limit exceeded" error (only under
Windows).

Jamshid Afshar
jamshid@emx.utexas.edu
Newsgroups: comp.lang.c++
From: tob@world.std.com (Tom O Breton)
Subject: Re: Name of Operator
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 12 Aug 1992 19:16:17 GMT

C. Xiong:

> I want to introduce some new notations for these operators.

Therein lies a basic impossibility. The parser simply needs to know ahead of
time what all the operators are and how they parse. Can't add new ones
without rewriting the compiler.

This is also why you can't (For instance) make 'operator =' take two
arguments, though classes like Complex and Pos_On_Screen could really use it.


>But I failed, not in the definition of the operator, but in later sentence.
>For example, I define operator as
>
>class vector {
>.....
>vector operatornl() const {  [etc]

Afraid not. That last line does not define an operator called 'nl', it
defines a function called 'operatornl'. If you added a space it would simply
not compile.

          Tom


-- 
Having decimated the hapless peasants, the Tom spreads its huge, scaly wings
and soars into the wild sky...      up...       up...     out of sight...
From: nandraj@unisql.UUCP (Nandraj Arni)
Newsgroups: comp.lang.c++
Subject: Re: Return value for the constructors.
Date: 18 Aug 92 22:54:36 GMT
Reply-To: nandraj@unisql.UUCP (Nandraj Arni)
Organization: UniSQL, Inc., Austin, Texas, USA

> In article <3462@unisql.UUCP>, nandraj@unisql.UUCP (Nandraj Arni) writes
> :
> >
> >    Why does C++ not let you have a return value for a constructor?
> > Is there any rationale behind this?
> 
> Before we answer that question, we should ask what do you want it for?
> A language can't provide every conceivable feature; unless a feature is a
> significant improvement to the language, it is an unnecessary complicati
> on.


  The reason I think it is a important feature the constructor should
return whether it was a success or not? Say I want there is a time
class which takes in put as MM/DD/YY. If the values were out of range
for an instance of this class, the user should know that it was a bad
way to construct this class. OR say it could not allocate memory...



-- 
*******************************************************************
Nandraj Arni

UniSQL, Inc.                           Voice: 512 343 7372 Ext. 107
9390 Research Blvd.                              Home: 512 794 9386
Kaliedo II			   	          FAX: 512 343 7383
Austin, TX 78759

Email: unisql!nandraj@cs.utexas.edu
*******************************************************************
Newsgroups: comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Dumb questions about Borland C++
Date: 18 Aug 92 00:04:14 GMT
Organization: Microsoft Corporation

In article <1992Aug13.152405.16170@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|	No. Its only a 16 bit machine. And the 386 still
|runs 16 bit operating systems.

Recent Intel PC chips such as the 386/486 can run in many different memory
model modes, including 16 bit flat, 16:16 segmented, 32 flat, and 16:32 
segmented.  The last mode, for example, gives the programmer 16,000 distinct
4 Gigabyte address spaces.  Most PC operating systems have historically
used the 16 bit flat and 16:16 segmented modes.  NT is an example that
uses a 32-bit flat programming model [like most recent Unix machines]
I'm not aware of any operating systems that currently exposes the 16:32 
programming mode.

But, the point is is that its the historical operating systems that are
the restriction, not the chips themselves.  Blame the Intel chips for having
a shortage of registers, or blame them for being CISC,...., but don't blame them
for being "16 bits" -- because they aren't.

Newsgroups: comp.lang.c++
From: jonas@beppe.ericsson.se (Jonas Nygren)
Subject: Re: Garbage Collection for C++
Reply-To: jonas@beppe.ericsson.se
Organization: Ericsson Telecom AB
Date: Mon, 17 Aug 1992 07:48:55 GMT

In article 23166@ucc.su.OZ.AU, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> In article <1992Aug15.005542.3104@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
> >
> >Reference counting suffers serious drawbacks:
> >
> >1. It can't handle cyclic data structures
> >
> >2. It is one of the most inefficient forms of garbage collection known to man.
> >
> >The main reason I'm pushing for true garbage collection is that I consider
> >reference counting (which I already have) to be an unacceptably poor solution.
> 
> 	Mm. Reference counting used to implement 'write on demand' in
> copy contructors is supposedly inefficient. But this is not at all
> the same as reference counting for garbage collection. In copy contructors,
> you have to check the reference count before each write operation,
> and if its not 1, clone off a copy of the object. Thats slow.
> 
> 	But for GC you only have to increment the reference count
> when you take the address of the object to form a GC pointer,
> decrement it when the pointer is destroyed, and destroy the 
> object when the count goes to 0. That doesn't seem to be so slow
> to me: please correct me if I'm wrong.

Wouldn't even a GC scheme have to create a copy of the object if the pointer was
used for non-const operations on the object? The advantage with implementing
GC pointers as separate constructs is that the programmer can decide when he
wants stucture sharing and whe he does not.


> -- 
> ;----------------------------------------------------------------------
>         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
> 	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
> ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------


/jonas
From: frank@Cookie.secapl.com (Frank Adams)
Subject: Re: Downcasting (was: Re: run-time type checking)
Date: Sat, 22 Aug 1992 00:49:23 GMT
Organization: Security APL, Inc.

In article <1992Aug15.170141.14667@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>	If the function f(Base&) calls a function g(Base&)
>which silently performs special actions if the reference
>is to some PARTICULAR derived class, then changes to
>the object can be made NOT conforming to the assumed
>invariants of the base, and so f may fail to operate
>correctly.
>
>	I will try to construct an example.
>
>	class X {
>	protected: 
>		int x;
>	public:
>		X(int i) : x(i) {}
>		int get()const {return x;}
>	};
>
>	f(X& a){ int n=a.get(); g(a); assert(n==a.get());}
>
>I would expect the assertion to obtain because class X provides
>no public mechanism to modify 'x', and f has been granted and grants
>to g only public access to the X object a.

Yes, in this example; but not if X has *any* virtual functions at all.  Any
such function may be overridden in a subclass Y to change x, and then called
by g().

>	It is sound for virtuals because they are declared!
>They are there PRECISELY to allow this ability.

And the "protected" declaration is there PRECISELY to allow subclasses
access to the objects so declared.  The protected declaration *delegates*
preservation of assumptions regarding the protected object to the
subclasses.  If you don't want that to happen, declare it private.  Why do
you want to declare it protected, anyhow?
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 17 Aug 92 12:24:36 GMT
Article-I.D.: alice.23466
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <1992Aug17.073500.24115@ericsson.se> jonas@beppe.ericsson.se writes:

> IMO temporaries should survive until end of statement.

This treatment has two significant disadvantages:

	1. If I break a statement up into several, it may
	   quietly change its meaning.  Thus, for example, if
	   String::operator const char*() exists, and s and t are
	   of class String, then

		printf("%s\n", (const char*)(s+t));
	
	   might work but

		const char* r = s + t;
		printf("%s\n", r);
	   
	   might not.

	2. It is a real pain to implement for statements that
	   generate temporaries inside conditionals.  Thus, for
	   example, in x>0?f(p+q):r, if p+q generates a temporary,
	   and it was necessary to wait until the end of the statement
	   to destroy it, it would also be necessary to remember which
	   branch of the ?: was taken to decide whether or not to
	   destroy it.  There are cases where this can add substantially
	   to execution time.  Moreover, it greately complicates the
	   implementation of exception handling, because it makes it
	   impossible to have a static map from program counter value
	   to offsets of statics to destroy.

For these reasons, I think a shorter lifetime than end of statement
is appropriate for temporaries.  Whether the committee will go that
way, however, remains to be seen.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: nagle@netcom.com (John Nagle)
Subject: Re: Is C++ "for the rest of us" ?
Date: Thu, 20 Aug 92 00:06:33 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

       I'd recommend learning Smalltalk before C++, even if you never intend
to write anything in Smalltalk.  Smalltalk offers object-oriented programming
with safety, at some cost in performance.  In Smalltalk, one can actually
see what this OOP thing is all about and what it buys you.  Then one can
learn to deal with the compromises made in C++ to bolt OOP onto C without
adding garbage collection.  If you learn C++ first, the clunky features
of the language obscure the object-oriented concept.

       I'd avoid any C++ without templates for new work.  You really
need a generic capability to make OOP work, and hokey schemes with
macros and heavy use of "(void *)" bypass most of the type checking
while not making it clear where it has been bypassed.

       I suppose we all have to go to C++, but after two years with the
language, I wish something better were available.

					John Nagle
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: run-time type checking, freezing, and thawing
Date: 12 Aug 92 21:37:06 GMT
	<1992Aug10.191631.4133@microsoft.com> <WNZ5RGC@netmbx.netmbx.de>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: jrobie@netmbx.netmbx.de's message of 12 Aug 92 13:43:05 GMT

In article <WNZ5RGC@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:

   jimad@microsoft.com (Jim Adcock) writes:

   >In article <2A827DFD.6D68@tct.com> chip@tct.com (Chip Salzenberg) writes:
   >|Therefore, EVEN IF the C++ standard includes RTTI, object storage will
   >|STILL require preprocessors and all that loathsome junk that you claim
   >|will be unnecessary once RTTI becomes available.

   >An alternative to loathsome preprocessors is to use loathsome postprocessors
   >instead and grovel over the debugging information emitted in the .objs.
   >This makes your postprocessors dependent on the .obj format emitted, but
   >still this should be an easier task.

   We could take that even one step further, and grovel over debugging info
   placed in the .EXEs.  In fact, we could develop a general purpose library
   for accessing this information.  And we could standardize this for all
   vendors.  We have now rederived the concept of extended run time type
   information....

No, "we" have not. Your version of "extended run time type
information" seems to encompass dynamic type information.  But, the
debugging information in ".o" files only gives you static type
information.

Concretely, using the usual C debugging information, you can ask "what
type does this variable have" and "what types is this structure type
composed of", but you can not ask "what type of object is this pointer
actually pointing to".

					Thomas.
Newsgroups: comp.lang.c++
From: s1066603@giaeb.cc.monash.edu.au (Rodney North (Rod))
Subject: Object libraries...
Organization: Monash University College Gippsland, Churchill 3842, Victoria, AUSTRALIA.
Date: Thu, 13 Aug 1992 07:35:40 GMT

Hi there...

I'm after object libraries for windows, wether they be input or ouput
interface.  Can any body help me, any public domain or copywrit titles would
be very, very much appreciated.

Cheers Rod

-----------------------------------------------------------------------------
s1066603@giaeb.cc.monash.edu.au
From: edelson@goudurix.inria.fr (Daniel Edelson)
Newsgroups: comp.lang.c++
Subject: Re: template static data members
Date: 19 Aug 92 08:42:56 GMT
Reply-To: Daniel R. Edelson <edelson@sor.inria.fr>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France

In article <Bt5FDH.DFK@apollo.hp.com>, vinoski@apollo.hp.com (Stephen Vinoski) writes:
|> 
|> ...
|> 
|> 	template<class T> Simple LessSimple<T>::s;
|> 
<problem and explanation omitted>
|> 
|> Unfortunately, in the example case
|> above, ``s'' cannot be explicitly initialized, and the problem cannot
|> be solved without changing the declaration of Simple so such
|> initialization is allowed (if possible).
|> 
|> -steve

Can't it be initialized with a temporary which the compiler
may or may not optimize away?

	template<class T> Simple LessSimple<T>::s = Simple();

(Not that this makes the bug much less annoying.)

daniel
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: destruction of temporaries
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 21 Aug 1992 00:57:22 GMT

In article <TMB.92Aug19113657@arolla.idiap.ch> tmb@idiap.ch writes:
>In article <1992Aug18.205211.16789@Warren.MENTORG.COM> adk@Warren.MENTORG.COM (Ajay Kamdar) writes:
>
>   So why would the ARM consider the example with a temporary sufficient
>   reason to reject the "end of function" approach? To me it appears that
>   the "end of function" approach for temporaries would not cause any more
>   difficulties or program bugs than those that can already occur even without
>   temporaries. So why not reconsider that approach?
>
>I don't want my temporaries to hang around until the end of the
>function. I often use large temporaries (megabytes), and I see no
>reason why they should stick around any longer than I need them.
>
>Temporaries should get destroyed as soon as their value has been used.

	As ordinary rvalues, a value can only get used ONCE.
But as lvalues that isnt so:

	int i;
	(i=3)=4;

Here i gets assigned to twice. For ordinary objects this is always
meaningless, but for class based objects the assignment
could have arbitrary side effects. So I'm not so sure when
the 'value' has been used---it is not the value but the object
that is being accessed twice.

	s(i,j)="Hello";

Here the string s has operator()(int,int) applied to make a 
substring object to which an assignment is subsequently done,
and that assignment copies the string "Hello" into the string
s. S itself could sensibly be an expression ...

	print( (s1+s2)(i,j)="Hello" );

so now how long does (s1+s2) have to last? Or is the above
idiom bad news?

>
>The properties of temporaries are no different (and no worse) than the
>properties of automatic variables: pointers to them become invalid
>when the object disappears.

	When is that?
>
>If you want to be able to implement anything more powerful, you need
>(surprise!) garbage collection (as stated in the ARM, p. 268). 

	In other words, if you cant define a sensible
length of time for temporaries to hang around on a static basis,
then dont--define it dynamically.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         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: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Proposal: auto T&
Date: 21 Aug 92 02:07:14 GMT
Article-I.D.: alice.23508
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Aug20.213417.5690@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:

> >>	a = stringfunction( b ) + stringfunction( c );

> >What do you mean by "it's not reentrant"? Why not?

> *****>	Because the "slot" allocated in the caller would first receive
> 	the temporary generated by "stringfunction( b )" then it would
> 	be clobbered by "stringfunction( c )" and clobbered yet again by
> 	the temporary generated by operator+, assuming it also used this
> 	proposed technique.

Hardly likely.  The compiler had better allocate different memory locations
for stringfunction(b) and stringfunction(c) regardless of parallelism,
because otherwise how is it going to have them both around to hand
to operator+?

> 	The problem with that is, what does the compiler do if a
> 	function returning an auto& calls itself?

No problem: each function allocates memory for the values returned
by the functions it calls directly.  That set is always known at
compile time.

Of course, that's no different from what happens now with functions
that return ordinary objects when compiled with a compiler with just
a tiny bit of optimization.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c++
From: jrobie@netmbx.netmbx.de (Jonathan Robie)
Subject: Re: Return value for the constructors.
Organization: netmbx, Berlin, Germany
Distribution: usa
Date: Thu, 20 Aug 1992 07:18:53 GMT

pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:

>In <H575V1E@netmbx.netmbx.de> jrobie@netmbx.netmbx.de (Jonathan Robie) writes:


>>	complex* p = new complex(i++);
>>	if (p == 0)  // allocation failed!

>*****>	No; the allocator new() is returning zero, not the constructor.
>	Also, if the ctor further allocates it's own stuff, there is 
>	currently no clean way of returning that fact to the caller--
>	new() will return success, i.e., non-zero.

>>On page 61 he also states that initialization will only be done if the
>>return from the new is nonzero.

I was trying to say that you can at least check to see if the memory
allocation succeeded.  

-- 
Jonathan

===========================================================================

Newsgroups: comp.lang.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: named loops
Date: Sat, 22 Aug 1992 03:10:05 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

Reid Ellis <rae@Alias.com> writes:
|Arlie Davis <aldavi01@starbase.spd.louisville.edu> writes:
||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
|
|How about an int argument to "break", as supported in many scripting
|languages?  Add a similar argument to "continue" while we're at it.

I think the version with names would be clearer and less likely
to cause errors in reading.  Imagine that the break statement is in
the middle of one of those mammoth loops that contain 500 lines of
code - can you be sure you've counted the nesting levels correctly
so you know what the break is doing?  (Of course no one reading this
writes loops like that :-), but we've all seen them, right?)

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca