HDTenEightyP/NetNews huggingface dataset:
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 16 Oct 92 23:48:51 GMT
Organization: Microsoft Corporation

In article <1992Sep10.094957.23588@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
|My opinion:  the idiom is sensible, in many cases even necessary.
|It is the pertinent part in the language definition that is broken,
|obviously (as explained by Johan above) in order to facilitate
|efficient implementation on obsolescent machine architectures.
|Was it William Wulf who wrote approximately: "More sins in programming
|are committed in the name of efficiency than all other reasons combined,
|including sheer stupidity"?

Note that many of the newest RISC machines also feature segmented architectures,
and are typically run with their compilers in a mode where pointer comparsions
are not done on the segment part.  

But in any case, at least my PC compiler (Large Model)
performs == and != comparisons based both on the segment and offset parts.
Its the ordered comparisons > < >= <= where only the offset part is compared.
Thus == != work for all ptrs.  > < >= <= only work within an array.

Which is as it should be.

I think the standard should define == != to always work on ptrs of comparable
types -- assuming those ptr are pointing at legitimate objects or one past
the end of a legitimate array.  > < >= <= to be only defined within an array
or one past its end.
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: implicit pointer of pointer argument promotion legal C++?
Date: 9 Oct 92 04:55:41 GMT
Article-I.D.: alice.23842
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Oct8.162653.12028@urbana.mcd.mot.com> qbarnes@urbana.mcd.mot.com (Quentin Barnes) writes:

> I can't find in the 23-sep-91 ANSI-C++ draft if pointer of pointer
> promotion is allowed or disallowed.  Can anyone point me to the
> appropriate reference(s) so I know whether cfront is broken or not?

Converting T** to const T** had better not be legal in C++, because if
it were, it would open a hole in the type system that would allow modification
of genuinely constant objects.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c++,comp.lang.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: The concept of templates considered ill designed
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Fri, 16 Oct 1992 13:03:32 GMT

In article <1992Oct15.070015.29776@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>In article <1992Oct13.143129.20733@bcrka451.bnr.ca> sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
>> [Almost all of a good posting deleted]
>> ...
>>4.  Sometimes speed is not as much an issue as being able to write the functionality
>>    in the first place.  
>
>This should be submitted to the Usenet "Understatement of the Month"
>contest :-)
>

	It was.

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


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: huang@cse.uta.edu (HUANG Kuochin)
Subject: need C++ grammar
Organization: Computer Science Engineering at the University of Texas at Arlington
Date: Tue, 13 Oct 1992 15:58:03 GMT

Hi everyone,

Does anyone of you know of a place where I can get a copy of C++
grammar ? I need a C++ grammmar to build a parer. I think it'd
be convenient if there is an anonymous FTP site where I can
obtain it. Your reply would be greatly appreciated.

-KC
-- 
If you have found any mispellings, that is because Dan Quale is
my role model ! :-)
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: implicit pointer of pointer argument promotion legal C++?
Date: 9 Oct 92 14:14:10 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <23842@alice.att.com>, I wrote:

> Converting T** to const T** had better not be legal in C++, because if
> it were, it would open a hole in the type system that would allow modification
> of genuinely constant objects.

I suppose I should give an example:

	const char x = '*';
	char* p;

Now, if we could make p point at x, that would be bad news because we
could then change the value of x even though it is a const object.

Well, if we can do this:

	const char** q = &p;

(which is illegal, but would be legal if conversions from T** to const T**
existed), then we would be able to do this:

	*q = &x;

which would effectively make p point at x.  All the other operations here
are unquestionably legal, which means we must rule out the declaration of q.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Xref: sparky comp.std.c++:1385 comp.lang.c++:15001
From: matt@physics2.berkeley.edu (Matt Austern)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: Exponentiation operator proposal
Date: 14 Oct 92 22:47:24
Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
	<23663@alice.att.com> <1992Oct14.225725.16486@microsoft.com>
	<ldpoc1INNbe7@exodus.Eng.Sun.COM>
Reply-To: matt@physics.berkeley.edu
NNTP-Posting-Host: physics2.berkeley.edu
In-reply-to: corbett@lupa.Eng.Sun.COM's message of 15 Oct 1992 03:12:01 GMT

In article <ldpoc1INNbe7@exodus.Eng.Sun.COM> corbett@lupa.Eng.Sun.COM (Robert Corbett) writes:

> >I just ran a quick measurement on a convenient sample of 85,000 lines of
> >C and C++ code.  Based on this sample "**" appears on average about once
> >per every 200 lines of code.  This is a pretty high occurance.
...
> I find it hard to believe that there are that many instances of
> multiplication following indirect referencing.  How many of those
> instances of ** are of the form
> 
> /*
> **  Commentary
> */
> ?

I can't speak for Jim (I haven't seen the code that he used for his
sample), but my guess is that most of the **'s he found weren't
comments, but, rather, double pointer dereference.  (For example, how
many times has the sequence **argv occurred in your programs?)

This wouldn't cause any direct ambiguity with ** as an exponentiation
operator, since exponentiation is an infix operator.  However, note
that it would still be necessary to define unary ** as a new operator
meaning double pointer dereference.  The parser would interpret ** as
a single token, whether it appears in a unary or a binary context.

There are a few expressions that would have their meaning changed if
we made ** into an operator---probably rare ones, but I'm sure that
they do crop up occasionally in real code.  (a/b**c, for example) I
think we probably would be better off using a different token for
exponentiation.
--
Matthew Austern                   Just keep yelling until you attract a
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!
From: myersn@hobo.ECE.ORST.EDU (Nathan Myers)
Newsgroups: comp.std.c++
Subject: Re: Object in this mirror may appear smaller than they are
Date: 16 Oct 92 19:26:56 GMT
Distribution: comp
Organization: ECE Dept.,OSU,Corvallis

Regarding inheritance from empty classes,
Given
  class A { /* empty */ };
  class B : A { int stuff; }
The language definition requires sizeof(A) > 0 but it does not
require sizeof(B) > sizeof(int).  Arguably, a compiler that does
is just broken.

I often want to declare an empty class just to define
enums and static functions for use by a family of classes; as it is,
I must not derive my other classes from it, and must use name
qualification everywhere; and all the members must be public.

Are there any compiler vendors reading this whose compiler is not broken
in this way?

Nathan Myers
myersn@roguewave.com
From: checker@acf5.NYU.EDU (checker)
Newsgroups: comp.std.c++
Subject: Re: pointers to class functions
Date: 12 Oct 92 01:53:42 GMT
Followup-To: comp.lang.c++
Organization: New York University

bilan@acs.ucalgary.ca (Bohdan Jens Bilan) writes:
>Can anyone tell me how I can assign a function pointer to a
>function, (ie. fptr=&foo()) when the assignment happens within a
>member function of the same class?

If you mean, what do pointers to members look like, see C++PL2 p. 166.

Followups directed to comp.lang.c++.

Chris
Xref: sparky comp.std.c++:1384 comp.lang.c++:15000
From: corbett@lupa.Eng.Sun.COM (Robert Corbett)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: Exponentiation operator proposal
Date: 15 Oct 1992 03:12:01 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: lupa

In article <1992Oct14.225725.16486@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <23663@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>>How frequent is a**p anyway? (has anyone got any data?) How confusing...
>
>I just ran a quick measurement on a convenient sample of 85,000 lines of
>C and C++ code.  Based on this sample "**" appears on average about once
>per every 200 lines of code.  This is a pretty high occurance.  For comparison
>"^" [XOR] appears on average once per 3000 lines of code!  Based on this
>measure I'd much rather see "^^" used for exponentiation, since the potential
>for confusion would seem to be much much lower.  Too bad "^" was misused to
>mean XOR in the first place or the problem would be solved!

I find it hard to believe that there are that many instances of
multiplication following indirect referencing.  How many of those
instances of ** are of the form

/*
**  Commentary
*/
?

					Yours truly,
					Robert Corbett
Xref: sparky comp.std.c++:1337 comp.lang.c++:14669
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: The concept of templates considered ill designed
Date: 7 Oct 92 12:52:17 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <IeoW7Ca00awVEGbFIn@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:

> What's the problem ?

> Why not take option 2 ?

> Every Baz object has method Foo::mem(int) cause it has inherited it
> from Foo.
> If you don't agree with it, why use inheritance ?

Well, let's make it more explicit.

	class Foo {
	public:
		void mem(int);
	};

	class Bar: public Foo {
	public:
		void mem(int);
	};

	template<class T> void f(T x) { x.mem(); }

	main()
	{
		Bar b;
		f(b);
	}

The whole point of templates is that the call f(b) should result in
calling Bar::mem, because b is an object of type Bar.

What you're saying is that you want f(b) to call Foo::mem if the template
function f has a constraint that T is Foo or derived from Foo.
It's already easy to obtain such behavior -- just don't bother with
templates at all!

In other words, I don't think option 2 is viable.  Do you still think
so after seeing this example?
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c++,comp.lang.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Exponentiation operator proposal
Date: 14 Oct 92 22:57:25 GMT
Organization: Microsoft Corporation

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

I just ran a quick measurement on a convenient sample of 85,000 lines of
C and C++ code.  Based on this sample "**" appears on average about once
per every 200 lines of code.  This is a pretty high occurance.  For comparison
"^" [XOR] appears on average once per 3000 lines of code!  Based on this
measure I'd much rather see "^^" used for exponentiation, since the potential
for confusion would seem to be much much lower.  Too bad "^" was misused to
mean XOR in the first place or the problem would be solved!
From: s913578@yallara.cs.rmit.OZ.AU (Fantom)
Newsgroups: comp.std.c++
Subject: Bug in BC++?
Date: 8 Oct 92 03:00:44 GMT


Hope i'm in the correct group here... sorry if i'm not

I wrote a small section of code recently which i saved in a file called 
shell.cpp.  Nothing spectacular, but when run it refused to produce any output.
I cut the program back to nothing except a 
void main(void)
{
	printf("hello");
}
and it still didn't do squat!

Only when i renamed the file to test.cpp did it work.  Bug or wot?  The filename
should not effect the program.

Fantom
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: ARM Specs Contradiction
Date: 9 Oct 92 13:46:32 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Oct8.123635.10160@nuscc.nus.sg> arthur@solomon.technet.sg (Arthur Sombrito) writes:

> Which is the correct spec: a friend
> function is entered in the same scope or it is entered in file scope?

At their meeting this summer, the ISO/ANSI committee decided that friend
functions should be entered in the nearest enclosing non-class scope.
That means that

	class A {
		class B {
			friend void f();
		};
	};

implicitly declares f at file scope.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: pabloh@hpwala.wal.hp.com (Pablo Halpern )
Newsgroups: comp.std.c++
Subject: Re: Exception Specifications
Date: 12 Oct 92 16:44:09 GMT
Organization: Hewlett-Packard Company

In article <KANZE.92Oct7151332@slsvdnt.us-es.sel.de>, kanze@us-es.sel.de (James Kanze) writes:
|> This leads to my basic premise.
|> 
|> Objects in a general library should not throw exceptions at all.  The
|> how and what of exception handling is *always* application specific,
|> and if a library like the iostream starts throwing exceptions, it
|> forces *all* applications that use it into its mould.
|> 
|> The solution I prefer is call-back functions.  The default failure
|> action is always to terminate the program with an error message.
|> Since this occurs near the point of the error, the error message can
|> actually be quite meaningful.  In failsafe applications, the user
|> replaces the default error function with one of his own, which may
|> very well (probably will) throw an exception.  This will be an
|> exception designed by the user however, and not one imposed by the
|> library.  The choice of whether one or many exception classes, etc.,
|> and in what class hierarchy they are, can then be made in an
|> application specific manner by the user.

Sorry to waste bandwidth on such a short follow-up, but I just want to
re-enforce James' premise and his call-back solution.  Let the client of a
general library choose what type of action to take for an error in a
general-purpose library.  Using this mechanism for the default allocator
would allow a GUI-based application to automatically display an "Out of
Memory" message and terminate, for example, rather than raise an exception.

-- 

- 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.
------------------------------------------------------------------------
From: warwick@cs.uq.oz.au (Warwick Allison)
Newsgroups: comp.std.c++
Subject: Re: Extended Double ?
Date: 8 Oct 92 03:01:49 GMT
Reply-To: warwick@cs.uq.oz.au

ddv@unix.brighton.ac.uk (Domenico De Vitto) writes:

>Is there a any classes anywhere that allow greater presision than long double?

The class Rational in libg++ may be what you are looking for.  It is built
using the libg++ class Integer (an infinite precision int).


--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /   C references are NULL && void*
      v      Brisbane, Australia.        /
From: am68@unix.brighton.ac.uk (AABStainer? AABSolutely!)
Newsgroups: comp.std.c++
Subject: semi colons after }
Date: 16 Oct 92 12:57:38 GMT
Organization: University of Brighton, UK



Can any body tell me why semi colons after closing braces for blocks
of code affect the performance of programs in C++?

I had a sort routine which didn't work until I removed the ;
any ideas
andy
Xref: sparky comp.std.c++:1361 comp.lang.c++:14777
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: The concept of templates considered ill designed
Date: 9 Oct 92 13:42:06 GMT
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <Eep9xSi00Vp_4391Iw@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:

> Who said there was no drawbacks ?

You implied it, by not mentioning any earlier.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: arthur@solomon.technet.sg (Arthur Sombrito)
Newsgroups: comp.std.c++
Subject: ARM Specs Contradiction
Date: 8 Oct 92 12:36:35 GMT
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]



--

There seems to be a contradiction in ARM specifications regarding
friend function declarations. In p. 250, it is stated that A:"If a
class or a function mentioned as a friend has not been declared
its name is entered in the same scope as the name of the class 
containing the friend declaration. In p. 251, it is stated that
B:"A function first declared in a friend declaration is equivalent
to an extern declaration." Which is the correct spec: a friend
function is entered in the same scope or it is entered in file scope?
Given the ff. example w/c is similar to the one in p. 188:

    class B {
      class C {
        friend f(); 
      };
    };
        
Following spec A, it would have created a B::f() member function.
I would therefore assume that  spec A is applicable only to classes.  
Following that assumption, it would also mean that the usual scope 
resolution rules are not followed for friend functions. For example:

    f();
    class A { f(); };
    class B {
      f();
      class C : public A {
        friend f();
      };
    };

Under normal scoping rules, the sequence would have been A::f(), B::f()
and ::f(). But in this circumstances, ::f() would always be the only
function visible to the friend declaration. A::f() and B::f() could only
be made friends by adding the class qualifiers.

Comments would be greatly appreciated.
Xref: sparky comp.std.c++:1376 comp.lang.c++:14918
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: The concept of templates considered ill designed
Date: 13 Oct 92 14:31:29 GMT
Organization: Bell-Northern Research Ltd., Ottawa, Canada

In article <1992Oct11.133704.5600@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>In article <Eep9xSi00Vp_4391Iw@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
>>
>>Every advance in languages has been associated with an increased overhead:
>>from assembler to C, from C to C++: every time you switch to a higher level
>>language you lose some speed. 
>>
>
>	Not true!
(Many examples provided)

Some additional points:

1.  I have seen assembler code that was written because the routine was
    expected to be time critical.  The code looked good on the surface, but
    saved all registers at the start and restored them all at the end.  This
    used up so much time that an equivalent routine I wrote in FORTRAN ran
    20% faster without even using any optimization options on the compiler.

2.  RISC processors exacerbate this problem of writing efficient code.  It
    really is true that the compiler may know how to handle most programming
    constructs better than you do.

3.  Advances in languages allow us to use more appropriate data structures
    and algorithms for the same amount of development time.  For this reason,
    the program written in the higher level language using those advances in
    languages is sometimes orders of magnitude faster than the one written in
    the lower level language.

4.  Sometimes speed is not as much an issue as being able to write the functionality
    in the first place.  

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: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: Object in this mirror may appear smaller than they are
Date: 9 Oct 92 13:44:21 GMT
Reply-To: ark@alice.UUCP ()
Distribution: comp
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <RWK.92Oct7181545@silver.sbi.com> rwk@silver.sbi.com (Richard W. Kreutzer Consultant) writes:

> This is not the real problem - assuming "class foo" above is indeed empty, by
> definition, can someone please explain to me the rational for requiring an
> "empty" class to be of size > 0?

Because C requires it and no one has pointed out a good enough reason
to break C compatibility on this issue.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Xref: sparky comp.std.c++:1392 comp.lang.c++:15062
From: matt@physics.berkeley.edu (Matt Austern)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: Re: Exponentiation operator proposal
Date: 16 Oct 92 17:19:45 GMT
	<1992Oct14.225725.16486@microsoft.com> <Bw8ADK.144@news.orst.edu>
Reply-To: matt@physics.berkeley.edu
Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
NNTP-Posting-Host: physics.berkeley.edu
In-reply-to: myersn@hobo.ECE.ORST.EDU's message of 16 Oct 92 19:05:38 GMT

In article <Bw8ADK.144@news.orst.edu> myersn@hobo.ECE.ORST.EDU (Nathan Myers) writes:

> I have long ignored "exponentiation proposal" notes, but it seems
> time to point out that there is no operator~(T,T) defined yet.
> Simply allowing it to be defined would permit experimentation,
> without committing anybody to a bigger language if the use didn't
> "catch on".

Binary operator~ is certainly one possibility for exponentiation.
operator*^ and operator^^ are other possibilities; of the three, I
think that *^ is the best.

Regardless of the name, however, I feel strongly that a real
exponentiation operator is far better than an operator which can be
defined as exponentiation by the user.  First, a compiler is much more
likely to optimize exponentiation aggressively if it is built into the
language than if it's something the user tacks on.  (Depending on
exactly what is inline and in scope, it might not even be possible to
do certain optimizations with a user-defined operator.)  

Second, if users each define this operator for themselves, then each
programmer will almost certainly define it slightly differently.  This
is likely to cause subtle bugs and conflicts when the work of
different programmers is put together.

Finally, and most important: things like exponentiation simply belong
either in the language or in the library; users should not be forced
to write them for themselves, any more than users should be forced to
implement malloc() or sin() or qsort().  Defining commonly used
operations and functions is what languages and libraries are for.
--
Matthew Austern                   Just keep yelling until you attract a
(510) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
matt@physics.berkeley.edu         solutions, become a part of the problem!
Newsgroups: comp.std.c++,comp.lang.c++