HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Downcasting (was: Re: run-time type checking)
Keywords: polymorphism, RTTI, downcasts.
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 16 Aug 1992 06:18:49 GMT

In article <1992Aug14.165432.14403@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
>> 		operator Derived1*() { return this; }
>> 	};

	Aslo,

	class Base {
		downcastable D1, D2;
	...
	
>
>The problem with this is that it requires explicit functions all over
>the place.  

	The second form requires it only in the base class.
(Downcastability is obviously inherited)

>It swells the interfaces (trust me, I've seen it used, even
>suggested it as the best possible in C++ today), swells the vtables, 

	If we use RTTI it doesnt impact the system beyond
what RTTI would anyway. 

>may
>thereby interefere with some language implementations, and makes the
>code brittle.
>
>But I like the idea of declarations in the derived type permitting or
>blocking an RTTI-based conversion.

	The problem with putting the permission in the derived class
is that it doesn't solve the original problem (if there was one)
that being able to downcast from a base violates the BASE classes
integrity.

	My premise is that the MOTHER of an object (the code
doing the 'new') knows the objects exact type (secret name),
and has control over who gets hold of it (when you 
know an objects secret name you have total power over it,
elementary principle of magic, and isn't programming just a 
form of magic :-)

	At this level, downcastability is easily controlled on
an object by object basis, the MOTHER making a list of
	{Base*, Derived*}
and passing the list to trusted confidants dynamically.
The declaration 'downcastable D' in the base class B is 
equivalent to puting the list in a static variable in the
base class--everone with access to the base is granted
permission to downcast to the nominated derived class,
which is now an integral part of the base classes interface.

	Other methods of passing around secret names include
tagged pointers, which have the advantage of static type
correctness that no other method has. Because of this
IMHO tagged pointers should be implemented anyhow, since they
are the best mechanism available when they actually do
the job (which is not always).


-- 
;----------------------------------------------------------------------
        TIM (TAL) LISTER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.lang.c++
From: pool@cs.utwente.nl (Sander Pool)
Subject: Problem with 'automatic' destructors
Keywords: destructor
Organization: University of Twente, Dept. of Computer Science
Date: Wed, 19 Aug 1992 12:58:47 GMT

hello,

I'm having a 'little' problem with destructors which are called
automatically when 'exit()' is called. For some reason the object
has turned to garbadge (e.g. the attributes have illegal values)
before the destructor is called. This results in funny/disasterous
situations. xdbx doesn't help much, when I trap the call to the
destructor and try to examine attributes he won't even show them.

The class structure looks like this (where Problem is the problem class):

class Problem {
public:
	~Problem(); // this gets called with a bogus object
};

class Super {
protected:
	Problem problem;
};

class Action: public xview_class, public Super;


I create an automatic instance of Action like this

Action	action;		// obvious :-)

and the somewhere in an eventhandler I call 'exit(0)'.


I'm at a total loss and hope someone can help me out. I
use cfront 2.1 on a Sparc.

thanks in advance and regards,
	
	Sander

******************************************************************
Sander O. Pool 		Twente University, 
			department of Computer Science 
			SETI group / TRESE project	H303
__________________________________________________________________
address:PO Box 217 		| misc.	phone 	+31-53-893715
	7500 AE Enschede 	|	fax	+31-53-356531
	The Netherlands 	|	email 	pool@cs.utwente.nl
******************************************************************



Newsgroups: comp.lang.c++
From: kestes@nswc-wo.navy.mil (Kent Estes)
Newsgroups: comp.lang.c++
Subject: Turbo C++ 3.0 : _loadds modifier doesn't work.
Date: 21 Aug 92 12:53:03 GMT
Organization: Naval Surface Warfare Center - White Oak

Has anyone noticed problems with the _loadds modifier in Borland's
Turbo C++ ?  I have code that will work correctly (with the _loadds)
if and only if called from within the same source file.  Otherwise,
if the call is from another file (i.e., (large data model) in
another data segment) the argument list gets trashed and the stack
gets messed up.
Newsgroups: comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: destruction of temporaries
Summary: When to allow copy constructors
Organization: :
Date: Fri, 14 Aug 1992 17:16:59 GMT

In article <rmartin.713716434@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
> bill@sunquest.UUCP (Bill Raves) writes:
 
> Giving the compiler access to the copy semantics of a class is a
> design decision which must be made carefully.  It should not be done
> in every case.  Many so called "cannonical forms" recommend the
> unquestioned inclusion of copy constructors and assigment operators.
> I disagree with this approach.  Copy semantics are often too complex
> to be allowed into general use.  
 
> Whenever you provide a regular copy constructor, you are granting
> permission to the compiler to make temporaries.  This must be a
> conscious choice, and must be supported by construction and
> destruction semantics which are valid in any context.

I'd like to offer some criteria to consider when making this decision.

The principle question, IMO, is `What are the relationships that the
object is involved with?'

If the object is involved with problem-domain relationships wherein the
object present in memory represents a cardinality-specific entity in the
problem, you cannot use a naive copy constructor and may not be able to
use any.  (e.g. you can't allow random copies of the object that represents
TheCEO, but you can allow any number of copies of the character array that
represents the CEO's name.)

If the object is involved with solution-domain relationships, and the
related objects lie entirely within the object (e.g. the real and
imaginary parts of a complex number) this relationship poses no
obstacle to copy construction.  But if the relationship involves objects
or entities (e.g. resources) outside the object (e.g. a String class
that allocates memory) either a special copy constructor is needed or
else no copy constructor is sensible.

Anyone who can express this more clearly and put it in a good textbook
deserves to make some money off it.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Garbage Collection for C++
Organization: Computer Science, University of Melbourne, Australia
Date: Mon, 17 Aug 1992 09:35:02 GMT

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.

OK, you're wrong, so I'll correct you :-)

The problem is that a pointer may be destroyed everytime you assign
a new value to a pointer variable.

Consider the following example:

	ListPtr p;
	...
	register int sum = 0;
	while(p) {
		sum += p->data;
		p = p->next;		// assign new value to pointer
	}

Now if p is simply a (ListNode *) then this will be very efficient.
If p is a pointer to a reference-counted list node, then each assignment

		ListNode *p;
		...
		p = p->next;

becomes something like this:

		struct RefCountedListPtr {
			int refs;
			ListNode *value;
		} *p;
		...
		if (p) {
			if (--p->refs == 0) {
				delete p->value;
			}
		}
		p = p->value->next;
		if (p) {
			p->refs++;
		}

So (at the very least) every pointer assignment now requires two additional
conditionals.

-- 
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: boehm@parc.xerox.com (Hans Boehm)
Subject: Re: Garbage Collection for C++
Organization: Xerox PARC
Date: 18 Aug 92 17:20:06 GMT

Some technical points:

daveg@synaptics.com (Dave Gillespie) writes:
>Also:  The trickiest part of a conservative GC like KCL's is checking
>whether a given word really is a valid pointer.  While this can be done
>fairly efficiently, it's still not lightning-fast; KCL has to do a
>modulo operation each time, for example.

>But the test for whether or not a pointer points *somewhere* in the
>GC-able zone of memory is trivial.  So if 90% of a program's allocation
>can use manual deletion, we can do that allocation in a different memory
>space and let the garbage collector do a trivial reject on 90% of
>the pointers (more or less).

This is highly system dependent.  In the latest versions of our collectors,
things may well be the other way around.  You generally can't assume
contiguity of the garbage collected heap.  You also don't really
want any bookkeeping information on the pages of the garbage collected
heap.  That way a page containing pointerfree objects is never touched
during a collection.  Neither is an entirely empty page.  Thus we find out
whether a page is in a GC-able zone by a lookup in a two-level tree.

Determining whether a pointer points to the beginning of a small object
doesn't really require a mod operation.  (We stopped doing that when
we moved to machines with a really slow mod operation.)  There are typically
a small number of distinct small object sizes.  You simply precompute
a layout map for pages for each size.  Thus the pointer validity check is
basically a single table lookup, once you have the page descriptor
form the two level tree.

In general, aside from anomalies like slow mod operations, I conjecture that
an important complexity measure for all of these algorithms is the number
of cache misses.  The amount of memory you have to read seems to matter
more than anything else.  (Ben Zorn's measurements suggest something
like this, but I have no conclusive evidence that the above is true.)

>>|>  (3) Even in a system with (conservative) GC, you can still return
>>|>      memory to the system using some form of unsafe "free" or "delete"
>>|>      (e.g., as provided by Boehm's collector).

>> Agreed, but there has to be some point in doing so. I see two possible reasons
>> for having an explicit delete:
>> ...
>> Any others?

>The best one (IMHO):

>Significant reduction in the number of GC's!  Again let's suppose 90%
>of our allocation can be deleted manually.  That means that, without
>doing any GC's, the amount of junk in memory grows only 10% as fast
>as with no deletion at all.  So, with GC's, it takes ten times as long
>to accumulate enough junk to cause another GC.

Presumably you're really worried about pause times, and frequency of pauses.
That's usually a valid concern, but in the presence of concurrent or
incremental collection, things become less clear.  Even in the presence
of generational collection, it may not buy you much if the short-lived
objects are the ones that are being handled manually.

Hans-J. Boehm
(boehm@parc.xerox.com)
From: ath@linkoping.trab.se (Anders Thulin)
Newsgroups: comp.lang.c++
Subject: Re: COOL C++ class library
Date: 21 Aug 92 12:56:50 GMT
Organization: Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden

In article <1031@ubbpc.tredydev.Unisys.COM> wgh@ubbpc.tredydev.Unisys.COM (Bill Hutchison) writes:

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

The symbolic links and the included libraries are not pretty, I can
agree with that.

However, the distribution does include the header files, and the
symbolic links are set up correctly during installation.  I just
installed GE_COOL from the distribution and tested it without any
problems.


-- 
Anders Thulin       ath@linkoping.trab.se 
Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden
From: jh@first.gmd.de (Joerg Heuer)
Newsgroups: comp.lang.c++
Subject: SNIFF C++ environment, what is it?
Keywords: SNIFF, C++ environment
Date: 21 Aug 92 11:21:39 GMT
Distribution: comp

In the recent issue of a german computer magazine, I read about an environ-
ment for development of C++ software, named SNIFF. Does anybody know/use
this and can tell about it. At least I'd like to know the company selling
it, so I could ask them for information.

Thanks in advance,
J"org.

Joerg Heuer                   | UUCP:     jh@gmdtub.uucp
GMD-FIRST an der TUB          | INTERNET: jh@first.gmd.de
Rudower Chaussee 5, Geb. 13.7 | KOMEX:    heuer@kmx.gmd.dbp.de
D-1199 Berlin Adlershof, FRG  | Tel/Fax:  +49 30 6704 - 5819/5610
--
Joerg Heuer                   | UUCP:     jh@gmdtub.uucp
GMD-FIRST an der TUB          | INTERNET: jh@first.gmd.de
Rudower Chaussee 5, Geb. 13.7 | KOMEX:    heuer@kmx.gmd.dbp.de
D-1199 Berlin Adlershof, FRG  | Tel/Fax:  +49 30 6704 - 5819/5610
From: wardrb@cs.utexas.edu (Richard Byron Ward)
Newsgroups: comp.lang.c++
Subject: Mac programming conventions?
Date: 18 Aug 1992 09:12:46 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: cs.utexas.edu

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?

Rick

P.S.  I am still looking for a tool to help me analyze the design
      of this code.
Newsgroups: comp.lang.c++
Subject: Help : Music File Formats.
From: ebolog@elaine.ee.und.ac.za (EDWIN BOLOGNA : THIRD)
Date: 20 Aug 92 13:00:25 +0200
Organization: Electronic Eng., Univ. Natal, Durban, South Africa


Does anyone out there happen to have PAS, C, or ASM source code to decode
.MOD, .SAM, .SND, or .ROL music formats.

Any information at all on any of these formats will be greatly appreciated.

        Desperate fellow programmer (And very Greatful for any information)

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

PS : Please be kind hearted and Assist !
Newsgroups: comp.lang.c++
From: eric@tfs.com (Eric Smith)
Subject: Proposal: auto T&
Organization: TFS
Date: Wed, 19 Aug 1992 23:49:13 GMT


Much recent discussion about destruction of temporaries suggests a
better way to solve the whole problem, and to allow returning references
to temporaries from functions.

auto String& stringfunction(const String& input)
{
   // Calculate/create a new temporary or named automatic String
   // and return a reference to it.
}

The "auto" in the function return value type tells the compiler to allocate
the space for that automatic in the stack frame of the caller, instead of
the stack frame of the called function.

The compiler can also do the same kind of thing implicitly within a function.
That is, allocate the space for each temporary in the outermost stack frame
containing references to it.  It doesn't need an explicit "auto" for that
because it can derive it during the compile.

Costs/benefits:  The compiler needs to do a little more work to handle auto T& 
and the auto might need to be accessed via a pointer because it might not be
possible for the compiler to know its stack offset at compile time.  The
benefits to the programmer might be a lot bigger than the obvious benefits
seem at first.  Beginning C++ programmers almost aways complain about the
problems caused by lack of this functionality, which they almost always
intuitively assume without even thinking about the implications.  A lot of
function interfaces would become much neater.  A lot of the complaints about
lack of garbage collection are really motivated by lack of this functionality.
Newsgroups: comp.lang.c++
From: pjl@sparc6.cs.uiuc.edu (Paul Lucas)
Subject: Re: Question: Complex Arrays
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 17 Aug 1992 14:09:46 GMT

In <92230.130533K3006E7@ALIJKU11.BITNET> <K3006E7@ALIJKU11.BITNET> writes:

>I am new to C++ so please forgive me if these questions are irritatingly
>elementary.  But if anyone could offer suggestions or answers, I would
>greatly appreciate it!

>In my program, I already have included <complex.h> that comes with
>the C++ package.  But when I try to create an array of complex numbers,
>the compiler issues an error.  How does one declare a complex array?

	complex foo[4];
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: BCC: virtual function calls from constructor/destructor
Organization: TauMetric Corporation
Date: Mon, 17 Aug 1992 17:17:30 GMT

nwatson@enuxha.eas.asu.edu (Nathan F. Watson) writes:


>I ran into a problem with virtual functions today when using my
>new C++ compiler (Borland C++ 3.1).

>The scenario is as follows:
>   * classes A and B are defined, and B is derived from A;
>   * A's constructor calls a virtual function A::vfunc().  B::vfunc()
>     is also defined.

>An unexpected (though perhaps not unreasonable) thing happens when I
>try to construct an object of class B.  A::A() is called first, which
>then calls the virtual function A::vfunc().  I would expect use of
>B::vfunc().  However, A::A() calls A::vfunc().

That is exactly what is supposed to happen.

When you construct an object of type A, only A's members are available.
No object of derived type yet exists, so no derived-class member
functions could be called (without an explict cast).

A simple pragmatic explanation:  Suppose the derived-class function
depends on derived-class data which is not yet available.  No good
could come of calling that function from a base-class constructor!

The same rule applies to destructors.  During the destruction of an
object, the derived classes are destroyed before the base classes.
During execution of base-class destructors, no derived data or
functions are available.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: mra@searchtech.com (Michael Almond)
Newsgroups: comp.lang.c++
Subject: Re: Precompiled headers in Turbo C++ 3.0
Date: 18 Aug 92 15:31:23 GMT
Organization: Search Technology, Inc.

In article <1992Aug15.045015.42365@kuhub.cc.ukans.edu> jeff@kuhub.cc.ukans.edu (Jeff Bangert) writes:
>What I know so far: include files must be in DECREASING order of size.

Hmm, I have not found this to be of any importance.

>But, when I build a library, with my own .h file, and my own .h file
>includes some .h files, then precompiled headers may or may not work.

They should, my do.  On thing I do is create a standard header file for 
each type of source file (file maintenance, records, file I/O, reports, etc).
Then include on this on file at the top of a module followed by #pragma 
hdrstop.  After the #pragma I include all the special *.h for the module.

>Since precompiled headers speed up compiles quite a bit, I really like
>them, and it's frustrating when they don't work.

Yes they do speed things up, however they work best when you have the
same set of headers marked for pre-compile across several modules.
-- 
Michael R. Almond (Georgia Tech Alumnus)          mra@srchtec.uucp (registered)
computer alli, inc.					    mra@searchtech.com
6000E dawson blvd.	      				    uupsi!srchtec!mra
norcross, georgia 30093				        (404) 840-1002 (office)
Newsgroups: comp.lang.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: named loops
Organization: TauMetric Corporation
Date: Sat, 22 Aug 1992 17:15:35 GMT

Reid Ellis <rae@Alias.com> writes:

>How about an int argument to "break", as supported in many scripting
>languages?  Add a similar argument to "continue" while we're at it.

This gets proposed every few months.  It makes a maintenance nightmare,
since changes in nesting change the semantics of the break with no
warning.  If you are very lucky, the break level will become illegal
and the compiler will complain.  More likely the wrong loop will be
exited -- a bug which may be hard to find, or which might not even
show up in testing.

A named loop would not have this problem, assuming loop names are like
statement labels.  I also agree that named loops are more structured
than using ordinary labels and gotos.  Nevertheless, I don't believe
there is any chance that named loops will be added to the language.
The main reason, as I see it, is that it adds no functionality and no
notational convenience to the language.  Compare:

	while loop1 (...) { ... break loop1;   ... }
	while       (...) { ... goto endloop1; ... } endloop1:

	while loop2 (...) { ... continue loop2; ...         }
	while       (...) { ... goto loop2;     ... loop2:; }
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.lang.c++
Subject: Re: References as class members
Date: 17 Aug 92 18:19:30 GMT
Distribution: comp
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

lvi@ida.liu.se (Lars Viklund) writes:
: 
: Is the following class declaration legal?
: 
: class X {
:     X& r;
: };

Two relevant (and contradicting!) quotes from the ARM:

(p291, about initializers)

	"This is the only way to initialize nonstatic const and
	reference members.",
	which implies that reference members must be initialized
	in conjuction with a constructor.

(p151, about aggregate initialization)

	"An aggregate is an array or an object of a class with no
	constructors, no private or protected members, no base classes,
	and no virtual functions".

G++ (version 1.40.3) seems to give p151 precedence, whereas CFront
takes p291 literally.

With g++ you must explicitly initialize the "r" member, like this
   X x = { x };

Similarly, CFront and g++ disagrees on the legality of the following:
   struct S { const int i; } s = { 3 };

The g++ interpretation may seem reasonable, but it does contradict
a third quote from the ARM (p264):

"A default constructor will be generated [only] if no constructor
 has been declared for class X",

which in this case is impossible to do for class X (there is no
reasonable default value for member "r").


So I guess the answer is "no", after all.

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