HDTenEightyP/NetNews huggingface dataset:
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:27:18 GMT

In article <1992Dec14.230730.24452@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <5366@miramon.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>
>What if ptrcmp [addrcmp] were allowed to return 0 for those objects
>and/or systems that don't define an ordering for those objects?
>

	Given a set of pointers p1, p2, p3, and some function f,
we require that

	f(p1), f(p2), f(p3)

be a total order, and returning 0 always is clearly a trivial
total order *of f(p)* in that case.

	Dag wanted to have

	p1 == p2  <==> ptrcmp(p1,p2)==0    (DC)

and this imposes some constraint on 'f' which would certainly
mean that returning 0 always was not a total order.

Taking 'f' to be the underlying bits of a pointer makes 
ptrcmp fast and useful, but DC will not be satisfied on
the 8086.

The purpose of ptrcmp, surely, is to allow say sorting or btree
algorithms to be applied to pointers AT ALL. It really
doesnt matter what the order produced actually is.
What's important is that the damn algorithms 
work correctly, for example terminate in the case of a sort,
or retrieve the pointer from a btree.

A completely randomly chosen total order will work for
any algorithm not requiring equality tests.
Sorts not requiring uniqueness will work.

Btrees require uniqueness so wont. They need condition DC.
Otherwise they mnay fail to put some things into the tree
(thinking there is duplication) and put others in twice
(finding duplication where not intended).

So... how about TWO functions :-)

	anytorder(void*,void*); // might give 0 always
	obeysDC(void*,void*); // must obey DC above

Now it was ALSO suggested that if < implement a partial
order, the total order be compatible with it.
If I remember my maths, this can always be done
(assuming < is a partial order ... have to go back
to my maths books and 8086 manuals here :-)

Anyhow, can we list all the possible reasonable functions,
what properties they have, what the implications are, then
pick a standard set for inclusion in the library?

Furthermore, we can also have an optional set, the condition
is that they must have the listed properties IF they are
implemented, otherwise they must NOT be implemented.
(Or, they are all implemented, but might cause exceptions
if not defined .. if you know what I mean :-)

That ensures that correct code will either work or
fail gracefully, rather than yielding unexpected results.

-- 
;----------------------------------------------------------------------
        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: srvishy@picasso.ocis.temple.edu (S. R. Viswanathan)
Newsgroups: comp.std.c++
Subject: Help needed in TEMPLATES ???
Date: 13 Dec 92 21:04:06 GMT
Organization: Temple University
X-Newsreader: Tin 1.1 PL5


Hi,

Can someone help me with this problem in Borland C++ 3.0 ?

I'm using the BI_QueusAsDoubleList template and it's iterator template
BI_QueueAsDoubleListIterator....I want to be able to do a non-destructive
iteration of the list and then do a selective deletion.

[I'm able to insert items into the list using the "put()" function...
but not able to delete items...I can only do a destructive iteration using 
the "get()" function...which also removes the item from the list.]

If it's not possible using this particular ADT template class...Can you
suggest any other template which will achieve this functionality ?

Any useful pointers and suggestions are most welcome...Please reply
to me directly..Thanx...


- Vishy


<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
  Internet: 			       <^>     Yellnet:  
     srvishy@picasso.ocis.temple.edu   <^>          (215) 787-1043 (Work)
     srviswa@astro.ocis.temple.edu     <^>          (215) 735-3563 (Home) 

  'T`(`'T`|_||) ^   'T` / | |  |       `T` n the beginning Man created God;
  (| (, | | ||\(_)   | (__| |_ |_       |  and in the image of Man
				       ,|, created he him.
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->

--
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
  Internet: 			       <^>     Yellnet:  
     srvishy@picasso.ocis.temple.edu   <^>          (215) 787-1043 (Work)
     srviswa@astro.ocis.temple.edu     <^>          (215) 735-3563 (Home) 

  'T`(`'T`|_||) ^   'T` / | |  |       `T` n the beginning Man created God;
  (| (, | | ||\(_)   | (__| |_ |_       |  and in the image of Man
				       ,|, created he him.
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
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: Fri, 18 Dec 1992 19:22:02 GMT

In article <BzCG7K.2sG@frumious.uucp> pat@frumious.uucp (Patrick Smith) writes:
>dag@seldon.control.lth.se (Dag Bruck) writes:
>| Suggested semantics: for any pointers p and q:
>|
>|       p == q   <=>   ptrcmp(p,q) == 0
>|
>|       p != q   <=>   ptrcmp(p,q) != 0
>|
>|       if p < q is defined,  ptrcmp(p,q) < 0   <=>  p < q
>
>On the other hand, this might be fairly cheap, given that
>we're already insisting on
>
>   p == q   =>   ptrcmp(p,q) == 0
>

	I'm NOT agreeing with this at present. I reject any relationship
between p ? q and ptrcmp. On some machines any such relationship
might make ptrcmp unimplementable, and thus defeat the proposal completely.
It is only Jims suggestion that ptrcmp might always return 0 that
makes it possible to make its existence mandatory.

In fact, p==q iff objects equal is unimplementable on some machines.
That is, even the existing ARM requirement is unworkable.

Consider that p < q is implementation defined, so it could mean
almosty anything. It does not have to obey ANY rules, unless
the pointers are into the same array.

As such tying < to ptrcmp, or any such function which requires
a total order immediately makes the specification inconsistent,
and thus it will have to be rejected.

Lets stop having 'wish lists' here and analyse the problem
properly. The first thing we have to do is fix the
unworkable requirement that p==q iff p,q point to same object.


	
-- 
;----------------------------------------------------------------------
        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: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 17 Dec 1992 20:45:22 GMT

In article <BzBHn4.26J@ssesco.com> nau@ssesco.com (William Nau) writes:
>
>It suggests that they didn't properly test that release.  Given
>a decent design, it's not asking that much out of a high level
>language.  It does amaze me that this wonderful object oriented
>language does not allow for nested functions.
>

	Some OO people claim nested functions are anathema to
good OO design. I have read the arguments, they relate to
cleanly dividing the problem up, and removing coupling.

	Nested function have an implicit interface
(bad design concept) to their enclosing scope.

	Not being a religious OO convert, and finding
in practice I could use nested functions here and there,
I would support their introduction, however.


-- 
;----------------------------------------------------------------------
        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: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Zero-length structures and pointer comparisons
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Fri, 11 Dec 1992 21:28:31 GMT

In article <5357@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>Put differently: the database ID total order and the corresponding
>transient pointer orders must be order-isomorphic (look it up, I did :-),
>to ensure that the total pointer order for the addresses of
>persistent objects mapped into transient memory is consistent between
>different runs of the same program.

Aren't we talking about a total ordering that is consistent for the
duration of the process?  The OODBMS objects can have an ordering that
is persistent, but obviously the transient objects won't have a persistent
ordering.  Do we care if the ordering of persistent objects is the same
between different runs of the program?  Am I missing something?

And as I said in an earlier post (which you might not have read when you
posted this), several OODBMSs allow multiple handles on the same object.
Furthermore, Objectivity (for example) has a handle in which the actual
address of the object in core is swizzled.  This swizzling is safe
because it is private to the handle, and the user's program never sees
the address of the actual object (if he is practicing safe programming).
In fact, the object might not be in core even if the handle is valid, and
the address in core may change unbeknownst to the user.  So the user
does not have the address of the object, so he won't be comparing
C++ pointers to these objects.  And in fact, comparing the address of
the actual object will not give you the consistent ordering for the
duration of the process unless you explicitly restrict the capabilities of
the OODBMS.  Since this is all OODBMS specific, it is much better to
let the OODBMS manage the ordering and forget about trying to get an
ordering out of whatever handles it gives you.

All that long-winded explanation aside, I would like to be able to 
define a total ordering on my objects - my persistent objects (stored in
various OODBMSs) and my transient C++ objects - that is consistent for
the lifetime of the objects and the duration of the process.  I don't 
have any specific need for it at the moment, but I expect I would use this
if I had it available.

Stuart

--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
Newsgroups: comp.std.c++
From: cmick@silver.ucs.indiana.edu (Baldy)
Subject: A simple problem...
Organization: Indiana University
Date: Sat, 19 Dec 1992 08:19:13 GMT

     This is propably a simple problem.  But I'm trying to write an invoice
type program for a friend.  I know how to read and write to a file but how
do you say save an invoice number, or a debit, credit amount, and then add
something to it.  I know how you get stuff from a file, but only character
by character, not integers that I can add + 1 to.
     If this makes sense, please help.

Thanks.
-- 
Later,
	Craig
cmick@silver.ucs.indiana.edu
cmick@acoma.ucs.indiana.edu
From: pnori@lsi-j.co.jp (Pochi NORIMATSU)
Newsgroups: comp.std.c++
Subject: Ambiguity in member pointer declaration
Date: 14 Dec 92 07:13:01 GMT
Organization: LSI Japan Co. Ltd., Tokyo, Japan

Sorry if this is on a FAQ list.

Assuming X, Y and Z are class names, how should

	X::Y::Z::*foo;

be interpreted?

1. foo is a pointer to member of class ::Y::Z of type X.
   ('X' is a decl-specifier and '::Y::Z::*foo' is a declarator)

2. foo is a pointer to member of class ::Z of type X::Y.
   ('X::Y' is a decl-specifier and '::Z::*foo' is a declarator)

3. X::Y::Z is a decl-specifier and ::*mptr is an error.

IMHO, correct interpretation should be 3, but I'm not sure.

Please E-mail me and I'll post a summary.

Thanks in advance!
--
Yasutoshi (Pochi) Norimatsu      | Never worry about theory as long as
pnori@lsi-j.co.jp                | the machinery does what it's supposed
LSI Japan Co. Ltd., Tokyo, JAPAN | to do.            -- R. A. Heinlein
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 11 Dec 92 23:30:39 GMT
Organization: Microsoft Corporation

In article <KANZE.92Dec10174617@slsvdnt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
|We already *have* this function.  Try the following:
|
|	void*	ptr1 ;
|	void*	ptr2 ;
|	int	cmp = memcmp( &ptr1 , &ptr2 , sizeof( void* ) ) ;
|
|This works on all implementations I can think of.  Is it guaranteed?
|(Ie: can pointers also hold undefined padding information which may
|vary in a random fashion.  Note that "memcmp" is *not* guaranteed to
|work on struct's.)

Not guaranteed, nor does there have to be random padding for it to not
be guaranteed.  All the bits could be used, but there could be multiple
bit combinations mapping to the same underlying memory address.  Early
PCs and OSs being an example.
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Must derived class reserve space for an empty base class?
Date: 18 Dec 92 15:41:08 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 <5386@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
: |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.

Your example (below) shows that at least we have established what we
are disagreeing on.

[...]
[or else] I strongly disagree,
: because I would counterclaim that pointer equality in the following
: example is a legal and perfectly reasonable, and efficient, implementation.
: On the contrary, requiring unnecessary and unexpected padding within
: structures just to meet your new requirements would be extremely 
: undesirable, in my opinion.

But the cases where "unnecessary" padding would be required would
have very minor impact on the majority of programs, at least if I
may consider the current implementation of virtuals (vtbl).  After all,
inheriting from a truly empty base class (no virtuals) is quite uncommon,
don't you think?

If pointer distinctness (as defined above) allows useful semantic constructs,
such as the very common idiom for operator=:
"if ( &other == this ) return", then a small and rare storage overhead
in examples such as the one below could easily be tolerated (IMHO).

: If you want object addresses to be
: unique, then write your code so that they are unique.

You cannot always guarantee that.  Suppose you create a class template
that uses pointers to an unknown class (T*) for identity tests (the
template could be specified to handle only statically allocated objects,
if you like).  That template cannot know that the type parameter (T)
specifies a class that will have distinct pointers to all instances,
_unless_ pointer distinctness is universally guaranteed.

Imagine the confusion that migh occur if you instantiated for example
a Lookup<B*> template class, using class B from your example (Lookup<>
is of course defined by a class/template library).

There are existing commercial class templates that rely on pointer
distinctness.  Are they invalid?

[ Jims example follows, press 'n' if you don't want to see it ]

: #include	<stdio.h>

: class A {};

: class B : public A
: {
: public:
: 	A a;
: };

: main()
: {
: 	B b;
: 	A* p1; 
: 	A* p2;

: 	p1 = &b;
: 	p2 = &(b.a);

: 	if (p1 == p2)
: 		printf("equal %lX %lX\n", (long)p1, (long)p2);
: 	else
: 		printf("unequal %lX %LX\n", (long)p1, (long)p2);

: 	return 0;
: }

-- 
--------------------------------------------------------------------------
| 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: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 14 Dec 92 22:56:59 GMT
Organization: Microsoft Corporation

In article <1992Dec12.154918.2220@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|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?

I think some flavor of "ptrcmp" makes sense on those implementations that
support casting pointers to integrals and back, and probably doesn't make
sense on those implementations that don't support the pointer/integral casts.

In either case, I would ask what kind of sense it makes to write a "standard"
that *requires* a certain behavior of *some* implementation but doesn't
*require* that behavior of *all* implementations?  How do you justify such
a dichotomy?

On the contrary, I suggest that in a "standard" either something IS *required*
of *all* implementations, or something IS NOT *required* of *all* 
implementations.  If the committee cannot agree that something IS or IS NOT 
*required* of all implementations, then what they should do instead is list 
this something as a "commonly implemented extension to the language."

Such would be the proper designation, IMHO, for both the bidi pointer/integral
cast, and for the proposed "ptrcmp" macro.  Then, on Lisp machines, or 
C++ OODBMS's or whatever systens would find the total ordering 
practically unsupportable in their environment, they simply would not implement
the "common extension."  This would be a quality of implementation issue then,
not an issue of conformance.

In any case, "ptrcmp" would be a misnomer, because what is being compared
is *not* pointers, but rather the underlying *assumed* implementation of 
pointers using machine addresses.  The correct name might be something like 
"addrcmp" then, so as to not further confuse programmers on the difference
between language and implementation.
Newsgroups: comp.std.c++
From: nau@ssesco.com (William Nau)
Newsgroups: comp.std.c++
Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Date: 15 Dec 92 20:16:15 GMT
Organization: SSESCO

>> Why are nested functions so hard? I think that 
>> Gnu C's implementation of nested functions shows that it does not
>> cause any particularly difficult implementation problems.
>
>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.

It suggests that they didn't properly test that release.  Given
a decent design, it's not asking that much out of a high level
language.  It does amaze me that this wonderful object oriented
language does not allow for nested functions.

-- 
William R. Nau
Supercomputer Systems Engineering and Services Company (SSESCO)
511 11th Avenue South, Suite 216
Minneapolis, Minnesota 55415-1536
(612) 342-0003

nau@SSESCO.com
Newsgroups: comp.std.c++
From: gjb@fig.citib.com (Greg Brail)
Subject: Re: "long long" and C++
Organization: Citibank IBISM
Date: Wed, 16 Dec 1992 20:22:42 GMT

In article <1992Dec15.182228.23669@taumet.com> steve@taumet.com (Steve Clamage) writes:
>gjb@fig.citib.com (Greg Brail) writes:
>
>>The most recent Sun ANSI C compiler (Sparc Works 2.0.1) supports a 64-bit
>>integer type called "long long". Since this type is only available with
>>the compiler in "strict ANSI" mode, I suppose it is part of the proposed
>>ANSI C standard. Is this true?
>The locution "long long" violates a constraint in section 3.5.2 of the
>ANSI Standard, and must be diagnosed as an error by a conforming
>implementation.  If the "long long" extension is available only in
>"strict ANSI" mode, they got it backwards.  I would expect such an
>extension to be available only when "strict" mode is disabled.

Sorry. I just looked at the man page for the new compiler, which says 
"long long" is available in "ANSI plus Sun extensions" mode, but disabled
in "strict ANSI" mode. So Sun didn't get it backwards.

>>But more importantly, are there any existing proposals to add "long long"
>>to the C++ standard? Such a data type would be quite useful. Are there
>>any existing C++ compilers that support, or plan to support this type?
>
>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.

Thanks for the help.

				greg
-- 
Greg Brail ------------------ Citibank -------------------- gjb@fig.citib.com
lose (lOOz) v. 1. a. To be unable to find; mislay. b. To incur the 
deprivation of, as by negligence or accident. 2. To be unable to maintain,
sustain, or keep. 3. The most commonly misspelled word on Usenet.
From: daniel@cse.ucsc.edu (Daniel R. Edelson)
Newsgroups: comp.std.c++
Subject: Re: Pointer comparisons
Date: 18 Dec 92 19:46:27 GMT
Organization: University of California, Santa Cruz (CE/CIS Boards)
NNTP-Posting-Host: oak.ucsc.edu

In article <1992Dec18.181029.1061@taumet.com> steve@taumet.com (Steve Clamage) writes:
>
>Right.  In the C Standard, it is stated explicitly that two pointers
>of the same type which compare equal point to the same object or
>function.  There is no such statment for C++ in the ARM or in the
>current C++ Committee working draft.
>
>Steve Clamage, TauMetric Corp, steve@taumet.com

There's also a problem regarding inline functions.
Specifically, under common file-based C++ implementations, 
the address of an inline function  can vary between
compilation units. Thus, the requirement from
Ansi C (Sec 3.3.9)
	``If two pointers to function types ... both point to
	the same function, they compare equal.''
is false under common C++ implementations. In my view, this
suggests that perhaps it should be illegal to take the address 
of an inline function.

Daniel Edelson
daniel@cse.ucsc.edu
Newsgroups: comp.std.c++
From: dag@bellman.control.lth.se (Dag Bruck)
Subject: Re: Zero-length structures and pointer comparisons
Organization: Department of Automatic Control, Lund, Sweden
Date: Fri, 18 Dec 1992 20:43:37 GMT

In <comp.std.c++> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
>In fact, p==q iff objects equal is unimplementable on some machines.
>That is, even the existing ARM requirement is unworkable.

No, some machines are unworkable :-).
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 12 Dec 92 20:11:37 GMT
Article-I.D.: alice.24400
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Dec12.162211.5076@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

> Andrew,
> Would any of these be likely to be accepted by the committee?

It's hard for me to say -- I am in the Core working group, which
meets concurrently with the Extensions group.  Since the latter would
consider any such proposal, and since I don't really know the dynamics
of that group, I'm ill-placed to comment.

> Do you personally favour nested functions?

In general, yes.  For C++, I'm not sure.

> If not, why not?

The main argument against it is that C doesn't have them, which means
that having them in C++ would make C interoperability more difficult.
It would also be more difficult to interface C++ programs with
low-level assembly-language things like on-board controllers.  I don't
care about that personally, but I know that other people do.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Xref: sparky comp.std.c++:1830 comp.std.c:3227