Christopher Wright wrote:
Frits van Bommel wrote:
But the union's alignment needs to be sufficient for all members, so
it depends on the maximum alignment of all members.
Or the least common multiple, assuming that align accepts arguments that
are not powers of 2.
I have never seen "alignme
Frits van Bommel wrote:
Stewart Gordon wrote:
Don wrote:
Stewart Gordon wrote:
Surely, align isn't applicable to unions at all. IINM the members
of a union, by design, start at the same offset.
Not so, the alignment of each member should be respected.
But the offset of a union member i
Frits van Bommel wrote:
Stewart Gordon wrote:
But the offset of a union member is always zero. So what would this do?
It should make sure the union is aligned appropriately in a containing
struct, meaning U.alignof >= M.alignof for all members M. Specifying
per-member alignment allows you
Stewart Gordon wrote:
Don wrote:
Stewart Gordon wrote:
Surely, align isn't applicable to unions at all. IINM the members of
a union, by design, start at the same offset.
Not so, the alignment of each member should be respected.
But the offset of a union member is always zero. So what w
Don wrote:
Stewart Gordon wrote:
Surely, align isn't applicable to unions at all. IINM the members of
a union, by design, start at the same offset.
Not so, the alignment of each member should be respected.
But the offset of a union member is always zero. So what would this do?
Most ob
Stewart Gordon wrote:
Unions are normally aligned to the maximum alignment for any member.
Now consider:
union U {
align(1) void* p;
ubyte[size_t.sizeof] bytes;
}
union U2 {
align(4) ubyte[12] data;
char[12] str;
}
What are U.alignof and U2.alignof?
According to that piece of t
Michel Fortin wrote:
On 2009-04-13 09:43:53 -0400, Frits van Bommel
said:
(How does this combine with the "D ABI" anyway? I know binary
compatibility between the different compilers is a bit of a pipe dream
at the moment, but the only way that could work would be to
standardize any and all
On 2009-04-13 09:43:53 -0400, Frits van Bommel
said:
(How does this combine with the "D ABI" anyway? I know binary
compatibility between the different compilers is a bit of a pipe dream
at the moment, but the only way that could work would be to standardize
any and all shuffling of class fie
On Mon, Apr 13, 2009 at 3:00 PM, Denis Koroskin <2kor...@gmail.com> wrote:
> On Mon, 13 Apr 2009 16:44:25 +0400, Tomas Lindquist Olsen
> wrote:
>
>> On Mon, Apr 13, 2009 at 2:05 PM, Frits van Bommel
>> wrote:
>>>
>>> Kagamin wrote:
Stewart Gordon Wrote:
> At the moment, the pro
Frits van Bommel wrote:
Stewart Gordon wrote:
[rearrangement of class fields]
Right, forgot about that bit. Probably because AFAIK no D compiler
actually reorganizes them...
(How does this combine with the "D ABI" anyway? I know binary
compatibility between the different compilers is a bi
Stewart Gordon wrote:
Frits van Bommel wrote:
Kagamin wrote:
Such mood was always in the spec: "AlignAttribute is ignored when
applied to declarations that are not structs or struct members".
I never saw that before. So it doesn't work for class members?
http://www.digitalmars.com/d/1.0/c
On Mon, 13 Apr 2009 16:44:25 +0400, Tomas Lindquist Olsen
wrote:
On Mon, Apr 13, 2009 at 2:05 PM, Frits van Bommel
wrote:
Kagamin wrote:
Stewart Gordon Wrote:
At the moment, the problem seems to be that the compiler is silently
ignoring many cases of (a), (b) and (c) alike. Some people
Frits van Bommel wrote:
Kagamin wrote:
Such mood was always in the spec: "AlignAttribute is ignored when
applied to declarations that are not structs or struct members".
I never saw that before. So it doesn't work for class members?
http://www.digitalmars.com/d/1.0/class.html
"The D compil
On Mon, Apr 13, 2009 at 2:05 PM, Frits van Bommel
wrote:
> Kagamin wrote:
>>
>> Stewart Gordon Wrote:
>>
>>> At the moment, the problem seems to be that the compiler is silently
>>> ignoring many cases of (a), (b) and (c) alike. Some people argue that the
>>> spec doesn't forbid such use of inapp
Kagamin wrote:
Stewart Gordon Wrote:
At the moment, the problem seems to be that the compiler is silently
ignoring many cases of (a), (b) and (c) alike. Some people argue that
the spec doesn't forbid such use of inapplicable attributes explicitly,
and so the compiler's treatment of these can
Stewart Gordon Wrote:
> At the moment, the problem seems to be that the compiler is silently
> ignoring many cases of (a), (b) and (c) alike. Some people argue that
> the spec doesn't forbid such use of inapplicable attributes explicitly,
> and so the compiler's treatment of these cannot be ca
Hello grauzone,
BCS wrote:
Just my $0.02 because that might make things less complex.
And if you want to remove complexity, start with the bigger chunks of
the D language.
complexity re the OP's point, not just in general. if only (i) is allowed
then there isn't (much of) a case for allo
BCS wrote:
Hello Stewart,
Perhaps what complicates matters further is that D has three ways of
specifying attributes:
(i) as part of the declaration itself
I more or less only use this.
(ii) in a block delimited by { }
If I remembered that this one even exists, I might use it.
(iii) wi
"BCS" wrote in message
news:a6268ff4a7a8cb89c641dc8...@news.digitalmars.com...
> Hello Stewart,
>
>> Perhaps what complicates matters further is that D has three ways of
>> specifying attributes:
>>
>> (i) as part of the declaration itself
>
> I more or less only use this.
>
>> (ii) in a block de
"Stewart Gordon" wrote in message
news:grtr90$1hl...@digitalmars.com...
> It's cropped up on a number of occasions. And again in the comments on
> http://d.puremagic.com/issues/show_bug.cgi?id=2830
> http://d.puremagic.com/issues/show_bug.cgi?id=1441
> which are essentially the same as each othe
Hello Stewart,
Perhaps what complicates matters further is that D has three ways of
specifying attributes:
(i) as part of the declaration itself
I more or less only use this.
(ii) in a block delimited by { }
If I remembered that this one even exists, I might use it.
(iii) with a colon t
It's cropped up on a number of occasions. And again in the comments on
http://d.puremagic.com/issues/show_bug.cgi?id=2830
http://d.puremagic.com/issues/show_bug.cgi?id=1441
which are essentially the same as each other. The basic matter of
debate is: If an attribute is applied to something to wh
22 matches
Mail list logo
