HDTenEightyP/NetNews huggingface dataset:
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Type System
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Mon, 4 Jan 93 19:43:18 GMT

In article <1993Jan1.172044.9659@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> Further to a previous post describing modifications to the type
|> system, I want to try to explain the underlying concept with some
|> further examples.
|> 
|> The basic idea is that 'int' and 'T' are object types,
|> whereas 'int&' or 'const int&' are not object types.
|> I would say they are 'accessors' to an object of type 'int'.
 
The semantics of "const" in types is confused because it is also
unsed with a different meaning in the English descriptions of
C++.  For several years I have been using "immutable" for this
sense of "const".  That adjective hasn't yet caught on but, 
I live in hope.

The way I understand it, when an object is created (constructed)
it can be "marked" as mutable or immutable. ("Marked" in quotes
because no runtime marking is implied).  This mark cannot be
changed.  The type system is designed so that (barring the
use of unsafe casts) the following rule is assured.

	If an lvalue has non-const type,
	then it refers to a mutable object.

Thus |int&| and |const int&| differ precisely because they
refer to objects rather than values.  The values that these
objects can hold are the same, but the information we have
about the setting of the mutability flag is different.

Discussions of "const" in the type system become slippery because
when talking about values mutability is irrelevant and so "int"
and "const int" are in some sense the same.

  -- Jerry Schwarz




Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: pointer comparisons
Date: 12 Jan 93 22:18:22 GMT
Organization: Microsoft Corporation

In article <1993Jan7.025948.23000@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
|We seem to be arguing as much about the meaning of terms
|and the model that should be used to define the semantics of C++
|as we are about what the semantics are or should be.  I don't
|think this is a fruitful discussion, so I'm going to take a different
|tack and present my point of view solely in terms of code.

So what's the point?  I can accept your code and still reserve
judgement to disagree with any implications you might try to push
forward from you particular code example.  One cannot reasonably
standardize from example.  ANSI-C realized this and avoided the
mistake of providing a conformance suite.

We do not have to agree on terms nor model.  If you put forward a set
of terms and model that I [and others] agree has to be acceptibly
implemented by all conforming C++ compilers using the "as-if" rule,
then you have won that right to that  particular model, whether or not I
"like" your particular model or terms.

An example starting point might be to put forth a simple object model
that only encompases SI and non-empty base classes.  If you can first
get "everybody" to buy into that particular model, then you might have
a starting point to expand into what model[s] compilers are allowed
to implement in regards MI, vfuncs, vbases, abstract bases, etc.

Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: pointer comparisons
Date: 06 Jan 93 19:47:10 GMT
Organization: Microsoft Corporation

In article <1993Jan5.203237.28304@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
|Yes.  An _other_ object is distinct, not identical to the object with which
|it shares storage.  For example, given
|	int x[9];
|then the bytes occupied by the objects x and x[2] overlap.

I still don't understand your [undefined] concepts of "distinctness"
and "identity"

Granted that in this case x and x[0] are different objects, and share
storage.  Yet x and &(x[0]) have identical addresses.  Likewise ANSI-C
requires a struct and its first member to have identical addresses.
So I still don't understand your [unstated] definitions of the terms
you are using.

Newsgroups: comp.std.c++
From: steve@taumet.com (Steve Clamage)
Subject: Re: initialized 'global' (extern) char arrays
Organization: TauMetric Corporation
Date: Sat, 9 Jan 1993 17:22:28 GMT

mbb@litwin.com (Mark Beyleveld) writes:

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

Is it not a good idea to use a C library version of strdup (which is
not part of the C Standard anyway) in a C++ program, for exactly this
reason.  If you need strdup, you would be better off writing your own
as a C++ function, possibly giving it another name to reduce confusion
for the readers of the program.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.std.c++
From: dwr@cci632.cci.com (Donald W. Rouse II)
Subject: Re: Argument matching
Organization: [Computer Consoles, Inc., Rochester, NY
Date: Wed, 6 Jan 1993 19:26:51 GMT

In article <1993Jan1.161813.1592@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>[...]  I would argue it is better style to have
>two functions with different names:
>
>	func_f(const int&); // proper function
>	proc_f(int&);  // procedure--warning side effects!
>

But you can't do this with (i.e., rename) constructors.
Newsgroups: comp.std.c++,comp.lang.c++
From: berczuk@space.mit.edu (Steve Berczuk)
Subject: Re: RESULTS: C++ file extension survey
Organization: MIT Center for Space Research
Date: Fri, 8 Jan 1993 17:20:50 GMT

One issue I haven't seen raised in this discussion (but which has arisen multiple
times in work situations where we are trying to decide on project-wide standards
for naming is file name length limitations. 

in a unix environment, you often want to be portable to system V systems which have
a file name limit of somethinglike 15 characters. you also want to have reasonably
descriptive names. so that seems like a good reason to use .C in a unix envirinment
rather than .cpp or .cc. Other platforms may have different issues.

what are thoughts about this?
(keep in mind that a 15 char limit really means less if you allow for 
 a ,v for the RCS file and teh "." between file name and extension and
 any subsystem prefixes you might establish at your work site)

-- 
Steve Berczuk			berczuk@mit.edu		
MIT Center for Space Research	(617) 253-3840

Newsgroups: comp.std.c++
From: sdm@cs.brown.edu (Scott Meyers)
Subject: Re: RESULTS: C++ file extension survey
Organization: Brown University Department of Computer Science
Date: Tue, 12 Jan 1993 15:30:45 GMT

In article <1569@nazgul.UUCP> 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.

I have never been able to fathom why any compiler *cares* what file
extension is used.  If I want to call my C++ source file foo.bar.baz, why
should the compiler give two hoots?  Certainly my text editor, my document
editor, my mail-reading program, etc., is happy to read/write whatever
files I tell it to.  Why do compilers insist on being so fascist?

Many compilers can actually parse more than one language (e.g., K&R C, ANSI
C, C++, Objective C), and they use the extension of the source file to
determine which parser to use, but certainly there is no reason why they
can't have a default mode and a command-line switch to tell them which
parser to use in the event that a non-standard extension is used.  Last I
looked, gcc did this.  Similarly, the command cc, CC, gcc, g++, etc., is
often more than a compiler, also invoking an assember, loader, etc.,
depending on what is passed in as an argument.  Still, there is no reason
why such tools shouldn't take arbitrary file names as long as there are
command line options to direct the behavior of the tool for nonstandard
extensions (or to override default behavior).

Scott

-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."
Newsgroups: comp.std.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: Type System
Date: Fri, 8 Jan 1993 07:32:11 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

jss@lucid.com (Jerry Schwarz) writes:
|The way I understand it, when an object is created (constructed)
|it can be "marked" as mutable or immutable. ("Marked" in quotes
|because no runtime marking is implied).  This mark cannot be
|changed.  The type system is designed so that (barring the
|use of unsafe casts) the following rule is assured.
|
|	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.
   }

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
From: pabloh@hpwala.wal.hp.com (Pablo Halpern )
Date: Mon, 11 Jan 1993 23:15:23 GMT
Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Organization: Hewlett-Packard Company
Newsgroups: comp.std.c++

In article <1993Jan06.193256.6590@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
|> In article <4048@hpwala.wal.hp.com> pabloh@hpwala.wal.hp.com (Pablo Halpern ) writes:
|> |Absolute orderings are a slightly different matter.  In the case of < and
|> |>, one might expect a significant performance improvement if the pointers
|> |are assumed to point into the same array, since the segment part can be
|> |ignored even for far pointers.  A ptrcmp() function might be worthwhile and
|> |should present no special implementation problems for segmented
|> |architectures.  However, systems (like the lisp machine) where pointers
|> |change behind the program's back DO present a problem since the
|> |bit-pattern-based ordering could change even if the equality/inequality
|> |property does not change.  This would argue against *requiring* a ptrcmp()
|> |function.
|> 
|> Except some OS's using segmented architectures implement movable segments, 
|> in which case the problem becomes the same as lisp machines --
|> "pointers change behind the programmers back"

Perhaps, but not usually.  Part of the power of segments is to be able to
change the physical location of a segment without changing pointers to that
segment.  Never the less, the problem DOES exist on some architectures,
both segmented and not.

|> 
|> My claim is that in either of these cases the pointers *aren't* changing --
|> they still point at the same objects.  What is changing is the underlying
|> implementation of the pointer, which is an implementation issue not
|> a language issue.  Casting pointers to and from int remains as always
|> implementation dependent.  The only issue in question is whether we
|> should introduce a new requirement on OS's that the OS must maintain
|> a total ordering on their objects.  Clearly IMHO this would represent
|> a stumbling block to many OS's, such a the lisp machines, movable segment
|> OS's and OO databases.  Making such a new requirement on C++ would make
|> C++ not reasonably portable to these systems.  The question then is
|> whether or not the standard C++ language should exist on such machines.

Exactly.  Maintaining a total ordering of objects based on pointers to
those objects is not resonable in some OS's.  IMHO, the need for a total
ordering of pointers is not as compelling as the ability to implement the
C++ standard on the widest variety of architectures.  A function like
ptrcmp() should fall into the "common extentions" catagory.  Most
systems could implement this function using a varient bit-by-bit
comparison.  Systems that patch pointers in running code could not
implement this function.

-- 

- 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++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: pointer comparisons
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 8 Jan 1993 01:05:26 GMT

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 meant the ones that I quoted in the article I was responding to
(maxtal = John MAX Skaller):

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

I can understand the opposing view, but it seems to me that we are just
starting from different axioms. Anyhow, this discussion does not seem to be
very fruitful.

-- 
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++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Compiler should generate virtual destructors
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 4 Jan 1993 15:48:17 GMT

In article <C0Ayt4.263@fiu.edu> feathers@serss0 (Michael Feathers) writes:
>In article <1992Dec31.050150.28929@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>I would like to propose that if a class has virtual functions,
>>then any destructor generated by the compiler will be virtual
>>by default.
>>
>>(The suggestion was first read by me in a paper of Markku Sakkinen,
>>who claims it was not his idea originally either.)
>>
>>Advantages: much safer, ensures correct deletion of objects
>>by default.  Removes a source of bugs. Removes the reminder
>>that its wise to do this from the FAQ.
>
>This would be a way in which a function within the source code would be
>virtual without the keyword 'virtual' having been used on it or a function of
>the same name in an inherited class.  That would bother me as a consistency 
>issue.

	Yes. But it is also a way to have a virtual function which
is NOT in the source code at all. Worse, it only applies
if the base class already has at least one virtual function.

>
>>Disadvantage: might slow down destruction a little. Can be
>>fixed by the programmer explicitly declaring a non-virtual
>>destructor.
>
>The only way to make something explicity non-virtual would be the absence
>of the 'virtual' keyword, unless we add a new keyword <shudder>.

	Yes, just define a destructor in the base class without
the keyword virtual.
>
>If the destructor is going to be made virtual by that rule, there is no
>need to declare it virtual.  But we can not make it explicitly non-virtual
>unless the virtual keyword is an option.

	Sure we can:

	class X { virtual fred(); } // has a virtual destructor
	class Y { virtual fred(); ~Y(){} }; // non-virtual destructor

The rule only applies to compiler generated destructors.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.std.c++
Subject: Re: Use of nested functions (Was: Proposal for default scope)
Date: 8 Jan 1993 21:42:16 GMT
Organization: Sun
NNTP-Posting-Host: rbbb

>Fergus James HENDERSON <fjh@munta.cs.mu.OZ.AU> writes:
>>Many people seem to think that the purpose of nested functions is purely
>>as encapsulation, a sort of code organization/modularization feature.
>>... the real reason that they are useful is that ... their addresses can
>>be passed to any function that just expects a function parameter.
>>If a local function never has its address taken, then it does not use
>>the full power of nested functions.

greg@qualcom.qualcomm.com (Greg Noel) writes:
>This is a valid point, but this is exactly the part that is expensive to
>implement.

This is not correct.  Nested functions are not expensive to implement.
I speak as someone who has done it.  Compared to the costs of
programming, and the potential wins (simpler interfaces, less
temptation to use thread/signal-unsafe global variables) nested
functions are a clear win.

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

Is this good or bad?  Does this decrease the cost of
writing/maintaining programs?  Does it make it easier for you to write
reusable code?  Does it lower the rate at which you introduce bugs to
a program?

David Chase
Sun

Newsgroups: comp.std.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: pointer comparisons
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Mon, 4 Jan 93 20:06:25 GMT

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.

Given a (pointer to) a base class subobject it is sometimes
necessary to find the containing derived class object. In the
past this conversion operation was necessary only for virtual
function call, but the semantics of C++ are best understood
by considering it a non-trivial operation.  In the future,
if RTTI is accepted, this may become an explicit user invocable
operation in some contexts.

   -- Jerry Schwarz


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: Fri, 8 Jan 1993 18:11:00 GMT

In article <1993Jan8.150113.1643@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
>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)
>> 
>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.  
>
>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.

	Um: globally defined objects yes.
	What else?

	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!  So I'm wrong. I concede.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: hlf@nic.cerf.net (Howard Ferguson)
Newsgroups: comp.std.c++
Subject: Latest on run-time type checking
Date: 10 Jan 1993 21:16:20 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net

Can any one tell me where I can find out what the latest proposal of
run time type checking is that the ANSII C++ committee are considering,
or have they already agreed on something ????
	ta,
			hjf

Newsgroups: comp.std.c++
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Need ANSI / POSIX spec for C
Date: Wed, 6 Jan 1993 21:53:52 GMT
Organization: U of Toronto Zoology

In article <tork.726279621@mozart> tork@convex.com (Bill Torkelson) writes:
>You can order the C standard by sending $139.10 ($130 + 7% S&H) to:
>
>	ANSI
>	11 W 42nd Street
>	New York New York 10036

Often a more convenient source for such things is Global Engineering
Documents, (714)261-1455.  For one thing, unlike ANSI, they take phone
orders using credit cards.
-- 
"God willing... we shall return."       | Henry Spencer @ U of Toronto Zoology
       -Gene Cernan, the Moon, Dec 1972 |  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.std.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Struct hack one last time (one last time)
Organization: SoftQuad Inc., Toronto, Canada
Date: Fri, 8 Jan 93 06:59:47 GMT

> ... Again, the basic question is still unresolved here: can a conversion
> from one pointer type to another affect bytes other than those
> where the pointer variable is stored?

There is nothing in the standard to justify such an action, so it
would be permissible only under the "'as if' rule".  It could, for
example, modify bytes that the program mustn't read because the
behavior would be undefined, such as the bytes of an object of
indeterminate value.  It could modify the bytes of a volatile object.
But it could NOT modify some arbitrary object with a well-defined
value that the program correctly expects to persist!

In particular, it could not modify padding at the end of a struct,
precisely *because* it would break the struct hack.  Another example
of code that would break is:

	struct st {
		/* anything */
	} *stp;
	union {
		struct st st;
		char chch[sizeof(struct st)];
	} uu;
	void *vp = &uu;
	int i;

	for (i = 0; i < sizeof uu.chch; ++i)
		uu.chch[i] = '#';
	stp = vp;
	for (i = 0; i < sizeof uu.chch; ++i)
		assert (uu.chch[i] == '#');

-- 
Mark Brader            \ "It's not in the slightest bit harder to write Fortran
SoftQuad Inc., Toronto  \ or Basic programs in C++ or Smalltalk than it is
utzoo!sq!msb, msb@sq.com \ to write them in C or Pascal."   -- Peter da Silva

This article is in the public domain.
Newsgroups: comp.std.c