HDTenEightyP/NetNews huggingface dataset:
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: Pointer comparisons
Organization: Liant Software Corporation
Date: Mon, 28 Dec 1992 15:11:46 GMT

In article <1992Dec24.011254.1982@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> What needs to be made clear includes what is meant by "point to the
> same object."  As in my example the pointers *do* point to the same object,
> and they do compare equal.  It's just that one pointer refers to an
> enclosing object, and one pointer the enclosed object.  Same object,
> just not identically the same object.  

This explanation of your example could be more clear.  
If one pointer refers to an an enclosing object, and another to an enclosed
object, that sounds like different objects to me.

I've been advocating a strong relationship between pointer comparison
and identity of the objects pointed to.  It occurs to me that pointers
of type void* do not fit into this framework in C++, and not really in
C either.  If we want a guarantee that
	(void*)&a == (void*)&a
then how would the standard specify it?

> Ultimately, I do not believe worrying about these pointer "details" 
> is very important unless one first decides what properties of object
> identity C++ objects must have and why.  The current permission of
> C++ compilers to create temporaries at will kind of blows object identity
> out of the water.  Why worry about pointer equality, then?

I'd be happy to have a more precise description of C++ objects and their
identity, but temporaries are not much of a problem.
Programs rely on object identity via pointers, references, and lvalues.
12.2 of the ARM and working paper sanctions the introduction of temporaries,
but no one interprets this as affecting pointer, reference, and lvalue
expressions.  
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.std.c++
Subject: Re: need help compiling (linking) Borland C++ programs using templates
Summary: #include the .cpp file in the template's header file
Date: 22 Dec 92 21:52:07 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <1992Dec17.231411.10943@engage.pko.dec.com> chou@riscee.pko.dec.com (Jesse Chou WSG/SECG) writes:
>This may be a very basic and silly question to ask but I am new to Borland
>c++.  It is greatly appreciated that someone could enlighten me or give me
>pointer to a FAQ.

The comp.lang.c++ FAQL is available by anonymous ftp at
sun.soe.clarkson.edu in the file pub/C++/FAQ (though there's not much
on templates).

>I am writing a list class using template and got link error:
>Error: Undefined symbol slist_base::append(slink near*) in module tpc.cpp
>I had a similar error using other c++ compiler and found that I have to use
>a command line switch with the compiler.

Different compilers currently do not handle the generation of template
functions in the same way.  The ARM leaves a lot unspecified and I'm
not sure what ANSI C++ will say about it.  Make sure you read your
compiler manuals as there are often different ways to do it even with
the same compiler, each method offering different tradeoffs.

The easiest way to do deal with this under BC++ (and I believe gcc) is
to just #include the .cpp file containing the non-inline template
functions in the corresponding header file.

	// List.h
	#ifndef List_H
	#define List_H

	template<class T> class List { /*...*/ };
	//...

	#ifndef DONT_NEED_CPP
	#include "List.cpp"
	#endif

	#endif // List_H

Jamshid Afshar
jamshid@emx.utexas.edu



Newsgroups: comp.std.c++
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: Fri, 25 Dec 1992 16:35:27 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>daniel@cse.ucsc.edu (Daniel R. Edelson) writes:
[...]
>>Thus, this property need not be true in any program that
>>calls the operating system.
>
>	That is in the spirit of what I wanted, but I'm
>not sure if a standard can say it in those words. Besides,
>I wanted to be more explicit: even if I do an operting
>system call somewhere, I want the system
>to guarrantee
>
>	T* p=new T;
>	T* q=p;
>	if(!(p==q))cout<"Non conforming program";

I'm afraid that this is not possible.
For proof, consider the following hypothetical operating system call:

	random_poke() : sets a random memory location to a random value

After calling this operating system call, you can make NO further guarantees
about the behaviour of your system.

-- 
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++,comp.std.c
From: diamond@jit533.jit.dec.com (Norman Diamond)
Subject: Re: Question about sizeof in C/C++.
Reply-To: diamond@jit.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Date: Mon, 21 Dec 1992 10:38:23 GMT

In article <jamesc.724907666@bart> jamesc@swapsdev.state.state.COM.AU (James Cribb) writes:
>Suppose a single struct Something needed 7 bytes of memory.  For word
>alignment, these might need to start on, say, 4-byte boundaries.
>Do the standards guarantee that sizeof(struct Something) will always be
>8 rather than 7?

Yes.  ANSI's original C standard section 3.5.2.1, page 62 lines 2 to 3:
"Each non-bit-field member of a structure or union object is aligned in an
implementation-defined manner appropriate to its type."  Lines 13 to 14:
"There may also be unnamed padding at the end of a structure or union, as
necessary to achieve the appropriate alignment were the structure or union
to be an element of an array."

If it is appropriate for a member type to be aligned on a 4-byte boundary,
then the implementation-defined manner will result in such alignment,
including if necessary a padding byte at the end of the structure.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."
Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: pointer comparisons
Organization: Liant Software Corporation
Distribution: usa
Date: Sat, 2 Jan 1993 21:15:38 GMT

In article <9300300.29900@mulga.cs.mu.OZ.AU> (Fergus James HENDERSON) 
writes:
> pkt@lpi.liant.com (Scott Turner) writes:
> > But note that section 1.3 of the working paper (The C++ Memory Model) says:
> >
> >	       The constructs in a C++ program create, refer to, access, and
> >	       manipulate objects in memory.  Each object (except bit-fields)
> >        occupies one or more contiguous bytes.

> > How much freedom does it leave a compiler to optimize away
> > an object's bytes (by application of the "as if" rule, etc.)?
> > I think a good deal of freedom, [...]
> 
> Perhaps, but
>   "The _sizeof_ operator yields the size, in bytes, of its operand".
> I think that it would be a very brave compiler-writer whose compiler
> made it unreliable to write() an object and read() it in again, because
>   read(fd, &object, sizeof object);
> randomly trashes the bytes past the end of the object.

Yes, that's a relevant point.  But it does not mean that 1.3 restricts
the compiler's ability to optimize, because 5.3.2 already says that
sizeof yields a result of at least 1.  So I'll hold to my conclusion
that the above excerpt from 1.3 belongs in the C++ standard.

> However, the murkiness of the concepts involved in "object identity" appears
> to make it very difficult or impossible to provide such guarantees
[about pointer comparison].

On the contrary, this lengthy discussion has regularly debated how pointer 
comparison should work in relation to whether the pointers refer to the
same object.  Despite murkiness in the ARM, our shared concept of object
identity has held up.  I can think of only one example in which there was
disagreement about object identity, and in that case it seemed to be 
cleared up quickly.

> My own metaphysical perspective is that subobjects are
> by definition not objects in their own right

My perspective, that subobjects are objects, has stood up to 4 years of
working with the C++ reference manual and working paper.  It fits in better
with the common application of the prefix "sub".  For example, a subset is
so called not because it belongs to a set, but because it _is_ a set 
subordinate to another set.  If a subset were not properly a set, then
it never would have been called a subset.  Likewise "subobject" would be
a poor term if it did not refer to an object.

Furthermore, the ARM calls subobjects objects.  Look toward the end of 
10.1.1 (p. 206) "the same object representing the base class".
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
Newsgroups: comp.std.c++
From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Subject: Re: Pointer comparisons
Organization: Bell-Northern Research Ltd., Ottawa, Canada
Date: Tue, 22 Dec 1992 14:02:12 GMT

In article <1992Dec19.001851.22116@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>In article <1992Dec17.151642.9954@bcrka451.bnr.ca> sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:
>|>4) If two pointers p and q (of the same type) are obtained through
>|>   sequences of "normal" operations, then
>|>
>|>      p == q   <==>   p and q point to the same object
>|
>|I could not find this statement in the current wording.  Is there a 
>|reason why the current wording is weaker than this?
>
>Again, a simple counterexample is as follows:
>
[Class A with no state; class B is derived from A and contains an A.
 Compare pointer to base A of B against pointer to member A of B]

1.  I would be annoyed if there was gratuitous padding here.
    I want to be able to have T_interface and  T_implementation : public T_interface.
    
2.  Perhaps there is a philosophical argument that might resolve this issue.
    If two objects have the same interface but no state (or constant state), and
    they have the same lifetime, are they in fact the same object?  Or, perhaps,
    can they be treated as if they are the same object?

    The rule about new returning different addresses is needed because the objects
    have different lifetimes and so part of their state (their existence) differs,
    and the objects can be observed to be different.  In your example, I see no way
    of determining which A is which other than by looking at the pointers.  Can I
    even tell if there really are two As?  Mightn't one have been optimized away?

    Maybe someone who feels strongly that there is only one 1, or conversely that
    there are an infinite number of identical 1s can comment.  Seems like a
    similar concept.
    
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: pkt@lpi.liant.com (Scott Turner)
Subject: Re: Argument Matching
Organization: Liant Software Corporation
Distribution: usa
Date: Sat, 2 Jan 1993 17:38:09 GMT

John (MAX) Skaller writes:
> Similarly,
> 
>   f(int*);
>   f(const int*);
> 
> would not both be allowed. The argument in favour of this
> is that overloading is for two purposes:
> 
> A)     families of semantically equivalent operations on different types
>   e.g. sin(float), sin(complex)
> 
> B)  [omitted]
>              
> In case (A) overloading is desirable because the associated
> 'transparency' renders the program more readable and amenable
> to change of the types (float->complex). 
> 
> Addition of extra overloaded functions may cause re-binding,
> say sin(double) is added, but it doesnt really matter
> because this doesnt affect the overall semantics.

In the cases where I've seen overloading based on const, there is a very tight
semantic relationship between the overloaded functions, so tight
that they would be the same function except for a difference in
return type.  For example,
      int & access_the_count (class S&);
      const int & access_the_count (const class S&);
in which the overloaded function is providing access to a concrete
or abstract element of an object, and whether the element is const
or not depends on whether the object is const or not.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
Newsgroups: comp.std.c++
From: pkt@lpi.liant.com (Scott Turner)
Subject: Re: pointer comparisons
Organization: Liant Software Corporation
Date: Thu, 31 Dec 1992 15:27:00 GMT

In article <1992Dec30.184614.5551@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> In article <1992Dec27.050118.1628@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
> |The desired feature is:
> |Two pointers to the same type, which point to distinct objects
> |of that type, compare not equal.
> 
> Can you define your terms for us?

> I'm sure each of these things seems clear to you, yet they are not.

I'm talking about expressions with equality operators,
i.e. 5.10 of the ARM.  By "two pointers to the same type" I mean
to address just those cases in which both operands are pointer-type
expressions, and in which the types of the expressions are
	[const/volatile] pointer to [const/volatile] type A
and
	[const/volatile] pointer to [const/volatile] type B
where A and B are the "same type".  (I spell this out to indicate that
this is concerned with the static expression type, not the type of some
object, possibly enclosing the one pointed to.)

"Same type" is a term used repeatedly in the ARM.  It has its limitations,
but is adequate for my purpose.

"Point to distinct objects" would imply two things:
(1) Each operand points to one object (not a function, and is not null or
    invalid).
(2) The objects are not identicial.  I hope to say more about this in 
    another article.

The case I'm concerned with is limited to "objects of that type", i.e.
each operand points to a properly constructed object of type A (which may
be a subobject of an enclosing object constructed with a different type).

"Compare not equal" is self-evident; the C standard uses the same kind
of wording.  It means that the result of the operator != is 1 (TRUE) and
the result of the operator == is 0 (FALSE).
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
Newsgroups: comp.std.c++
From: mkohtala@lesti.hut.fi (Marko Kohtala)
Subject: Proposal for default scope
Reply-To: Marko.Kohtala@hut.fi
Organization: Helsinki University of Technology, Finland
Date:  4 Jan 93 00:52:54 GMT

While writing the implementations to classes, I have often missed the
possibility to define a default scope like below:

class Class { 
  int var;
  int func1();
  int func2();
};

Class::{	// This is just syntactic sugar to enclose the implementation
  int var;
  int func1()
  {
    /* ... */
  }
  int func2()
  {
    /* ... */
  }
}

This would be treated as

class Class { 
  static int var;
  int func1();
  int func2();
};

int Class::var;
int Class::func1()
{
  /* ... */
}
int Class::func2()
{
  /* ... */
}

The point being, that the identifiers to define are searched from the
specified scope and if not found, reported as not being members of
Class.

Especially in the case of nested classes this can make the source much
more readable and easier to write and maintain.

This idea could be extended to apply with compound statements, in
which case any unmatched identifiers should be searched for in
enclosing scopes. Also operators `.' and `->' should be implemented in
addition to `::' to be able to access instance members:

Class::{ /* statement list */ }
	The statements in the list could access by default the static members
	of the Class or in member functions the ancestor Class members. Of
	course, if the referenced variable is not a member, it is searched
	for in enclosing scope.

Class_var.{ /* statement list */ }	
Class_ptr->{ /* statement list */ }

	These would access the members in the class instance specified.

I am not really a C++ language expert, so I do not know if there will
be any conflicts with these additions to the language. At least, if
there are no conflicts, I think they should be quite easy to implement
after the details have been well specified (which I have not done, as
you can see). 

Please, tell me if it is possible to include this in the language.
-- 
---
Marko Kohtala - INTERNET:Marko.Kohtala@hut.fi, mkohtala@otax.tky.hut.fi
Student at (not representative of) the Helsinki University of Technology
Newsgroups: comp.std.c++
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: Mon, 21 Dec 1992 11:06:35 GMT

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>pat@frumious.uucp (Patrick Smith) writes:
>>   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.

I remain unconvinced that such a relationship is unimplementable on
some machines.

>It is only Jims suggestion that ptrcmp might always return 0 that
>makes it possible to make its existence mandatory.

A ptrcmp that always returned 0 would be useless, IMHO.

-- 
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!
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Date: 21 Dec 92 19:30:51 GMT
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
Cc: jbn
X-Newsreader: TIN [version 1.1 + PL8]

Fergus James HENDERSON (fjh@munta.cs.mu.OZ.AU) wrote:
: jbn@lulea.trab.se (Johan Bengtsson) writes:

: >Markku Sakkinen (sakkinen@jyu.fi) wrote:
: >: BTW, actually total order is
: >: a simple thing within an OODB _because_ the identity of each object
: >: is assured not to change.
: >
: >It would impose severe restrictions on how the virtual address space
: >could be used though.  The OODBMS may end up in a situation where
: >it can't get a persistent object into memory, not because it has used up
: >all virtual memory addresses, but because all unused virtual memory
: >adresses would violate the total ordering property.

: I thought that the idea was that for OODBMSs, you DON'T compare virtual
: addresses for pointers to persistent objects, instead you compare the object
: ids. Maybe someone could explain the problems in a little more detail?

As Stuart MacMartin said, if the OODBMs uses objects of class Handle
(never mind the name) to represent references to persistent objects
you will need to have

ptrcmp(Handle,Handle), if you want templates to compare Handles the
same way they compare pointers.  The OODBMs should provide that.
Also it should provide ptrcmp(Handle,void*) and ptrcmp(void*,Handle).

_Some_ OODBMs use void* as their Handles (they play tricks by
using virtual memory mapping to persistent storage), so they must
provide a ptrcmp(void*,void*) that can tell the difference between
pointers to persistent objects and normal memory pointers.  For persistent
objects, it then finds the object ids and makes the comparison.

My point is that this may be difficult, or slow (although I don't
really have any data on that).  The alternative is to simply compare
the void pointers, even for pointers to persistent objects, however
that imposes the unacceptable restrictions I described in my previous
posting.

A more difficult issue is what do you do if there is more than one
OODBMs in use, or more realistically, one OODBM, and one distributed
object manager (that similarly uses Handles to distributable objects).
Who is responsible for providing the needed ptrcmp(OODB_Handle,Distr_Handle)
and ptrcmp(Distr_Handle,OODB_Handle) functions?  This may become
totally unmanageable if handle-based schemes become common.

Hope this is a little bit clearer.

--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------
-- 
--------------------------------------------------------------------------
| 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: Pointer Comparisons
Date: 24 Dec 92 20:37:26 GMT
Organization: Microsoft Corporation

In article <1992Dec23.172735.15352@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|ARM requires non-zero length objects doesnt it?

No, ARM does not make such a requirement.  ARM requires sizeof(Ob) to
be greater than zero.  And ARM requires new Ob to return a distinct address.
But this is not the same as requiring Ob to have non-zero length.
The basic underlying requirement is that the space that Ob takes as an
element of an array be greater than zero, so that pointers to different
elements in the array have different values.  This can be achieved for
zero-length objects by requiring them to have at least one-byte trailing
alignment padding when placed in arrays.  When used as a member of a structure,
the object wouldn't necessarily have the same padding and alignment
requirements.  For example ARM *explicitly* makes no requirement of
implementations in the following example:

class A {};

class B
{
public:
	A a1;
public:
	A a2;
};

main()
{
	B b;
	A* p1 = &(b.a1);
	A* p2 = &(b.a2);

	if (p1 == p2)
		cout << "its undefined according to ARM!\n";
	else
		cout << "boring case -- but still undefined behavior!\n";

	return 0;
}
Newsgroups: comp.std.c++
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Pointer comparisons
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 25 Dec 1992 15:38:05 GMT

sjm@bcrki65.bnr.ca (Stuart MacMartin) writes:

>2.  Perhaps there is a philosophical argument that might resolve this issue.

Philosophical arguments never resolve anything ;-)

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