HDTenEightyP/NetNews huggingface dataset:
From: steve@taumet.com (Steve Clamage)
Subject: Re: How About a Pragma Specifying All Functions Virtual?
Organization: TauMetric Corporation
Date: Sat, 12 Sep 1992 18:05:08 GMT

feustel@netcom.com (David Feustel) writes:

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

Nothing prevents a C++ implementation from providing such a pragma.

But IMHO pragmas which change language semantics are very dangerous.

1.  If you miss including the pragma in one place, or remove it
    from all but one place, you can get bizarre program failures,
    not necessarily caught in testing.

2.  If the code moves to another compiler which doesn't support the
    pragma, it will be silently ignored and the program will have a
    different meaning.  If you are very lucky, the compiler will
    warn about the pragma, or the program will fail in testing.
    (In Standard C, unknown pragmas are not errors.)

3.  The code might move to a compiler which has the same pragma, but
    with a different meaning.  Example:
	#pragma once
    Everybody knows this pragma, right?  It turns on special features
    for the customer engineer.  You turn them off again with
	#pragma offce
    (I didn't think this one up, but it's my favorite.)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: pabloh@hpwala.wal.hp.com (Pablo Halpern )
Date: Thu, 3 Sep 1992 14:01:16 GMT
Subject: Re: Destruction of Temporaries, Yet Another Posting
Organization: Hewlett-Packard Company
Newsgroups: comp.std.c++

In article <1992Sep2.171859.852@lucid.com>, jss@lucid.com (Jerry Schwarz) writes:
|> In article <1992Sep2.143007.5655@bnrmtl.bnr.ca>, john@bnrmtl.bnr.ca (John Hickin) writes:
|> |> 
|> |> A compiler using the const temporary approach and a thoughtful programmer
|> |> can combine to make code like that of the String example safer:
|> |> 
|> |>    class String { public:
|> |>        operator const char*(); // NON-const
|> |>        String( const char* );
|> |>        ...
|> |>    };
|> |> 
|> 
|> Making the function that gives the pointer to char a non-const is a mistake.
|> The function may modify the underlying representation, but it certainly
|> does not modify the represented character sequence.  There is no
|> reason that I shouldn't be able to apply it to a const String
|> 
|> |>    String h( "hello " ), w( "world" );
|> |>    const char* p = h + w;
|> 
|> A careful programmer might have written
|> 
|> 	const String h("hello "), w(" world") ;
|> 
|> and be surprised that  (const char*)h isn't allowed.

Well, until the language support for abstract const is solidified, I
suggest the following:

    class String { public:
       operator char*();             // NON-const
       operator const char*() const; // const
       String( const char* );
       ...
    };

A non-const string can be converted to a non-const char*, a const string
can only be converted to a const char*.  If only conversion to a const
char* is desired, then I agree with Jerry that the non-const version should
be eliminated.

|> I believe the use of the implicitly invoked conversion operator
|> obscures the issue of lifetime of temporaries and that we should 
|> be writing the above example out in full as.
|> 
|> 	const char* p = (h+w).pchar();

I tend to agree, although I am open to opposing views.

|> 
|>   -- Jerry Schwarz

-- 

- Pablo

------------------------------------------------------------------------
Pablo Halpern             (617) 290-3542
HP Waltham                pabloh@hpwarq.wal.hp.com

I am self-employed, so my opinions *do* reflect those of my employer.
However, they may not reflect the opinions of my client.
------------------------------------------------------------------------
Newsgroups: comp.std.c++,comp.lanf.c++
From: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Subject: Re: Exponentiation operator proposal
Reply-To: gs4t@virginia.edu (Gnanasekaran Swaminathan)
Organization: University of Virginia
Date: Tue, 15 Sep 1992 20:18:01 GMT

matt@physics2.berkeley.edu (Matt Austern) writes:

: I believe that an exponentiation operator would be of genuine benefit
: to C++ scientific programmers, and I believe that we who write
: scientific code are justified in asking that it be included.  I don't
: think, however, that we are justified in asking for a change to the
: language that makes life harder for other C++ programmers.  Using **
: to denote exponentiation does exactly that: it changes the meaning of
: legal C++ code, and it makes a useful programming technique more
: difficult.
: 
: It is possible to implement an exponentiation operator so that the
: extension to the language will have no effect at all for people who
: don't deliberately use the new feature.  This is a better idea.

Did you consider operator () for exponentiation?
It seems to have correct precedence and doesn't need new tokens to be
introduced.

// if op () is available for exp
double e= -10(2); // e = -100.0
double d=10;
double *p = &e;

e = d(3) - (*p)(2) + d + 3; // e = -8987.0

// status quo
class Double {
	double d;
public:
	Double(double f): d(f) {}
	operator double () { return d; }
	Double operator - () { return -d; }
	Double operator () (int i) { ... }
	Double operator () (double f) { return pow(d,f); }
	// other ops ...
};

Double a(10);  // a = 10.0
double d=a(5); // d = 10000.0

a = a(3.0)*2.5; // a = 2500.0

Double b(2); // b = 2
a = -b(4) + 3*b(3) - 2*b(2) + b + 3; // a = 5.0

Similary you can define your own Int as well and use it wherever
you want int and exp op. 

-Sekar
Newsgroups: comp.std.c++
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Integral promotions
Organization: Harvey Mudd College, Claremont, CA 91711
Date: Fri, 11 Sep 1992 17:12:15 GMT

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.

--
Jason Merrill
jason@jarthur.claremont.edu
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 17:32:59 GMT


In article <1992Sep15.140027.17387@sunb10.cs.uiuc.edu>
pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
>In <1992Sep15.054226.4126@cc.tut.fi> jk87377@cc.tut.fi (Juhana
>Kouhia) writes:
>
>>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.

I didn't thought this. 

>	For new operators, the precedence and associativity may seem
>	arbitary at the time of creation

At the compile time; just like functions are created.
Am I missing something? In what order the compiling the X and
the Y happens?

If X and Y provides the same function with different meanings,
how this is handled? I think the same apply to new operation.
That is, compile time error.
The same scope rules apply to the new operation too.

Lets suppose both X and Y makes the new operation to the
default operation precedence and associativity data set.
If they both offers the same operation, it is compile time error.
If both offers different operations, then this is valid.
But how to make the common operation predence and associativity
data set? I have to think about this a bit.
Just by adding the both operations to the same level?
For example,

Default set:
Level 1: * /
Level 2: + -

X:
Level 1: * / foo
Level 2: + -

Y:
Level 1: * /
Level 2: + - bar

The common set:
Level 1: * / foo
Level 2: + - bar



Juhana Kouhia
Xref: sparky comp.std.c++:1173 comp.lang.c++:13601
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: Exponentiation operator proposal
Date: 14 Sep 92 07:39:52 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <BuJJxs.8Hx@world.std.com> rr@world.std.com (Robert I Ransbottom) writes:
>[How about spelling it "^^", then?]

Some people still hope to adopt that symbol for boolean xor.  (I don't,
but I don't want to stand in the way of those who do.)

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.std.c++
From: sdm@cs.brown.edu (Scott Meyers)
Subject: Re: Zero-length structures and pointer comparisons
Organization: Brown University Department of Computer Science
Date: Thu, 10 Sep 1992 15:32:02 GMT

In article <1992Sep10.094957.23588@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
| In article <4945@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
| >
| >const T& operator = ( const T& t )
| >{
| >	if ( &t == this ) return;	// avoid self-assignment
| >	// ...
| >}
| >
| >Is the above idiom broken?
| 
| Oh dear, why have I not noted this _horrible_ defect in the language
| definition before?  Probably because it was too bad to be suspected.
| The above idiom is certainly common, and it is used in Stroustrup's
| own books.  The first example I could found now in "The C++ P. L." (2. ed.)
| is in 8.3.3 (p. 266).

The idiom is clearly older than that.  Stroustrup uses it in the FIRST
edition of his book, section 6.6, p. 179:

    void String::operator=(String& a)
    {
        if (this == &a) return;  // beware of s=s;
        ...

It would certainly cause grief to many a program if this were to suddenly
be found to be unportable.

Scott

-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."
Xref: sparky comp.std.c++:1187 comp.lang.c++:13680
From: hosken@spss.com (Bill Hosken)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: Exponentiation operator proposal
Date: 15 Sep 92 14:51:19 GMT
Organization: SPSS, Inc.

In article <1992Sep15.140027.17387@sunb10.cs.uiuc.edu>, pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
> 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.

To illustrate these points, consider the << operator.

cout << 1 ? 2 : 3 ;

The result is a little hard to figure out until you remember
the precedence rules.

---------------
Bill.
Organisation: European Space Operation Centre (E.S.O.C)
Date: Friday, 11 Sep 1992 15:42:16 CET
From: Karl Keyte <KKEYTE@ESOC.BITNET>
Newsgroups: comp.std.c++
Subject: Re: Answers on a postcard

...from a posting on 'comp.lang.c++'

In article <1992Sep10.174914.838@taumet.com>, steve@taumet.com (Steve Clamage)
says:
>
>Karl Keyte <KKEYTE@ESOC.BITNET> writes:
>
>|#include <iostream.h>
>
>|class X {
>|   private:    int           value;
>|   public:     int           operator , (int i) { return i+10; };
>|               int           operator + (int i) { return value+i; };
>|               X &           operator = (int i) { value=i; return *this; };
>|};
>
>
>|void main()
>|{
>|   X         x;
>
>|   cout << "Value is " << (x=1, x+1) << endl;
>|}
>
>In the expression in parens, it is unspecified whether "x=1" or
>"x+1" is evaluated first.  They are arguments to the "operator,()"
>function, not the left and right side of a comma-expression.  If
>"x+1" is evaluated first, which is legal, it will use an
>uninitialized "x.value".
>
>Don't write code which depends on unspecified order of evaluation.
>
>If there were no "op,()", the "," would mark a comma-expression,
>and the "x=1" would have to be evaluated first; in that case the
>whole expression would be well-defined.

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
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.std.c++
Subject: Re: template overloading
Date: 11 Sep 92 18:44:03 GMT
Distribution: comp
Organization: AT&T Bell Laboratories, Murray Hill NJ



girod@tele.nokia.fi (Marc Girod @ kpd) writes

 > 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."


How about (pg343):

	A class template name must be unique in a program and may not
	be declared to refer to any other template, class, function,
	value, or type in the same scope.

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

No. That seems to be a g++ bug.

 > But now, why? What would be the problem? Wouldn't it be more natural
 > to allow template name overloading?

It would be nice to be able to overload templates, but to do this we'd
have to work out the exact overloading rules. That is not a trivial task,
it hasn't been done, and there may be fundamental problems lurking.
Hence the prohibition.
Newsgroups: comp.std.c++
From: mskuhn@cip.informatik.uni-erlangen.de (Markus Kuhn)
Subject: Re: Status of C++ standard?
Organization: CSD., University of Erlangen
Date: Fri, 11 Sep 1992 09:05:13 GMT

landauer@morocco.Eng.Sun.COM (Doug Landauer) writes:

>	ISO/IEC JTC1 SC22/WG21
>This is an international committee.  (I'm not up on exactly what all of
>the letters stand for.  "J" stands for "Joint".  :-)

The letters mean 

 International Organization for Standardization (ISO)
 International Electrotechnical Commission (IEC)

both have formed a

 Joint Technical Commitee No. 1 (JTC)  (responsible for information precessing)

which has a

 SubCommitee 22 (SC) for programming languages

and there a

 Working Group No. 21 (WG)

is doing the work (e.g. on C++).

The members of these commitees are members of the national standard
bodies (e.g. ANSI in the US of A, DIN in Germany, BSI in GB, ...)

Markus

---
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
-A distributed system is one in which the failure of a computer you didn't-
-even know existed can render your own computer unusable. (Leslie Lamport)-
Newsgroups: comp.std.c++
From: tob@world.std.com (Tom O Breton)
Subject: Re: Answers on a postcard
Organization: The World Public Access UNIX, Brookline, MA
Date: Sat, 12 Sep 1992 17:19:31 GMT

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.


In general, chain operators by returning references (Usually to the same
argument they took).

        Tom

-- 
The Tom spreads its huge, scaly wings and soars into the wild sky...      
up...       up...     out of sight...   (tob@world.std.com)
Newsgroups: comp.std.c++,comp.lang.c++
From: menden@Informatik.TU-Muenchen.DE (Juergen Menden)
Subject: Re: Exponentiation operator proposal
Originator: menden@hphalle1a.informatik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Tue, 15 Sep 1992 09:41:46 GMT


Hi,
just an idea: how about 
	a ^^ b; 



-- 
Juergen Menden			menden@informatik.tu-muenchen.de
Newsgroups: comp.std.c++,comp.lang.c++
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Exponentiation operator proposal
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Tue, 15 Sep 1992 14:19:40 GMT

In article <23663@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>How frequent is a**p anyway? (has anyone got any data?)

I always avoid ** when I mean a mixture of multiplication and dereference
(in C).  I use parentheses to make it clear what is dereference and what
is multiplication.  Thus I would always write:  a * (*p)

Or, in the case of a***p, I would write:  a * (**p)

There are two situations where I might have generated a**p accidentally:

1.  #define THE_VALUE *p  /* This is C code.  Should be (*p) anyway */

    a*THE_VALUE

2.  a*i
    global change of i to *p


Case 1 should not show up in C++ code and is poor style in C code
because of the missing parentheses in the #define.

Case 2 should be a global change to (*p) anyway because of the
danger of a/i being changed to a/*p  (comment!)

So no, I do not intentionally generate code of the problem form.
I have seen such code, but only in code that I consider a nightmare
to read and maintain anyway.  Keep in mind also that I know of the
"global change results in comment" problem, so that means there must
be some a**p code around here generated that way.

Stuart
--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.std.c++,comp.lang.c++
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c++
Subject: Re: FULL HOUSE
Date: 14 Sep 92 07:34:47 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <1992Sep13.144341.24950@wuecl.wustl.edu> ppc1@cec1.wustl.edu (Peter Pui Tak Chiu) writes:
>for(int i=0;i<5;i++)hand[i]=rand()%13;	// deal the cards

I would say you're not playing with a full deck.

(Incidentally, your article has nothing to do with the process of
standardizing the C++ language.  Perhaps comp.programming would be
a better place to ask this sort of question.)
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 11 Sep 92 10:19:57 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: Tin 1.1 PL4

pete@genghis.borland.com (Pete Becker) writes:
: 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

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?

And for memory models that do not have this requirement (the s.c.
"huge" model), pointer comparison should be smart enough anyway, no?

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
From: cek@sdc.boeing.com (Conrad Kimball)
Newsgroups: comp.std.c++
Subject: Status of C++ standard?
Date: 4 Sep 92 16:38:37 GMT
Organization: Boeing Computer Services, Seattle, WA

Forgive me if this is an FAQ, but I haven't been monitoring this group
and I need an answer quickly...

Can someone please tell me:

1.  What is the official name of the C++ standard that is being developed
    (e.g. ANSI X1234.567 or something like that).

2.  The status of the standard, and any informed estimates of when it might
    be formally adopted.

--
Conrad Kimball		| Unix Server Tech Services, Boeing Computer Services
cek@sdc.boeing.com	| P.O. Box 24346, MS 7A-35
(206) 865-6410		| Seattle, WA  98124-0346
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Newsgroups: comp.std.c++
Subject: Re: FULL HOUSE
Date: 13 Sep 92 15:49:19 GMT
Organization: Computer Science, University of Melbourne, Australia

ppc1@cec1.wustl.edu (Peter Pui Tak Chiu) writes:

>hi everyone,
>
>i am trying to find the probability of getting a hand of full house from a
>shuffled deck of 52 cards.

This post does not belong in comp.std.c++.
comp.std.c++ is for discussion of standarization issues with regard
to the C++ language, not for general programming questions.

I have posted a follow-up in comp.programming.

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