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

In article <9235215.11144@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
|Why would ptrcmp() be practically unsupportable in these environments?
|OODBMS's maintain an object identity for each object, so it should be
|possible to base a total ordering on this object identity. I don't see
|the problems. What makes it difficult for Lisp machines? Are efficient
|BTrees and such-like genuinely impossible on such machines?

Of course BTrees and such-like are NOT impossible -- you just don't
base them on pointers!  You base them on some other well defined total
ordering of the objects, such as based on object surrogates.

Consider the case of OODBMSs where you use virtual memory schemes
to trap on pointers to objects not in memory and then bring such
objects into memory.  Such objects have unique [large] obids globally
identifying them, and smaller pointers [addresses] to them in their
current incarnations in memory.  Granted that an inverse mapping can
give you the obid from the pointer, its just that such would typically
be very slow compared to the address comparisons you expect.  Slower
than using surrogates for example.  So why not use surrogates?

|The function should be named after its interface, not its implementation.
|The function takes two (void *) _pointers_, and returns an integer which
|is meant to be a comparison of those pointers according to some total
|ordering.
|Whether it is implemented by comparing addresses or by sending mail to
|the Usenet Oracle and waiting for a reply is not relevant.

I strongly disagree.  Because systems that DO implement ptrcmp by
sending mail to the Oracle are not going to be acceptable implementations
*in practice* of what you require.  You insist for pedagogical reasons
that *all* implementations support your hacks so that you can say your
code is portable to *all* implementations even when in fact your code does
not run acceptably on *all* machines.  Such code is NOT in fact portable.
The portability of such code is pure fiction.  You ask that system
implementors provide you with the implausible so that you can maintain
your fiction.  I disagree.  Rather we should look at those capabilities
that a *very* wide variaty of systems and implementations *can* reasonably
*in reality* support, standardize on the *reality* not the fiction, 
and leave the rest implementation defined.
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.std.c++
Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Date: 16 Dec 1992 23:47:32 GMT
Organization: Sun
NNTP-Posting-Host: rbbb

In article <24413@alice.att.com> ark@alice.UUCP () writes:
>The first time I tried to use gcc's nested functions,
>my program dumped core -- apparently due to a bug in gcc.
>The next version of gcc I tried worked.  This suggests
>that the implementation isn't exactly trivial.

See other post.  In our (Olivetti Research Center, now defunct)
experience, nested functions were not hard, though not trivial (is the
compiler that you use made up only of trivial pieces?  Somehow, I
doubt it.  Keep things in proportion.)  We implemented C-interoperable
nested functions in one (68k-only) release of Modula-3, and it was
a relative no-brainer compared to most other parts of a modern
compiler.  Keep in mind that gcc 2.* says "beta-test" all over it, so
I am not surprised if a shiny new non-standard feature doesn't work
perfectly.

David Chase
Sun
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Must derived class reserve space for an empty base class?
Date: 15 Dec 92 19:24:49 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Jim Adcock (jimad@microsoft.com) wrote:
: In article <5367@miramon.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
: |Jim Adcock (jimad@microsoft.com) wrote:
: |[ Questionable C example involving compiler-generated conversion
: |  to void* deleted ]

: On the contrary, unquestionably conforming C example involving conversions
: to char*.

I thought ANSI C specifies void* to be the generic pointer type
instead of the previous char*.  Am I (and K&R2, 2nd Ed.) mistaken?

I still would call your example a degenerate case.  I still agree with you
that it would be gross to require pointer distinctness for generic pointers.

: |The fact that applying the adress operator (&) to a reference yields
: |a pointer to the referred-to object is irrelevant, since a reference
: |is just an alias for the referred-to object.  You cannot obtain
: |a pointer to a reference (as you already know).  This should not cause
: |any trouble.

We have been talking about _pointer_ distinctness (at least I hope we have),
not the result of applying the address operator (although they coincide,
except for references and perhaps arrays).  That is how I think we had
not been clear enough.

You were applying the address operator (&) to a reference-to-X (I don't
have your example available).  The result of that is not of type
pointer-to-reference-to-X, it is simply pointer-to-X, and is a pointer to
the referred-to object, not to the reference.

If pointer-distinctness is blessed, then it should be clarified that
taking the address of a reference is not regarded as a pointer to the
reference, but a pointer to the referred-to object (to me this is
already crystal clear, as defined in the ARM).

: |Perhaps with this clarification you can finally agree with us?

: I guess I don't understand what you are asking me to agree to?

That your examples need not be relevant to the discussion, or
even more preferably:

That two non-generic pointers of the same type (possibly converted from
pointer-to-derived) to different objects or data members should be
guaranteed to compare unequal.

Please? (:-)

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Zero-length structures and pointer comparisons
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Wed, 16 Dec 1992 15:52:31 GMT

In article <1992Dec07.225634.19943@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>
>|As long as we have C++ objects, i.e. in memory, their addresses (or at least the
>|valid pointer values to access them) _must_ stay constant, because C++ has no
>|means to automatically track down and modify all pointers to an object.
>
>Wrongo.  Again you confuse language and implementation.  On the contrary, 
>I've written an internal implementation of C++ that does have the means to 
>automatically track down and modify all pointers to an object.  There
>are other systems that do this kind of thing too.  Such as early versions of
>Windows.

	Certainly, such an internal tracking mechanism (Jim, you really
actually wrote such a routine??) is legal with the
current definition of C++ provided object identity is preserved.

	Clearly retaining a total order over such a routine,
especially an incremental one, would be a heavy constraint
on the sort of algorithm you would be allowed to implement.

	Even restricting the intent of such a routine
to say, compaction: At the moment the only requirement would be that all the
pointers to a moved object be changed in one increment.
(So equality tests continue to work)

You might reorder all the objects in memory. Preserving a total order
in an incremental system might be suboptimal. So that requirement
would break your system OR force you to make it suboptimal.
(Where suboptimal might include abandoning it altogether .. and then
maybe the program wont run at all .. totally breaking the program)

	So there is a tradeoff---a class of code using Jims
sneaky tricks breaks, or an as yet non-existant class
of code depending on total order breaks.

	Perhaps unfortunately such a tradeoff can only be resolved
one way by the committee---namely that of requiring
compatibility with existing code. Because no one can be
sure Jim is the only one doing sneaky tricks. Or there arent
other types of legal sneaky tricks.

(** 'sneaky tricks' is not meant to be anything than the first words
that popped into my head.)


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: davidm@consilium.com (David S. Masterson)
Newsgroups: comp.std.c++
Subject: Re: "long long" and C++
Date: 17 Dec 92 05:20:40 GMT
Distribution: comp
Organization: Consilium Inc., Mountain View, California
In-reply-to: steve@taumet.com's message of 15 Dec 92 18:22:28 GMT
X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> On 15 Dec 92 18:22:28 GMT, steve@taumet.com (Steve Clamage) said:

> The next C standard will probably support an integer type longer than
> type long.  The C++ Committee has no proposals that I know of for
> adding such a type.  When it is added to C, it will certainly be
> added to C++.  If the ANSI C numerical extensions group decides on a
> longer integer type and it looks likely to be included in C, I would
> expect the C++ Committee to adopt it.  It is thus possible that C++
> will have it officially before C, if only due to timing.

> Whether the longer type will be called "long long" or something else is
> anyone's guess.

I've heard a lot of talk about "long long", but never understood why C would
need new syntax to represent a 64-bit integer.  Is there anything wrong with:

	char	-	8 bits
	short	-	16 bits
	int	-	32 bits		(16 on 16-bit architecture)
	long	-	64 bits		(32 on 16-bit architecture)
	long long -	128 bits	(64 on 16-bit architecture)

--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
davidm@consilium.com				Mtn. View, CA  94043
====================================================================
"Bureaucracy is a giant mechanism operated by pygmies."
-- Honore de Balzac
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: char * to const char*&
Date: 10 Dec 92 13:26:41 GMT
Article-I.D.: alice.24377
Reply-To: ark@alice.UUCP ()
Distribution: comp
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <JPOLITO.92Dec9155725@sysgem1.encore.com> jpolito@sysgem1.encore.com (Jonathan Polito) writes:

> I am curious to what the current wisdom is on accepting char* as a
> valid argument to a function expecting const char*&

It's invalid, though the reason may not be obvious at first glance.

The main thing to realize is that const char*& means "reference to
pointer to const char" and not "reference to constant pointer to
char" as one might think at first.

That means that in order to accept a char* as an argument, it would
be necessary to convert the char* to a temporary of type const char*
and then bind a reference to that temporary.  However, the reference
does not refer to a const object (because a pointer to const is not
itself a const), so it must be bound to a variable of the same type and
not a temporary.

The thing that makes this example tricky is that if we define

	typedef char* T;

then const T and const char* represent different types! -- const T is
"constant pointer to char" and const char* is "pointer to constant char".

The way to write "constant pointer to char" without a typedef it
char *const&, so the following should be OK:

	extern void f(char *const&);

	main()
	{
		char* p = /* some value */;
		f(p);
		// ...
	}

Here, p is of type "pointer to char" and there is no problem binding to
p a "reference to constant pointer to char".
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 14 Dec 92 23:07:30 GMT
Organization: Microsoft Corporation

In article <5366@miramon.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
|Other OODBMSs that use straight pointers to refer to persistent
|objects (e.g. ObjectStore,Texas) must provide a rather special
|ptrcmp(void*,void*), or disallow use of ptrcmp() for persistent
|objects (may be difficult to check).

What if ptrcmp [addrcmp] were allowed to return 0 for those objects
and/or systems that don't define an ordering for those objects?

The implication would be that one routine could be written that uses
a fast ordering scheme on those OS's and/or objects that support the 
ordering, but a slower secondary scheme would have to be included for
those cases of objects or OS's where the order is undefined. 
The secondary scheme would only have to be implemented by those programmers
*really* interested in writing *really* portable code, since a defined
ordering out of ptrcmp would be a common extension.

???
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Newsgroups: comp.std.c++
Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Date: 20 Dec 92 14:33:22 GMT
Organization: MAXTAL P/L C/- University Computing Centre, Sydney

>
>What can nested functions do that OO features of C++ can't? Use
>of nested functions sounds like you may be trying to delegate
>implementation, which is a great use for objects.
>

	What nested functions allow you to do that you cant with objects
is take a function that is getting to big and decompose it rapidly
and reliably into several smaller functions.

	The second thing you can do is rapidly and reliably factor
out common pieces of code, again to reduce the size of a function,
improve readability and reliability.

	One can then later reorganise so the functions are put
into a class instead of a function, however this is a much bigger
job, and it tends to enforce design decisions when one would
prefer to defer them. And when one does finally 'objectify'
the code, it would be nice to have the nested functions
already there waiting to be turned into members,
instead of having to do functional and data decomposition
simultaneously.

	There are times when procedural code is much cleaner
than using objects. For example, when one has some objects
with complex links between them (including mutual self reference),
it is often easier to just make the objects raw and then stick
all the pointers in. Doing it with constructors is quite tricky,
especially considering that some of the pointers dont exist yet,
and the initialisation code is spread all over the place
like spagetti. This is particularly true while rapid prototyping.

	There's also a couple of technical advantages to
having nested functions even when coding
member functions, over adding a private helper member, one being
that the class interface doesnt have to be changed.

	I've mentioned all these things, because I've just
gone through the process of taking a parser function
and turning it into an object. It took longer to
do this than write the original procedural code.
I had to do it, but I would have prefered to be able to
do some functional decomposition first, I think the whole
process would have been quicker.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: swf@tools3teradata.com (Stan Friesen)
Newsgroups: comp.std.c++
Subject: Re: Now is the time (Was: Improvements on C++?)
Date: 14 Dec 92 17:25:41 GMT
Distribution: world
Organization: NCR Teradata Database Business Unit

In article <5349@holden.lulea.trab.se>, jbn@lulea.trab.se (Johan Bengtsson) writes:
|> Is this true?  Are you all depending on "default int", you poor sods?
|> I for one _never_ depend on that rule.

I *used* to.  I don't anymore, nowadays I always declare the type of a function.
(If anything I tend towards a 'default void' style, in C, except I usually even
declare that).

And, in C++, where all function *must* be declared, I *always* declare the
return type.

-- 
sarima@teradata.com			(formerly tdatirv!sarima)
  or
Stanley.Friesen@ElSegundoCA.ncr.com
Newsgroups: comp.std.c++
From: michi@ptcburp.ptcbu.oz.au (Michael Henning)
Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Organization: Pyramid Technology Corporation
Date: Thu, 17 Dec 1992 23:25:59 GMT

ark@alice.att.com (Andrew Koenig) writes:

>The first time I tried to use gcc's nested functions,
>my program dumped core -- apparently due to a bug in gcc.
>The next version of gcc I tried worked.  This suggests
>that the implementation isn't exactly trivial.

I could also suggest that the implementor was trivial :-)

								Michi.
-- 
      -m------- Michael Henning                 +61 75 950255
    ---mmm----- Pyramid Technology              +61 75 722475 FAX
  -----mmmmm--- Research Park, Bond University  michi@ptcburp.ptcbu.oz.au
-------mmmmmmm- Gold Coast, Q 4229, AUSTRALIA   uunet!munnari!ptcburp.oz!michi
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Zero-length structures and pointer comparisons
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 12 Dec 1992 15:49:18 GMT

In article <1992Dec9.075125.22405@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
>	p != q   <=>   p < q   |   p > q
>
>for all pointers.  I'm not asking for a particular ordering, just an
>implementation defined behaviour that meets the equivalence above.
>
	Since existing 8086 implementations do not satisfy the above
condition, yet are conforming programs, would you accept Fergus
Henderson's suggestion:

	p != q <=>  ptrcmp(p,q)<0 || ptrcmp(p,q)>0

which cannot break existing implementations but provides a  total
order by way of a library function? If so, can we put this to
the library WG?


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: pete@borland.com (Pete Becker)
Newsgroups: comp.std.c++
Subject: Re: Template names
Date: 17 Dec 92 17:25:10 GMT
Distribution: comp
Organization: Borland International
Originator: pete@genghis.borland.com

In article <TEUBEN.92Dec16162305@lynx.astro.umd.edu> teuben@lynx.astro.umd.edu (Peter Teuben) writes:
>
>If one defines a template as e.g.
>
>  template <class T> class star {
>	...
>  };
>
>and also define a real class with that same 'template' name, i.e.
>
>  class star {
>        ...
>  };
>
>the Borland C++ compiler (3.0) complains. Can anybody confirm if this 
>is a Borland bug?

	I hope not, since it isn't a bug.  ARM, section 14.2:

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

	-- Pete
Newsgroups: comp.std.c++
From: girod@tele.nokia.fi (Marc Girod)
Subject: Re: Ambiguity in member pointer declaration
Reply-To: marc.girod@ntc.nokia.com
Organization: kpd
	<1992Dec15.011359.17235@lucid.com>
	<PNORI.92Dec16132118@hyperion.lsi-j.co.jp>
Date: Fri, 18 Dec 1992 12:27:28 GMT

>>>>> On 16 Dec 92 04:21:18 GMT, pnori@lsi-j.co.jp (Pochi NORIMATSU) said:
pnori> In article <1992Dec15.011359.17235@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
jss> The grammar
jss> doesn't contain any rules that derive a declarator starting with "::".
jss> And that omission is deliberate.

pnori> But in ARM section 8.2.3, it says that the declarator representing a
pnori> pointer to members has the form

pnori> 	complete-class-name :: * cv-qualifier-list<opt> D1

pnori> And complete-class-name can start with ::. Or is it typo?

Do you have a version of the ARM different than mine (1990, 
ISBN 0-201-51459-1...)?

In my book it reads in section 8.2.3, p 135:

	class-name :: * cv-qualifier-list<opt> D1

and class-name is just identifier (17.1 p 387)

when (p 392)
	complete-class-name:
		qualified-class-name
		:: qualified-class-name

and
	qualified-class-name:
		typedef-name
		class-name :: qualified-class-name

--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Pointer comparisons and templates
Date: 15 Dec 92 01:14:31 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
X-Newsreader: TIN [version 1.1 + PL8]

Dag Bruck (dag@bellman.control.lth.se) wrote:
: In the recent discussion on pointer comparisons, Fergus Hendersson
: suggested adding a standard library function ptrcmp() instead of
: extending the definitions of "<" and ">" for pointers.  I think we
: also agreed on a reasonable relationship between ptrcmp() and the
: relational operators.

: While I think ptrcmp() is better than nothing, I still think extending
: the definition of the relational operators is far better.  Consider
: this template class (the code may be wrong, I'm just inventing an
: almost real example for the purpose of discussion):

[ class template needing total ordering on objects _and_ pointers deleted ]

: Now, here's the problem: this implementation works fine for all
: element types that have an "operator < ()" including plain built-in
: types and many user-defined types.  However, it is not guaranteed to
: work with pointer elements for reasons we have discussed before.

: They way around this problem is to make a specialization for pointers:

Dag, there is another way:

Have the class template rely on a function template isless() instead,
with a specialization for pointers:

template<class T> inline int isless(T a, T b)
{ return a < b; }

inline int isless( const void* a, const void* b )
{ return ptrcmp(a,b) < 0; }

That ought to do it.  NOTE: I don't yet have a compiler that does
function templates, so this is untested.  Perhaps someone with a
more real compiler can check that this really works?

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
Newsgroups: comp.std.c++