HDTenEightyP/NetNews huggingface dataset:
From: shang@corp.mot.com
Newsgroups: comp.lang.c++
Date: 17 Jul 92 18:39 MDT
Subject: Re: array classes (Re: Novice? ques
Nf-ID: #R:rmartin.711308202@thor:-237329595:1992Jul17.143928.15719@cadsun.co:-2069152803:001:1309
Nf-From: corp.mot.com!shang    Jul 17 18:39:00 1992


In article <TMB.92Jul16235255@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M.  
Breuel) writes:

> Inheritance and virtual functions provide polymorphism that is, in
> many ways, much more limited than what you get via templates. The
> difference is that virtual functions are around at runtime, while
> polymorphism-via-templates (usually called "genericity" in the C++
> world) can only take advantage of type information at compile time.
> 

I disagree in three points:

1. It is not true that the polymorphism achieved by dynamic binding is much  
more limited than the polymorphism achieved by static binding.

2. It is not true that the polymorphism-via-templates can only take advantage  
of type information at compile time. Parameterized classes are not necessarily  
a static instanciation mechanism. They can be implemented as a dynamic feature  
to support dynamic polymorphism (dynamic binding).

3. It is not true that the templates can substitute the inheritance even the  
templates can support dynamic binding. As I already memtioned in my previous  
poster, inheritance support code reuse through expanding the previous defined  
part while parameterized classes support code reuse through specializing the  
previous defined part. They cannot be substituted with each other. 

David Shang


Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)
Distribution: world
Subject: Re: run-time type checking)
X-Mailer: cppnews $Revision: 1.10 $
Organization: Trumphurst Ltd.
Date: Fri, 31 Jul 1992 11:33:16 +0000


In article <TMB.92Jul29125322@arolla.idiap.ch> tmb@idiap.ch writes:
> It would, in fact, be nice if C++ had a tagged union type, like Pascal
> or SML. Something along the lines of:
> 
> union hetero int {
> case 1: type1 *p1;
> case 2: type2 *p2;
> };
> 
> int f(hetero h) {
> 	switch(h) {
> 	case 1: return h.p1->foo();
> 	case 2: return h.p2->bar();
> 	}
> }
**** YEEEUUUURRRGGGGHHHH *****
Surely this is what virtual functions are for.
---
Nikki Locke              |                        | nikki@trmphrst.demon.co.uk
Trumphurst Ltd.          | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
PC and Unix consultancy  | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
trmphrst.demon.co.uk is NOT connected with ANY other sites at demon.co.uk.
Demon.co.uk is a dial-up subscription access point to the Internet.
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.lang.c++
Subject: Re: const on pass by value
Date: 29 Jul 92 16:55:53 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

In article <1992Jul27.154311.26719@cdsmn.mn.org> wells@cdsmn.UUCP (Rich Wells) writes:
>In article <9220801.5026@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>mat@uunet.uu.net!mole-end writes:
>>
>>>In article <1992Jul24.151010.11969@PacBell.COM>, pjcondi@lepton (Paul Condie) writes:
>>>> Should pass by value arguments be declared as "const" for
>>>> good coding style?  Or is that nit picking?
>>> 
>>>> For example:
>>> 
>>>> void foo (const int a);
>>>> or
>>>> void foo (int a);
>>>
>>>It's not nitpicking.  It's part of something called const correctness.
>>>Your program has it or doesn't.  Programs that have it are almost immune
>>>to a certain large family of errors.
>>
>>Huh? In this example, it IS just nitpicking.
>>How could the presence or absence of const in the declaration for foo
>>affect the program's const correctness?
>>
>
>Consider this case:
>
>void bar(int & a)
>{
>}
>
>void foo(const int a)
>{
>   bar(a);
>}
>
>Should the compiler allow the call to bar() from foo()?  I think not.
>I'm still a relative newcomer to C++ but it seems to my this is an
>example of where  the presence or absence of const in the declaration
>of foo DOES affect the program's const correctness.

	No, it is the const in the DEFINITION that is important here.

	The definition

void foo(int a) { ...}

	is clearly different to foo above.

	But the corresponding declarations

	foo(int);
	foo(const int);

are ambiguous, they cannot be distinguished.

-- 
;----------------------------------------------------------------------
        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: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: mating dogs and cats (Re: run-time type checking)
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 29 Jul 1992 17:31:49 GMT

In article <TMB.92Jul28121957@arolla.idiap.ch> tmb@idiap.ch writes:
>In article <1992Jul23.154254.5306@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>   The problem is why you proposed 'thisclass' and is a real problem.
>   It is a problem for which RTTI is the wrong solution,
>   but never-the-less is the best we will get for a while.
>   We really need multiple dispatch.
>
>   class Animal {
>	   int mate(Animal&);
>   };
>   class Dog : Animal {
>	   int mate (Animal&);
>   };
>
>   We REALLY want Dog::mate(Dog&), but we cant have it.
>
>I don't see the problem.
>
>class Animal {
>	virtual int mate(Animal &) = 0;
>	virtual int mate_dog(Animal &other) {error("not a dog");}
>	virtual int mate_cat(Animal &other) {error("not a cat");}
>};

	You clearly DONT see the problem. You do not understand the
open/closed principle. The problem with the definition of Animal
above is that it is not OPEN. you cant make the mechanism work
if you add RAT without modifying Animal. That is a violation
of the open/closed principle. 

A base class must be CLOSED
so that it can be compiled and the inteface frozen, even the
source code thrown away for the definitions. Algorithms
defined for the base class can be written, and compiled,
and type checked WITHOUT knowledge of the derived classes.
The closure of the base should  guarrantee that.
(Which is why I am suspicious of downcasting).

A base class must be OPEN to extension by derivation.
Arbitrary extension. AND in particular 'arbitrary'
means not only that you can add any new derived classes
you choose, but also that you can OMIT any you choose.
Downasting voids that guarrantee.

Virtual functions achieve this. They are closed in the base.
They are still open to overriding in the derived class.

Unconstrained Downcasting voids both the open-ness and the closedness.
Without the open closed principle assured by the language,
polymorphism is flawed and the system is unsound.

Indeed CASTING of any kind (changing the type of something)
is unsound. Upcasting is sound because a derived
'isA' base, so you are not changing the type,
just forgetting some details.

-- 
;----------------------------------------------------------------------
        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: richieb@bony1.bony.com (Richard Bielak)
Subject: Re: reference to C++ assertion macro package?
Summary: ET++ exists
Keywords: C++, assertions, precondition, postcondition, invariants
Organization: multi-cellular
Date: Thu, 30 Jul 92 18:59:09 GMT

In article <18760@drutx.ATT.COM> weh@abasin.dr.att.com (William E. Hopkins) writes:

[...]

>Annotated C++ (a.k.a. A++) appears to provide much of the same capability as
>the pre- and post-conditions and invariants in Eiffel (as I mentioned in my
>original posting).  A++ defines a notation and provides a preprocessor to
>make it happen.
>
>I'm still waiting for a response from a reference librarian on the two A++
>references I posted earlier.  Since one of the authors is Doug Lea of
>libg++ fame, maybe he knows of other papers on A++ that are more accessible
>(I tried the GNU documents that come with Lynx/OS on the off-chance it would
>be there...no luck!).
>

ET++ was described in JOOP. I'm afraid I can't find the issue right
now, but I think it was sometime within last year. 

ET++ was a preprocessor that allowed you to add Eiffel-style pre- and
post-conditions.

I'm not sure what happens to the assertion in derived classes. In
Eiffel pre-conditions can only be weakened and post-condition
strengthened in a child class.


...richie



-- 
* Richie Bielak   (212)-815-3072   | "Your brain is a liquid-cooled parallel  *
* Internet:       richieb@bony.com | super-computer". He pointed to his nose, *
* Bang {uupsi,uunet}!bony1!richieb | "This is the fan."                       *
*    - Strictly my opinions -      |                     - David Chudnovsky - *
From: smneyln@ariel.lerc.nasa.gov
Newsgroups: comp.lang.c++
Date: 17 Jul 92 22:00 MDT
Subject: Is this call necessary?...
Nf-ID: #N:17JUL199213004515@ariel.lerc.nas:1576324756:001:881
Nf-From: ariel.lerc.nasa.gov!smneyln    Jul 17 22:00:00 1992


I have classes defined as such:
class A {
..
};

class B : public A {
private:
	a *a;
..
};

Now, at some point in the program, I need to modify some of the values of
the A member refenenced by B.  To do so, I have the following private
function in B:

A GetAMember() {return *a;};

My question is: If then have: A amember = bmember.GetAMember, can I
assume that changes made in amember will be also done in a->a? Or do i need
a put function as void PutAMember(A amember) {a = &amember); ?

Thanks...


Mike Neylon          aka Masem the Great and Almighty Thermo GOD
  // Only the | Univ. of Toledo - Chemical Engineering - Senior
\X/   AMIGA!  |   NASA Lewis Research Center - Summer Intern
\_____________|_____smneyln@ariel.lerc.nasa.gov________________/
       -+ How do YOU spell 'potato'?  How about 'lousy'? +- 
      "Me and Spike are big Malcolm 10 supporters."-J.S.,PLCL

Newsgroups: comp.lang.c++
From: epp@mala.bc.ca (Lorne Epp)
Newsgroups: comp.lang.c++
Subject: Re: HELP with overloading binary operator...
Date: 28 Jul 92 14:21:21 -0700
Organization: Malaspina College

In article <28JUL199210114546@ariel.lerc.nasa.gov>, smneyln@ariel.lerc.nasa.gov (Michael Neylon) writes:
> I have the following class...
> 
> class ARRAYBASE {
> private: float matrix[MAXSIZE][MAXSIZE];
> public: int xsize, ysize;
> 	ARRAYBASE(int x, int y) {xsize=x+1;ysize=y+!;};
> // put + get handlers
> // overloaded operator= which is fine
> // Inverse() function, taken from _Num. Rec. in C_
> 	ARRAYBASE ARRAYBASE::operator*(ARRAYBASE array1, ARRAYBASE array2)
> 	{
> 		//fill the array using matrix multiplication
> 		//fill in matrix[][] and xsize, and ysize vars
> 		return *this;
> 	};
> };
> 
> (obviously, this defines arrays with a base as 1 (a[1..6][1..6]))
> However, when i compile, i get...
> ARRAYBASE::operator*() must take only 0 or 1 arguments

Since you have declared operator* as a member of arraybase, it has an
implied argument, the <this> pointer, which is the left operand of the
expression A2*A3.  This means that an overloaded binary operator that
is implemented as a member function should have only one explicit
argument.  There are two things you can do:

	//
	// Member function - implied argument is ARRAYBASE *this
	//
 	ARRAYBASE ARRAYBASE::operator*(const ARRAYBASE &array1 )
 	{
		ARRAYBASE array;
		/* Code to multiply *this by array1, putting
			result in array */
 		return array;
 	};
	
or...
	//
	// Friend function - there is no implied argument, so both
	// arguments appear in the parameter list.
	//
 	friend 
	ARRAYBASE ARRAYBASE::operator*(const ARRAYBASE &array1, 
				       const ARRAYBASE &array2 )
 	{
		ARRAYBASE array;
		/* Code to multiply array1 by array2, putting
			result in array */
 		return array;
 	};

(Note that the arguments are now declared "const ARRAYBASE &" instead
of "ARRAYBASE" - this is not required, but it saves memory and
copy constructor calls.)

> huh? this is the same format that I can find in several C++ books for
> overloaded binary operators.  Whats wrong?!
> 
Your code resembles the format for overloaded binary operators with
side effects, such as

	const FOO &FOO::operator+=( const FOO &foo ) 	// Only one argument
	{ /* add foo to *this leaving result in *this */
	  return *this;
	}
Use this form when you want side effects.  I don't think you want them
in the example you gave, though.


Lorne Epp
epp@mala.bc.ca
From: kbhatt@ctron.com (Kulbhushan Bhatt)
Newsgroups: comp.lang.c++
Subject: Re: Speed, Correctness, Availability, and the Real World
Date: 27 Jul 92 17:36:43 GMT
To: jimad@microsoft.com (Jim Adcock)


jim,


 Could you please send me a copy of your proposal? 
 I have missed it.

-kulbhushan
From: epp@mala.bc.ca (Lorne Epp)
Newsgroups: comp.lang.c++
Subject: Re: Borland C++ 3.1 fails to conform to C++ Standard
Date: 24 Jul 92 13:37:38 -0700
Distribution: world
Organization: Malaspina College

In article <j_ohearn.711991770@dn73>, j_ohearn@dsg4.dse.beckman.com () writes:
> 
> class Vector
> {
>     double huge *data;
>     unsigned long low, high;
> 
>     public:
> 
>     Vector ( unsigned long, unsigned long );
>     ~Vector(){ delete[] data; }
> 
>     double& operator()( unsigned long i )
>     {
>         return data[i - low]; //Line that offends ver 3.1 but compiled without
>                               //error under 3.0
>     }
> };
> 
> The above class compiled and functioned successfully under version 3.0 
> but under version 3.1 I receive the error message:
>     "Reference initialized with 'double' requires lvalue of type 'double'"
> which referred to the line I have indicated in the above class listing.
> 

Just a note:  I have received the same error message for similar code in
Turbo C++ 3.0.
Xref: sparky comp.lang.c++:11269 comp.std.c++:904
From: wmm@world.std.com (William M Miller)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: Language extensions for run-time type identification
Date: 21 Jul 92 20:42:59 GMT
Article-I.D.: world.BrrAvo.EFA
Organization: Software Emancipation Technology, Inc.

In article <14ft2uINNjh4@agate.berkeley.edu>, Joe Buck writes:
> * the virtual impossibility of designing a more general solution that does
>   not break compatibility with C structs (a requirement that may be
>   meaningless to theoretical folks but that is nevertheless vital).
>   This constraint forbids adding any data to the object of any kind.

I presented such a solution in my position paper on runtime type
information given in a technical session at the March, 1991 X3J16
meeting.  It is somewhat more costly in time and space than the vtable
approach, so it would probably require as a practical matter that both
mechanisms be implemented, fast for classes with virtual functions and
slow(er) for other classes.

The issue is whether complete generality is sufficient justification
for complicating the implementation and adding some runtime expense
(which would be present even in programs that did not use RTTI
facilities, unless turned off by command line or #pragma).  I assume
from the fact that my suggestion was not adopted into the current
proposals that the general consensus was that complete generality was
not sufficient justification.  I don't know how to evaluate the
relative importance of these factors.

> I could also argue the other way: for a debugger, it isn't enough to
> identify all class objects.  I also need to be able to identify the
> types of any int, double, pointer, or reference variables.

This also turns out not to be terribly difficult.  Again, the issue is
trading off utility versus cost.

-- William M. Miller, wmm@world.std.com
From: jimad@microsoft.com
Newsgroups: comp.lang.c++
Date: 18 Jul 92 00:06 MDT
Subject: Re: virtual call efficiency (Re: ar
Nf-ID: #R:9219919.15720@mulga.cs.mu.oz.au:-1880726321:1992Jul17.200654.16033@microsoft:2132721639:001:1708
Nf-From: microsoft.com!jimad    Jul 18 00:06:00 1992


In article <1992Jul16.184747.28930@cmcl2.nyu.edu> checker@acf3.nyu.edu (Christopher Hecker) writes:
|I'm curious, have you timed the virtual call mechanism on your C++
|compiler and compared it to the static call mechanism?  I would be
|interested in seeing the results that forced you to make the above
|decision; when I did timings on my compiler I discovered only a 10%
|difference.  The test was on an empty function body for both virtual and
|static functions, so in real code the difference would be much less than
|that observed for a null function body.

The general "rule of thumb" is that the overhead for various kinds
of function calls in C++ is *about* as follows:

call-type		overhead-cost
--------- 		-------------

inline			   0
non-virtual		   1
virtual			   2

where "overhead-cost" has been normalized to be expressed in units of
what it "normally" would cost to do a function call on your particular
machine.

Depending on what one is doing then, one can find results where using
an inline function is "infinitely" faster than using "normal" non-virtual
function call or virtual function call.  Or alternately one might find
that using inlines only removes 1 unit of time costs from one's program.
Just like going from virtual to non-virtual might only save you 1 unit
of time.

The big win results if say in the main loop of your software all "normal"
function calls are replaced with inlines, replacing an N*1 or N*2 cost
with a N*0 cost.  Of course, in a "real" inline function chances are
the actual actions of that inline function do not come at "0" cost --
but in many cases the actions that inline function performs *are* very
inexpensive compared to the cost of a function call.


Newsgroups: comp.lang.c++,comp.std.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: Language extensions for run-time type identification
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Fri, 24 Jul 92 13:56:09 GMT

In article <1992Jul24.012050.6092@hellgate.utah.edu>  
clark%asylum.cs.utah.edu@cs.utah.edu (Charles Clark) writes:
> 
> Yes, compatibility with C structs is compromised by this scheme of
> hijacking the vtable to provide run-time type id.  If you just can't
> give up on this scheme, and are determined to make it work -- no matter
> what -- here are a couple other patches to consider:
> 
> (a) Modify the C compiler to provide RTTI for structs, using the same
>     technique.  (After modifying the C++ compiler you'll be good at this
>     kind of thing... :-} ).
> 

Each argument in C is specified by a unique type and a typecast in C is  
definitely a cast between two different types (if we view void as a concrete  
type). There for C DOES NOT need RTTI. It is not a good idea to enforce a C++  
penalty to C.

> (b) Force the use of a linkage specifier for, not only C functions, but
>     also C structs.  No type identification would be provided for C structs
>     (both C++ classes and structs would have RTTI).
> 
This is not a good solution either. Within a C++ module, we should not  
distinguish what is C struct, what is C++ struct, or what is C int and what is  
C++ int. The only distinguish should be made is that what module is written in  
C and what module is written in C++. For those module written in C, we still  
can add RTTI for those types and struts contained in the head files for C++  
environment IF IT IS REQUIRED (although the C programms never use RTTI).

David Shang
Newsgroups: comp.lang.c++
From: loewis@informatik.hu-berlin.de (M.v.Loewis)
Subject: Q: static members and private constructors
Organization: Humboldt University, Department of Computer Science
Date: Thu, 23 Jul 1992 12:33:26 GMT


In the following program, it is not possible to create static (class)
instances of a class with only private constructors. I suppose it is
a general compiler error:

class B;
class A{
friend class B;
A(int);
int i;
};

A::A(int){}

class B{
static A m;
public:
int func();
};

int B::func()
{
 return m.i;
};

A B::m(1);

The problem is the last statement: I think it should be possible to create
the m member of B somehow, since B is a friend of A, but all compilers I 
tried complained about sth:
BC: A::A(int) is not accessible in function _STCON_()
g++: In function _GLOBAL_$I$__1Ai(): ...invalid initializer to constructor
	for type A
CC: sorry, not implemented: static member B::m of class A with constructor

Obviously, BC and g++ try to create a function which calls the constructors
for all static instances. This function can't access the private
constructors. But I didn't please the compilers to do it in such a way,
and I wasn't able to declare these functions as friends of A.

So, is there a way out of this problem?

--
Martin
From: maxtal@extro.ucc.su.OZ.AU
Newsgroups: comp.lang.c++
Date: 18 Jul 92 10:29 MDT
Subject: Re: boolean (was: Re: typedef vs enum)
Nf-ID: #R:1992Jul11.195547.18323@cmcl2.nyu:1382747533:1992Jul18.062922.124@ucc.su.oz.a:1138516199:001:1439
Nf-From: extro.ucc.su.OZ.AU!maxtal    Jul 18 10:29:00 1992


In article <23195@alice.att.com> ark@alice.UUCP () writes:
>I do not use a special Boolean type in my programs because
>the built-in operators == != < > <= >= && || ! all return int
>and there's no way to change that.
>
>I would love to see a built-in Boolean type in C++, but
>unfortunately it's too big a change from C.
>-- 
>				--Andrew Koenig
>				  ark@europa.att.com

No it isnt. Just add a new standard type bool. It converts
to int or anything else as 0 and 1. Anything non-zero
assigned to a bool turns into a 1 (incuding a pointer
if you want). End.

Such a bool is quite transparent: its only effect is the
converion on assignment (or initialisation) to 1.

That is exactly the same as assigning a long to a char,
except the conversion rules are slightly different.

What wrong with this?

Well, you can ALREADY do it trivially:

	class bool {
		int x; //any integral type can be used for 'int'
		bool(const int y) : x(y){}
		operator int(){return x;}
	};

	const bool true=1;
	const bool false=0;

Something wrong with the way this works?
[A standard type might allow bools to be stored bit-wise,
otherwise it ought to be the same as the above class IMHO]

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: ser@netcom.com (Steve Rubin)
Newsgroups: comp.lang.c++
Subject: Summary:  C -> C++
Date: 28 Jul 92 19:06:18 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Everyone that emailed me said that the Pohl book sounded good.  Someone
also suggested Class Construction with C and C++.  Which, when I worked
at Computer Literacy was selling VERY well.  So I might just get both :).

Thanks for all the input!

-- 
___________________________________________________________________________
Steve Rubin			    ser@netcom.com, support@netcom.com
Technical Support Staff             Netcom - Online Communication Services 
Newsgroups: comp.lang.c++