HDTenEightyP/NetNews huggingface dataset:
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Must derived class reserve space for an empty base class?
Date: 16 Dec 92 20:28:00 GMT
Organization: Microsoft Corporation

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.
|
|Please? (:-)

Either you are misstating what you think you are stating, or I am 
misunderstanding what you are stating, 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.  If you want object addresses to be
unique, then write your code so that they are unique.  Don't ask the
compiler to put the padding in for you.



#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;
}
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:05:48 GMT

In article <24398@alice.att.com> ark@alice.UUCP () writes:
>In article <1992Dec12.162211.5076@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>
[deleted]
>No, that's just the opposite of that I said.
>
>I said `the context that WAS current.'

	Phew! Sorry, I think ...
>
>Perhaps an example will make it clearer:
>
>	void (*p)(void);
>	void f(int n)
>	{
>		void g() { printf("%d\n", n); }

	of there being only *one* function 'g()' here,
not a new one for each activation record. I though you were saying
only ever one trampoline for 'g' was needed, what you meant
was at most one for each pair (g,activation of f)

-- 
;----------------------------------------------------------------------
        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: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 15 Dec 92 18:59:55 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 <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?

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

No, this is not right.  You can require that a total ordering of all
pointers exist, without assuming anything about their representation.

The abstract ordering property will probably be implemented using
machine addresses if pointers are implemented that way, but it is not
a given that total pointer ordering needs machine addresses.

Therefore, "ptrcmp" is a much better name than "addrcmp".

-- 
--------------------------------------------------------------------------
| 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: Sat, 19 Dec 1992 20:37:05 GMT

In article <5347@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
>Dag Bruck (dag@seldon.control.lth.se) wrote:
>: 	p == q   <=>   ptrcmp(p,q) == 0
>
>: 	p != q   <=>   ptrcmp(p,q) != 0
>
>: 	ptrcmp(p,q) < 0   <=>   ptrcmp(q,p) > 0
>
>I think ptrcmp() is a good way to resolve this issue.
>
>There is only one possible remaining weakness (I think):

	I disagree, but anyhow ...
>
>Any environment that relies on pointer translation (swizzling) to
>transport objects between executing processes will have difficulty
>maintaining a common total ordering for the pointers (IDs) of
>objects within those processes (Jim Adcock pointed this out).
>Examples include OODBMS and distributed systems.  Code relying
>on ptrcmp() may be unportable to those environments.
>
>Should those environments be required to (somehow) provide special
>ptrcmp() functions, that look at some object ID (not memory address)?
>What if a program uses more than one pointer swizzling scheme (e.g.
>distributing some objects over communication channels, and storing other
>objects in an OODBMS)?  Is it the users job to provide the ordering
>between those different object spaces?
>
>Anyone have a good solution for this?
>
	Yes. First look at ==. It is already flawed. The rules
must be rewritten so that == has the given semantics only
in 'domestic' cases. The results of == can be implementation
defined in any cases the pointers are not derived by
'ordinary' operations. That lets OODBMS off the hook.

	The same solution can be applied to ptrcmp now.

-- 
;----------------------------------------------------------------------
        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: girod@tele.nokia.fi (Marc Girod)
Subject: Initialization of private static members
Reply-To: marc.girod@ntc.nokia.com
Organization: kpd
Distribution: comp
Date: Tue, 15 Dec 1992 13:23:24 GMT

Hi net world!

------------------------------------------------------------
// stinit.C

class A {
  private:
    A();
    static A a;
};

A A::a; //HP CC v 3.0: error: global scope cannot access A::A(): private  member (1298)
        //
        //GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
        //stinit.C: In function `void  _GLOBAL_$I$_1A$a ()':
        //stinit.C:5: constructor `A::A ()' is private
        //stinit.C:7: in base initialization for class `A'

------------------------------------------------------------

The ARM states p 180 that 'Static members obey the usual member access
rules except that they can be initialized (in file scope)'.

This allows a private static member to be initialized, as long as the
constructor for its class is public.

Are my compilers correct in refusing me the access to private
constructors, to build a private static member?

Sorry if this has already been dealt with...

Best Regards!
--
+-----------------------------------------------------------------------------+
| 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: hendrik@vedge.com (Hendrik Boom)
Newsgroups: comp.std.c++
Subject: Re: Now is the time (Was: Improvements on C++?)
Date: 14 Dec 92 15:28:54 GMT
Organization: Visual Edge Software Ltd.

jbn@lulea.trab.se (Johan Bengtsson) writes:
: Johan Bengtsson (jbn@lulea.trab.se) wrote:
: Fergus James HENDERSON (fjh@munta.cs.mu.OZ.AU) wrote in comp.lang.c++:
: : 
: : The compiler should warn about any code that has a high likelyhood of being
: : a programming error, except where such code is actually necessary in some
: : cases and cannot easily be rewritten to avoid the warning.
: 
: I absolutely agree.  How about this one:
: 
: // myFile.cc
: class MyClass {
: //...
: };
: IMPLEMENT_TYPE(MyClass);
: 
: "IMPLEMENT_TYPE" is a macro defined in a header file, and guess what?
: I forgot to #include it.  Does the compiler warn about this?  No!
: It thinks it is a function prototype with return type "int"!
: How wonderful...

But C++ allows another place where you can leave out the int.
How about:

typedef int Foo;

class MyClass {
	MyClass(Foo())
};

Is this a constructor taking a Foo-valued function argument,
or a redeclaration of Foo in an inner scope as a method returning a MyClass?
-- 
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work:	hendrik@vedge.com,  iros1!vedge!hendrik
at home:	uunet!ozrout!topoi!hendrik
Newsgroups: comp.std.c++
From: larsn@Autodesk.COM (Lars Nyman)
Newsgroups: comp.std.c++
Subject: Re: Pointer comparisons
Date: 18 Dec 92 22:09:23 GMT
Organization: Autodesk Inc., Sausalito CA, USA

ARM specifies what a comparison of two pointers to objects should return
IF:
	- the objects are the same
	- the objects are non-static members of same object
	- the objects are elements of the same array

Otherwise, the pointer comparison is implementation dependent.


So, if I have pointers to two different objects the result of comparing
them is implementation defined !?!
Thus, I cannot even trust that a '!=' test will return 1 for two objects
that are not the same !

This must surely be wrong... can somebody, please, correct me and explain
what I'm overlooking.


Newsgroups: comp.std.c++
From: gjb@fig.citib.com (Greg Brail)
Subject: "long long" and C++
Organization: Citibank IBISM
Date: Mon, 14 Dec 1992 19:56:20 GMT

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?

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?

				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.
Newsgroups: comp.std.c++
From: pat@frumious.uucp (Patrick Smith)
Subject: Re: Zero-length structures and pointer comparisons
Date: Thu, 17 Dec 1992 00:08:15 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
|In article <BzCG7K.2sG@frumious.uucp> pat@frumious.uucp (Patrick Smith) writes:
|>
|>jss@lucid.com (Jerry Schwarz) writes:
|>|And
|>|
|>|       if p < q is defined,  ptrcmp(p,q) < 0   <=>  p < q
|>
|>
|>This strikes me as nice to have, but not essential.
|
|It makes me nervous to disagree with you, but haven't we already 
|hammered to death the concept that p < q might be defined (but 
|not generate a total ordering) if some ps and qs are not in the
|same segment?  Or do the PC compilers only permit p < q for ps
|and qs in the same array?

Please don't be nervous, Stuart!  I make _lots_ of mistakes.
(No smiley here, because it's quite true.)

This seems to depend on what one means by "p < q is defined".
I can't say what Jerry meant, but (without thinking about it
too much), I took him to mean something something like
"if the standard defines what p < q means".  Which I _thought_
meant p and q had to point to objects in the same array or
subobjects of the same object.  And p < q does have to behave
as expected in those cases (with some of the "subobjects
of the same object" cases being legal exceptions).

The emphasis on _thought_ is because then I looked at the
draft standard.  More on that in another posting...

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Newsgroups: comp.std.c++
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Date: 11 Dec 92 23:11:31 GMT
Organization: Microsoft Corporation

In article <9234601.10277@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
|Actually, nested functions can be handled quite transparently.
|Gnu C handles pointers to nested functions by creating a "trampoline"
|function on the stack, and using the address of the trampoline
|function. When the trampoline function is called, all it does is push
|the pointer to the stack frame, and then jump to original nested
|function. This way, the nested function does receive a hidden stack
|frame parameter, but you can use pass the address of the nested
|function to any function such as qsort() that just expects a normal
|function pointer, since the address which will be automatically
|converted to the address of a newly-created trampoline.

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

Newsgroups: comp.std.c++
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Ambiguity in member pointer declaration
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Wed, 16 Dec 92 21:16:48 GMT

In article <PNORI.92Dec16132118@hyperion.lsi-j.co.jp>, pnori@lsi-j.co.jp (Pochi NORIMATSU) writes:
|> In article <1992Dec15.011359.17235@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
jss:
|> >   The grammar
|> >   doesn't contain any rules that derive a declarator starting with "::".
|> >   And that omission is deliberate.


pnori:
|> But in ARM section 8.2.3, it says that the declarator representing a
|> pointer to members has the form
|> 
|> 	complete-class-name :: * cv-qualifier-list<opt> D1
|> 
|> And complete-class-name can start with ::. Or is it typo?


pnori is right.  This grammar path does lead to a declarator that begins
with a "::".  I suspect this is an oversight. Since, as the original
item pointed out, it also leads to an ambiguity it is something the
standards committee should address.  I think it should be made illegal
on the grounds of my original comment.

  -- Jerry Schwarz
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:54:17 GMT

In article <1992Dec9.133956.29659@lth.se> dag@seldon.control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>
>>What I propose is that we define a *standard library function* which computes
>>a total ordering on pointers.
>>
>>int compare_pointers(const void *, const void *);
>>    /* Returns negative, zero, or positive in the same manner as strcmp().
>>       Perhaps in the interests of tradition and unreadability it should
>>       be called ptrcmp() instead of compare_pointers() :-) */
>
>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? In particular, on the 8086 if
ptrcmp was a bitwise compare it would yield a total order,
but we would have

	p == q && ptrcmp(p,q) !=0


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: pnori@lsi-j.co.jp (Pochi NORIMATSU)
Newsgroups: comp.std.c++
Subject: Re: Ambiguity in member pointer declaration
Date: 16 Dec 92 04:21:18 GMT
	<1992Dec15.011359.17235@lucid.com>
Organization: LSI Japan Co. Ltd., Tokyo, Japan

In article <1992Dec15.011359.17235@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
[stuff deleted]
>   The grammar
>   doesn't contain any rules that derive a declarator starting with "::".
>   And that omission is deliberate.

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

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

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

--
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
From: harvey@opl.com (Harvey Reed)
Newsgroups: comp.std.c++
Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Date: 17 Dec 92 16:31:56 GMT

nau@ssesco.com (William Nau) 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.
>>
[Koenig replied]
>>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.

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.



-- 
++harvey
========================================================================
internet:  harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice:     617-965-0220
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 15 Dec 92 19:06:22 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 <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 problem is not to be able to order persistent objects, once
you know that you have a void* refering to one.  Also, I wouldn't
expect the comparison on persistent object IDs to be too slow to use,
since we are talking about objects that anyway needs to be transferred
to and from slow disks.

The real problem is distinguishing between void* to memory objects and
void* to persistent 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.

I think systems that can't completely support ptrcmp() should simply
refrain from defining it.  That will make the problem evident at an early
stage (link time).

-- 
--------------------------------------------------------------------------
| 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: Must derived class reserve space for an empty base class?
Date: 14 Dec 92 22:40:35 GMT
Organization: Microsoft Corporation

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

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

Excuse me?

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

I guess I don't understand what you are asking me to agree to?
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, 18 Dec 1992 20:25:35 GMT

In article <1992Dec17.230520.13836@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>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?

Not to mention the fact that some of us feel that the object id should
be private information of the OODBMS.  I would not like a specification
that effectively required the oid to escape into the application.
If I were an OODBMS developer, I might then be tempted to have 2 oids
per object, one for references and the other for ordering.

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