HDTenEightyP/NetNews huggingface dataset:
From: feustel@netcom.com (David Feustel)
Subject: How About a Pragma Specifying All Functions Virtual?
Date: Sat, 12 Sep 92 00:09:34 GMT
Organization: DAFCO: OS/2 Software Support & Consulting

Coplien's book "Advanced C++" makes the point that very little overhead
would be incurred in most programe even if all functions were declared
virtual and that some programs might even run faster than equivalent C
programs using switch constructs to achieve the same effects. Why not
define a pragma that would make all class functions virtual by
default?
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
RE Drug Warriors who enjoy making a "good" bust: I'm sure the Salem
Witch Hunters enjoyed their law enforcement achievements too.
Xref: sparky comp.std.c++:1167 comp.lang.c++:13565
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Exponentiation operator proposal
Date: 12 Sep 92 18:30:53 GMT
Article-I.D.: alice.23660
Organization: AT&T Bell Laboratories, Murray Hill NJ


Comments on Mat Austern's proposal for an exponentiation
operator in C++ (posted to comp.lang.std and, I think,
also to comp.lang.c++).

(1) I think overloading and inlining can be used a bit
	more effectively than is assumed in tht proposal.
	For example:

	double pow(double,double); // what C gives us
	double _pow(double,int); // general pow(double,int)

	inline double pow(double d, int i) // inlining to catch
					   // important special cases
	{
		if (i == 2) return d*d;
		else if (i == 3) return d*d*d;
		else _pow(d,i);
	}
	
	
	void f(double d, int i)
	{
		pow(d,d);
		pow(d,i);
		pow(d,2);
		pow(d,3);
		pow(d,4);
	}

	will generate better code for small integer powers.
	This technique is fairly gaeneral and does not depend on
	cleverness beyond the average C++ compiler.

	I agree that a clever compiler can do better, but for now
	this technique might be helpful to some.

(2) I think we could actually get ** as the exponentiation operator.

	Consider the well-known counter-example:

		int a;
		int* p;

		a**b;

	For C compatibility, a**b must mean a * (*b). However,
	with a minor sleigh of hand this can be achieved even
	if we introduce and exponentiation operator represented
	by the single token **.

	All we need to do is to say that the exponentiation
	operator ** given a first operand `a' of arithmetic type
	and a second operand `b' of pointer type (that is, `a**b')
	mean multiply the first operand with the dereference value
	of the second operand (that is, `a*(*b)'). This would not
	be quite 100% compatible because a*b**p where p is a pointer
	would mean a*(b*(*p)) rather than (a*b)*(*p), but I suspect
	that it would be compatible enough.

	Similarly the token ** when used in a declarator must mean
	* * (that is pointer to pointer.

	
	I think this would take care of the compatibility problems.
	There may be other minor details to consider, but I don't
	see any insurmountable problems.

Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Zero-length structures and pointer comparisons
Organization: TauMetric Corporation
Date: Fri, 11 Sep 1992 19:01:34 GMT

jbn@lulea.trab.se (Johan Bengtsson) writes:

|pete@genghis.borland.com (Pete Becker) writes:

|: 	0x0000:0x0010
|: 	0x0001:0x0000
|: 
|: These two addresses refer to the same memory location.  Converting them to
|: longs in the most obvious way produces these two values:
|: 
|: 	0x00000010
|: 	0x00010000

|But can this really happen, if the rule "pointer arithmetic only
|within an array" is adhered to?  Shouldn't all pointers within an
|array be based on the same segment?


If you do non-normalized pointer arithmetic, the offset portion could
be greater than 15 and still point within the array.  This causes no
problems for the hardware, which doesn't care whether pointers are
normalized.  The compiler must still arrange for pointer comparisons
to come out right, such as by normalizing them first.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.std.c++,comp.lang.c++
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: What does "::" really mean?
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
Date: Tue, 8 Sep 92 13:43:41 GMT

In article <1992Sep4.140615.9469@cadsun.corp.mot.com> shang@corp.mot.com (David  
(Lujun) Shang) writes:
> [ examples deleted]
>
> We should use:
> 
>    AA1.AA.NAA
> 
> to denote the class NAA nested in class AA nested in class AA1, and use
> 
>    AA1::AA.NAA
> 
> to denote the class NAA nested in the base class AA of AA1.
> 
Sorry, this is a typo. I correct as follows:

We should use:
 
    AA1::AA.NAA
 
 to denote the class NAA nested in class AA nested in class AA1, and use
 
    AA1::AA::NAA
 
 to denote the class NAA nested in the base class AA of AA1.

David Shang
Xref: sparky comp.std.c++:1181 comp.lang.c++:13664
From: girod@tele.nokia.fi (Marc Girod)
Subject: template overloading
Reply-To: marc.girod@ntc.nokia.com
Organization: kpd
Distribution: comp
Date: Fri, 11 Sep 1992 11:15:10 GMT

Someone proposed some time ago that a void type would be created,
which would be guarrantied to be of null length, which eventually gave
birth to various threads.

The originally alleged use for such a type would have been a special
use of certain templates, as follows:

template <class A, class B> class X;

X<int, void> x;

This made me wonder whether it was possible to overload template
definitions, such as:

template <class A> class X {};
template <class A, class B> class X {};

X<int> x1;       //from the first template
X<int, int> x2;  //from the second

I checked with g++ v2.2.2, and was surprised to notice that the
overriding of the templates was legal, but thus hid the former
declaration, without any warning. The result was thus an error, at
delaration time of x1:

incorrect number of parameters (1, should be 2) in template expansion

Well, I had a look in ARM, and couldn't find anything better than:

p 347
14.5c Declarations and Definitions
"There must be exactly one definition for each template of a given
name in a program."

This sounds like g++ was right (apart from allowing the superseeding
to occur, additionally without warning).

But now, why? What would be the problem? Wouldn't it be more natural
to allow template name overloading?
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+
Newsgroups: comp.std.c++
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Answers on a postcard
Organization: University of Jyvaskyla, Finland
Date: Mon, 14 Sep 1992 08:34:25 GMT

In article <BuH6sK.54r@world.std.com> tob@world.std.com (Tom O Breton) writes:
>Karl:
>
>> If not, I would ask: How does one overload the comma operator while
>> maintaining its attibutes as an operator?
>
>
>It's of dubious usefulness but it can be done:
>
>class thisclass
>{ int&  operator,(int a); }
>
>//To call this:  (thisclass)X, (int)Y ... (outside of arg-lists, of course)
>  
>This will return you an int, just as if the default comma operator had
>executed.
> ...

Sorry, but you did not see what the problem is.
With an overloaded comma operator it is impossible to make sure
that the first operand (X) is _evaluated_ (completely) before
the second one, as is the case with the built-in operator.
Indeed, one would probably often like not to have the second operator
evaluated yet at all before the operator function is invoked.
This is important if either of the operands is an expression
with side effects (and with the built-in comma, you would not use
it at all unless the first operand really has side effects).

BTW, I regard it as a mistake to make comma (and '&') overloadable at all.
It is a clear breach of the principle: "C++ was designed to be
extensible, but not mutable".

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
From: daniel.edelson@inria.fr (Daniel R. Edelson)
Newsgroups: comp.std.c++
Subject: Re: Answers on a postcard
Date: 14 Sep 92 09:00:50 GMT
Reply-To: Daniel R. Edelson <edelson@sor.inria.fr>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France

In article <92255.154216KKEYTE@ESOC.BITNET>, KKEYTE@ESOC.BITNET (Karl Keyte) writes:
|> ...from a posting on 'comp.lang.c++'
|> 
|> In article <1992Sep10.174914.838@taumet.com>, steve@taumet.com (Steve Clamage)
|> says:
|> >
|> The implication of what you say is that it is not possible to overload
|> operators maintaining the correct functionality of the operator.  This
|> indeed means that precedence in overloaded operators cannot be maintained
|> if all operands are simply passed as arguments to the function implementing
|> the operator functionality and evaluated in a language independent order.
|> Imagine commonly used "chain" operators such as && and ::.
|> 
|> If what is described above is correct, and Mr.Clamage clearly has much
|> experience in the area, then I think we have justification for pressing
|> for a change in this area.  If not, I would ask: How does one overload
|> the comma operator while maintaining its attibutes as an operator?
|> 
|> Karl

It seems to me that the ability to look at a comma expression and
infer some semantics from the syntax is a valuable aid 
for program readability. This seems to me like an argument for
not permitting the comma operator to be overloaded. Of course,
the logical extension is to then forbid && and || from being
overloaded as well, but this seems unlikely to happen, unfortunately.

Daniel.Edelson@inria.fr
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Integral promotions
Organization: TauMetric Corporation
Date: Sat, 12 Sep 1992 17:47:05 GMT

jason@jarthur.claremont.edu (Jason Merrill) writes:

>Why is the conversion int -> long (or unsigned int -> unsigned long) not
>considered an integral promotion?  

>I am in the situation of trying to take either a pair of longs (with
>default arguments) or a double for creation of a Fraction.  If I do
>something like 

>Fraction(1), 

>my compiler (BC++ 3.0) complains about ambiguity.  This seems wrong to me.

The "promotions" are from "smaller" types to int or unsigned int.
There are automatic conversions to long and double.  This is the
heritage from C, unchanged in C++.  That isn't much of a "why",
but I don't have a better answer.

In contrast to your question, some programmers complain about having
so many silent conversions, some of which they feel ought to be errors.

No conversion is preferred over any other conversion when resolving
a call to an overloaded function.  If you have only
	foo(long)
	foo(double)
and call foo() with an int argument, neither function is preferred
over the other, and the call is ambiguous.

You generally want to provide an overloaded function taking an int
parameter if you have any taking any other integral types, and
one taking a double parameter if you have any taking other
floating types.  You can do this:

inline T foo(int i) { return foo((long)i); } // foo(long) returns type T

(Hmmm.  T foo(long) sounds like a beverage.)

Make this NON-virtual in the base class, and don't override it in
any derived class.  You will then always get the correct version
of a virtual foo(long) every time you call foo with a (signed)
integer type, with no extra overhead.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Newsgroups: comp.std.c++
From: gu24522@uxa.cso.uiuc.edu (Gennady Ushman )
Subject: operator overloading [] with derived classes
Organization: University of Illinois at Urbana
Date: Wed, 16 Sep 1992 02:18:35 GMT

Like, how do I do this? If I have the & operator[] defined in the base class,
how do I access the array elements from the derived classes. Each array is
allocated by the base class constructor when the object of the derived class
is created. There are a series of virtual functions defined in the base class
that are redefined within the derived classes and that must access the arrays
defined by the base class. Does anyone know how to do this?

Newsgroups: comp.std.c++,comp.lang.c++
From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
Subject: Re: Exponentiation operator proposal
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 15 Sep 1992 14:00:27 GMT

In <1992Sep15.054226.4126@cc.tut.fi> jk87377@cc.tut.fi (Juhana Kouhia) writes:

>Hi,

>I'm very new in C++ world; I have not done any programs so far;
>and I'm currently reading C++ Primer books on chapter 3   :-)

>Instead of making exponential operator; I would like to get
>a new basic operation which allows programmer to define new
>operations like 'a ** b'; that is, the '**' is defined.
>('a pow b' is also good.)

*****>	The short answer is that it's a _real_ pain.  The somewhat
	longer answer is that making new operators means that you have
	to also establish the precedence and associativity of the new
	operator relative to all the other operators *AND* any other
	operators created by other people.  Every time an operator is
	added, the hierarchy would have to be readjusted.

	For new operators, the precedence and associativity may seem
	arbitary at the time of creation, but it may later be realised,
	after experience, that it could have been done better...of
	course it's too late to change it now because code would break.

	Also, if you were to use library X and library Y, each could use
	the same operator for different reasons, and the two operators
	were developed without regard to the others precedence and
	associativity; how would the compiler resolve this?  (I'm not
	looking for people to show how smart they are here by telling me
	how a compiler could resolve this...the point is that even if
	the compiler could do it, most _people_ would have a tough time
	looking at the code.)

	It's more trouble than its worth.  The _point_ of operator
	overloading is to give an operator a _natural_ extension to
	another type.  People shouldn't sit around trying to figure out
	how to force an operator (square peg) to be used for a new type
	(round hole).  If the operator's use in a new context isn't
	intuitively obvious, forget it and use function-notation.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
From: jhelberg@nl.oracle.com (Joost Helberg)
Newsgroups: comp.std.c++
Subject: Re: drawing a point without using BIOS......
Date: 10 Sep 92 12:20:05 GMT
Organization: Oracle Europe
X-Newsreader: Tin 1.1 PL3

X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

JORTIZ@vmtecqro.qro.itesm.mx (Jose Luis Ivan Ortiz Lopez) writes:
: Hey, I need ideas ASAP about drawing a point without using BIOS
: for a IBM PS/2 55 SX with a 386, using TC ++ 2.0.. You may replay me
: to my account if you like...

In this newsgroup!
yakee

: Thanks in advance.
: Ivan Ortiz
: jortiz@vmtecqro.qro.itesm.mx

--  
   Joost Helberg                                Rijnzathe 6
   jhelberg@oracle.nl                           NL-3454 PV De Meern
   jhelberg@nl.oracle.com                       The Netherlands

   Oracle Europe BV                             Product Line Development	
   Phone: +31 3406 94211                        Fax:   +31 3406 65609
Newsgroups: comp.std.c++
From: pete@genghis.borland.com (Pete Becker)
Subject: Re: Zero-length structures and pointer comparisons
Originator: pete@genghis.borland.com
Organization: Borland International
Date: Thu, 10 Sep 1992 16:29:06 GMT

In article <4945@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>
>If sizeof(long) >= sizeof(void*), then you should be able to
>test like this:
>
>assert( (long)p1 != (long)p2 );
>
>since a pointer stored in an integer variable must keep all information
>needed to restore the pointer (if the integer type is large enough).
>

	Not necessarily. The requirement is only that the original pointers can
be restored, not that their representations as longs be identical.  For 
example:

	0x0000:0x0010
	0x0001:0x0000

These two addresses refer to the same memory location.  Converting them to
longs in the most obvious way produces these two values:

	0x00000010
	0x00010000

The trick on segmented architectures is to always normalize the pointers before
comparing. The first pointer above isn't normalized, because it has an offset
greater than 15.  The second one is normalized. Comparisons between normalized
pointers are always valid.
	-- Pete



 


Newsgroups: comp.std.c++,comp.lang.c++
From: hbf@durin.uio.no (Hallvard B Furuseth)
Subject: Re: Exponentiation operator proposal
Organization: University of Oslo, Norway
Date: Mon, 14 Sep 1992 19:53:33 GMT

Sorry, I just cancelled an article where a rather essential part was
deleted (I just intended to move it...)  Here is next attempt -

In article <23660@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:

> (2) I think we could actually get ** as the exponentiation operator.
> (...)
>	   All we need to do is to say that the exponentiation
>	   operator ** given a first operand `a' of arithmetic type
>	   and a second operand `b' of pointer type (that is, `a**b')
>	   mean multiply the first operand with the dereference value
>	   of the second operand (that is, `a*(*b)').

The few times I use a**b, a and *b are usually class objects.  operator*
could be cross product or a set operation.  b.operator*() may exist too,
but to me that is less important.  To allow both this and Complex
operator**(Complex&,Complex&), I think the rule must be something like
"** is exponentiation unless that is an error".  I do not volunteer to
write the parser though.  A binary operator~ is my favorite.
--

Hallvard
Xref: sparky comp.std.c++:1139 comp.lang.c++:13446
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: What does "::" really mean?
Date: 9 Sep 92 19:40:25 GMT
Followup-To: comp.std.c++
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

shang@corp.mot.com (David (Lujun) Shang) writes:
: 
: We should use:
:  
:     AA1::AA.NAA
:  
:  to denote the class NAA nested in class AA nested in class AA1, and use
:  
:     AA1::AA::NAA
:  
:  to denote the class NAA nested in the base class AA of AA1.

Since people seem to diagree what the "natural" rule is for
scope order when both nesting and inheritance are considered, I'd
rather keep AA1::AA::NAA for both cases, and require that these
expressions be unambigous.

Even if clear rules are defined, I think it will be confusing
if the same name may appear along different inheritance/nested
paths.  It is (kind of) the visibility aspect of multiple inheritance
applied to nesting as well.

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Zero-length structures and pointer comparisons
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 10 Sep 1992 04:37:29 GMT

jbn@lulea.trab.se (Johan Bengtsson) writes:

>If sizeof(long) >= sizeof(void*), then you should be able to
>test like this:
>
>assert( (long)p1 != (long)p2 );
>
>since a pointer stored in an integer variable must keep all information
>needed to restore the pointer (if the integer type is large enough).

I don't think that this is the case.

If the integer variable is *larger* than the pointer, then some of the
bits in the integer need not be used when converting from integer to pointer.
I do not see any restriction in the reference manual that would require
the opposite conversion to initialize those bits.
This would then mean that (long) p1 != (long) p2 might return true even
when p1 == p2, because the uninitialized padding bits might be different.

[This means that ((long) p1) may behave "non-deterministically", although
((void *)(long)p1) is guaranteed to evaluate to p1 provided that "long"
is sufficiently large.]

Is that all correct?

-- 
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.std.c++,comp.lang.c++
From: jk87377@cc.tut.fi (Juhana Kouhia)
Subject: Re: Exponentiation operator proposal
Organization: Tampere University of Technology
Date: Tue, 15 Sep 92 05:42:26 GMT


Hi,

I'm very new in C++ world; I have not done any programs so far;
and I'm currently reading C++ Primer books on chapter 3   :-)

Instead of making exponential operator; I would like to get
a new basic operation which allows programmer to define new
operations like 'a ** b'; that is, the '**' is defined.
('a pow b' is also good.)

The operation '**' may hide freely some other operations;
like, maybe, 'c ** **p' which should be written 'c ** (**p)'
(maybe poor example; I write always clearly anyway and don't
study those ****a*******b**** hacker tricks).


Juhana Kouhia