In article <366D603C.66DD@pratique.fr>, Valentin Bonnard
<bonnardv@pratique.fr> writes
>> The term "alignment" is the *VERY FIRST THING* defined in the C
>> Standard, in clause 3.1:
>>
>>     3.1
>>     [#1] alignment
>>     requirement that objects of a particular type be located  on
>>     storage   boundaries  with  addresses  that  are  particular
>>     multiples of a byte address
>
>Again, what does it mean for an address to be a multiple
>of a number ?

Assume that the alignment of some type T is A. Given:

    char *cp = malloc (N);

then:

    * (T *)(cp + offset) = some_T_value;

is defined when:

    offset >= 0                  // lower boundary requirement
    offset <= N - sizeof (T)     // upper boundary requirement
    offset % A == 0              // alignment requirement

The same applies when cp points to a static or automatic object of N
bytes whose start is aligned correctly (e.g. by being an array of T).

--
Clive D.W. Feather    | Director of            | Work: <clive@demon.net>
Tel: +44 181 371 1138 |   Software Development | Home: <clive@davros.org>
Fax: +44 181 371 1037 | Demon Internet Ltd.    | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


[ 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 <74kaa0$jfn$1@pegasus.csx.cam.ac.uk>, Nick Maclaren
<nmm1@cus.cam.ac.uk> writes
>There is a reasonably clear statement that pointer values must behave
>as if they increment by one for every byte within an object, but I can
>find no statement that the address of an object has the same property,
>except some very throw-away remarks in examples and footnotes.
>
>Consider a machine where pointer values are hashed before looking up
>the memory location - is it explicitly forbidden for the address to
>be the real memory location, and for it to be converted to the
>virtual one when assigned to a pointer?  I can find nothing.
>
>Furthermore, there is a LOT of precedent for addresses having only
>an interval scale

I don't think these are a problem. Any object in C has to be expressable
as a set of adjacent bytes, and the alignment rules can be applied to
offsets within that sequence. I've phrased this one way in another
posting just now, and I see someone else has phrased it in another (and
equally) good way.

If your systems do casts and pointer arithmetic properly, everything
works.

For the avoidance of doubt, casting a pointer to an integer or vice
versa is *not* required to understand this stuff.

--
Clive D.W. Feather    | Director of            | Work: <clive@demon.net>
Tel: +44 181 371 1138 |   Software Development | Home: <clive@davros.org>
Fax: +44 181 371 1037 | Demon Internet Ltd.    | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


[ 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 <vnQydgGFzgf2Ew$Q@on-the-train.demon.co.uk>,
Clive D.W. Feather <clive@demon.net> wrote:
>
>In article <74kaa0$jfn$1@pegasus.csx.cam.ac.uk>, Nick Maclaren
><nmm1@cus.cam.ac.uk> writes
>>There is a reasonably clear statement that pointer values must behave
>>as if they increment by one for every byte within an object, but I can
>>find no statement that the address of an object has the same property,
>>except some very throw-away remarks in examples and footnotes.
>>
>>Consider a machine where pointer values are hashed before looking up
>>the memory location - is it explicitly forbidden for the address to
>>be the real memory location, and for it to be converted to the
>>virtual one when assigned to a pointer?  I can find nothing.
>>
>>Furthermore, there is a LOT of precedent for addresses having only
>>an interval scale
>
>I don't think these are a problem. Any object in C has to be expressable
>as a set of adjacent bytes, and the alignment rules can be applied to
>offsets within that sequence. I've phrased this one way in another
>posting just now, and I see someone else has phrased it in another (and
>equally) good way.

Actually, I have serious reservations about both phrasings, and feel
that they introduce an unreasonable number of implementation dependent
assumptions.  I am happy with the example you give, but not with any
of the revised wordings.

The point is that there are two concepts, which should really be
separated and specified individually:

    1) The constraint on alignment as being a suitable value of
ptrdiff_t to convert one valid pointer of type T* into another.

    2) The constraint on which pointers may be suitable for casting
to types T * in the first place.  E.g. malloc is, but getenv isn't.

The latter gets REALLY nasty when (say) getenv returns a string
that is over twice the length of (say) a struct {char a;}.  Is it
REQUIRED that there be at least one offset that can be added to the
string and legally cast to a pointer to the latter?

This isn't a problem with the standard C library, as there are few
occasions on which this is worth the effort, but most definitely is
for some C-conforming interfaces - especially ones that are defined
to be a fixed header plus a variable-length array, with the array
aligned correctly.

And, yes, I was caught by that.  Eventually, I thought "Sod it.  Any
implementation that disables this entirely will break so much that
they will never get around to compiling my code."  But I couldn't
do it completely cleanly.

>If your systems do casts and pointer arithmetic properly, everything
>works.
>
>For the avoidance of doubt, casting a pointer to an integer or vice
>versa is *not* required to understand this stuff.

Absolutely.  There is no particular reason why casting to an integer
shouldn't return an encrypted form of the value.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


[ 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 <75masa$feq$1@pegasus.csx.cam.ac.uk>,
  nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
> The latter gets REALLY nasty when (say) getenv returns a string
> that is over twice the length of (say) a struct {char a;}.  Is it
> REQUIRED that there be at least one offset that can be added to the
> string and legally cast to a pointer to the latter?

I think that this is the best expression yet of the problem.
What's really being asked is how to modify an address, which
leads to questions about addresses being numbers or at least
containing a numeric offset...

But if you have a buffer of size 2*sizeof(myClass) or more,
is it required that somewhere in that buffer is a chunk of
memory which we can use for a myClass object? The standard
doesn't say so directly -- and yet, I say that the PRACTICAL
requirement is there. That is, on ANY architechture capable
of hosting a C++ program, this MUST apply.

--
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 <francis@robinton.demon.co.uk> wrote:

>
> In article <366FD3DA.FF631963@physik.tu-muenchen.de>, Christopher
> Eltschka <celtschk@physik.tu-muenchen.de> writes
> >From the standard it follows that correctly aligned
> >addresses exist (because you can create objects). For separate
> >objects, this is all you need to know.
>
> But surely I need to know if I am to write overloads/replacement for
> operator new.

As far as I can tell, the standard does not give you any means to
do this. If you want to write operator new that manages (say) a
large buffer (for example, carves out sections off a char[1000000]),
you need to make non-portable assumptions. It would sure be nice
if you could say "get_next_possible_address<T>(begin,end)", but
there's no portable way to do so currently.

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

Francis Glassborow wrote:
>
> In article <366FD3DA.FF631963@physik.tu-muenchen.de>, Christopher
> Eltschka <celtschk@physik.tu-muenchen.de> writes
> >From the standard it follows that correctly aligned
> >addresses exist (because you can create objects). For separate
> >objects, this is all you need to know.
>
> But surely I need to know if I am to write overloads/replacement for
> operator new.

In C++, there are generally only three ways to get memory:
- via an built-in allocation function
- via a static variable
- via an automatic variable

If you write your own allocation function, you either use a
built-in allocation function,. in which case you know the result is
correctly aligned, or you "sub-allocate" from a static variable
(usually a char array), in which case you are dealing with
addresses within one single object, so you don't need any knowledge
about the relation of addresses of separate objects as well.

Now, unfortunately, the standard doesn't give us enough
in the second case, namely a way to determine a correctly aligned
address inside a function (or at least a way to determine
if an address is correctly aligned). However, if there were
such a function, we would still use it inside one single
object - the char array object.

So even if the standard *would* give us the necessary information,
it would not invalidate my claim: For *separate* objects, you
don't need to know about alignment, except that correctly
aligned addresses exist. Address arithmetic is undefined there
anyway.

Indeed, in a segmented architecture, you cannot really prove
that "real" memory addresses are aligned "correctly" - there
could be different types of real memory which have different
alignment rules, and ther virtual memory mechanism might map
the memory according to those rules (i.e. may be able to put
memory on byte boundary resolution on "fine grained" memory,
and on word boundary resolution otherwise. Not that I think
any computer does this, or that it would make sense. But it
is possible in theory, and no program would be able to check
it (except if the OS provides info about it, of course).


[ 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 <366FD3DA.FF631963@physik.tu-muenchen.de>, Christopher
Eltschka <celtschk@physik.tu-muenchen.de> writes
>From the standard it follows that correctly aligned
>addresses exist (because you can create objects). For separate
>objects, this is all you need to know.

But surely I need to know if I am to write overloads/replacement for
operator new.



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              ]

> Valentin:
> > And can anyone explain clearly and correctly (and in a
> > provably correct way) what is alignment ?

In article <3.0.5.32.19981208193048.00935a70@central.beasys.com>,
  David R Tribble <david.tribble@dallas.beasys.com> wrote:
> I'm not going to try.  But what, precisely, is wrong with the
> wording in the standard?  We all seem to know what alignment is,
> yet some claim that the concept can't be written in plain English.
> Why not?
>
> I changed my mind, I'll try:
>     The addresses of primitive types of objects may be restricted
>     to different ranges of values.  For example, the possible
>     addresses of an object of type T1 may be limited to a subset
>     of the possible addresses of a object of type T2, or they
>     be limited to a completely disjoint set of values entirely.
>
> Oh, to hell with it.  How do Intel, Motorola, et al define
> alignment?  Do they use words that are better than 'byte',
> 'storage', 'address', 'boundary', and 'multiples'?

As far as I know, alignment is always in terms of some power of two.
So alignment becomes a requirement that for certain data types, the
low N bits of the bit-pattern of a pointer value must be set to 0,
where the value N depends both on the data type and on the
implementation.

Given this description, we can calculate M as the maximum value for
N for all data types on any one given implementation, and require
that malloc, operator new, etc. return pointers where the low M bits
are always 0 bits. The result is suitably aligned for any type of
datum.

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

David R Tribble <david.tribble@dallas.beasys.com> writes:

>Oh, to hell with it.  How do Intel, Motorola, et al define
>alignment?  Do they use words that are better than 'byte',
>'storage', 'address', 'boundary', and 'multiples'?

There is no problem in defining "alignment" for a particular
implementation or platform.

Example: This platform uses a single linear address space, each
possible address being represented and interpreted as an
unsigned integer of 32 bits. Some data types must be allocated
at addresses which are multiples of some small integer, as
follows: short-2, int-4, double-8, [... etc]

The problem is defining it in an implementation-neutral way.
The above example isn't quite adequate for a segmented
architecture, and fails to take into account validation built
into some architectures (capability-based architectures, for
example).

The C++ standard tries to be implementation-neutral, and
tries not to rule out unusual or innovative architectures.
It therefore tries not to imply any particular mapping
between addresses and pointers, and tries not to imply any
particular characteristics of addresses. (Some characteristics
are probably constrained by the required properties of integer
types and arrays, however.)

Ideally, the standard wouldn't mention the word "address" at
all, but that doesn't seem possible.  It acknowleges that some
implementations have requirements on the placement of various
kinds of entities. It subsumes those requirements under the
term "alignment."

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

David R Tribble wrote:
[...]
> Valentin Bonnard wrote:
[...]
> > And can anyone explain clearly and correctly (and in a
> > provably correct way) what is alignment ?
>
> I'm not going to try.

Well, let me try, in C++ language:

First, we define two pointers p1 and p2 to be "comparable", if there
exists an integral number n, so that (char*)p1 + n == (char*)p2.
In that case, obviously n==(char*)p2-(char*)p1. Let's call n the
"true difference" of the two pointers.

Then, we can define a pointer type to have an alignment of m,
if for each pair of comparable pointers to that type the true
difference of that pointer is an integral multiple of m.

Now you might object that for pointers to separate objects,
the sum is not defined. Now, for different objects, the alignment
doesn't really matter, except that the start of each object is
correctly aligned for that object. An implementation on a segmented
architecture could decide to put each complete object into its own
segment. From the standard it follows that correctly aligned
addresses exist (because you can create objects). For separate
objects, this is all you need to know.

[...]


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

David R Tribble wrote:
>
> Clive D.W. Feather wrote:
> > The term "alignment" is the *VERY FIRST THING* defined in the C
> > Standard, in clause 3.1:
> >     3.1
> >     [#1] alignment
> >     requirement that objects of a particular type be located  on
> >     storage   boundaries  with  addresses  that  are  particular
> >     multiples of a byte address.
>
> Valentin Bonnard wrote:
> > Is there a diffence between an address and a pointer?
>
> Probably.  Consider a pointer to an int on a machine where ints
> must be aligned on 4-byte boundaries.  (Notice that I'm using the
> same words that are used in the standard, which seemed to convey,
> until recently, fairly well-understood concepts. </digression>)

It isn't recent: I have never understound alignement.

> Valentin:
> > And can anyone explain clearly and correctly (and in a
> > provably correct way) what is alignment ?
>
> I'm not going to try.  But what, precisely, is wrong with the
> wording in the standard?

It doesn't make sens. It never defines how an address can be
a multiple of whatever (an integer, an address, a program,
an arrow or what you want).

> We all seem to know what alignment is,

In C/C++, I am not sure that I know what it is

> yet some claim that the concept can't be written in plain English.
> Why not?

I don't. (But we are in comp.STD.c++, so we should try
to write it in standardise, not english. <g>)

> I changed my mind, I'll try:
>     The addresses of primitive types of objects may be restricted
>     to different ranges of values.  For example, the possible
>     addresses of an object of type T1 may be limited to a subset
>     of the possible addresses of a object of type T2, or they
>     be limited to a completely disjoint set of values entirely.

Quite nice. Now, if we had a way to determine which addresses
are valid for a given type, it would be even better... maybe
for the next std ?

--

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              ]

In article <74c927$g3m$1@pegasus.csx.cam.ac.uk>, Nick Maclaren
<nmm1@cus.cam.ac.uk> writes
>To the best of my knowledge, the definition of the term "alignment"
>has been intentionally left unspecified.

Huh ?

The term "alignment" is the *VERY FIRST THING* defined in the C
Standard, in clause 3.1:

    3.1
    [#1] alignment
    requirement that objects of a particular type be located  on
    storage   boundaries  with  addresses  that  are  particular
    multiples of a byte address

--
Clive D.W. Feather    | Director of            | Work: <clive@demon.net>
Tel: +44 181 371 1138 |   Software Development | Home: <clive@davros.org>
Fax: +44 181 371 1037 | Demon Internet Ltd.    | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


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

Clive D.W. Feather wrote:

> The term "alignment" is the *VERY FIRST THING* defined in the C
> Standard, in clause 3.1:
>
>     3.1
>     [#1] alignment
>     requirement that objects of a particular type be located  on
>     storage   boundaries  with  addresses  that  are  particular
>     multiples of a byte address

Again, what does it mean for an address to be a multiple
of a number ?

Is there a diffence between an address and a pointer ?

And can anyone explain clearly and correctly (and in a
provably correct way) what is alignement ?

--

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              ]

In article <moGA+hBPKOb2Ewe$@on-the-train.demon.co.uk>,
Clive D.W. Feather <clive@demon.net> wrote:
>
>In article <74c927$g3m$1@pegasus.csx.cam.ac.uk>, Nick Maclaren
><nmm1@cus.cam.ac.uk> writes
>>To the best of my knowledge, the definition of the term "alignment"
>>has been intentionally left unspecified.
>
>Huh ?
>
>The term "alignment" is the *VERY FIRST THING* defined in the C
>Standard, in clause 3.1:
>
>    3.1
>    [#1] alignment
>    requirement that objects of a particular type be located  on
>    storage   boundaries  with  addresses  that  are  particular
>    multiples of a byte address

Yes, I mean what I say.  That defines it in terms of two other concepts,
one of which is defined only by implication and the other not at all.

There is a reasonably clear statement that pointer values must behave
as if they increment by one for every byte within an object, but I can
find no statement that the address of an object has the same property,
except some very throw-away remarks in examples and footnotes.

Consider a machine where pointer values are hashed before looking up
the memory location - is it explicitly forbidden for the address to
be the real memory location, and for it to be converted to the
virtual one when assigned to a pointer?  I can find nothing.

Furthermore, there is a LOT of precedent for addresses having only
an interval scale - i.e. ones where the difference between two is an
integer, but where the ratio of two addresses is not well-defined.
Most segmented systems are like this, and there is no obvious reason
why addresses within a segment shouldn't be offset by anything that
the compiler feels is convenient, whether or not it bears any
relationship to the hardware requirements.  In such a case, what IS
the address of an object, because its numeric value (converted to
an integer) is not a multiple of its alignment.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


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

Clive D.W. Feather wrote:
> The term "alignment" is the *VERY FIRST THING* defined in the C
> Standard, in clause 3.1:
>     3.1
>     [#1] alignment
>     requirement that objects of a particular type be located  on
>     storage   boundaries  with  addresses  that  are  particular
>     multiples of a byte address.

Valentin Bonnard wrote:
> Is there a diffence between an address and a pointer?

Probably.  Consider a pointer to an int on a machine where ints
must be aligned on 4-byte boundaries.  (Notice that I'm using the
same words that are used in the standard, which seemed to convey,
until recently, fairly well-understood concepts. </digression>)
Thus, int objects have stricter alignment requirements than simple
byte (char) objects.

Now consider that the pointer contains a value that does not
correspond to the address of an integer object of proper alignment.
It is reasonable to say that the address is not a valid int pointer.
In other words, addresses are not necessarily pointers.  (But
pointers, with the possible exception of null, are addresses.)

Valentin:
> And can anyone explain clearly and correctly (and in a
> provably correct way) what is alignment ?

I'm not going to try.  But what, precisely, is wrong with the
wording in the standard?  We all seem to know what alignment is,
yet some claim that the concept can't be written in plain English.
Why not?

I changed my mind, I'll try:
    The addresses of primitive types of objects may be restricted
    to different ranges of values.  For example, the possible
    addresses of an object of type T1 may be limited to a subset
    of the possible addresses of a object of type T2, or they
    be limited to a completely disjoint set of values entirely.

Oh, to hell with it.  How do Intel, Motorola, et al define
alignment?  Do they use words that are better than 'byte',
'storage', 'address', 'boundary', and 'multiples'?

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

Valentin Bonnard wrote:
>
> Clive D.W. Feather wrote:
>
> > The term "alignment" is the *VERY FIRST THING* defined in the C
> > Standard, in clause 3.1:
> >
> >     3.1
> >     [#1] alignment
> >     requirement that objects of a particular type be located  on
> >     storage   boundaries  with  addresses  that  are  particular
> >     multiples of a byte address
>
> Is there a diffence between an address and a pointer ?

Yes. An address is the physical numeric location of something within an
underlying address space understood by the hardware, while a pointer is
a C++ (or C) construct used to hold an address. They differ in that the
compiler implicitly redefines (or leaves undefined) pointer arithmetic
operations to hide the relationship between pointers and addresses from
the programmer (e.g., by scaling increments by sizeof(T)).

> Again, what does it mean for an address to be a multiple
> of a number ?

Given the above distinction, the answer is self-evident.

> And can anyone explain clearly and correctly (and in a
> provably correct way) what is alignement ?

I don't see what the difficulty is. As long as you never cast anything
to a pointer, then you can ignore alignment questions, as the compiler
completely takes care of it, and you can therefore pretend that pointers
are mere conceptual constructs that point to other things. As soon as
you cast something to a pointer (either a number or a different type
pointer), you expose the possible limitations of the underlying
hardware, and have to understand that pointers are actually numeric
addresses that have to adhere to certain restrictions. But as soon as
you view a pointer as a number, it is perfectly obvious what it means to
require that it be a multiple of two, or four, or eight.

Or am I missing the significance of your question?

--

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              ]

On 8 Dec 1998 17:49:22 GMT, Valentin Bonnard <bonnardv@pratique.fr>
wrote:

>
>Clive D.W. Feather wrote:
>
>> The term "alignment" is the *VERY FIRST THING* defined in the C
>> Standard, in clause 3.1:
>>
>>     3.1
>>     [#1] alignment
>>     requirement that objects of a particular type be located  on
>>     storage   boundaries  with  addresses  that  are  particular
>>     multiples of a byte address
>
>Again, what does it mean for an address to be a multiple
>of a number ?

I think the problem arises because the definition of alignment does
not mention that, although pointers are self-sustained concepts,
alignments are with respect to some (conceptual) char array object.

The alignment of "T*p;" would then be defined by the difference
"(char*)p-q" (a number) where q is a char array into which p points.
(The process that made p point into *q is unspecified.)

As far as I can tell, this definition is supported by the "spirit" of
the standard, but is not what you called "provably correct".




[ 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 <366890A0.AD570224@wizard.net>,
James Kuyper  <kuyper@wizard.net> wrote:
>Valentin Bonnard 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.
>
>I just copied it; I didn't write it. I'm cross-posting to comp.std.c, to
>see if those who know more about it than I do would care to comment.

Pointers aren't numbers, but addresses generally are.  Addresses are the
hardware things that pointers are an abstraction of.

On hardware that doesn't have numeric addresses, alignment typically isn't
an issue.  The alignment references in the standard are there to make
allowances for hardware that does have alignment restrictions.  They
specify the expectations that a programmer can make in the face of
implementation needs to deal with these hardware-specific issues.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.


[ 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 <366890A0.AD570224@wizard.net>,
James Kuyper  <kuyper@wizard.net> wrote:
>
>Valentin Bonnard 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.
>
>I just copied it; I didn't write it. I'm cross-posting to comp.std.c, to
>see if those who know more about it than I do would care to comment.

To the best of my knowledge, the definition of the term "alignment"
has been intentionally left unspecified.  Certainly, there have been
formal requests for clarification that were met with the response that
the standard is clear enough as it is (or equivalent.)

I believe that I understand what is implied by the term, but it has
taken me 10 years to deduce it, and I am only 75% confident that I
am right.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


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

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

Alignment isn't part of the language, but it's relevant because
it impacts implementations, causing padding to appear.
The need for alignment is (usually) caused by an underlying
numerical addressing scheme that has the properties as described.
Sometimes the hardware enforces the requirement,
and sometimes the implementation makes the choice so that the code
runs faster (typically, by aligning at the cache level).



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

I just copied it; I didn't write it. I'm cross-posting to comp.std.c, to
see if those who know more about it than I do would care to comment.


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