In the D manual, at: http://www.digitalmars.com/d/memory.html#newdelete, there is an example of a custom memory allocator. The interesting bit is the example:

>       class Foo
>       {
>           new(uint sz)
>           {
>               void* p;
>
>               p = std.c.stdlib.malloc(sz);
>               if (!p)
>                   throw new OutOfMemory();
>               gc.addRange(p, p + sz);
>               return p;
>           }

Now the manual explicitly states, and I quote, "The critical features of new()
are ...  The pointer returned from new() must be to memory aligned to the
default alignment. This is 8 on win32 systems."

Anyone else see the problem?

Just in case you didn't spot it, the value returned by std.c.stdlib.malloc is NOT aligned on an eight byte boundary. (In fact, it will be an address ending in 4 or C). This example violates one of the "critical features of new".

I don't know enough about this in depth to know whether or not it matters, but I would definitely appreciate some guidance here. Is this example good to follow, despite the violation, or is the example in error?

Please help. I need to get this right.
Arcane Jill

It must at least be aligned to 4 for the gc to work on it. However, if it is not aligned to 8, the app will be a little slower manipulating 8 byte values like doubles.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca0s66$1eiu$1@digitaldaemon.com...
> In the D manual, at: http://www.digitalmars.com/d/memory.html#newdelete,
there
> is an example of a custom memory allocator. The interesting bit is the
example:
>
> >       class Foo
> >       {
> >           new(uint sz)
> >           {
> >               void* p;
> >
> >               p = std.c.stdlib.malloc(sz);
> >               if (!p)
> >                   throw new OutOfMemory();
> >               gc.addRange(p, p + sz);
> >               return p;
> >           }
>
> Now the manual explicitly states, and I quote, "The critical features of
new()
> are ...  The pointer returned from new() must be to memory aligned to the default alignment. This is 8 on win32 systems."
>
> Anyone else see the problem?
>
> Just in case you didn't spot it, the value returned by std.c.stdlib.malloc
is
> NOT aligned on an eight byte boundary. (In fact, it will be an address
ending in
> 4 or C). This example violates one of the "critical features of new".
>
> I don't know enough about this in depth to know whether or not it matters,
but I
> would definitely appreciate some guidance here. Is this example good to
follow,
> despite the violation, or is the example in error?
>
> Please help. I need to get this right.
> Arcane Jill
>
>

And will fail on other architectures that are not so lenient as Intel.

"Walter" <newshound@digitalmars.com> wrote in message news:ca0u8f$1hii$1@digitaldaemon.com...
> It must at least be aligned to 4 for the gc to work on it. However, if it is not aligned to 8, the app will be a little slower manipulating 8 byte values like doubles.
>
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ca0s66$1eiu$1@digitaldaemon.com...
> > In the D manual, at: http://www.digitalmars.com/d/memory.html#newdelete,
> there
> > is an example of a custom memory allocator. The interesting bit is the
> example:
> >
> > >       class Foo
> > >       {
> > >           new(uint sz)
> > >           {
> > >               void* p;
> > >
> > >               p = std.c.stdlib.malloc(sz);
> > >               if (!p)
> > >                   throw new OutOfMemory();
> > >               gc.addRange(p, p + sz);
> > >               return p;
> > >           }
> >
> > Now the manual explicitly states, and I quote, "The critical features of
> new()
> > are ...  The pointer returned from new() must be to memory aligned to the default alignment. This is 8 on win32 systems."
> >
> > Anyone else see the problem?
> >
> > Just in case you didn't spot it, the value returned by std.c.stdlib.malloc
> is
> > NOT aligned on an eight byte boundary. (In fact, it will be an address
> ending in
> > 4 or C). This example violates one of the "critical features of new".
> >
> > I don't know enough about this in depth to know whether or not it matters,
> but I
> > would definitely appreciate some guidance here. Is this example good to
> follow,
> > despite the violation, or is the example in error?
> >
> > Please help. I need to get this right.
> > Arcane Jill
> >
> >
>
>

In article <ca0u8f$1hii$1@digitaldaemon.com>, Walter says...
>
>It must at least be aligned to 4 for the gc to work on it. However, if it is not aligned to 8, the app will be a little slower manipulating 8 byte values like doubles.

Thank you very much for your quick and accurate reply. I do appreciate it.

Jill

I fully expect anyone implementing malloc() for another architecture to follow the alignment rules for it <g>.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:ca10q9$1l4a$1@digitaldaemon.com...
> And will fail on other architectures that are not so lenient as Intel.
>
> "Walter" <newshound@digitalmars.com> wrote in message news:ca0u8f$1hii$1@digitaldaemon.com...
> > It must at least be aligned to 4 for the gc to work on it. However, if
it is
> > not aligned to 8, the app will be a little slower manipulating 8 byte
values
> > like doubles.