HDTenEightyP/NetNews huggingface dataset:
From: mlanett@Apple.COM (Mark Lanett)
Newsgroups: comp.lang.c++
Subject: Re: Mac programming conventions?
Date: 18 Aug 92 18:34:40 GMT
Organization: Apple Computer Inc., Cupertino, CA

wardrb@cs.utexas.edu (Richard Byron Ward) writes:

>I am trying to analyze a large body of C++ code right now and
>there are comments interspersed through it that simply
>say: /* T */

>They are generally placed before member definitions (same line),
>but I can't figure out what the T stands for.  This reminds me of
>a variable naming convention that I heard about on the Macintosh,
>but this program is written to run on Unix.  Can anyone shed some
>light on these mysterious Ts?

There is a convention that class names begin with T, for Type, because of the
Object Pascal origin of the larget-used class library on the Mac. I'll bet
someone decided they didn't like hand-mangling their class names and did a
search-and-replace on them...
-- 
Have a bajillion brilliant Jobsian lithium licks.
Mark Lanett, NOT speaking for anyone. Personal opinion only.
Newsgroups: comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Borland Australia?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 13 Aug 1992 15:26:21 GMT

In article <1992Aug12.010917.4620@csuvax1.csu.murdoch.edu.au> wai@csuvax1.csu.murdoch.edu.au (Julian Wai) writes:
>Hi,
>
>Does anyone know Borland Pacific Australia's phone number?  I've tried
>dialing the number printed on my registration card, but the operator said
>the number has been disconnected.
>

	Borland International
	02-953-9500

	Ask for Jordan for tech support, he's very good.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: kazi@chopin.udel.edu (Zunaid Kazi)
Newsgroups: comp.lang.c++
Subject: Problem: Viewing intermediate C in Borland C++?
Date: 21 Aug 92 13:09:21 GMT
Organization: University of Delaware

Is it possible to view the intermediate C files in Borland C++,
like the +i option for CC?

Thanks,
Zunaid Kazi
kazi@cis.udel.edu
Newsgroups: comp.lang.c++
From: pkturner@world.std.com (Prescott K Turner)
Subject: Re: destruction of temporaries
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 14 Aug 1992 14:53:38 GMT


Bill Raves writes:
> For example, Jim Adcock has suggested
> (<70784@microsoft.UUCP>) "NEVER rely on unnamed temporaries to do
> anything...", but this would seem to erode the expressiveness of the
> language: constructs like "foo(x + y)" and "foo()[i]" would no longer
> be permissible. 

I second Adcock's advice.  Actually, those constructs can be made to
work at the expense of some extra implementation effort, and some
execution cost.  But the cost is not an impediment if it's being compared
to code which is not portable to the platforms one needs.

What the programmer must beware (in the absence of garbage 
collection) is pointers and references that refer to unnamed objects.
The standards committee may eventually mandate that these objects 
hang around somewhat longer, but not indefinitely.
Classes which rely on such pointers entail pitfalls.  Late destruction
of temporaries (as in cfront) reduces but does not eliminate
the problem.
--
Prescott K. Turner, Jr.
13 Burning Tree Rd., Natick, Massachusetts USA
Internet: pkturner@world.std.com
Newsgroups: comp.lang.c++
From: jonas@beppe.ericsson.se (Jonas Nygren)
Subject: Re: destruction of temporaries
Reply-To: jonas@beppe.ericsson.se
Organization: Ericsson Telecom AB
Date: Mon, 17 Aug 1992 07:35:00 GMT


In article 49v@world.std.com, pkturner@world.std.com (Prescott K Turner) writes:
> 
> Bill Raves writes:
> > For example, Jim Adcock has suggested
> > (<70784@microsoft.UUCP>) "NEVER rely on unnamed temporaries to do
> > anything...", but this would seem to erode the expressiveness of the
> > language: constructs like "foo(x + y)" and "foo()[i]" would no longer
> > be permissible. 
> 
> I second Adcock's advice.  Actually, those constructs can be made to
> work at the expense of some extra implementation effort, and some
> execution cost.  But the cost is not an impediment if it's being compared
> to code which is not portable to the platforms one needs.
> 
> What the programmer must beware (in the absence of garbage 
> collection) is pointers and references that refer to unnamed objects.
> The standards committee may eventually mandate that these objects 
> hang around somewhat longer, but not indefinitely.
> Classes which rely on such pointers entail pitfalls.  Late destruction
> of temporaries (as in cfront) reduces but does not eliminate
> the problem.

IMO temporaries should survive until end of statement. At least they should not be destroyed
as early as in gcc-2.x. In C you can write:

	X *p;
	a = (p+10)->f();

where (p+10) will survive through the call. In gcc-2.x I wrote a small string class which had
a member function 'string sub(int pos, int len)' which results in a temporary. I could do

	s2 = s.sub(2,3);

but not

	s2 = s.sub(2,3).strip();

because the temporary representing 's.sub(2,3)' was destroyed before tmp.strip(). This is kind of
confusing. 

So let temporaries live until end of statement.

> --
> Prescott K. Turner, Jr.
> 13 Burning Tree Rd., Natick, Massachusetts USA
> Internet: pkturner@world.std.com



/jonas
From: Eric.Price@FtCollins.NCR.com (Eric.Price)
Newsgroups: comp.lang.c++
Subject: Re: error in Stroustrup text      (?)
Date: 12 Aug 92 12:12:43 GMT
Reply-To: Eric.Price@FtCollinsCO.NCR.com
Organization: NCR Microelectronics, Ft. Collins, CO
In-reply-to: weeks@hpscit.sc.hp.com's message of 11 Aug 92 19:00:10 GMT

>>>>> On 11 Aug 92 19:00:10 GMT, weeks@hpscit.sc.hp.com (Greg Weeks) said:

Greg> Someone please correct me if I'm mistaken, but the following text from pg
Greg> 216 of Stroustrup's 2nd edition C++ text seems to be wrong:

Greg>     If you want to supply an allocator/dealocator pair that works correctly
Greg>     for derived classes, you must either supply a virtual destructor in the
Greg>     base class or refrain from using the size_t argument in the
Greg>     deallocator.

I suspect Dr Stroustrup's unstated assumption is that a deallocator
which does not use the size_t argument accesses the size of the
allocated memory from a location where the allocator has secretly
squirreled it away. (That information might include the initially
allocated address, if polymorphic MI is supported by the allocator.)

Greg>     _Whenever_ a derived class object may be deleted through a pointer to base
Greg>     object, a virtual destructor is required.  It does not suffice to refrain
Greg>     from using the size_t argument in the deallocator.  The reason is that
Greg>     `delete' needs to know both the size _and_ the location of the thing to be
Greg>     deleted; and the location of the derived object may differ from the
Greg>     location of the base object.  (That is, it may be that (void*)pd is
Greg>     different from (void*)pb.)

The section you reference does not discuss multiple inheritance. Given
single inheritance, (void*)pd would equal (void*)pb.

-Eric
--
Eric Price, Software Architect, Computer Aided Design
NCR Microelectronic Products Division
2001 Danfield Court; Ft. Collins, CO 80525
(303) 223-5100 x471; FAX: 226-9556; EMAIL: Eric.Price@FtCollinsCO.NCR.COM
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Garbage Collection for C++
Date: 18 Aug 92 20:58:33 GMT
	<TMB.92Aug16164940@arolla.idiap.ch>
	<1992Aug18.021453.24394@news.mentorg.com>
	<TMB.92Aug18123919@arolla.idiap.ch> <9223122.20958@mulga.cs.mu.OZ.AU>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: fjh@munta.cs.mu.OZ.AU's message of 18 Aug 92 12:05:19 GMT

In article <9223122.20958@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

   tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

   >Conservative GC with a "free" function is a safety net. If you don't
   >run out of storage, you don't know it's even there. If you do run out
   >of storage, it lets your program continue to run when it would
   >otherwise have crashed. Whether you want to rely on this feature is up
   >to you, but, in general, I can see no harm in having it in the
   >language...

   This presumes that you will only perform garbage collection when there
   is *no* more storage available.
   [...]
   It is therefore essential that a GC version of malloc() sometimes perform
   garbage collection even though there is still (virtual) memory available.
   The question is, how can we do this in a way that does not impact poorly
   on the performance of programs that do mostly manual allocation?

I was responding to someone who claimed that GC cost him something
just by being present in the language and applicable to all pointers.

If you force concurrent or premature GC on the programmer, the feature
will cost you something even if you don't use it. While I am for GC, I
would be against that; by default, the GC should only be invoked once
there is no more memory(*).

Of course, there must exist the usual options to set GC aggressiveness
(e.g., telling the GC to try to maintain a fixed ratio of live data
and free space), and, maybe, even to run the GC concurrently with the
C++ program.

						Thomas.


(*) 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.
Newsgroups: comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: Proposal: auto T&
Organization: University of Illinois at Urbana-Champaign
Distribution: usa
Date: Fri, 21 Aug 1992 04:13:54 GMT

In <171m8oINNdu7@early-bird.think.com> barmar@think.com (Barry Margolin) writes:

>In article <1992Aug20.213417.5690@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
>>In <9223406.29682@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>>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 )" 

>I think the rest of us understood that enough temporaries would be
>allocated so that there would be no clobbering.

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

>That's what stack frames are for.  Each stack frame for the function would
>contain space for all the temporaries that are returned.

>The easiest way to understand this is to transform the program into a
>version where the temporaries are explicit.  Thus,

>	String a, b, c;			// also assume + has been overloaded
>	// ...
>	a = stringfunction( b ) + stringfunction( c );

>is equivalent to:

>	String a, b, c, temp1, temp2;
>	// ...
>	temp1 = stringfunction(b);
>	temp2 = stringfunction(c);
>	a = temp1 + temp2;

>Your claim of non-reentrancy suggests that you think the temporaries would
>be static, not automatic.

*****>	You're right; I stand corrected.  What I was thinking was that
	the return-value _always_ was in the first caller of a recursive
	calling sequence; I forgot to make the mental leap where yet
	another slot would be created in the next stack frame just like
	everything else.

	Apologies for any confusion.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c++
Subject: Re: Pointers to member functions
Summary: FAQ Part17, get CPL2
Date: 12 Aug 92 23:58:24 GMT
Organization: The University of Texas at Austin; Austin, Texas

In article <1992Aug9.230153.16147@organpipe.uug.arizona.edu> dave@cs.arizona.edu (Dave Schaumann) writes:
>[...]
>While this behavior does make sense (you shouldn't be able to call a
>member function as if it were a "normal" function), it also means that class
>member functions behave in a way quite different from "normal" functions.

Exactly!

>	class Foo {
>	public:
>	   void print();
>	   ...
>	};
>[...]
>	1. Just what is the type of the expression "foo.print"?
>	   (as in the above context)

I guess you could say its type is "member function pointer", but C++
is very strict on the syntax for m.f.p.'s.  Let's just say that the
type of the expression "&Foo::print" is "void (Foo::*)(void)" -- a
member function pointer.

	void (Foo::*mfp)(void); // 'mfp' is a pointer to a Foo member function
	                        // that returns 'void' and takes no params
	mfp = foo.print;    // syntax error
	mfp = &foo.print;   // syntax error
	mfp = Foo::print;   // syntax error
	mfp = &Foo::print;  // correct
	
As you realized, you cannot invoke a member function pointer as you
would invoke a regular function pointer.  You must call it "on" an
object.  The syntax is:

	Foo* fooptr;
	Foo foo;
	...
	(fooptr->*mfp)();  // call the member func pointed to by mfp on fooptr
	(foo.*mfp)();  // call the member func pointed to by mfp on foo

Note, the extra set of parens are necessary because of precedence
rules.  Also note that you must always use the "->*" or ".*" operators
when invoking a member function pointer, even inside a member function
('this' is *not* assumed).

	void Foo::call() {
	   void (Foo::*mfp)(void) = ...;
	   mfp();           // syntax error (doesn't assume call 'mfp' on this)
	   (this->*mfp)();  // correct
	   Foo& self = *this;
	   (self.*mfp);     // also correct
	   }

See the comp.lang.c++ FAQ Part17 (ftp sun.soe.clarkson.edu,
pub/C++/FAQ) for more information about member function pointers (btw,
there's also data member pointers) and other, more important,
features of C++ (like templates).

>	2. I guess I really need to get a technical book on C++,
>	   preferrably one that is written in an accessable way.
>	   What's my best choice?

Don't write C++ without Stroustrup's _C++ Prog. Lang. 2nd Ed_.  It
contains the reference part of the _Annotated C++ Ref. Manual_ (the
ANSI C++ committee base document).  It does not contain the ARM's
commentary, which you'll want if you really want to know why certain
language decisions were made or want more clarification on the
nitty-gritty details of C++.

Jamshid Afshar
jamshid@emx.utexas.edu
From: Eric.Price@FtCollins.NCR.com (Eric.Price)
Newsgroups: comp.lang.c++
Subject: Re: error in Stroustrup text      (?)
Date: 12 Aug 92 11:58:25 GMT
Reply-To: Eric.Price@FtCollinsCO.NCR.com
Organization: NCR Microelectronics, Ft. Collins, CO
In-reply-to: weeks@hpscit.sc.hp.com's message of 11 Aug 92 19:00:10 GMT

>>>>> On 11 Aug 92 19:00:10 GMT, weeks@hpscit.sc.hp.com (Greg Weeks) said:

Greg> Someone please correct me if I'm mistaken, but the following text from pg
Greg> 216 of Stroustrup's 2nd edition C++ text seems to be wrong:

Greg>     If you want to supply an allocator/dealocator pair that works correctly
Greg>     for derived classes, you must either supply a virtual destructor in the
Greg>     base class or refrain from using the size_t argument in the
Greg>     deallocator.

I suspect Dr Stroustrup's unstated assumption is that a deallocator
which does not use the size_t argument accesses the size of the
allocated memory from a location where the allocator has secretly
squirreled it away.

-Eric
--
Eric Price, Software Architect, Computer Aided Design
NCR Microelectronic Products Division
2001 Danfield Court; Ft. Collins, CO 80525
(303) 223-5100 x471; FAX: 226-9556; EMAIL: Eric.Price@FtCollinsCO.NCR.COM
Newsgroups: comp.lang.c++
From: feustel@netcom.com (David Feustel)
Subject: Re: Help : Extended and Expanded Memory
Date: Thu, 20 Aug 92 23:49:38 GMT
Organization: DAFCO: OS/2 Software Support & Consulting

ebolog@elaine.ee.und.ac.za (EDWIN BOLOGNA : THIRD) writes:


>Does anyone out there happen to have PAS, C, or ASM source code that is
>able to access Extended or Expanded memory. This computer has got Three Mbytes
>Extended memory and I am unable to use any of it in my programs.

>Any information at all on this will be greatly appreciated.

>        Desperate fellow programmer (And very Greatful for any information)

>                E.B. (EBOLOG@ELAINE.EE.UND.AC.ZA)

Get OS/2 v2.0. All three kinds of memory are supported by the OS with
no further work by you.
-- 
Dave Feustel N9MYI <feustel@netcom.com>
---
Given Civil Seizure, from the DEA's point of view, winning the War on
Drugs would be killing the Goose that lays golden eggs.

The Drug War is a government-sponsored, taxpayer-financed,
full-employment program for psycho/socio-paths, wannabees and
gonnabees.
From: pjl@sparc6.cs.uiuc.edu (Paul Lucas)
Newsgroups: comp.lang.c++
Subject: Re: pointer to member functions question
Date: 17 Aug 92 21:14:32 GMT
Organization: University of Illinois at Urbana-Champaign

In <hons.714103910@rkw-risc> hons@rkw-risc.cs.up.ac.za (Honneurs Studente) writes:


>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 

*****>	No, you can't.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: nandraj@unisql.UUCP (Nandraj Arni)
Newsgroups: comp.lang.c++
Subject: Re: Return values for constructors.
Date: 19 Aug 92 14:10:22 GMT
Reply-To: nandraj@unisql.UUCP (Nandraj Arni)
Organization: UniSQL, Inc., Austin, Texas, USA

n
>
>>   Why does C++ not let you have a return value for a constructor?
>>Is there any rationale behind this?
>
>*****>	Because there's nothing for it to return.  A c'tor is s'posed to
>	turn raw memory into an object.  Period.
>
>	Anyway, where would the return value _go_?
>
>	class Foo {
>		int Foo( ... ) { ... return expr; }	// hypothetical
>	};
>
>	Foo x(...);			// no use for a return-value here
>	Foo *p = new Foo(...);		// nor here; the address is returned


   One way would be like this:

   Foo *p;

   int return_value = new p(...); // not allowing Foo *p = new Foo(...);
				  // This could be invalid assingment...

 
   And for others:
 
   float value;        // This does not have a value, even objects
		       // should be like that.


   So other way would be:

   Foo p;

   int return_value = p(...);



   

-- 
*******************************************************************
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
*******************************************************************
From: rgp@mpd.tandem.com (Ramon Pantin)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 21 Aug 92 02:54:45 GMT
Organization: Tandem Computers, Micro-Products Division

In article <1992Aug20.190313.3407@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>In article <TMB.92Aug20142610@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
>
>|> Let me put in another vote for leaving things the way they are.
>|
>
>There may be some confusion about where we are now. The ARM (and the
>x3j16 working paper) give compilers a lot of freedom about where
>to destroy temporaries. 
>
>This is generally considered unsatisfactory because it means
>that programs frequently break when move between compilers with
>different strategies.   If all compilers were making the same
>or similar choices in this area x3j16 could just standardize that
>decision. The reason this didn't happen is that there are good arguments
>for a variety of different strategies. 

I've got a simple (poor man's?) solution to this problem:

	Let the compiler destroy temporaries as soon as it wishes
	to do so, with the exception of objects for which a member function
	that has been declared with a new keyword (say "longlived")
	_might_ have been executed, in which case the object persist
	until the end of the function (or some other convenient
	place for destruction).

	Member functions that return pointers or references to their
	internal data structures would be declared as "longlived".
	The "_might_ have been executed" above would allow enough
	freedom to the compiler implementation to make choices such as:

		- Add some logic to the compiler to determine if
		  any of the "longlived" methods are invoked (maybe
		  even some flow control analysis could be done).

		- Always destruct objects that have any member function
		  that is "longlived" at the end of the function even
		  if none of them are invoked in the body of the function.
		  (Maybe classes themselves could be declared as "longlived")

What do you think? 

Ramon Pantin
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Handling of operator . pro
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 14 Aug 1992 04:38:15 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>In article <9222523.7061@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>Also you have to learn the advanced feature every time you are maintaining
>>code that used it, even if that code could have been written using only
>>simpler features.
>
>	I'm not so sure. Why is it harder to learn a properly conceived
>language facility than to learn someones emulation of that facility
>in reams of code? Sure you can read the code and deduce what it does,
>but you are basically saying language manual writers ought to
>write their manuals in C not english.
>
>	[BTW: I sometimes think this!]

One example is reference arguments. Without reference arguments, you know that
a call like f(x) will not modify x [*]. In C++, even if YOU don't use reference
arguments, you still have to check the declaration of f to be sure, because
you don't know whether the writer of f did.

	[*] Sure, things are different for macros / array arguments, but
	    the point remains.

Here's another example: consider this hypthetical extension to C++ enum's.

	enum<<2 Bar {		// better use an operator (<<) rather than a
		Fee,		// keyword, to make things more confusing :-)
		Fie,
		Foe,
		Fum
	};

Now this might be useful and convenient in some circumstances, but it adds to
the complexity of the language and is yet another construct to remember.
Instead you could just use standard C++ to achieve the desired effect, albeit
slightly more verbosely:

	enum Bar {
		Fee = 0x01,
		Fie = 0x02,
		Foe = 0x04,
		Fum = 0x08,
	};

Generally if a facility does provide a *large* reduction in the complexity
of programs that need it, then it's not worth it.

>>I shouldn't have said PL/1 (I have never learnt that language, I was just
>>repeating what I have heard and read). Instead I should have said C++ :-)
>>
>
>	Some people complain about complexity of learning C++.
>Bull. They have not traded off the advantages as compared to C.

If there's one thing that C++ does well, then that thing is making C obsolete.
For C++, the competition will come from languages that are more powerful
yet less complex; as Bjarne has said, C compatability is C++'s biggest strength
and also its biggest weakness.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature VIRUS is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)