www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Custom new - Critical Problem

reply 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
Jun 06 2004
parent reply "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,

 is an example of a custom memory allocator. The interesting bit is the

       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

 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

 NOT aligned on an eight byte boundary. (In fact, it will be an address

 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,

 would definitely appreciate some guidance here. Is this example good to

 despite the violation, or is the example in error?

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

Jun 06 2004
next sibling parent reply "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,

 is an example of a custom memory allocator. The interesting bit is the

       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

 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

 NOT aligned on an eight byte boundary. (In fact, it will be an address

 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,

 would definitely appreciate some guidance here. Is this example good to

 despite the violation, or is the example in error?

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


Jun 06 2004
parent "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


 not aligned to 8, the app will be a little slower manipulating 8 byte


 like doubles.


Jun 07 2004
prev sibling parent 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
Jun 07 2004