www.digitalmars.com         C & C++   DMDScript  

D - DMD 0.53 release

reply "Walter" <walter digitalmars.com> writes:
No bugs fixed, but added new capability to allocate memory outside of the
garbage collector, to appeal to programmers who want to do their own
allocation/deallocation.

www.digitalmars.com/d/changelog.html

Note: this will require a recompile of any existing .obj's and .lib files,
as the contents of the ClassInfo changed.
Feb 09 2003
next sibling parent "Nic Tiger" <nictiger progtech.ru> writes:
Thanks, it seems to be very useful for critical applications.

Nic Tiger.

"Walter" <walter digitalmars.com> сообщил/сообщила в новостях следующее:
news:b255i0$1ufn$1 digitaldaemon.com...
 No bugs fixed, but added new capability to allocate memory outside of the
 garbage collector, to appeal to programmers who want to do their own
 allocation/deallocation.

 www.digitalmars.com/d/changelog.html

 Note: this will require a recompile of any existing .obj's and .lib files,
 as the contents of the ClassInfo changed.
Feb 10 2003
prev sibling next sibling parent reply "Robert Medeiros" <robert.medeiros utoronto.ca> writes:
 No bugs fixed, but added new capability to allocate memory outside of the
 garbage collector, to appeal to programmers who want to do their own
 allocation/deallocation.
Anyone thinking to take advantage of this new functionality might find this paper interesting: Reconsidering Custom Memory Allocation http://citeseer.nj.nec.com/berger01reconsidering.html Rob
Feb 12 2003
parent Bill Cox <bill viasic.com> writes:
No bugs fixed, but added new capability to allocate memory outside of the
garbage collector, to appeal to programmers who want to do their own
allocation/deallocation.
Anyone thinking to take advantage of this new functionality might find this paper interesting: Reconsidering Custom Memory Allocation http://citeseer.nj.nec.com/berger01reconsidering.html Rob
Nice paper, thanks for the link. However, since I'm very interested in speed, I wouldn't use their allocator. It looks like they've built a nice general purpose allocator, but of the 8 benchmarks, only two seem important in measuring speed: ICC, and Muddle. These are the only two that have advanced memory allocation (region allocators) while still being significantly impacted in run-time by memory allocation. They focused on these two at the end of the paper, and reported to be within 10% of the run-time of the region allocators in these two benchmarks. However, the memory allocation in these programs only took 25-33% of the run-time, so you have to multiply the difference by 3 to 4 to see the difference that region allocation makes. That leaves their allocator at somewhere from 20-40% slower. Let's face it. If you need speed, region allocators rock. Bill
Feb 12 2003
prev sibling parent reply Scott Wood <scott buserror.net> writes:
On Sun, 9 Feb 2003 01:05:04 -0800, Walter <walter digitalmars.com> wrote:
 No bugs fixed, but added new capability to allocate memory outside of the
 garbage collector, to appeal to programmers who want to do their own
 allocation/deallocation.
Are there any plans to allow non-member user-supplied new and delete functions, such as in C++? For example, one might have a special new function that allocates from a given shared memory region, or one might want to do a mark/release on a specific collection of objects or structs, regardless of type. Currently, to do this one would have to add non-default member new()s to every class that do nothing but call the global new. Globally replacing the generic new and delete could also be useful for debugging memory leaks. Also, I notice that new() takes a uint argument for size; shouldn't this be stdint.uintptr_t, to allow allocating arrays larger than 4GiB on 64-bit platforms? Perhaps there should be a more readable basic type, such as "word/uword", which would be defined as the size of an integer register (sort of like "extended")... -Scott
Feb 12 2003
parent "Walter" <walter digitalmars.com> writes:
"Scott Wood" <scott buserror.net> wrote in message
news:slrnb4m44u.tl.scott ti.buserror.net...
 Are there any plans to allow non-member user-supplied new and delete
 functions, such as in C++?

 For example, one might have a special new function that allocates
 from a given shared memory region, or one might want to do a
 mark/release on a specific collection of objects or structs,
 regardless of type.  Currently, to do this one would have to add
 non-default member new()s to every class that do nothing but call the
 global new.

 Globally replacing the generic new and delete could also be useful
 for debugging memory leaks.
I've found in practice that replacing the global new/delete in C++ leads to bugs after bugs, generally from adding in code that expects otherwise, such as the library routines. But the member new/delete *are* inheritable, so you could define a base class and then derive all your classes from it, and they'll all use your custom allocator.
 Also, I notice that new() takes a uint argument for size; shouldn't
 this be stdint.uintptr_t, to allow allocating arrays larger than 4GiB
 on 64-bit platforms?  Perhaps there should be a more readable basic
 type, such as "word/uword", which would be defined as the size of an
 integer register (sort of like "extended")...
That's a good point.
Feb 13 2003