In article <WLudnWjZzJkLOynYnZ2dnUVZ_tHinZ2d@giganews.com>,
 pete@versatilecoding.com (Pete Becker) wrote:
>   wrote:
> > Is there a portable way to implement an allocation function that fulfills
> > the alignment requirements
> > by other means than calling the standard C library functions?
> No. There are two approaches commonly used. One is to define a union of
> a bunch of types and hope that you've hit all the alignments that the
> compiler uses.

Which will fail on as common a plattform as the Mac. The required
alignment is multiples of 16, whereas the size of the largest standard
type is only 8.

> The other is to simply define the alignment you're going
> to use to match the compiler's documented alignment. The latter works
> fine in practice.

Which implies that the code is only portable to what it was specifically
designed for. Aka not portable.

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

"K   i   tof    elechovski" wrote:
> Is there a portable way to implement an allocation function that fulfills
> the alignment requirements
> by other means than calling the standard C library functions?

I think you could do

template<typename T>
T* allocate(size_t n);

Then you will have to explicitly specify T when calling the function,
and T must be complete.

This is probably cleaner than a void* interface anyway.


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

  wrote:
> Is there a portable way to implement an allocation function that fulfills
> the alignment requirements
> by other means than calling the standard C library functions?

No. There are two approaches commonly used. One is to define a union of
a bunch of types and hope that you've hit all the alignments that the
compiler uses. The other is to simply define the alignment you're going
to use to match the compiler's documented alignment. The latter works
fine in practice.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

"K   i   tof    elechovski" wrote:
> Is there a portable way to implement an allocation function that fulfills
> the alignment requirements
> by other means than calling the standard C library functions?
> The problem is that the result must be aligned for any type;
> however, it is impossible to test whether a given raw pointer is suitably
> aligned for an object of any possible type,

No, the requirement is not that the memory allocated must be suitably
aligned for "any" type - just suitably aligned for any type small
enough to fit within the allocated block. After all, if an instance of
a particular type is too large to be placed in the allocated memory,
then whether the block is suitably aligned for objects of that
particular type is not a practical concern.

Greg


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy wrote:
> "K=F8i=B9tof =AEelechovski" wrote:
>> Is there a portable way to implement an allocation function that fulfi=
lls
>> the alignment requirements
>> by other means than calling the standard C library functions?
>> The problem is that the result must be aligned for any type;
>> however, it is impossible to test whether a given raw pointer is suita=
bly
>> aligned for an object of any possible type,
>=20
> No, the requirement is not that the memory allocated must be suitably
> aligned for "any" type - just suitably aligned for any type small
> enough to fit within the allocated block. After all, if an instance of
> a particular type is too large to be placed in the allocated memory,
> then whether the block is suitably aligned for objects of that
> particular type is not a practical concern.
>=20

That's a reasonable suggestion, but I don't see it in the standard. In=20
particular, [basic.stc.dynamic.allocation]/2 says: "The pointer returned=20
shall be suitably aligned so that it can be converted to a pointer of=20
any complete object type ..."

--=20

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and=20
Reference." (www.petebecker.com/tr1book)

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Pete Becker wrote:
> Greg Herlihy wrote:
> > "K   i   tof    elechovski" wrote:
> >> Is there a portable way to implement an allocation function that fulfills
> >> the alignment requirements
> >> by other means than calling the standard C library functions?
> >> The problem is that the result must be aligned for any type;
> >> however, it is impossible to test whether a given raw pointer is suitably
> >> aligned for an object of any possible type,
> >
> > No, the requirement is not that the memory allocated must be suitably
> > aligned for "any" type - just suitably aligned for any type small
> > enough to fit within the allocated block. After all, if an instance of
> > a particular type is too large to be placed in the allocated memory,
> > then whether the block is suitably aligned for objects of that
> > particular type is not a practical concern.
> >
>
> That's a reasonable suggestion, but I don't see it in the standard. In
> particular, [basic.stc.dynamic.allocation]/2 says: "The pointer returned
> shall be suitably aligned so that it can be converted to a pointer of
> any complete object type ..."

I would cite the Standard's discussion of C++'s new() operator -
including both the new() operator that allocates single objects:

"The allocation function called by a new-expression to allocate size
bytes of storage suitably aligned to represent any object of that
size.' [   18.5.1.1/1]

as well as the new[] operator that allocates arrays of objects:

"The allocation function called by the array form of a new-expression
to allocate size bytes of storage suitably aligned to represent any
array object of that size or smaller. [   18.5.1.2/1]" (also    5.3.4/11)

Greg


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "Pete Becker" <pete@versatilecoding.com> napisal w wiadomosci news:WLudnWjZzJkLOynYnZ2dnUVZ_tHinZ2d@giganews.com...
>  wrote:
>> Is there a portable way to implement an allocation function that fulfills
>> the alignment requirements
>> by other means than calling the standard C library functions?
>
> No. There are two approaches commonly used. One is to define a union of
> a bunch of types and hope that you've hit all the alignments that the
> compiler uses. The other is to simply define the alignment you're going
> to use to match the compiler's documented alignment. The latter works
> fine in practice.

In that case, how about adding a constant for universal alignment to the Standard?
If the compiler vendor is required to document the alignment,
she should also be required to publish this essential information in a standard header, e.g. <cstddef>.
Perhaps it should be imported from the C standard?
What do you think?
Chris

(And, by the way, Microsoft CRT malloc library function
does not provide an alignment appropriate for extended arithmetic types
specified by the compiler to support advanced Intel coprocessor extensions.)

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy wrote:
> Pete Becker wrote:
>> Greg Herlihy wrote:
>>> "K=F8i=B9tof =AEelechovski" wrote:
>>>> Is there a portable way to implement an allocation function that ful=
fills
>>>> the alignment requirements
>>>> by other means than calling the standard C library functions?
>>>> The problem is that the result must be aligned for any type;
>>>> however, it is impossible to test whether a given raw pointer is sui=
tably
>>>> aligned for an object of any possible type,
>>> No, the requirement is not that the memory allocated must be suitably
>>> aligned for "any" type - just suitably aligned for any type small
>>> enough to fit within the allocated block. After all, if an instance o=
f
>>> a particular type is too large to be placed in the allocated memory,
>>> then whether the block is suitably aligned for objects of that
>>> particular type is not a practical concern.
>>>
>> That's a reasonable suggestion, but I don't see it in the standard. In
>> particular, [basic.stc.dynamic.allocation]/2 says: "The pointer return=
ed
>> shall be suitably aligned so that it can be converted to a pointer of
>> any complete object type ..."
>=20
> I would cite the Standard's discussion of C++'s new() operator -
> including both the new() operator that allocates single objects:
>=20
> "The allocation function called by a new-expression to allocate size
> bytes of storage suitably aligned to represent any object of that
> size.' [=A718.5.1.1/1]
>=20
> as well as the new[] operator that allocates arrays of objects:
>=20
> "The allocation function called by the array form of a new-expression
> to allocate size bytes of storage suitably aligned to represent any
> array object of that size or smaller. [=A718.5.1.2/1]" (also =A75.3.4/1=
1)
>=20

That's what the standard library's operator new and operator new[] are=20
specified to do. But it's not what allocation functions in general are=20
required to do. The difference may be accidental, but it's there,=20
nevertheless.

--=20

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and=20
Reference." (www.petebecker.com/tr1book)

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Kristof Zelechovski wrote:
> Uzytkownik "Pete Becker" <pete@versatilecoding.com> napisal w wiadomosci news:WLudnWjZzJkLOynYnZ2dnUVZ_tHinZ2d@giganews.com...
>>  wrote:
>>> Is there a portable way to implement an allocation function that fulfills
>>> the alignment requirements
>>> by other means than calling the standard C library functions?
>> No. There are two approaches commonly used. One is to define a union of
>> a bunch of types and hope that you've hit all the alignments that the
>> compiler uses. The other is to simply define the alignment you're going
>> to use to match the compiler's documented alignment. The latter works
>> fine in practice.
>
> In that case, how about adding a constant for universal alignment to the Standard?
> If the compiler vendor is required to document the alignment,

Sorry, I overstated it: the compiler isn't required to document the
alignment. Sometimes you just have to experiment.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

"K   i   tof    elechovski" wrote:
> Is there a portable way to implement an allocation function that fulfills
> the alignment requirements
> by other means than calling the standard C library functions?

No.

> The problem is that the result must be aligned for any type;

Correct. The closest you can come is to define a static array of a type
which is the union of many different C++ types. However, there's an
effectively infinite number of different types that could have distinct
alignment requirements from each other.  The will only be a small
number of different alignment requirements, but there's no way to
construct a  correspondingly small set of types guaranteed to cover
them all. In practice, a union that includes every basic type, every C
standard library typedef, a structure type, a pointer to that struct,
void*, and void(*)(void) is likely to work on most implementations.


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

kuyper@wizard.net wrote:
> "K   i   tof    elechovski" wrote:
> > Is there a portable way to implement an allocation function that fulfills
> > the alignment requirements
> > by other means than calling the standard C library functions?

> No.
>
> > The problem is that the result must be aligned for any type;

> Correct. The closest you can come is to define a static array of a type
> which is the union of many different C++ types. However, there's an
> effectively infinite number of different types that could have distinct
> alignment requirements from each other.  The will only be a small
> number of different alignment requirements, but there's no way to
> construct a  correspondingly small set of types guaranteed to cover
> them all. In practice, a union that includes every basic type, every C
> standard library typedef, a structure type, a pointer to that struct,
> void*, and void(*)(void) is likely to work on most implementations.

In practice, the typedef's in the standard library are either to
basic types, pointers, or structs or unions of such types, so
you don't need them.  I also dropped pointers to members (which
you seem to have forgotten) from my union, because in practice,
compilers implement them as if they were an existing basic type
or a struct.  So you're down to a fairly small, finite set for
C++, today.

In C, of course, and in the next version of C++, you also have
the types defined in <stdint.h>.  And this is an open set.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik <kuyper@wizard.net> napisal w wiadomosci news:1169467148.54035=
4.258200@l53g2000cwa.googlegroups.com...
> "K=F8i=B9tof =AEelechovski" wrote:
>> Is there a portable way to implement an allocation function that fulfi=
lls
>> the alignment requirements
>> by other means than calling the standard C library functions?
>=20
> No.
>=20
>> The problem is that the result must be aligned for any type;
>=20
> Correct. The closest you can come is to define a static array of a type
> which is the union of many different C++ types. However, there's an
> effectively infinite number of different types that could have distinct
> alignment requirements from each other.  The will only be a small
> number of different alignment requirements, but there's no way to
> construct a  correspondingly small set of types guaranteed to cover
> them all. In practice, a union that includes every basic type, every C
> standard library typedef, a structure type, a pointer to that struct,
> void*, and void(*)(void) is likely to work on most implementations.
>=20

And what about enumerated types, member pointers,=20
polymorphic classes with virtual inheritance that cannot be members of a =
union? =20
I am afraid it can be much more complicated.
But this also means=20
that [new.delete.single] does not really impose any requirement upon the =
compiler vendor=20
since the vendor can always do away=20
by not providing the information how alignment requirements are generated=
. =20
Any user-supplied implementation of the global operator new,=20
except for the one that always fails or is a wrapper around a C library a=
llocation function,
would cause undefined behaviour in this setting.
Therefore this requirement really means that the user-. =20
I would welcome such a footnote to the text.
And besides, it is still underspecified what data alignment *really* mean=
s.
And that also means that the compiler-supplied array length prefix size=20
as is sometimes required for the expression new T[] must really be sizeof=
(union { size_t; T; }), doesn't it?

Chris

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Kristof Zelechovski wrote:
>
> And what about enumerated types, member pointers,
> polymorphic classes with virtual inheritance that cannot be members of a union?

They're usually consistent with the others. Writing a union doesn't
guarantee that you'll get the alignment right, but in practice, it works.

> I am afraid it can be much more complicated.
> But this also means
> that [new.delete.single] does not really impose any requirement upon the compiler vendor
> since the vendor can always do away
> by not providing the information how alignment requirements are generated.

It imposes a requirement, but that requirement is not testable by code
written to conform to the standard.

> And besides, it is still underspecified what data alignment *really* means.

Yup. Deliberately.

> And that also means that the compiler-supplied array length prefix size
> as is sometimes required for the expression new T[] must really be sizeof(union { size_t; T; }), doesn't it?
>

Its size has to match the alignment required for T, which is often
smaller than T itself.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> kuyper@wizard.net wrote:
.
> > Correct. The closest you can come is to define a static array of a type
> > which is the union of many different C++ types. However, there's an
> > effectively infinite number of different types that could have distinct
> > alignment requirements from each other.  The will only be a small
> > number of different alignment requirements, but there's no way to
> > construct a  correspondingly small set of types guaranteed to cover
> > them all. In practice, a union that includes every basic type, every C
> > standard library typedef, a structure type, a pointer to that struct,
> > void*, and void(*)(void) is likely to work on most implementations.
>
> In practice, the typedef's in the standard library are either to
> basic types, pointers, or structs or unions of such types, so
> you don't need them.  I also dropped pointers to members (which
> you seem to have forgotten) from my union, because in practice,

It's not that I forgot them, but rather that I've used them so seldom
that I wasn't confident of my ability to declare an example correctly,
and all of my C++ books were at home (which tells you something about
WHY I don't use pointers to members very often). However, I was also
thinking of your reason:

> compilers implement them as if they were an existing basic type
> or a struct.

My list could not possibly be exhaustive, which was my point. It was
quite long enough to work on a very wide array of platforms, and that's
pretty much the best you can hope for, which was also my point.

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Is there a portable way to implement an allocation function that fulfills
the alignment requirements
by other means than calling the standard C library functions?
The problem is that the result must be aligned for any type;
however, it is impossible to test whether a given raw pointer is suitably
aligned for an object of any possible type,
even if we can use alignment_of, because there are infinitely many composite
types
and their alignment cannot be inferred from their structure by standard
means.
Cf. also [basic.types]/5: it is undefined what it means that an address
meets alignment requirements.
Cf. also [meta.unary.prop]/2: it is undefined what it means that an address
is a multiple of an integer;
although it seems to be a more specific description than that
[basic.types]/5,
the standard does not specify any way to obtain an address from an integer
by multiplication,
except for reinterpret_cast<address>(integer * alignment), which is
implementation-defined;
however, it is not clear that this is the intended meaning.


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]