HDTenEightyP/NetNews huggingface dataset:
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: New operators wish list
Date: 27 Jul 92 19:31:57 GMT
Organization: Microsoft Corporation

In article <l6smdpINNjmc@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
|Those people that I know who dislike C++, dislike it because they
|believe it contains too many features (that cannot now be removed).

I am one of the people who thinks C++ has too many "features" --
[other people including myself would say "bugs"] 

However, some of the these features/bugs CAN be successfully removed.

One of the "features" that I have formally proposed be removed is the
special case language preventing a few operators from being overloaded.
Its much easier to teach, program, remember, the language etc, if there
isn't a plethora of special case restrictions in the language.

If the language is implemented in an "orthogonal" manner [to the greatest
extent possible] then people can simply learn general rules, they do not
have to remember all these special cases.

People keep trying to argue against making the language orthogonal, people
keep arguing that I need to "prove" the benefits of trying to make the 
langauge orthogonal.  This continues to amaze me.  Rather, I would expect
that a reasonable group of people would insist that anyone who wants to 
defend special cases in the language would be required to show a great
burden of proof.  Each of those special cases represents an additional
"feature" that C++ programers have to try to learn, remember, and continually
program around.
Newsgroups: comp.std.c++
From: checker@acf3.nyu.edu (Christopher Hecker)
Newsgroups: comp.std.c++
Subject: Re: abstraction (was: Re: Give me a break)
Date: 24 Jul 92 20:40:04 GMT
Organization: New York University


>In article <1992Jul23.020241.11513@cmcl2.nyu.edu> checker@acf3.nyu.edu (Christopher Hecker) writes:
>|Hmm, I'm not sure you want to make this argument.  Carried to its
>|extreme, we could say, why are so many people using OWL?

>How many people ARE using it?  If many people are using it, why aren't the
>other compiler vendors licensing it?

I have no clue how many people are using it.  I do know that the BIX
Borland forum is clogged with OWL questions, and MEWEL supports it (and
mentions that in their advertisements) among other things.  Add that to
the fact that Borland's share of the DOS C++ market approaches monopoly
and I'd say that there are more people writing OWL applications than
there are using MSC7 as a C++ compiler, but I have no way of proving
that.

Anyway, the real answer to, `How many people ARE using it?' is, `Too
many.'  Of course, that answer holds whether the `it' in the question is
OWL or MFC.

Chris
Newsgroups: comp.std.c++
From: wmm@world.std.com (William M Miller)
Subject: Re: Alternatives to operator.()
Organization: Software Emancipation Technology, Inc.
Date: Fri, 24 Jul 1992 01:03:10 GMT

In article <9220604.6372@mulga.cs.mu.OZ.AU>, Fergus James HENDERSON writes:
> There are also several ways of hiding away the circumlocution, if it still
> bothers you (variations on the usual macro-hackery).

Yes, I think both of these are better than "(&r)->query_status()";
however, they are both still circumlocutions.

This may be an opportune time to point out that I have never claimed
that any of my three objections was a "killer," i.e., something that
made the proposal completely unacceptable; they are just points that
have to be weighed against the obvious attractions of the proposal.  I
think that posts like this, which reduce the negative impact of the
problems, are exactly the kind of helpful contributions I would hope
to see from the proposal's supporters.

-- William M. Miller, wmm@world.std.com
From: daniel.edelson@inria.fr (Daniel R. Edelson)
Newsgroups: comp.std.c++
Subject: name of class as name of nonconstructor member
Date: 21 Jul 92 12:12:23 GMT
Reply-To: Daniel R. Edelson <daniel.edelson@inria.fr>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France

I think the following code is illegal, but am not
certain the draft Standard contains a prohibition.

   struct S {
	int S;
   };

Without explicitly discussing this case (as far as I have
discovered), I think the draft Standard forbids this for the
following reason.

	Whether or not the user declares one, S has a
	constructor. There may not be an outline function
	emitted, but S::S() can be called. Therefore, the
	declaration of "int S" redeclares as a datum an
	identifier that is already declared in the same 
	scope to be a function.

I don't consider this argument completely waterproof. 
If someone can phrase it more convincingly, I'd appreciate 
hearing the argument.

Thanks a bunch,
Daniel 
daniel.edelson@inria.fr

	
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: How do I... (regarding overloading)
Date: 27 Jul 92 19:37:01 GMT
Organization: Microsoft Corporation
Distribution: usa

In article <1992Jul23.154922.26676@sunb10.cs.uiuc.edu> pjl@sparc11.cs.uiuc.edu (Paul Lucas) writes:
|	Why do they want to do that?  If I want to call functions on
|	temporaries, that's my business (and I accept any consequences).
|	I think that compiler warnings are sufficient.

Remember, if you say that warning are sufficient, then you are also saying
that not having warnings is sufficient, because warning represent a compiler
implementation, not a language specification.  Errors are part of the language,
warnings are implementation specific.

Why would they not allow functions on temporaries?  Beats me, but someone
is proposing this.  I don't know the details.  Perhaps it relates to all
the committee discussions about trying to invent special case rules for
handling the lifetimes of temporaries?   As opposed to handling the lifetimes
of temporaries just like all other objects?
From: cok@sunshine.Kodak.COM (David Cok)
Newsgroups: comp.std.c++
Subject: Re: Alternatives to operator.()
Date: 24 Jul 92 19:03:21 GMT
Article-I.D.: kodak.1992Jul24.190321.5671
Organization: Eastman Kodak Co., Rochester, NY

In article <9220614.4939@mulga.cs.mu.OZ.AU> fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>
>The more I think about this the more I like it.
>In fact I would say that is is *better* than just allowing
>	r.invalidate_cache();
>since you *want* meta-operations to stand out as being semantically different
>to standard operations. This method allows you to clearly seperate the two.
>Also in general you might want to control access to meta-operations, and
>having this seperation also makes that easier.
>
>-- 
>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!

No, I don't want meta-operations to stand out.  I want to be able to design
interfaces in which construction, copying, destruction, conversion all happen
silently and automatically where the interface designs them to.  The same
would apply to operator. if it were allowed to be overloaded.

David Cok
Eastman Kodak
cok@Kodak.COM
From: pjl@sparc11.cs.uiuc.edu (Paul Lucas)
Newsgroups: comp.std.c++
Subject: Re: How do I... (regarding overloading)
Date: 23 Jul 92 15:49:22 GMT
Distribution: usa
Organization: University of Illinois at Urbana-Champaign

In <1992Jul23.012111.16784@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

>In article <1992Jul21.232959.13540@sunb10.cs.uiuc.edu> pjl@sparc1.cs.uiuc.edu (Paul Lucas) writes:
>|*****>	operator= has got nothing to do with it unless the thing that []
>|	returns is itself a class object (in which case operator= would
>|	be overloaded in _that_ class--whether operator= is overloaded
>|	in _this_ class is irrelevant...unless you're doing something
>|	non-canonical).  operator[] should return a reference to the
>|	thing...that's it; the assignment just happens.  

>The overloading of operator= becomes relevant IF some committee members
>succeed in changing the language such that functions cannot be invoked
>on temporaries.

	Why do they want to do that?  If I want to call functions on
	temporaries, that's my business (and I accept any consequences).
	I think that compiler warnings are sufficient.
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.std.c++
From: checker@acf3.nyu.edu (Christopher Hecker)
Subject: Re: abstraction (was: Re: Give me a break)
Organization: New York University
Date: Thu, 23 Jul 1992 02:02:41 GMT

>|Now, how about addressing the point: if you agree that it is possible to
>|write an efficient class library that does a good job of abstracting the
>|problem domain, why didn't Microsoft do it?  
>The MFC people did do so, you just disagree with them as to what "the 
>job" is.

I guess so.

>I argue simply: if MFC isn't doing a good job, then why are several 
>other C++ compiler houses licensing it for distribution with their compilers?

Hmm, I'm not sure you want to make this argument.  Carried to its
extreme, we could say, why are so many people using OWL?

Chris

Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: How do I... (regarding overloading)
Date: 23 Jul 92 01:21:11 GMT
Organization: Microsoft Corporation
Distribution: usa

In article <1992Jul21.232959.13540@sunb10.cs.uiuc.edu> pjl@sparc1.cs.uiuc.edu (Paul Lucas) writes:
|*****>	operator= has got nothing to do with it unless the thing that []
|	returns is itself a class object (in which case operator= would
|	be overloaded in _that_ class--whether operator= is overloaded
|	in _this_ class is irrelevant...unless you're doing something
|	non-canonical).  operator[] should return a reference to the
|	thing...that's it; the assignment just happens.  

The overloading of operator= becomes relevant IF some committee members
succeed in changing the language such that functions cannot be invoked
on temporaries.  Then the common approach of returning a SmartRef from
operator[] fails:

bitarray[100] = TRUE; // code in error if functions cannot
                      // be invoked on temporaries!

because this really means:

bitarray.operator[](100).operator=(TRUE);

where operator[] is returning a temporary SmartBitRef that in turn has
its operator= on it.

Newsgroups: comp.std.c++
Newsgroups: comp.std.c++
Subject: How do I... (regarding overloading)
From: choate@acs.harding.edu (Brad S. Choate)
Date: 21 Jul 92 14:48:55 -0500
Reply-To: choate@acs.harding.edu
Organization: Harding University

Ok... I'm new at this business, so this should be easy for some of the experts
out there.

I know about operator overloading and I can implement it to some degree without
consulting the manuals too much, but I'm stuck on this one:

    a[1]=x;

Ok.  "a" is an object that I have created and I've overloaded the [] operator
to allow me to return a value at position "1" (in this case) from my object.
However, in this case, I'm not needing output, I'm trying to _assign_ a value
to that position.  I know how to overload the "=" operator, but _how_ do you
do _both_ operators at the same time?

Perplexed++
(any ideas?)
e-mail me if you have an answer!  This one's been bugging me.
 - Brad
--
 Disclaimer: "I really don't care."

 |) |) /\ |\  | Brad S. Choate                      | 1314 E. Market, Apt. 6
 |) |\ || |/  |                                     | Searcy, AR  72143
 --------_--  | choate@acs.harding.edu              | (501) 279-2584
  <||()/\|[   | V.P., Software Extensions, Inc.
Newsgroups: comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Alternatives to operator.()
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 23 Jul 1992 18:34:54 GMT

wmm@world.std.com (William M Miller) writes:

>In article <1992Jul23.024159.18039@microsoft.com>, Jim Adcock writes:
>> No circumlocution is necessary because of "implied this."
>
>No circumlocution is needed in the smart reference's member functions,
>agreed, but that was not the context I was describing.  If there is a
>"metaoperation" to be performed on the smart reference itself, the
>circumlocation *is* necessary.  Such metaoperations might include
>status queries, cache invalidation, network rerouting, etc.

True.

However in general the idea with smart references is that they be "just like"
real references, so that most of the code doesn't need to tell the difference.
One would expect therefore that most of the code would not need to access
such meta-operations.

There are also several ways of hiding away the circumlocution, if it still
bothers you (variations on the usual macro-hackery). One way would be to
use a functional syntax for the meta-operations:

	SmartRef r;
	invalidate_cache(r);
	query_status(r);

Alternatively you could define one function on smartrefs that returns
a smartref-controller:

	Smartref r;
	control(r).invalidate_cache();
	control(r).query_status();

This looks like a nice way of doing it to me, since it visually flags
the use of meta-operations, while still allowing the normal "." syntax.

[I've left the implementation details unstated; perhaps someone with a little
time to spare might like to fill them in.]
-- 
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!
From: daniel.edelson@inria.fr (Daniel R. Edelson)
Newsgroups: comp.std.c++
Subject: Re: name of class as name of nonconstructor member
Date: 22 Jul 92 09:22:18 GMT
Reply-To: Daniel R. Edelson <daniel.edelson@inria.fr>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France

In article <4011@seti.UUCP>, daniel.edelson@inria.fr (Daniel R. Edelson) writes:
|> I think the following code is illegal, but am not
|> certain the draft Standard contains a prohibition.
|> 
|>    struct S {
|> 	int S;
|>    }; 

Thanks to Jerry Swartz for pointing out the last line of 
section 9.2. The code is legal.
Newsgroups: comp.std.c++
Subject: Re: How do I... (regarding overloading)
From: pjl@sparc5.cs.uiuc.edu (Paul Lucas)
Date: Tue, 28 Jul 1992 16:45:33 GMT
 <1992Jul23.012111.16784@microsoft.com> <1992Jul23.154922.26676@sunb10.cs.uiuc.edu> <1992Jul27.193701.6815@microsoft.com>
Distribution: usa
Organization: University of Illinois at Urbana-Champaign

In <1992Jul27.193701.6815@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

>In article <1992Jul23.154922.26676@sunb10.cs.uiuc.edu> pjl@sparc11.cs.uiuc.edu (Paul Lucas) writes:
>|	Why do they want to do that?  If I want to call functions on
>|	temporaries, that's my business (and I accept any consequences).
>|	I think that compiler warnings are sufficient.

>Remember, if you say that warning are sufficient, then you are also saying
>that not having warnings is sufficient, because warning represent a compiler
>implementation, not a language specification.  Errors are part of the language,
>warnings are implementation specific.

	True.  Perhaps the inclusion of warnings (and the ability to
	selectively turn them off) is what will differentiate vendor X's
	compiler from vendor Y's.  People could put this down on their
	requirements list when shopping for a compiler; if a vendor's
	compiler isn't robust, they could shop elsewhere.  Marketing by
	word-of-mouth will hopefully prod compiler vendors to include
	warning also.

>Why would they not allow functions on temporaries?  Beats me, but someone
>is proposing this.  I don't know the details.  Perhaps it relates to all
>the committee discussions about trying to invent special case rules for
>handling the lifetimes of temporaries?   As opposed to handling the lifetimes
>of temporaries just like all other objects?

	Hello?  Anybody on the comittee want to answer this?
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Problems casting an object derived from a virtual base class.
Organization: TauMetric Corporation
Date: Tue, 21 Jul 1992 17:10:19 GMT

shang@corp.mot.com (David (Lujun) Shang) writes:

>In article <1992Jul19.151041.5458@taumet.com> steve@taumet.com (Steve Clamage)  
>> The proposals have been to allow runtime type information only for types
>> with virtual functions.  (Some questions were raised this past week at the
>> C++ meeting about type information for built-in types, but that doesn't
>> apply to this discussion.)  Type information would then be tied to the
>> virtual table for the type.  There would be no space overhead in any
>> object.  (The type information is per class type, not per object.)
>> 

>You still need reverse information for classes with virtual functions for a  
>proper downcast from a virtual base to the derived.

That is part of the RTTI, not necessarily stored in the object.  Example:

class b1 { ... };
class b2 { ... };
class d : virtual public b1, virtual public b2 { ... };
class e : virtual public b1, public d { ... };

b1 *p = ...;

Variable p will point to some object of type b1, d, or e.  To cast from
b1* to e*, we use a "checked cast", which looks up the type information
at run time.  The data needed for the conversion is part of the type
info.  Typically, the virtual base is contiguous with the rest of the
object, so only an offset is needed.  Non-contiguous virtual bases
cause a number of problems which the implementation would have to
solve, including this problem.

We don't need to specify in the standard something which turns out to
be perfectly efficient for any conceivable implementation.  The
standard does not require virtual tables or pointers to them, for
example, but merely allows them.  Less-efficient implementations are
possible and allowable.  More efficient implementations might be
possible with smarter compilers and linkers, and would likewise be
allowable.

An implementation which required reverse pointers in objects would
still be allowable, but users would probably vote with their purchase
orders for other implementations.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.std.c++
Subject: Re: Alternatives to operator.()
Date: 30 Jul 1992 21:45:38 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

In article <Bs6n59.GD@world.std.com> wmm@world.std.com (William M Miller) writes:
>The reason I "ignore" this point is because it is irrelevant to the subject
>of the analysis I was making -- that built-in "." is different from built-in
>"->" because the former does not have a corresponding run-time operation,
>while the latter does.  Since the built-in "." has no runtime operation, it
>does not make sense, IMHO, to allow an overloaded operator.(), since
>overloaded operators are primarily runtime operations (calling a function to
>perform some action).  The built-in "->" _does_ perform a runtime operation
>(indirection), so providing an overloaded operator->() does make sense from
>this perspective.

I don't want to take any sides in this mudfight, but the preceding
analysis strikes me as particularly bogus.  Without looking at the
assembly language, you don't know what "." or "->" do in terms of
run-time operations.  In different contexts (in C, ignoring C++) they
do different things -- for instance, "&(X -> a)" is not performing an
indirection.  In certain compilation modes (e.g., position independent
code generation) they do different things at run-time.  If you're
interpreting the program, they may do other different things at
run-time.  From my current point of view (head firmly stuffed into the
back-end of a compiler) it all looks like bits, and (after cfront and
cc and the optimizer get through with them) not very attractive bits.

So, do please try not to confuse the language specification with the
language implementation/compilation.  (Didn't I say this once already
in a different context?)  If, generally speaking, a proposal isn't a
run-time turkey (a well-defined term, eh?), then it ought to be
evaluated on how well it works with the rest of the language and what
programmers need.

David Chase
Sun
Newsgroups: comp.std.c,comp.std.c++
From: ebb@world.std.com (Earl B Beutler)
Subject: NIH Class Library
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 29 Jul 1992 22:05:48 GMT

I have seen a number of commercial references to an "NIH
Class Library", which apparently was developed at the NIH
and is in the public domain.  Does anyone know where to
obtain this library?

Thanks for your help!
Earl B. Beutler
ebb@world.std.com
Research Information Systems
Phone: (619) 438-5526
Newsgroups: comp.std.c
From: bbs.dennis@tsoft.sf-bay.org (Dennis Yelle)
Subject: can I call vprintf() twice in a row?
Organization: The TSoft BBS and Public Access Unix, +1 415 969 8238
Date: Sat, 25 Jul 1992 01:19:58 GMT

#if 0
    Is the following legal ansi c?
    I beleave that it is, but if not, I would like to know why not.
    Note in particular that vprintf() is called twice in a row.
    I just discovered a vprintf() that changes arg_ptr when
    I do this, causing the second vprintf to fail.
    In case you are wondering, the bad vprintf() came from Watcom.
#endif

/* --------- cut here for vfpf.c -------------------- */

#include <stdarg.h>
#include <stdio.h>

void report( char *fmt, ...)
{
    va_list arg_ptr;
    
    va_start( arg_ptr, fmt);
    vprintf( fmt, arg_ptr);
    vprintf( fmt, arg_ptr);  /* Yes, we want to print it twice.     */
                             /* In the original program, the second */
                             /* was vfprintf to a log file.         */
    va_end( arg_ptr);
}

main( int argc, char **argv)
{
    int a;
    
    for( a=0; a<argc; a++) {
        report( "arg %d is %s\n", a, argv[a]);
    }
    return 0;
}
/* --------- cut here for vfpf.c -------------------- */

--
Dennis Yelle (bbs.dennis@tsoft.sf-bay.org)
Newsgroups: comp.std.c
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Aligning an arbitrary pointer?
Date: 25 Jul 92 19:56:42 GMT

pds@lemming.webo.dg.com (Paul D. Smith) writes:
>I would
>expect that on at least some systems the compiler will happily allow
>you to assign 0x01381 (or some other non-aligned value) to an int*,
>say, and then just core with a bus error (or otherwise die) when you
...
>In fact I'd much rather it did that than quietly modify my pointer by
>dropping bits... it would be a *major* pain to find *that* bug! :-)

One common reason for dropping the additional accuracy is when the pointers are
actually of different format, so that the pointer-to-int cannot represent the
finer-grained pointing.  For example, the machine may be word-addressed, so
that (say) only every four eight-bit-bytes does the address go up by one (so
like the pointers to adjacent ints will have adjacent internal values).
Then a pointer-to-char may be larger than a pointer-to-int and contain the
pointer-to-int's information plus a number which is 0, 1, 2, or 3.  A cast from
pointer-to-char to pointer-to-int would simply have to throw away this second
number.