HDTenEightyP/NetNews huggingface dataset:
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: pointer comparisons
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 9 Jan 1993 19:01:36 GMT

In article <1993Jan7.025948.23000@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>	struct X { int i ; } ;
>	struct D : public X {
>		X xInD ;
>	} ;
>
	This example is not contentious. But:

	struct X { virtual int f()=0; };

	struct Y : public X { int i; int f(){return i;} };

	struct D : public X {
		Y y;
		int j;
		int f(){return j;}
	};

Now this example IS contentious. For an implementation not using
vtble pointers, the abstract class X might occupy 0 bytes.

Then:

	D d;
	d.i=1;
	d.j=2;
	
	X* p1=&d; // base subobject
	X* p2=&d.y; // included object base subobject
	p1==p2; // OH!
	cout<<"1=="<<p1->f();
	cout<<"2=="<<p2->f();

and I dont see how such an implementation could actually work
UNLESS at least the language require that abstract base
subobjects occupy at least one byte.

I dont believe this is required by the ARM, clearly it should be.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.std.c++
From: webb@tsavo.hks.com (Peter Webb)
Newsgroups: comp.std.c++,comp.lang.c++
Subject: RESULTS: C++ file extension survey
Date: 6 Jan 1993 12:44:34 -0500
Organization: Hibbitt, Karlsson & Sorenson, Inc.
NNTP-Posting-Host: tsavo.hks.com


On Dec. 11, 1992, I surveyed the Net to determine the most popular extension
to use for C++ code.  Each respondent was permitted multiple votes.
Here are the results:

Total votes: 72

           |      |      |      |      |      |      |
___________|__.C__|__.c__|_.cxx_|__.cc_|_.cpp_|_.c++_|
           |      |      |      |      |      |      |
In favor:  |  9   |  3   |  2   | 16   |  8   |  2   |
___________|______|______|______|______|______|______|
           |      |      |      |      |      |      |
Against:   | 12   |  7   |  5   |  1   |  3   |  4   |
___________|______|______|______|______|______|______|
           |      |      |      |      |      |      |
Total:     | 21   | 10   |  7   | 17   | 11   |  6   |
___________|______|______|______|______|______|______|

The distribution of the votes is very interesting.  The .C extension got the
most votes, but more people voted against than for it, though not by an
overwhelming majority.  Most people who voted against .C did so because it
is not appropriate for machines with case-insensitive file names, including
PC clones.  Some, however, did object to it because it is visually difficult 
to distinguish from .c. The .cc extension is the least controversial, with only
a single respondent objecting to it.

Note that this distribution is counter to the advice given in the FAQ, which
recommends .C for Unix machines and .cpp or .cxx for DOS and OS/2.

Respondents agreed that there was no standard or consensus yet.

-- 
Peter Webb 					webb@hks.com
Hibbitt, Karlsson & Sorenson, Inc.		Voice: 401-727-4200
1080 Main St, Pawtucket RI 02860		FAX: 401-727-4208 
Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: pointer comparisons
Organization: Liant Software Corporation
Date: Fri, 8 Jan 1993 15:01:13 GMT

In article <9300812.4038@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
> maxtal>	One consequence: abstract objects can exist.
> maxtal>
> maxtal>	Corollary: such objects have states not accessible via
> maxtal>	the contiguous storage allocated for them.
> maxtal>	(via virtual function calls)
> 
> To me, an abstract class is a class without any actual objects of that class,
> so the idea of an "abstract object" seems to be an oxymoron. Similarly, the
> idea that an object can have "state" that is not stored in its "storage" seems
> to make a mockery of the whole idea of "storage".

Since John MAX Skaller was drawing inferences from my belief that base
class subobjects are objects, I want to go on record.  I agree that
"abstract objects" can exist, but the corollary does not follow.  

The easiest way to find an actual object of an abstract class is from
the point of view of a constructor for an abstract class.  What's the
type of the object pointed to by 'this'?  The type of that object is the
abstract class, no question about it.

In the corollary, John MAX Skaller is referring to a different scenario
in which the object of abstract class is a base class subobject of a
fully-constructed enclosing object.  He concludes that the state of the 
enclosing object is part of the state of the base class subobject.  The
reasoning has something to do with the additional state being accessible via
virtual function calls, but there's a big hole in it.  Virtual functions 
(and non-virtual functions) can access any number of other objects,
independent of the object for which they are called.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
Newsgroups: comp.std.c++
From: greg@harvey.qualcomm.com (Greg Noel)
Subject: Re: Use of nested functions (Was: Proposal for default scope)
Organization: Qualcomm, Inc., San Diego, CA
Date: Sun, 10 Jan 1993 02:34:40 GMT

Steve Clamage <steve@taumet.com> writes:
>I have to disagree with this point.  C++ hides a lot of grungy detail
>from the programmer, with the consequence that simple constructs may
>require a lot of compiler-generated code.

There's a difference between hiding a lot of grungy detail and intrinsic
inefficiency.  If the compiler filling in the grungy details is what is
causing the inefficiency, the programmer can always replace it with something
more efficient.  If it's inefficient because of something required by the
language, that's not possible.

It's curious---I posted my original article to try to start a discussion
about how something like modules or packages could be added to C++ as
seamlessly as possible, because I see that as something that the language
doesn't handle well and needs badly.  But most of the responses have been
from people who reacted to one throw-away clause as a disparagement of
nested functions, which is not what I intended at all.

Personally, I'd prefer to let those who feel passionately about nested
functions debate this point.  As it is, I'm mooting a point about which
I don't care very much.  In my thirty years of experience, including using
languages that provided them, I've only wanted nested functions a few
times---and I've _never_ wanted to take the address of one.  If I don't
use them and if they don't cause me any inefficiency, then I don't really
care if they are present or not.

On the other hand, there are literally hundreds of times I've wanted to
have a helper function that was not externally visible.  In C, a static
function provides most of the functionality I want, while in C++ it's
all but impossible.  If C++ wants to be considered a ``better'' language
than C, that's something that will have to be addressed.
-- 
-- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: RESULTS: C++ file extension survey
Organization: TauMetric Corporation
Date: Tue, 12 Jan 1993 17:01:09 GMT

bright@nazgul.UUCP (Walter Bright) writes:

>In article <1993Jan7.182757.8297@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>/It would be really nice if everybody
>/agreed on some common extension; I'm tired of wrting batch files to
>/rename things, and shell scripts to build symbolic links when I switch
>/from one platform to the other.

>Zortech C++ will recognize .cpp, .cxx, .cc and .c++ all as valid C++
>filename extensions, though our examples all use .cpp.

Not to be outdone, I should say the same is true of Oregon C++, a product
of my company.  We don't discriminate on the basis of file names, as long
as the extention starts with 'c' or 'C'.  Further, you choose C or C++
compilation with a compiler flag, not via the file name.  If you wish to
choose compilation mode on the basis of file names, you can write that
into the make file script.

If you are unhappy with the parochial attitude of your C++ compiler,
complain to the vendor, or switch to a more ecumenical one.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: pointer comparisons
Date: 05 Jan 93 00:25:47 GMT
Organization: Microsoft Corporation

In article <1992Dec31.152700.21521@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
|"Same type" is a term used repeatedly in the ARM.  It has its limitations,
|but is adequate for my purpose.

"Defined by use"?  How about a "real" definition?

|"Point to distinct objects" would imply two things:
|(1) Each operand points to one object (not a function, and is not null or
|    invalid).
|(2) The objects are not identicial.  I hope to say more about this in 
|    another article.

Presumably distinct objects are not identical and objects that are not
identical are distinct? ;-)  I hope you will tell us more about this
later!

|The case I'm concerned with is limited to "objects of that type", i.e.
|each operand points to a properly constructed object of type A (which may
|be a subobject of an enclosing object constructed with a different type).

Define "subobject" and "enclosing now."

|"Compare not equal" is self-evident; the C standard uses the same kind
|of wording.  It means that the result of the operator != is 1 (TRUE) and
|the result of the operator == is 0 (FALSE).

"Compare not equal" was self-evident in C because C has a clearly stated
object model with well-defined object identity.  No such luck in C++.

Newsgroups: comp.std.c++
From: mbb@litwin.com (Mark Beyleveld)
Subject: Re: initialized 'global' (extern) char arrays
Organization: Litwin Process Automation
Date: Fri, 8 Jan 1993 13:55:47 GMT

jimlynch@netcom.com (Jim Lynch) writes:

>I am given to understand that the storage allocated by
>
>char *x = "abcde" ;
>
>is not writable.

As was also pointed out, the problem is more subtle, in that somewhere
further into the program, one cannot distinguish between the above, and
strings that were malloc'ed.

There are two solutions, depending on what the author intended:

1) If it is supposed to be read-only, declare it as

    const char * const x = "abcde" ; 

Note that this asserts that the value of the pointer may change, but what
is pointed to is constant.

Also, note that unless the constness is deliberately cast away, one
should not be able to attempt to change the data.

2) If it is not to be read-only, 

	char * x = strdup("abdce");

This is ugly, in that twice the storage is required, but now it is legal 
to say free(x);

There is a similar but more subtle problem:

char * x = strdup("abcde");
char * y = new char[6];
(void) strcpy(y, "abcde");

Further down the road, I want to dispose of the data (which is legal,
since both are dynamically allocated). Do I use free or delete? If
new and delete have not been overloaded, most heap manager implementations
would not care, but this is relying on compiler implementation.

One could declare internal coding standards, but if one uses a third-party
library (for which there may be only object code), what then?


-- 
---------------------------------------------------------------------
Mark Beyleveld
Litwin Process Automation
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Type System
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Mon, 11 Jan 93 23:34:27 GMT

In article <1993Jan10.162757.1097@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:


jss:
|> >You're right.  I knew about that loophole, but forgot about it when
|> >I posted my original item.  If anyone has ideas for a clean way
|> >to close this loophole, I'd be interested to hear them.  
|> 

maxtal:
|> 	Do we want to close it?


I do.

jss:
|> >
|> >The problem is that the object is only "marked" immutable when the
|> >constructor returns.  The constructor itself is supposed to be free
|> >to modify the object in any way it chooses.

maxtal:
|> 
|> 	The problem is that the object is *never* marked const.
|> What is made const is the 'reference' or pointer to the object.

The original item explained that "marking" wasn't actually caried
out a runtime, but the concept is useful in explaining the intentions
of the type system.

To repeat. The desired (by me) property (with slightly more
explicit wording than the original and avoiding the use of "mark's")
is 

	If an object is constructed const(immutable), then
	between the time that the constructor (if any) completes
        and the destructor (if any) is called (if ever) the
        type system should guarantee that any expression that refers to 
        this object or a subobject of it will do so via
        const(qualified) type.  

I use const(immutable) to indicate a property of an object, and
const(qualified) to indicate a property of a type.

This is a desirable property whether or not "const" has any effect
on the primitives, and whether or not the language specifies the
effect of modifying a const(immutable) object.

Anything that permits violation of this property is a "loophole".

The rest of maxtal's discussion concerned the meaning of "const",
which is a different subject altogether.

   -- Jerry Schwarz
Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: pointer comparisons
Organization: Liant Software Corporation
Date: Mon, 11 Jan 1993 19:23:37 GMT

In article <1993Jan8.181100.10727@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
> In article <1993Jan8.150113.1643@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
> >> maxtal>	Corollary: such objects have states not accessible via
> >> maxtal>	the contiguous storage allocated for them.
> >> maxtal>	(via virtual function calls)
> >> 
> >Since John MAX Skaller was drawing inferences from my belief that base
> >class subobjects are objects, I want to go on record.  I agree that
> >"abstract objects" can exist, but the corollary does not follow.  
> 
> 	Well, you can have a pointer to another object in an object,
> and access the other object via the pointer, right?
> 
> 	But this doesn't count :-) The pointer is part
> of the state of the object, and thus so is the object pointed
> to (and so on recursively)
> 
> 	In any case, I will fill in the hole:
> 
> 	class X {
> 	public:
> 		virtual int f()=0;
> 	};
> 
> 	class Y : public X {
> 		int i;
> 	public:
> 		int f() {return i;}
> 		void setint(int j) {i=j;}
> 	};
>  
> In this single example, the abstract subobject X in Y has
> public states  of measure 'int'. (There are 'int' values).
> Yet X has private storage of measure zero.
> 
> Where is the hole in this argument? Answer: X has a vtble
> pointer!  

Yes, that's close to the way I look at it.  X declares a virtual function f
with the consequence that any subobject of type X includes
some indication of how f has been overridden in constructing the enclosing
object.   f may refer to non-contiguous storage, but that's no more
problematic than if X had a pointer member which refers to non-contiguous
storage.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com

Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: pointer comparisons
Organization: Liant Software Corporation
Date: Thu, 7 Jan 1993 15:23:29 GMT

Jim Adcock writes:
> |And a "base subobject" bears an analogous relationship to the
> |containing object(s).  
> 
> I disagree.  I consider the analogy to be sufficiently weak 
> that I don't think a consistent set of rules can be developed
> for both base parts and other objects that reasonably captures
> the behavior of both categories.

It always seemed to me that the very term "base class subobject" was
making the analogy, and pointing to the fact that there were other kinds of
subobjects, i.e. elements and members.

If you don't think base class subobjects can be objects and still
support a reasonable set of rules regarding objects, how about saying
more clearly what's the conflict with the present rules?  Your multiple 
inheritance example is interesting, but do you think it indicates any
difficulties for Jerry Schwarz's and my reading of the rules?

(You have indeed pointed out one conflict with the present rules.  1.3 of the
working paper says that an object occupies a contiguous set of bytes,
which conflicts with the usual implementation techniques for virtual bases
of base classes.  But it's easy enough to make an exception to this rule, for
base class subobjects.)
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Type System
Date: 12 Jan 93 21:45:47 GMT
Organization: Microsoft Corporation

In article <1993Jan9.001948.28388@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>In article <C0Iy9o.9x@frumious.uucp>, pat@frumious.uucp (Patrick Smith) writes:
||> |	If an lvalue has non-const type,
||> |	then it refers to a mutable object.
||> 
||> There is another loophole. :-(
||> But it's (I hope) an unusual type of situation. :-)
||> 
||>    struct A { A(); /*...*/ };
||>    A* pa;
||>    A::A { pa = this; }
||> 
||>    void f() {
||>       const A a;
||>       // Now pa has non-const type but points to an immutable object.
||>    }
|
|You're right.  I knew about that loophole, but forgot about it when
|I posted my original item.  If anyone has ideas for a clean way
|to close this loophole, I'd be interested to hear them.  

A* pa;

A::A() const
{
	pa = this; // compile-time error: non-const ptr to const object
}

Such a const ctor can only give its members or base parts values via
the colon section initializers.  Members cannot be changed within the
body of the constructor.  For backwards compatibility, if you don't
declare a const ctor, then the loophole would be allowed to continue
in ctors of that class, and in which case members could continue to
be changed within the body of the ctor.
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: pointer comparisons
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 5 Jan 1993 06:03:32 GMT

In article <1993Jan4.200625.5680@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>In article <9300300.29980@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>|> 
>|> As I noted in a previous article, I don't agree with Scott Turners belief
>|> that base class subobjects are objects. To me, these are absurd 
>|> consequences, and thus I conclude that the assumption used in deriving them
>|> must be flawed.
>
>Perhaps fjh would specify some of these "absurd consequences".  I
>agree with Scott.  Base class subobjects are objects. Anything else 
>would be incomprehensible to me.

	If an 'object' is something whose attributes are computed
from its internal state, then clearly subobjects need not
be objects. In the sense an object is 'self contained',
an 'instance' of an abstract class cannot be an object.

	In particular, the semantics of a virtual function
in a subobject are not encapsulated in the subobject class
definition (especially for pure virtuals :-)

	I suspect that only 'complete objects' can really
qualify to be genuine, true blue objects. 
Which is not to say they shouldn't support object identity.
However the current rules do seem to provide object
identity --- if at all -- only for complete objects.

	Since the current system does not provide subobjects
with object identity, nor do subobjects enjoy the same
'completeness' properties of complete objects, it is difficult
to argue that because subobjects are objects they ought to
have all the properties of objects---the converse argument
that because subobjects dont have the properties of
objects, they aren't objects is equally compelling and
equally meaningful (or devoid of such).

	Is the issue not simple: either we waste bytes
to obtain object identity for subobjects or we dont.

If we do .. we waste bytes.

If we dont, then comparison of pointers in a subroutine

	f(X* x1, X* x2) { if(x1==x2) ... }

is reliable only if f is called with complete object pointers.
I.e.: there is a precondition, and one that might be hard for
the caller to ensure.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: Use of nested functions (Was: Proposal for default scope)
Organization: TauMetric Corporation
Date: Sat, 9 Jan 1993 17:33:10 GMT

greg@qualcom.qualcomm.com (Greg Noel) writes:

>The ``Spirit of C'' is that expensive things are exposed to
>the programmer; C++ inherits much of this spirit.

I have to disagree with this point.  C++ hides a lot of grungy detail
from the programmer, with the consequence that simple constructs may
require a lot of compiler-generated code.

Example 1:  A class in a multiply-inherited hierarchy with virtual base
classes and virtual functions winds up with a very large and complicated
constructor, even if all the constructors for all the classes have
very simple bodies.

Example 2:  User types, with code hidden in a library, may require very
complicated runtime routines.  The very simple expression
	a + b
might invoke enormous amounts of calculation, memory management, and
even file access.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.std.c++
From: greg@harvey.qualcomm.com (Greg Noel)
Subject: Re: Proposal for default scope
Organization: Qualcomm, Inc., San Diego, CA
Date: Fri, 8 Jan 1993 22:58:29 GMT

Donald W. Rouse II <dwr@cci632.cci.com> writes:
>You can accomplish the same thing with
>	class Class {
>	private: static int helper ();
>	public:  int func1();
>	};
>although you don't get the syntactic sugar.

You miss my point.  I specifically want to be able to use a type-safe
helper function that _isn't_mentioned_in_the_class_header_.  That is, the
function is _not_ part of the interface, it's part of the implementation.  A
helper function in the class header is visible, even if it is not accessible,
and can cause an ambiguity under derivation.

Another way of saying this is that there's no reason to declare names that
are part of the implementation in the class header.  If the implementation
is changed, helper functions may be added, changed, or dropped, but as long
as the _interface_ is unchanged, clients of the interface shouldn't need to
be changed.

It also permits multiple implementations of the same interface, which you
could select among based on whatever criteria you wished: speed of operation,
space efficiency, precision of result, freedom from bugs, NIH, ....  If the
implementation functions are fixed as part of the interface, this is not
always possible.
-- 
-- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com