HDTenEightyP/NetNews huggingface dataset:
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Zero-length structures and pointer comparisons
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 17 Dec 1992 04:43:04 GMT

jimad@microsoft.com (Jim Adcock) writes:

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

ptrcmp() is intended to be universal, ie. required of *all* implementations.

>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 [...]

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?

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

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.

-- 
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: Zero-length structures and pointer comparisons
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Tue, 15 Dec 1992 16:22:02 GMT

In article <1992Dec11.230534.10499@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <1992Dec10.121935.19315@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>|	The answer to this particular question is YES, they must
>|compare equal according to the ARM. And I think this is a problem
>|for OS design for the 386, for example, where the memory management
>|kernel will just have to ignore the ARM.
>
>No more nor less than any other virtual memory OS that allows
>multiply mapped pages.  Since there is no functionality in the
>language requiring such multiply mapped pages, you only get in
>this situation by invoking some system dependency, in which case
>you are making use of implementation dependencies.  If you will,
>a common C/C++ implementation defined extension to the language
>is to allow the use of OS calls in order to map various regions
>of memory to the same underlying page, allowing the same object
>to be accessed via differing addresses.  Implementation defined,
>no more nor less.
>

But Jim, it is not implementation defined, it is required that 
pointers to the same object compare equal. It is therefore
legal to have a function:

	f(X* a, X*b) {
	if(a==b) { /* special case, copy b object */ ... }
	else *a+=*b;
	}

where the += operation is destructive and wont work if a and b point
to the same object. The above code is guarranteed in C++, but
will fail on a suitably organised system. It is therefore not
allowed to do this sort of memory mapping in C++ behind the scenes,
which is what I'm concerned with...we actually want to.

So the question is really whether the requirement that pointers to
the same object compare equal should be left implementation defined.
Or perhaps more restrictions be made, like saying they must
compare equal if one is assigned from another, but not otherwise.



-- 
;----------------------------------------------------------------------
        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: pat@frumious.uucp (Patrick Smith)
Subject: Re: Zero-length structures and pointer comparisons
Date: Wed, 16 Dec 1992 22:51:29 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|	I'm not yet convinced it need bear ANY relation to
|	==, !=, < etc on pointers.

["it" == ptrcmp]


Surely one would want to insist on

   p == q   =>   ptrcmp(p,q) == 0

If this weren't true, one wouldn't be able to use ptrcmp as a basis
for organizing an ordered binary tree for searching.  Are there any
likely-to-be-common uses of ptrcmp which don't need this assumption?

Unfortunately, meeting this condition might be expensive on
segmented architectures (according to the many other postings
on this subject).


The converse,

   ptrcmp(p,q) == 0   =>   p == q

seems not quite as essential, but still very useful.  Can anyone
describe an otherwise reasonable implementation of ptrcmp which
would _not_ meet this condition?  If not, what's the harm in
asking for it?

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
From: dag@bellman.control.lth.se (Dag Bruck)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 12 Dec 92 21:52:55 GMT
Organization: Department of Automatic Control, Lund, Sweden

In <comp.std.c++> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>In article <...> dag@seldon.control.lth.se (Dag Bruck) writes:
>>
>>Suggested semantics: for any pointers p and q:
>>
>>	p == q   <=>   ptrcmp(p,q) == 0
>
>	Are you SURE you need this? Why should == and ptrcmp
>be in any way related?

Because it would be very counter-intuitive, hence error-prone, if that
equality did not hold.

I also support the additional rule suggested by Jerry Schwarz:

	if (p < q) is defined:

	p < q   <=>   ptrcmp(p,q) < 0
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Virtual base classes and mem initializers
Date: 14 Dec 92 21:31:14 GMT
Organization: Microsoft Corporation
Keywords: mem initializers, virtual base classes, multiple inheritance

In article <1992Dec11.165754.9910@Cadence.COM> cox@cadence.com (Henry Cox) writes:
|What I propose, then is that the virtual base class constructor call
|be required _only_ at the apex of a multiple-inheritance cone.
|Otherwise, the compiler should figure it out, from the base classes,
|exactly as for a "normal" base class.
|
|Comments?  Suggestions?  

1) Don't use virtual base classes.

2) If you insist on using virtual base classes, use default constructors.
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: Nested functions and trampolines
Date: 12 Dec 92 19:57:31 GMT
Article-I.D.: alice.24399
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <9234805.9274@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

> But that block may be entered multiple times, recursively, in which case
> you need more than one trampoline for a single nested function.

But each function binds a different context, so it should be
considered a different function anyway -- just like local variables.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: Zero-length structures and pointer comparisons
Date: Fri, 18 Dec 1992 07:16:44 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

pkt@lpi.liant.com (Scott Turner) writes:
|In article <1992Dec15.162202.11231@ucc.su.OZ.AU> John (Max) Skaller writes:
|It makes me uneasy, but I think Jim Adcock is correct: an implementation
|can define an extension, such as memory mapping, which overrides the usual
|execution time rules of C/C++, including the rule that pointers to the same
|object compare equal.  The rule that 1+1==2 would likewise be subject to
|"extension".

For C, this is my impression also.  Although I find the terminology
unfortunate; it's unsettling to think that a conforming implementation
could compile and run a conforming program - which could then compute
1+1 and get 3.

Has X3J16 adopted similar notions of conformity?


|Nevertheless, the C standard implies that the onus is on the invoker of memory 
|mapping to be aware of libraries and other code which may rely on the usual
|execution time rules of C/C++, such as the rule that pointers to the same
|object compare equal.  If we don't want libraries to make that assumption,
|then John (Max) Skaller is also correct to say
|
|> So the question is really whether the requirement that pointers to
|> the same object compare equal should be left implementation defined.

Here I would disagree.  I think the question is whether, if the C++
standard adopts the same notions of conformity as the C standard,
pointers to the same object should be required to compare equal
in a conforming program.

And the answer is _no_.  I hope this requirement would exist for
_strictly_ conforming programs.  And it might be _reasonable_ to
expect it to hold in conforming programs.  But in a conforming 
program which depends on behaviour undefined or unspecified by
the standard, none of the rules apply, so the standard doesn't
actually _require_ anything.  (It's not clear to me whether all
rules disappear if a program fails to be strictly programming
because it depends on implementation-defined behaviour, but it
doesn't depend on any undefined or unspecified behaviour.)

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 12 Dec 92 06:25:32 GMT
Article-I.D.: alice.24392
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <1992Dec11.231131.10956@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

> So that taking the address of a nested function in different scopes
> causes differing trampolines to be created, and differing pointers returned?

It shouldn't need to do that.  At most one trampoline is ever necessary
for a given nested function during its lifetime, namely the one that
binds the lexically surrounding context that was current when the
block containing the definition of that function was entered.

Moreover, that trampoline address is unique until the corresponding
function has gone out of scope, at which point the address is moot.
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.std.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: exceptions, unexpected() and muddle_on()
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Tue, 15 Dec 92 01:23:51 GMT

In article <spuler.724363604@coral>, spuler@coral.cs.jcu.edu.au (David Spuler) writes:
|> 
|> My question is: what happens if a function installed by set_unexpected returns?
|> Stroustrup says
|> 
|> "This will cause a normal return from a function detecting an unexpected
|> exception. .... "
|> 

The current x3j16/sc22 working paper says "The unexpected() function
[i.e. the one set by set_unexpected] may not return, but it may throw
an exception. Handlers for the exception will be looked for starting
at the call of the function whose exception-specification was violated."

Thus the answer to the question is: undefined.

   -- Jerry Schwarz
Newsgroups: comp.std.c++
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Virtual base classes and mem initializers
Keywords: mem initializers, virtual base classes, multiple inheritance
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sat, 12 Dec 1992 15:14:20 GMT

In article <1992Dec11.165754.9910@Cadence.COM> cox@cadence.com (Henry Cox) writes:
>(I posted this last night - it did not appear on our systems, so I am
>posting it a second time.  I apologize for any duplication you see.)
>
>I ran into an interesting situation with respect to multiple
>inheritance and [initialising] virtual base classes.  

>Comments?  Suggestions?  
>
	Markku Sakkinen has written a paper on this issue, due to
appear in the C++ Report I believe. it is generally felt
that initialisation by the 'join' class should be used.
	Another idea I put forward was to use the name dominance
rule, but this would require the ctor initialisers to be part
of the interface.

	The real question is 'why am I initialising virtual bases',
and 'how do I explain that there are *different* initialisers'.
It should be that if a base is initialised at all, it is initialised
in only one way. This is enforced for single inheritance by
only allowing initialisation of direct bases, and for virtual bases
by insisting that the most derived class initialises them,
even if not direct bases, so any other initialisers are unfortunately
ignored.

	This phenomenon is extremely annoying when using mixins,
when all the abstract base classes are virtual, and the whole lot
have to be initialised in the most derived class.

	A general rule of thumb would appear to be that candidates
for shared base status should never require non-default initialisation,
since this is the only reasonable way to have unique initialisation.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.std.c++
Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Date: 15 Dec 92 19:37:58 GMT
Article-I.D.: alice.24413
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <9235019.15484@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

> 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.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: srvishy@picasso.ocis.temple.edu (S. R. Viswanathan)
Newsgroups: comp.std.c++
Subject: Help needed in TEMPLATES ???
Date: 13 Dec 92 21:03:27 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 if possible..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.
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 17 Dec 92 22:10:57 GMT
Organization: Microsoft Corporation

In article <1992Dec16.150144.6004@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|In article <1992Dec14.225659.24225@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
|>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.
|
|	Why not?

Because in the cases I can think of, if one fails to be reasonably implementable
on a given system, the other also fails to be reasonably implementable, and
since C already allows that systems NOT be required to support the
pointer/integral cast.

|>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?
|
|	ptrcmp is standard, required function, it must yield a total
|	order.

I was referring to the pointer/integral cast.  It is not required of
all systems, only of some systems.  *Required* of *some* systems????
This certainly contradicts my expectations of what a "standard" means!

|	In that case it is implementable on all systems
|	where (opinion follows, please correct errors)
|
|	a) void* is big enough to hold all pointer types
This assumption is almost univerally violated.

|	b) conversions always pad systematically
|	c) bitwise comparison is done 
|	d) the bits of a pointer cannot be magically changed by the system
Violated  by real mode Windows, Violated by evacuating GC'ed machines.
Violated by at least one GC'ed C++ implementation. Violated by
at least some OODBMSs.

|	e) a pointer is implemented as an object in contiguous storage
Probably violated by some OODBMSs.

|	Certainly, (e) might cause problems on the 80x86 where part of the
|pointer is implicit and not physically stored. Does it *actually*
|cause this problem?

No because implied segments can be made specific.  Segments can
be moved on some systems however, implying an ordering that requires
the segment part will not remain consistent.  Within a segment however,
object orderings remain consistent.  Unless the PC is running a system
with GC and ptr tracing, such that objects are moved to be compacted.
Since such systems by a large margin have the best memory management
that I've seen, I think it would be a big mistake to preclude them 
for the kind of algorithm implemetation tricks you guys have been 
talking about -- especially since surrogates or similar approaches
can accomplish your goals about as well as the ptrcmp stuff.
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 16:22:11 GMT

In article <24392@alice.att.com> ark@alice.UUCP () writes:
>In article <1992Dec11.231131.10956@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>
>> So that taking the address of a nested function in different scopes
>> causes differing trampolines to be created, and differing pointers returned?
>
>It shouldn't need to do that.  At most one trampoline is ever necessary
>for a given nested function during its lifetime, namely the one that
>binds the lexically surrounding context that was current when the
>block containing the definition of that function was entered.

	Are you saying that if I have a recursive function with a nested
function in it, and store the address of the nested function in scope
at the time of entering the n'th recursion into an array in slot n,
then executing the j'th slot will access the n'th activation record
and not the j'th one? (I.e. all the functions in the array
access the most recent activation record?)

>
>Moreover, that trampoline address is unique until the corresponding
>function has gone out of scope, at which point the address is moot.

	Irrespective of how it is implemented, and even if
taking the address of a nested function is allowed, I would like
to see C++ allow nested functions.

	There are several levels to which this could be done:

	1) Same as non-nested function: no access to environment,
	BUT the name is function local, also no address taking.

	2) Allow access to environment, but not taking address.

	3) Full hog: allow address taking.

One could also restricted nesting to one level.

Andrew,
Would any of these be likely to be accepted by the committee?
Do you personally favour nested functions?
If not, why not?
Anyone else? Anyone with GNU actually using them?
Anyone hate them?



-- 
;----------------------------------------------------------------------
        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++