AllanW@my-dejanews.com wrote:

> Since so much about alignment is already acknowledged to be
> implementation-dependant, how about going the extra inch and
> simply declaring it to be?

There's no reason to. What would be achieved?

>
> We should declare that user-defined operator new, et. al., are
> required to conform to implementation-defined rules of alignment,
> which must be documented for each conforming compiler. This is
> not an extra burden on the programmer, since non-placement new
> is likely to be non-portable anyway.

As I have pointed out in a previous post, writing portable new
operators would have been possible had the standard defined an
operator to get a pointer aligned for a given type to be
supplied by the implementation. This would have separated the
problem of memory allocation into two parts -- the portable
user-defined part to locate a free char array whose memory would
be used to create the new object, and an implementation-supplied
part to point out the first valid address in that array the
object could be placed.


--------------------------------
Ziv Caspi
zivca@netvision.net.il


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <fzViQOAlFQd2Ewob@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:

>>BTW, I chose void* as IIRC sizeof(void*) >= sizeof(T*) holds for
>>all T.
>
>Being a pedant, I am not sure that this is required.  Certainly void*
>items must be able to hold all the information that a T* holds but I
>could envisage a circumstance where void* held the data compressed while
>T* used more generous storage to provide greater efficiency according to
>some other metric.

I can imagine an implementation on a tagged architecture where casting
to (void *) discards the tag and casting to another type creates one.

--
    John Carr (jfc@mit.edu)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

>Since so much about alignment is already acknowledged to be
>implementation-dependant, how about going the extra inch and
>simply declaring it to be?

>We should declare that user-defined operator new, et. al., are
>required to conform to implementation-defined rules of alignment,
>which must be documented for each conforming compiler.

The standard already says that. That is, in 3.7.3.1 the standard
acknowledges that some platforms have alignment requirements and
says that all allocation functions are required to respect them.
It says in 3.9 paragraph 5 that alignment is implementation-defined.

What started this thread was a desire for the standard to
define alignment in some detailed way. I don't think that
is feasible, as I explained in an earlier article.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco (pderocco@ix.netcom.com) wrote:

: Tony Cook wrote:
: >
: > Is there anything wrong with a theoretical machine that uses a
: > structure similar to a URL as pointers?
: >
: > This would obviously be very slow but might be used in modelling some
: > kinds of distributed processing.
: >
: > Is there anything in the C or C++ standard that prevents such a
: > 'machine' being suitable for implementation of C++?

: Well, what does it mean to do ++ on such a pointer? Even if a pointer
: has a component that is a URL, machine name, or file name, ultimately
: you will be pointing into some address space in which the bytes are
: numbered, even if that address space is only big enough to hold that one
: object. And the offset within that address space will be subject to the
: usual alignment requirements of the hardware it is running on.

I don't want (can't be bothered) to take this too far, but ++ for an
array pointer would simply include '+offset' after the URL, possibly
with a '+byte' for character level access (which I'd expect to be
fairly rare).  Character level access could possibly be emulated by
the 'machine' - I don't think the standard requires atomic access to
memory with a size other than sig_atomic_t.

: In other words, in theory you can get pretty abstract with "addresses",
: but C++ does have at least one foot on the ground, due to its definition
: of pointer arithmetic, sizeof, alignment, etc.

I tend to think in machine terms too, but the C/C++ standards don't
necessarily describe implementations only on the machines we have
experience with.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36756DFF.8A4325E@technologist.com>, David R Tribble
<dtribble@technologist.com> writes
>
>Of course, to be conforming, such a system of "addresses" must be able
>to order pointers to different elements in the same array, and there
>must be a unique null pointer value distinct from all possible valid
>object addresses.
>
>It must also be possible to cast a pointer to any type into a void
>pointer and back again without loss of value.  Certainly this fact
>implies *something* about the bits of a pointer; void pointers hold
>addresses with the least restrictive alignment requirements, and
>every pointer is convertible into a void pointer.
>
>Oh, and, I musn't forget the ;-)

Yes I think I should have used a liberal sprinkling of those :)


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3674467A.AA291425@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>In other words, in theory you can get pretty abstract with "addresses",
>but C++ does have at least one foot on the ground, due to its definition
>of pointer arithmetic, sizeof, alignment, etc.

Not that it really matters but none of the above actually require any
numerical element to addresses.

all ++ and -- do with addresses is generate the next and prior address
for an object of the requisite size.  We all (i think) understand all
the fundamental concepts (though some want to force these into terms of
numerical addresses) but it is wording a standard that causes a problem.
How do we describe exactly what we mean by alignment?  A nice essay
topic for an advanced Computer Science student.

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <3671E830.D34BBC9A@ix.netcom.com>, Paul D. DeRocco
> <pderocco@ix.netcom.com> writes
> >It has nothing to do with the C++ standard, or even to do with C++.
> >That's just how computers work. Addresses, like everything else in the
> >underlying representation, are numbers. A segmented address can be
> >thought of as two separate numbers or one bigger number, without having
> >any effect on the question of alignment, because such machines use the
> >least signficant bits for the offset, and alignment requirements are
> >always small powers of two.
>
> NO.  That is the way you think computers work.  If I am working across a
> LAN, memory is possibly allocated via a computer name + a more
> conventional address.
>
> If I am working with very large data an address might consist of a
> filename and an offset.
>
> I am not advocating these but just using them to show that there is more
> to a storage location than some way of refering to some bit of RAM.  C++
> makes no assumptions about how data is stored.

However, the C++ standard demands some type of "offset", in that
for each object, you can access the individual bytes by casting
its (start) address to char and adding a nonnegative number less
than sizeof(object) to that pointer. That is, even if the pointer
itself doesn't contain an numeric "offset" part, there is
conceptionally always an offset part. That is, one always can
separate C++ pointers into a "segment" which may be of any type
(even URL), and of which there may be any number (from 1 segment
for all objects - the "pointer is number" model - to 1 segment
per complete object), and an offset part, which is - at least
conceptionally - a number. Note that there's no requirement
that this offset starts at 0, or that the distinction segment/offset
is "real" in the hardware (or even that the pointer representation
contains a field which by itself may be interpreted as an offset).
Now, since there's always a numeric offset part, it makes sense
to do arithmetic on that offset part. Especially, it makes sense
to calculate the difference of the offsets of two objects in
the same segment (esp. two subobjects of a larger object; this
includes objects placed into the same char array with placement new).
And "Type T has alignment n" just means that for two valid pointers
to T pointing into the same segment (only guaranteed for subobjects
of same complete object), the difference of the offsets is always
a multiple of n.
Since raw allocation functions must return memory correctly aligned
for any type, there exists an offset for which each pointer is
correctly aligned. Therefore this is also true for each offset which
differs from that only by a multiple of maximum alignment.
By arbitrary defining one of those maximum-aligned offsets as
zero (where offset zero need not result in a valid pointer),
we have defined an offset for which each correctly aligned pointer
has its offset dividable by the alignment of the type.

Note that this offset is not uniquely defined; on an x86,
one could use the address offset as offset, but one could also
define the whole segment:offset pair as the logical offset, as
long as the physical offset is the least significant part.
One could also calculate the linear address, and use that as offset,
of use as offset the result after subtracting the first maximum-aligned
linear address usable by the program.

Note that the result of casting a pointer to int will be a
valid offset in most implementations. However, it is not
guaranteed.

[...]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Y6pzSdAVGZd2EwZk@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
>
> In article <3674467A.AA291425@ix.netcom.com>, Paul D. DeRocco
> <pderocco@ix.netcom.com> writes
> >In other words, in theory you can get pretty abstract with "addresses",
> >but C++ does have at least one foot on the ground, due to its definition
> >of pointer arithmetic, sizeof, alignment, etc.
>
> Not that it really matters but none of the above actually require any
> numerical element to addresses.
>
> all ++ and -- do with addresses is generate the next and prior address
> for an object of the requisite size.  We all (i think) understand all
> the fundamental concepts (though some want to force these into terms of
> numerical addresses) but it is wording a standard that causes a problem.
> How do we describe exactly what we mean by alignment?  A nice essay
> topic for an advanced Computer Science student.

Since so much about alignment is already acknowledged to be
implementation-dependant, how about going the extra inch and
simply declaring it to be?

We should declare that user-defined operator new, et. al., are
required to conform to implementation-defined rules of alignment,
which must be documented for each conforming compiler. This is
not an extra burden on the programmer, since non-placement new
is likely to be non-portable anyway. We would also stipulate
that returning the results of malloc(), et. al, or the address
of a static buffer are automatic ways to conform to this
requirement.

For Intel computers, the compiler documentation would look similar
to this:
    Alignment on this system is usually optional, in the sense that
    any valid memory-allocation scheme will produce correct results.
    However, alignment is still important because mis-aligned data
    will reduce performance significantly. Also, volatile data must
    be aligned, or else the data will be treated as non-volatile
    and no warning message will be produced. See the documentation
    for "volatile" for more details.

    In flat memory models, the address is a number. In segmented
    memory models, the low 16 bits are a number. Alignment is
    specified in terms of this number; for instance, if the
    alignment is 16, then the numeric portion of the address
    should be a multiple of 16. When the alignment is 1, we call
    this "no alignment." It is never neccesary to use an
    alignment greater than 16. Using greater alignment than
    required never hurts performance, but it may waste space.

    For all built-in types including pointers, the alignment is the
    size of that type. For instance, sizeof(short int) is 2, so
    alignment for short int data should be 2.

    For classes and structures, use an alignment that causes all of
    the data elements to be properly aligned. With normal padding,
    this is the same as the alignment of the largest built-in type,
    including built-in types of non-static data members and base
    classes. If the padding method is changed, it may be impossible
    to align all of the data elements -- see the documentation for
    "#pragma pack" for more details.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> The only meaning I can find for an address in C/C++ is a mechanism for
> identifying a specific piece of storage.  There is no reason why that
> storage should be in any particular location.  The use of segment and
> offset is one example of how an address may be more than a number.
> Why do you require that the segment identifier be a number?  If you
> think so please quote from either standard to support your claim.

It has nothing to do with the C++ standard, or even to do with C++.
That's just how computers work. Addresses, like everything else in the
underlying representation, are numbers. A segmented address can be
thought of as two separate numbers or one bigger number, without having
any effect on the question of alignment, because such machines use the
least signficant bits for the offset, and alignment requirements are
always small powers of two.

> The only place where a binary reprsentation is required is in the
> representation of integers.  Just because something is usual does not
> make it a requirement.

I think I can realistically predict that no one will ever build a
non-binary computer, at least a serious general-purpose computer that is
expected to be able to run things like C++ programs.

> Of course the concept of alignment is hard to pin down because what we
> are actually trying to do is highlight that some things that have the
> form of an address are not actually acceptable as addresses.  (This is
> an instance of a deep problem, some things that have the form of a
> sentence are not acceptable as a sentence etc.)  I think we can get
> quite far in pinning down what we mean but I doubt that we can do a
> complete job short of writing a substantial thesis.  I have better
> things to do with my time:)

Maybe I don't see the problem because I come from the hardware world and
assembly language. To me alignment requirements are self-evident. An
address is represented as a binary number. If a datum is bigger than a
byte, then it spans a range of consecutive addresses. The hardware
either requires or prefers that the base addresses used in such accesses
be multiples of some small power of two. This is so that the only bits
that are different between the lowest and highest byte accessed are
those bits that _must_ be different. For instance, if four bytes are
being accessed at a time, the address should be a multiple of four so
that the addresses of the four bytes will differ in only the bottom two
bits. This allows the machine to do the access in the minimum number of
bus cycles.

C++ is nice because it supports abstraction, and it's tempting therefore
to think as abstractly as possible about everything. However, C++ still
runs on real hardware machines which have certain characteristics, some
of which are absolutely universal. Sometimes the intrinsic limitations
of hardware become visible to the programmer, and you have to stop
thinking so abstractly. But note that if you never forge a pointer by
casting from a number or unrelated pointer type (including indirectly,
as through placement-new), then you can absolutely ignore everything in
the standard that has anything to do with alignment, as it is all
handled properly by the people who wrote the compiler.

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3671E830.D34BBC9A@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>It has nothing to do with the C++ standard, or even to do with C++.
>That's just how computers work. Addresses, like everything else in the
>underlying representation, are numbers. A segmented address can be
>thought of as two separate numbers or one bigger number, without having
>any effect on the question of alignment, because such machines use the
>least signficant bits for the offset, and alignment requirements are
>always small powers of two.

NO.  That is the way you think computers work.  If I am working across a
LAN, memory is possibly allocated via a computer name + a more
conventional address.

If I am working with very large data an address might consist of a
filename and an offset.

I am not advocating these but just using them to show that there is more
to a storage location than some way of refering to some bit of RAM.  C++
makes no assumptions about how data is stored.

In addition someone seemed to think that because pointers and integers
can be cast to each other that this implies that pointers are some kind
of number.  Unfortunately there is absolutely no requirement that such
conversions should be value preserving.  I am not even sure that there
is a requirement that successive casts of the same pointer value to an
int should result in the same value.  I.e if:

char * cptr = 0;
char x;
int i, j;
cptr = &x;
i = (int)cptr;
j = (int)cptr;

is it required that i==j;

Don't just say that it is obvious, quote the requirement in either the C
or C++ standard.




Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco (pderocco@ix.netcom.com) wrote:

: It has nothing to do with the C++ standard, or even to do with C++.
: That's just how computers work. Addresses, like everything else in the
: underlying representation, are numbers. A segmented address can be
: thought of as two separate numbers or one bigger number, without having
: any effect on the question of alignment, because such machines use the
: least signficant bits for the offset, and alignment requirements are
: always small powers of two.

Is there anything wrong with a theoretical machine that uses a
structure similar to a URL as pointers?

This would obviously be very slow but might be used in modelling some
kinds of distributed processing.

Is there anything in the C or C++ standard that prevents such a
'machine' being suitable for implementation of C++?


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
....
> char * cptr = 0;
> char x;
> int i, j;
> cptr = &x;
> i = (int)cptr;
> j = (int)cptr;
>
> is it required that i==j;
>
> Don't just say that it is obvious, quote the requirement in either the C
> or C++ standard

The closes the standard comes to specifying this conversion is in
section 5.2.10 p5: "A pointer converted to an integer of sufficient size
(if any such exists on the implementation) and back to the same pointer
type will have its original value; mappings between pointers and
integers are otherwise implementation-defined".

Thus, if 'int' is big enough, and the conversion from pointer to int can
produce multiple different values, then all of those values must convert
back to the same pointer. For example, a machine with 32 bit pointers
and 64 bit integers could set the other 32 bits of the integer value
randomly, and ignore them on the reverse conversion.

That paragraph doesn't say as much as it might appear to; an
implementation can simply document that it doesn't have any integer type
of sufficient size, and do whatever it wants in pointer/integer
conversions.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

>Francis Glassborow wrote:
>....
>> char * cptr = 0;
>> char x;
>> int i, j;
>> cptr = &x;
>> i = (int)cptr;
>> j = (int)cptr;
>>
>> is it required that i==j;
>>
>> Don't just say that it is obvious, quote the requirement in either the C
>> or C++ standard

>The closes the standard comes to specifying this conversion is in
>section 5.2.10 p5: "A pointer converted to an integer of sufficient size
>(if any such exists on the implementation) and back to the same pointer
>type will have its original value; mappings between pointers and
>integers are otherwise implementation-defined".

>Thus, if 'int' is big enough, and the conversion from pointer to int can
>produce multiple different values, then all of those values must convert
>back to the same pointer.

Not quite. It must convert back to the same pointer VALUE. It
is possible for the same pointer to have different representations
On the x86 architecture, different segment/offset pairs can
refer to the same location in memory, for example.

Assuming the pointer fits in an int, two pointer bit patterns
could reasonably convert to different int values. When converted
back to a pointer of the original type, the pointer must compare
equal to the original pointer, and refer to the same entity; it
need not have the original bit pattern. (It is up to the compiler
to take care of different bit patterns comparing equal, such as
by normalizing pointers before comparing them.) Conversions in
either direction between pointers and in might involve
normalizing the pointer representation.

And of course, it is not required that a pointer actually fit
in any integer type.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 13 Dec 1998 18:30:50 GMT, James Kuyper <kuyper@wizard.net>
uttered the following words:

>That paragraph doesn't say as much as it might appear to; an
>implementation can simply document that it doesn't have any integer type
>of sufficient size, and do whatever it wants in pointer/integer
>conversions.

Isn't size what is returned by sizeof?
If sizeof(void*) <= sizeof(long), then it must be a conversion.

I don't see any implementation artificially enlarging the size of
a pointer to fulfill this minor detail.

BTW, I chose void* as IIRC sizeof(void*) >= sizeof(T*) holds for
all T.

Regards,
Luis Coelho.
C++ Programming Language, 3rd Ed. by B. Stroustrup. My exercise answers at:
http://www.geocities.com/SiliconValley/Way/3972/index.html


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

deepblack@geocities.com (Luis Coelho) writes:

>On 13 Dec 1998 18:30:50 GMT, James Kuyper <kuyper@wizard.net>
>uttered the following words:

>>That paragraph doesn't say as much as it might appear to; an
>>implementation can simply document that it doesn't have any integer type
>>of sufficient size, and do whatever it wants in pointer/integer
>>conversions.

>Isn't size what is returned by sizeof?
>If sizeof(void*) <= sizeof(long), then it must be a conversion.

>I don't see any implementation artificially enlarging the size of
>a pointer to fulfill this minor detail.

Yes, but there is no requirement in the standard that
sizeof(void*) <= sizeof(long). The standard explictly allows for
the case when that isn't true.  (Consider the AS400 architecture,
with 48-bit pointers and 32-bit longs.)

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Tony Cook wrote:
>
> Is there anything wrong with a theoretical machine that uses a
> structure similar to a URL as pointers?
>
> This would obviously be very slow but might be used in modelling some
> kinds of distributed processing.
>
> Is there anything in the C or C++ standard that prevents such a
> 'machine' being suitable for implementation of C++?

Well, what does it mean to do ++ on such a pointer? Even if a pointer
has a component that is a URL, machine name, or file name, ultimately
you will be pointing into some address space in which the bytes are
numbered, even if that address space is only big enough to hold that one
object. And the offset within that address space will be subject to the
usual alignment requirements of the hardware it is running on. If an
"address space" is only big enough to hold one object, then the offset
will be zero, and alignment requirements are trivially met, since zero
is a multiple of everything. However, if an address space holds an array
of objects, for which ++ on a pointer is meaningful, then you obviously
may have some nonzero numeric component to the address, and this numeric
component must always be a multiple of the alignment requirement for the
object.

In other words, in theory you can get pretty abstract with "addresses",
but C++ does have at least one foot on the ground, due to its definition
of pointer arithmetic, sizeof, alignment, etc.

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> NO.  That is the way you think computers work.  If I am working across
> a LAN, memory is possibly allocated via a computer name + a more
> conventional address.
>
> If I am working with very large data an address might consist of a
> filename and an offset.
>
> I am not advocating these but just using them to show that there is
> more to a storage location than some way of refering to some bit of
> RAM. C++ makes no assumptions about how data is stored.

But even your kind of pointer includes an offset part which is numeric,
and for which alignment has the usual meaning. Even if we allowed C++
pointers to hold something as huge as a file name made up of 512
eight-bit characters, plus a 32-bit offset, then alignment remains
meaningful, as we can still insist that for a four-byte datum that
4128-bit "number" be a multiple of four, since that's the same as saying
that the 32-bit offset must be a multiple of four.

This discussion began, if I recall, with Valentin Bonnard saying he
didn't understand the C++ standard's use of "alignment" since in his
view:

1) alignment as a logical concept only makes sense when applied to
numbers (e.g., a binary RAM address can be said to be "aligned" on a
four-byte boundary, but an e-mail address cannot), but

2) a pointer is not necessarily a number.

I would merely counter that all these mentions of "alignment", which
only make sense if pointers are implemented as numbers, themselves imply
that pointers are implemented as numbers. And in all implementations of
C++, pointers really are implemented as numbers which identify locations
in an address space which is the execution environment of the C++
program.

Certainly you can invent a more complex type of address that isn't a
simple number, but to the extent that the hardware imposes alignment
requirements on them (and to the extent that you can do pointer
arithmetic like ++ on them), they must have a component that is
meaningful as a number. What's more, you can always arrange the bits
that make up the address so that this numeric component is in the least
signficant bit positions. And since whether a binary number is a
multiple of a power of two depends only upon the least significant bits,
the conventional understanding of alignment requirements works just
fine.

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <367431df.2025029@news.ist.utl.pt>, Luis Coelho
<deepblack@geocities.com> writes
>BTW, I chose void* as IIRC sizeof(void*) >= sizeof(T*) holds for
>all T.

Being a pedant, I am not sure that this is required.  Certainly void*
items must be able to hold all the information that a T* holds but I
could envisage a circumstance where void* held the data compressed while
T* used more generous storage to provide greater efficiency according to
some other metric.

We should avoid making assumptions however sane they appear.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Luis Coelho wrote:
>
> On 13 Dec 1998 18:30:50 GMT, James Kuyper <kuyper@wizard.net>
> uttered the following words:
>
> >That paragraph doesn't say as much as it might appear to; an
> >implementation can simply document that it doesn't have any integer type
> >of sufficient size, and do whatever it wants in pointer/integer
> >conversions.
>
> Isn't size what is returned by sizeof?
> If sizeof(void*) <= sizeof(long), then it must be a conversion.

It says "sufficient size", not "equal or greater size", and it doesn't
define what sufficient size means. An implementation is free to define
the pointer->integer conversion as producing two copies in the resulting
integer, of every bit in the pointer's representation.

....
> BTW, I chose void* as IIRC sizeof(void*) >= sizeof(T*) holds for
> all T.

There's no such requirement. The conversion rules require reversable
conversions, in that converting to void* and back again should produce a
pointer that compares equal to the original. This implies, but does not
require, the size relationship you state.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alfred Kellner <alfkellner@magnet.at> writes
> >However, the question is still : Is an address a number ?

Francis Glassborow wrote:
> Indeed, why should it be?  I can imagine working on a distributed
> system where an address might be some form of extended URL.  Of course
> the bit pattern could be interpreted as a number but in that sense
> everything in a program is a number.

Of course, to be conforming, such a system of "addresses" must be able
to order pointers to different elements in the same array, and there
must be a unique null pointer value distinct from all possible valid
object addresses.

It must also be possible to cast a pointer to any type into a void
pointer and back again without loss of value.  Certainly this fact
implies *something* about the bits of a pointer; void pointers hold
addresses with the least restrictive alignment requirements, and
every pointer is convertible into a void pointer.

Oh, and, I musn't forget the ;-)

-- David R. Tribble, dtribble@technologist.com --



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <74v0bc$js$1@ns.cook.ml.org>,
  tony@ns.cook.ml.org (Tony Cook) wrote:
>
> Paul D. DeRocco (pderocco@ix.netcom.com) wrote:
>
> : It has nothing to do with the C++ standard, or even to do with C++.
> : That's just how computers work. Addresses, like everything else in the
> : underlying representation, are numbers. A segmented address can be
> : thought of as two separate numbers or one bigger number, without having
> : any effect on the question of alignment, because such machines use the
> : least signficant bits for the offset, and alignment requirements are
> : always small powers of two.
>
> Is there anything wrong with a theoretical machine that uses a
> structure similar to a URL as pointers?

Speaking practically, this couldn't work by itself. The URL identifies
one connection point on a network. Using a URL as a pointer would allow
only one type of data per connection point.

It should be possible to use an URL as *PART* of a pointer. This would
be similar to the 16-bit x86 world's use of segment:offset, except that
this would take the idea to new extremes. Another part of the pointer
would probably be a 16-bit port number. Besides that, we would have
some sort of connection ID (once the connection times out, the
destination could free the resources), and probably a 32-bit machine-
dependant number (which could be THAT computer's native address, or
a task ID:virtual address, or anything else)... in case you're not
counting, we're close to (or possibly over) 128 bits now.

> This would obviously be very slow but might be used in modelling some
> kinds of distributed processing.

"very slow" to say the least. If dereferencing them requires I/O then
calling them "pointers" probably isn't a good idea. A better name would
probably be "URL" or "Data location tag".

> Is there anything in the C or C++ standard that prevents such a
> 'machine' being suitable for implementation of C++?

I'm sure there is nothing that bars this except user expectations.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <366C96BB.5DDC@sig.please>,
  look@sig.please wrote:
>
> Steve Clamage wrote:
>
> (pointer arithmetic)
>
> > It's only defined when the results remain within the same complete
> > object. Example:
> >         char A[100];
> >         char *P = A + 101; // 2 past the end of A
> > The addition of A and 101 is not guaranteed to produce a result;
> > if it does, the assignment to P is not guaranteed to succeed;
> > if it does, no operation on P except a new assignment has any
> > defined result. That is, you are not guaranteed even to be able
> > to inspect the value of the pointer P.
>
> Once the "A+101" expression has appeared, is ANYTHING defined?
> Just wondering.

   5.7 Additive operators                               [expr.add]

   5 When an expression that has integral type is added to or
     subtracted from a pointer,
     ...
     If both the pointer operand and the result point to elements
     of the same array object, or one past the last element of the
     array object, the evaluation shall not produce an overflow;
     otherwise, the behavior is undefined.

   1.3.12 undefined behavior                     [defns.undefined]
     behavior ... for which this International Standard imposes no
     requirements ... [ Note: permissible undefined behavior
     ranges from ignoring the situation completely with
     unpredictable results, to behaving during translation or
     program execution in a documented manner characteristic of
     the environment (with or without issuance of a diagnostic
     message), to terminating a translation or execution (with the
     issuance of a diagnostic message). ...

So no, nothing at all is defined, either at run-time or even at
translation time. For instance, as soon as your compiler saw this
program it might start formatting your hard drive. Unlikely for
sure, but allowed by the standard.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote in message <366C9137.E55E15DE@wizard.net>...
    [snip]
>> std::less<T*>, etc. provides a total order for pointers and gives the same
>> answer as '<' for cases in which '<' gives a defined result.
>
>Sorry, I keep forgetting that. Why is less<T*> required to provide a
>total order, rather than '<'? Does less<T*> typically run much slower
>than '<' on systems where '<' does not naturally provide a total order?


A canonical example would be a machine with segmented pointers,
where '<' only compares the offsets (one machine-instruction, say);
less<T*> would have to compare the offsets, and, if they are equal,
compare the segments as well -- it seems to me that this might well
translate to several machine-instructions, e.g., in pseudo-assembler

inline expansion of pA < pB:
    compare pA_offsetWord, pB_offsetWord
    [result is left in "isLess" machine-flag]

inline expansion of less<T*>(pA,pB)
    compare pA_offsetWord, pB_offsetWord
    jump_if_isEqual afterwards
    compare pA_segmentWord, pB_segmentWord
afterwards:
    [result is left in "isLess" machine-flag]

2-3 machine-instructions (typically 2, but, *with* a
normally-taken forward-branch); I would expect in this case
a slowdown of _at least_ 100% for less<> with respect to
just <, probably a bit more than that (very low-level details
of the implementation of this hypothetical architecture may
make a big performance difference here, of course).


Alex



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <34AC99F6.E6821FCE@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>But since alignment requirements are always small powers of two, it
>doesn't matter if you treat the segment part as a bunch more MSBs on the
>number. The C standard may not _say_ that alignment requirements are
>always small powers of two, but in real life they always have been and
>always will be. That's the intrinsic nature of the underlying binary
>nature of computers. (And yes, C/C++ requires a binary implementation.)

Curious how we are getting embroiled in implementation details:)  Yet
the standard leaves that sort of thing to implementors and focuses more
on interface.

All you are doing is asserting that your view of the World is obviously
the right one.  I am not so sure.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <34AC9764.D81A88BF@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>Oh, come on now. In that sense, an "address" could be that crayon scrawl
>on little Jimmy's letter to Santa. But in the context of the discussion
>of the alignment of data in a C++ program, and address most certainly
>_is_ an integral number, even if broken into fields (e.g., segment and
>offset), and any definition of alignment requirement are in terms of
>whether these numbers are integral multiples of certain small powers of
>two.

The only meaning I can find for an address in C/C++ is a mechanism for
identifying a specific piece of storage.  There is no reason why that
storage should be in any particular location.  The use of segment and
offset is one example of how an address may be more than a number.  Why
do you require that the segment identifier be a number?  If you think so
please quote from either standard to support your claim.


>And in case you wish to argue that an alignment requirement could
>specify a non-power-of-two, I would respond that C/C++ requires an
>underlying binary implementation (otherwise, &, |, ^ and ~ would be
>meaningless), and no (non-pathological) binary implementation will have
>non-binary alignment requirements on pointers.

The only place where a binary reprsentation is required is in the
representation of integers.  Just because something is usual does not
make it a requirement.

Of course the concept of alignment is hard to pin down because what we
are actually trying to do is highlight that some things that have the
form of an address are not actually acceptable as addresses.  (This is
an instance of a deep problem, some things that have the form of a
sentence are not acceptable as a sentence etc.)  I think we can get
quite far in pinning down what we mean but I doubt that we can do a
complete job short of writing a substantial thesis.  I have better
things to do with my time:)



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:
> No. Let's look at the x86 protected mode: A full address contains
> of a selector an an offset. The selector is a number, actually an
> index into a descriptor table. The offset is a number as well.
...
> Alignment here just means the *offset* part is a multiple of some
> number.

Paul D. DeRocco wrote:
> But since alignment requirements are always small powers of two, it
> doesn't matter if you treat the segment part as a bunch more MSBs on
> the number. The C standard may not _say_ that alignment requirements
> are always small powers of two, but in real life they always have been
> and always will be. That's the intrinsic nature of the underlying
> binary nature of computers. (And yes, C/C++ requires a binary
> implementation.)

I seem to recall that the Cyber/60 used 60-bit data words and 12-bit
instruction words.  It had instructions for packing and unpacking
five 12-bit words within a single 60-bit word (which were used by
things like the linker).  C was undoubtedly ported to such a beast.
I don't know but I assume that, at some level, it probably enforced
a multiple-of-5 alignment restriction.  (Presumably pointers to
12-bit entities were complicated things, since they probably had to
contain the address of the whole 60-bit word along with the
offset/index of the 12-bit word inside it.)

Don't assume that all machines, or even all binary machines, size
everything in integral powers of 2.

The standard only states assumptions about the binary representation
of integer data types.  It says precious little about the
representation of pointers, which is perfectly reasonable.

It also discusses the conversion of pointers into integers and
back again.  So pointers are convertible to numbers even if they,
deep down, are not "numeric" themselves.

-- David R. Tribble, dtribble@technologist.com --



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco wrote:
>
> Francis Glassborow wrote:
> >
> > Indeed, why should it be?  I can imagine working on a distributed
> > system where an address might be some form of extended URL.  Of course
> > the bit pattern could be interpreted as a number but in that sense
> > everything in a program is a number.
>
> Oh, come on now. In that sense, an "address" could be that crayon scrawl
> on little Jimmy's letter to Santa. But in the context of the discussion
> of the alignment of data in a C++ program, and address most certainly
> _is_ an integral number, even if broken into fields (e.g., segment and
> offset), and any definition of alignment requirement are in terms of
> whether these numbers are integral multiples of certain small powers of
> two.
>
> And in case you wish to argue that an alignment requirement could
> specify a non-power-of-two, I would respond that C/C++ requires an
> underlying binary implementation (otherwise, &, |, ^ and ~ would be
> meaningless), and no (non-pathological) binary implementation will have
> non-binary alignment requirements on pointers.

C/C++ requres a binary representation of ints, but it doesn't
require anything about the size/alignment. From the implementation
of processors/memory in digital hardware, it follows that for
physical memory access, an alignment of a small power of two
is quite probable. But this is completely independant from the
number representation. There's no reason why you shouldn't create
an 80 bit data bus, and if you assume 8 bit bytes, the most
efficient alignment on that architecture would be 10. Probably
on this machine int would be a 10 byte type (and nevertheless
use a binary representation for int - just with 80 bits).
Now I hope you won't tell me 10 is a small power of 2 ;-)

AFAIK machines have been built with 9 bit chars and 36 bit
ints. Now, sizeof(int)==4*sizeof(char), and 4 is a power of 2.
However, there's nothing inherent, which would have prohibited
27 bit ints or 45 bit ints. I guess, the int alignment would
have been 3 resp. 5 in that case.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alfred Kellner wrote:
>
> James Kuyper <kuyper@wizard.net> wrote:
>
> > Alfred Kellner wrote:
> > >
> > > Valentin Bonnard <bonnardv@pratique.fr> wrote
> > > > James Kuyper wrote:
> [...]
> > > > > I don't have a
> > > > > copy of the C89 standard, but the draft C9X standard defines alignment
> > > > > as the "requirement that objects of a particular type be located on
> > > > > storage boundaries with addresses that are particular multiples of a
> > > > > byte address".
> > > >
> > > > A very interresting sentence, as an address isn't a number
> > > > and simply cannot be a multiple of anything.
> > >
> > > A very interresting sentence, since IMHO an address designates an
> > > element of a sequence and can be represented by an ordinal seq-number
> > > ( the I-th element of N elements).
> > > I think the confusion comes from mixing ordinal with cardinal numbers.
> > > ( position 3 twice isn't position 5 or 6 )
> [...some explicit pointer arithmetic...]
> > > That is, what's a multiple is the cardinal amount of predecessors
> > > and not the address. I agree, an address is not a number, though it
> > > can be converted into a number.
>
> > The construction you've done makes unportable assumptions. In
> > particular, there's not guaranteed to be any number 'n' such that
> > '(T*)0+n' is a valid pointer value. There are actual systems where this
> > wouldn't work. There are many systems where most randomly chosen values
> > for 'n' would result in invalid pointers.
>
> Agreed. T*t=0; Has been meant as an address designating the very first
> element of the lagest array of the smallest type that can exist in a given
> address space - not as claim *that* address *is* the NULL pointer, in
> fact, it cannot be (..is distinguishible from every other value of pointer..).
>
> However, the question is still : Is an address a number ?

No. Let's look at the x86 protected mode: A full address contains
of a selector an an offset. The selector is a number, actually an
index into a descriptor table. The offset is a number as well. However,
there complete address isn't a number. Two addresses with different
selectors may have any relation, depending on the setup of the
descriptor table. There may be invalid selectors and invalid offsets
for each selector. If both pointers are valid, they may point to
the same memory address if both selectors describe the same segment
(even if they are not the same; maybe one gives readonly access, while
the other one gives read/write access) and the offsets are the same.
But they might as well point to different memory addresses, if
the descriptor table is set up different, despite having the
same representations as above.
Alignment here just means the *offset* part is a multiple of some
number.

However, one thing we know for each conforming C++ implementation
is that if we can make a char array c for which we have
bitwise_equal(&c[some_index], p1) and bitwise_equal(&c[other_index], p2),
then we have a "common index" for which we can make arithmetic.
(Note that bitwise_equal implies ==, as for each p we have p==p,
but the reverse is not true).

Now the first requirement on alignment would that the difference of
the indices in such a situation would have to be a multiple of a
given number.
Add to that the second requirement, implicit in raw allocation
requirement, that there must exist an address which fulfills the
alignment requirement for every type at the same time, and the
alignment rule is basically fixed.

As it happens, the implementations tend to fulfil a third rule:
If we have a char array c0, for which no other char array c1 can exist
which has a lower address (that is, there is no array c1 possible
where c0=c1+i, i>0), then &c0[0] fulfils the raw allocation
alignment requirement.

Now we can define the index of c0 as the "offset" of the address
(on systems as the x86, it will indeed be the offset part of the
address). Now the address can be interpreted as a number iff there's
exactly one address where c0 as defined above may be placed.

Note that for 32 bit x86 C++ implementations, usually only one
segment is used, so pointers are really offsets into that segment
and therefore on those implemenations pointers "are" numbers.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alfred Kellner wrote:
>
> Valentin Bonnard <bonnardv@pratique.fr> wrote
> > James Kuyper wrote:
> > > I couldn't find a definition of alignment within the C++ standard.
> > > However, it incorporates the C89 standard by reference.
> >
> > But only for the library part.
> >
> > > I don't have a
> > > copy of the C89 standard, but the draft C9X standard defines alignment
> > > as the "requirement that objects of a particular type be located on
> > > storage boundaries with addresses that are particular multiples of a
> > > byte address".
> >
> > A very interresting sentence, as an address isn't a number
> > and simply cannot be a multiple of anything.
>
> A very interresting sentence, since IMHO an address designates an
> element of a sequence and can be represented by an ordinal seq-number
> ( the I-th element of N elements).

A very interresting interpretation.

A pointer could be decomposed as an offset and a base address (the
address of the first element in an array, or of the first byte in a complete
object or whatever). The offset is a number, but the base address certainly
isn't.

> I think the confusion comes from mixing ordinal with cardinal numbers.
> ( position 3 twice isn't position 5 or 6 )

Well, the confusions comes from treating pointers as numbers. Pointers
are unique names (or unique identifiers) plus an offset.

> Would it make more sense to phrase
>    "... on storage boundaries with addresses that are equal to a byte address
>    whose preceeding amount of bytes is a particular multiple" ?

You have to define the notion of address...

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Chris Kuan <look@sig.please> writes:

>Steve Clamage wrote:

>(pointer arithmetic)

>> It's only defined when the results remain within the same complete
>> object. Example:
>>         char A[100];
>>         char *P = A + 101; // 2 past the end of A
>> The addition of A and 101 is not guaranteed to produce a result;
>> if it does, the assignment to P is not guaranteed to succeed;
>> if it does, no operation on P except a new assignment has any
>> defined result. That is, you are not guaranteed even to be able
>> to inspect the value of the pointer P.

>Once the "A+101" expression has appeared, is ANYTHING defined?
>Just wondering.

Some systems generate a trap for operations involving an invalid
address. That would normally cause a program abort, and the
standard allows such behavior.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> Indeed, why should it be?  I can imagine working on a distributed
> system where an address might be some form of extended URL.  Of course
> the bit pattern could be interpreted as a number but in that sense
> everything in a program is a number.

Oh, come on now. In that sense, an "address" could be that crayon scrawl
on little Jimmy's letter to Santa. But in the context of the discussion
of the alignment of data in a C++ program, and address most certainly
_is_ an integral number, even if broken into fields (e.g., segment and
offset), and any definition of alignment requirement are in terms of
whether these numbers are integral multiples of certain small powers of
two.

And in case you wish to argue that an alignment requirement could
specify a non-power-of-two, I would respond that C/C++ requires an
underlying binary implementation (otherwise, &, |, ^ and ~ would be
meaningless), and no (non-pathological) binary implementation will have
non-binary alignment requirements on pointers.

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:
>
> No. Let's look at the x86 protected mode: A full address contains
> of a selector an an offset. The selector is a number, actually an
> index into a descriptor table. The offset is a number as well.
...
> Alignment here just means the *offset* part is a multiple of some
> number.

But since alignment requirements are always small powers of two, it
doesn't matter if you treat the segment part as a bunch more MSBs on the
number. The C standard may not _say_ that alignment requirements are
always small powers of two, but in real life they always have been and
always will be. That's the intrinsic nature of the underlying binary
nature of computers. (And yes, C/C++ requires a binary implementation.)

One might conceive of a segmented architechture in which the segment
part of a pointer is stored in the lsbs of a register. In this case, a
pointer needing, say, even-byte alignment wouldn't necessarily contain
an address that is a multiple of two, but would be an address that had
zero fixed in some other bit position. But one can visualize the mapping
of pointers to addresses any way one wants (Even in x86, one _could_
write off:seg instead of seg:off, as long as whatever is reading it
agrees.) and so one merely has to _define_ the numeric address such that
the lsb of the byte offset is in the lsb of the numeric value. I doubt
any real-world machine would make you do that, though.

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <bonnardv@pratique.fr> wrote
> James Kuyper wrote:
> > I couldn't find a definition of alignment within the C++ standard.
> > However, it incorporates the C89 standard by reference.
>
> But only for the library part.
>
> > I don't have a
> > copy of the C89 standard, but the draft C9X standard defines alignment
> > as the "requirement that objects of a particular type be located on
> > storage boundaries with addresses that are particular multiples of a
> > byte address".
>
> A very interresting sentence, as an address isn't a number
> and simply cannot be a multiple of anything.

A very interresting sentence, since IMHO an address designates an
element of a sequence and can be represented by an ordinal seq-number
( the I-th element of N elements).
I think the confusion comes from mixing ordinal with cardinal numbers.
( position 3 twice isn't position 5 or 6 )

So, if I need to calculate a multiple of an address-location, I have to do:
 Byte * pB1=0;  // addr B at position 1
 T * pT1=0;  // addr T at position 1
 unsigned istart = 1; // ordinal begin position 1
 unsigned ipos = 42; // ordinal any position 1..n
 int nT = ipos - istart; // cardinal count predecessors
 T * pT42 = pT1 + nT; // addr T at position 42
 int nBinT = sizeof(T); // cardinal storage equivalence
*) int nBT = nT * nBinT; // translate T-amount to B-amont
 Byte * pBT = pB1 + nBT;// advance by cardinal B-amount
 bool bTrue = (pT42 == (T*) pBT);
That is, what's a multiple is the cardinal amount of predecessors
and not the address. I agree, an address is not a number, though it
can be converted into a number.

Would it make more sense to phrase
   "... on storage boundaries with addresses that are equal to a byte address
   whose preceeding amount of bytes is a particular multiple" ?

 --ALfred


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alfred Kellner wrote:
>
> Valentin Bonnard <bonnardv@pratique.fr> wrote
> > James Kuyper wrote:
> > > I couldn't find a definition of alignment within the C++ standard.
> > > However, it incorporates the C89 standard by reference.
> >
> > But only for the library part.
> >
> > > I don't have a
> > > copy of the C89 standard, but the draft C9X standard defines alignment
> > > as the "requirement that objects of a particular type be located on
> > > storage boundaries with addresses that are particular multiples of a
> > > byte address".
> >
> > A very interresting sentence, as an address isn't a number
> > and simply cannot be a multiple of anything.
>
> A very interresting sentence, since IMHO an address designates an
> element of a sequence and can be represented by an ordinal seq-number
> ( the I-th element of N elements).
> I think the confusion comes from mixing ordinal with cardinal numbers.
> ( position 3 twice isn't position 5 or 6 )
>
> So, if I need to calculate a multiple of an address-location, I have to do:
>         Byte * pB1=0;           // addr B at position 1
>         T * pT1=0;              // addr T at position 1
>         unsigned istart = 1;    // ordinal begin position 1
>         unsigned ipos = 42;     // ordinal any position 1..n
>         int nT = ipos - istart; // cardinal count predecessors
>         T * pT42 = pT1 + nT;    // addr T at position 42
>         int nBinT = sizeof(T);  // cardinal storage equivalence
> *)      int nBT = nT * nBinT;   // translate T-amount to B-amont
>         Byte * pBT = pB1 + nBT;// advance by cardinal B-amount
>         bool bTrue = (pT42 == (T*) pBT);
> That is, what's a multiple is the cardinal amount of predecessors
> and not the address. I agree, an address is not a number, though it
> can be converted into a number.

The construction you've done makes unportable assumptions. In
particular, there's not guaranteed to be any number 'n' such that
'(T*)0+n' is a valid pointer value. There are actual systems where this
wouldn't work. There are many systems where most randomly chosen values
for 'n' would result in invalid pointers.

Furthermore, your use of the term ordinal implies that arbitrary pairs
of addresses can be ordered. There are implementations where that
doesn't work either. You might think that you could, at a minimum, order
addresses by interpreting the bits that make them up as a single
unsigned integer. Unfortunately, there exist systems where such an
ordering would give &array+n < &array, or p1<q && q<p2, where p1 and p2
point at the same object.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote in message <366BEAC5.41C6@wizard.net>...
>Furthermore, your use of the term ordinal implies that arbitrary pairs
>of addresses can be ordered. There are implementations where that
>doesn't work either.

It doesn't help with alignment, but arbitrary pairs of addresses can be
ordered.

std::less<T*>, etc. provides a total order for pointers and gives the same
answer as '<' for cases in which '<' gives a defined result.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> wrote:

> Alfred Kellner wrote:
> >
> > Valentin Bonnard <bonnardv@pratique.fr> wrote
> > > James Kuyper wrote:
[...]
> > > > I don't have a
> > > > copy of the C89 standard, but the draft C9X standard defines alignment
> > > > as the "requirement that objects of a particular type be located on
> > > > storage boundaries with addresses that are particular multiples of a
> > > > byte address".
> > >
> > > A very interresting sentence, as an address isn't a number
> > > and simply cannot be a multiple of anything.
> >
> > A very interresting sentence, since IMHO an address designates an
> > element of a sequence and can be represented by an ordinal seq-number
> > ( the I-th element of N elements).
> > I think the confusion comes from mixing ordinal with cardinal numbers.
> > ( position 3 twice isn't position 5 or 6 )
[...some explicit pointer arithmetic...]
> > That is, what's a multiple is the cardinal amount of predecessors
> > and not the address. I agree, an address is not a number, though it
> > can be converted into a number.

> The construction you've done makes unportable assumptions. In
> particular, there's not guaranteed to be any number 'n' such that
> '(T*)0+n' is a valid pointer value. There are actual systems where this
> wouldn't work. There are many systems where most randomly chosen values
> for 'n' would result in invalid pointers.

Agreed. T*t=0; Has been meant as an address designating the very first
element of the lagest array of the smallest type that can exist in a given
address space - not as claim *that* address *is* the NULL pointer, in
fact, it cannot be (..is distinguishible from every other value of pointer..).

However, the question is still : Is an address a number ?

> Furthermore, your use of the term ordinal implies that arbitrary pairs
> of addresses can be ordered.

Agreed, that's implied in pointer arithmetic ++ptr gets the next ptr in sequence,
and ptr+n the (1+n)-th.

> There are implementations where that doesn't work either.
*This* comes as a very surprise to me. Pointer arithmetic doesn't work ?

> You might think that you could, at a minimum, order addresses by
> interpreting the bits that make them up as a single unsigned integer.
No, I don't do that.
The representation of a pointer-value is up to the implementation.

> Unfortunately, there exist systems where such an
> ordering would give &array+n < &array, or p1<q && q<p2, where p1 and p2
> point at the same object.
Again agreed. Comparison of pointers to different objects is unspecified,
otherwise ....
<quote>
 5.9 Relational operators
 - If two pointers point to elements of the same array
   or one beyond the end of the array, the pointer to
   the object with the higher subscript compares higher.
<quote>
Did you notice the word 'subscript' ? It defines the order !
It is the, long waited for, ordinal number.

However, the question is once more : Is an address a number ?
 --ALfred


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <01be2221$d580b640$15dcdcdc@mentor.magnet.at>, Alfred Kellner
<alfkellner@magnet.at> writes
>However, the question is still : Is an address a number ?

Indeed, why should it be?  I can imagine working on a distributed system
where an address might be some form of extended URL.  Of course the bit
pattern could be interpreted as a number but in that sense everything in
a program is a number.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Alfred Kellner" <alfkellner@magnet.at> writes:

>T*t=0; Has been meant as an address designating the very first
>element of the lagest array of the smallest type that can exist in a given
>address space - not as claim *that* address *is* the NULL pointer, in
>fact, it cannot be (..is distinguishible from every other value of pointer..).

In fact it MUST be a null pointer. A language requirement is that
a literal zero assigned to a pointer type yields a null pointer
of that type, distinguishable from a pointer to any object (or
function) of that type.

For example, a simple implementation on a system with a linear
address space is for address zero to be reserved, and not used
as the address of any entity in the program.

An implemenation can choose to use something else for a null
pointer. In that case, assigning a literal zero to a pointer
object does not result in all-bits-zero, but in some other
value that is never used for any entity in the program.

>However, the question is still : Is an address a number ?

>> Furthermore, your use of the term ordinal implies that arbitrary pairs
>> of addresses can be ordered.

>Agreed, that's implied in pointer arithmetic ++ptr gets the next ptr in sequence,
>and ptr+n the (1+n)-th.

No, that operation is only well-defined for objects within the
same array. The operation result is not defined once you go outside
the bounds of the array. (The address of array+n for an array of
n elements is defined.)

Arbitrary pairs of of addresses need not have any such relationship.

>> There are implementations where that doesn't work either.
>*This* comes as a very surprise to me. Pointer arithmetic doesn't work ?

It's only defined when the results remain within the same complete
object. Example:
 char A[100];
 char *P = A + 101; // 2 past the end of A
The addition of A and 101 is not guaranteed to produce a result;
if it does, the assignment to P is not guaranteed to succeed;
if it does, no operation on P except a new assignment has any
defined result. That is, you are not guaranteed even to be able
to inspect the value of the pointer P.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage <stephen.clamage@sun.com> wrote:
>
> "Alfred Kellner" <alfkellner@magnet.at> writes:
>
> >T*t=0; Has been meant as an address designating the very first
> >element of the lagest array of the smallest type that can exist in a given
> >address space - not as claim *that* address *is* the NULL pointer, in
> >fact, it cannot be (..is distinguishible from every other value of pointer..).
>
> In fact it MUST be a null pointer. A language requirement is that
> a literal zero assigned to a pointer type yields a null pointer
> of that type, distinguishable from a pointer to any object (or
> function) of that type.
>
I'm not talking about well known and accepted language basics.
I'm talking about
 "what conceptually a storage-address within the language is"
The original statement was:
<quote>
<J> I don't have a
<J> copy of the C89 standard, but the draft C9X standard defines alignment
<J> as the "requirement that objects of a particular type be located on
<J> storage boundaries with addresses that are particular multiples of a
<J> byte address".
<V> A very interresting sentence, as an address isn't a number
<V> and simply cannot be a multiple of anything.
</quote>
and I presented a detailed analysis, why this assertion has a solid foundation.

> For example, a simple implementation on a system with a linear
> address space is for address zero to be reserved, and not used
> as the address of any entity in the program.
>
> An implemenation can choose to use something else for a null
> pointer. In that case, assigning a literal zero to a pointer
> object does not result in all-bits-zero, but in some other
> value that is never used for any entity in the program.

The same what I wrote and what got deleted:
<A> The representation of a pointer-value is up to the implementation.
>
> >However, the question is still : Is an address a number ?
No opinion ?
>
> >> Furthermore, your use of the term ordinal implies that arbitrary pairs
> >> of addresses can be ordered.
>
> >Agreed, that's implied in pointer arithmetic ++ptr gets the next ptr in sequence,
> >and ptr+n the (1+n)-th.
>
> No, that operation is only well-defined for objects within the
> same array. The operation result is not defined once you go outside
> the bounds of the array. (The address of array+n for an array of
> n elements is defined.)

The same what I wrote and quoted and what got deleted:
<A>Comparison of pointers to different objects is unspecified,
<quote>5.9 Relational operators
 - If two pointers point to elements of the same array
   or one beyond the end of the array, the pointer to
   the object with the higher subscript compares higher.
</quote>

> Arbitrary pairs of of addresses need not have any such relationship.
>
> >> There are implementations where that doesn't work either.
> >*This* comes as a very surprise to me. Pointer arithmetic doesn't work ?
>
> It's only defined when the results remain within the same complete
> object. Example:
>  char A[100];
>  char *P = A + 101; // 2 past the end of A
> The addition of A and 101 is not guaranteed to produce a result;
> if it does, the assignment to P is not guaranteed to succeed;
> if it does, no operation on P except a new assignment has any
> defined result. That is, you are not guaranteed even to be able
> to inspect the value of the pointer P.

Agreed. See above. Nothing new so far.
But the subject is *not* language basics - the subject is:
 "cannot or can an address be a multiple of anything"

We are wasting time, if we talk about "how many bits in a pointer?".

I think Francis Glassborow knew that, when he wrote:
 [ I can imagine working on a distributed system where
 an address might be some form of extended URL. ]

though I think he left out the smiley :)
 --Alfred



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Wade wrote:

> James Kuyper wrote in message <366BEAC5.41C6@wizard.net>...
> >Furthermore, your use of the term ordinal implies that arbitrary pairs
> >of addresses can be ordered. There are implementations where that
> >doesn't work either.
>
> It doesn't help with alignment, but arbitrary pairs of addresses can be
> ordered.
>
> std::less<T*>, etc. provides a total order for pointers and gives the same
> answer as '<' for cases in which '<' gives a defined result.

Sorry, I keep forgetting that. Why is less<T*> required to provide a
total order, rather than '<'? Does less<T*> typically run much slower
than '<' on systems where '<' does not naturally provide a total order?


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:

(pointer arithmetic)

> It's only defined when the results remain within the same complete
> object. Example:
>         char A[100];
>         char *P = A + 101; // 2 past the end of A
> The addition of A and 101 is not guaranteed to produce a result;
> if it does, the assignment to P is not guaranteed to succeed;
> if it does, no operation on P except a new assignment has any
> defined result. That is, you are not guaranteed even to be able
> to inspect the value of the pointer P.

Once the "A+101" expression has appeared, is ANYTHING defined?
Just wondering.

--

Chris Kuan, BHP Information Technology
Concatenate for email: mr gazpacho @ hotmail . com

"The fools must be dealt with, however."
- Dan Pop, comp.lang.c <danpop.912009650@news.cern.ch>



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alfred Kellner wrote:
>
> James Kuyper <kuyper@wizard.net> wrote:
>
> > Alfred Kellner wrote:
....
> > > A very interresting sentence, since IMHO an address designates an
> > > element of a sequence and can be represented by an ordinal seq-number
> > > ( the I-th element of N elements).
> > > I think the confusion comes from mixing ordinal with cardinal numbers.
> > > ( position 3 twice isn't position 5 or 6 )
> [...some explicit pointer arithmetic...]
> > > That is, what's a multiple is the cardinal amount of predecessors
> > > and not the address. I agree, an address is not a number, though it
> > > can be converted into a number.
>
> > The construction you've done makes unportable assumptions. In
> > particular, there's not guaranteed to be any number 'n' such that
> > '(T*)0+n' is a valid pointer value. There are actual systems where this
> > wouldn't work. There are many systems where most randomly chosen values
> > for 'n' would result in invalid pointers.
>
> Agreed. T*t=0; Has been meant as an address designating the very first
> element of the lagest array of the smallest type that can exist in a given
> address space - not as claim *that* address *is* the NULL pointer, in
> fact, it cannot be (..is distinguishible from every other value of pointer..).

T* t=0 automatically converts a 0 to a (T*); by definition, that is a
null pointer.

The largest array of the smallest type that can exist in a given address
space needn't cover the entire address space. On segmented
architectures, I've seen implementations where arrays were restricted to
fit within a single segment. Incrementing a pointer past the end of one
segment moved the pointer back to the beginning of the segment. (in
order to guarantee that &array[sizeof(array)/sizeof(array[0])]!=array,
the object must actually be smaller than the segment). Differencing
pointers into different segments was meaningless. Comparing them for
equality was the only meaningful relational operation.

> However, the question is still : Is an address a number ?

No.

> > Furthermore, your use of the term ordinal implies that arbitrary pairs
> > of addresses can be ordered.
>
> Agreed, that's implied in pointer arithmetic ++ptr gets the next ptr in sequence,
> and ptr+n the (1+n)-th.

That's only guaranteed to work for pointers within the same object.

> > There are implementations where that doesn't work either.
> *This* comes as a very surprise to me. Pointer arithmetic doesn't work ?

Pointer arithmetic is only defined for pointers that stay within the
same object (or one past it's end).

> > You might think that you could, at a minimum, order addresses by
> > interpreting the bits that make them up as a single unsigned integer.
> No, I don't do that.
> The representation of a pointer-value is up to the implementation.
>
> > Unfortunately, there exist systems where such an
> > ordering would give &array+n < &array, or p1<q && q<p2, where p1 and p2
> > point at the same object.
> Again agreed. Comparison of pointers to different objects is unspecified,
> otherwise ....
> <quote>
>         5.9 Relational operators
>         - If two pointers point to elements of the same array
>           or one beyond the end of the array, the pointer to
>           the object with the higher subscript compares higher.
> <quote>
> Did you notice the word 'subscript' ? It defines the order !
> It is the, long waited for, ordinal number.

Only within a single array object.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:

> I couldn't find a definition of alignment within the C++ standard.
> However, it incorporates the C89 standard by reference.

But only for the library part.

> I don't have a
> copy of the C89 standard, but the draft C9X standard defines alignment
> as the "requirement that objects of a particular type be located on
> storage boundaries with addresses that are particular multiples of a
> byte address".

A very interresting sentence, as an address isn't a number
and simply cannot be a multiple of anything.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]