• Arcane Jill (14/25) Jun 06 2004 Now the manual explicitly states, and I quote, "The critical features of...
• Walter (12/38) Jun 06 2004 It must at least be aligned to 4 for the gc to work on it. However, if i...
• Matthew (3/49) Jun 06 2004 And will fail on other architectures that are not so lenient as Intel.
• Walter (6/12) Jun 07 2004 I fully expect anyone implementing malloc() for another architecture to
• Arcane Jill (3/6) Jun 07 2004 Thank you very much for your quick and accurate reply. I do appreciate i...

Arcane Jill <Arcane_member pathlink.com> writes:

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

"Walter" <newshound digitalmars.com> writes:

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

"Matthew" <matthew.hat stlsoft.dot.org> writes:

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

"Walter" <newshound digitalmars.com> writes:

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.

Arcane Jill <Arcane_member pathlink.com> writes:

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