ne we can actually
build upon.
Great many C libraries work with just 3 preprocessor macros for
malloc, free, realloc, something like that. A standard struct
with 3 pointers in druntime would be great!
We just can't build upon std.experimental.allocator if it doesn't
work in bet
On Sunday, 13 August 2023 at 16:00:51 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Yeah you're right Ternary should probably be replaced, although
amazingly it has never caused problems so far.
But I cannot agree about RAII. Its a valid tool for managing
lifetimes of memory allocators. Memory
On Sunday, 13 August 2023 at 11:44:50 UTC, IchorDev wrote:
I feel like I can't possibly be the first to ask, but I
couldn't find any prior discussion of this:
When is `std.experimental.allocator` going to be moved out of
`experimental`? Is there any roadmap for it? Is it just in
li
On 14/08/2023 4:10 AM, ryuukk_ wrote:
Also if you want people to use D for games, you want an allocator API
that doesn't use RAII, same for exceptions btw
After thinking about it a bit, this would suggest to me that you are
trying to solve a problem that I would outright recommend against usin
On Sunday, 13 August 2023 at 16:00:51 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Yeah you're right Ternary should probably be replaced, although
amazingly it has never caused problems so far.
But I cannot agree about RAII. Its a valid tool for managing
lifetimes of memory allocators. Memory
Yeah you're right Ternary should probably be replaced, although
amazingly it has never caused problems so far.
But I cannot agree about RAII. Its a valid tool for managing lifetimes
of memory allocators. Memory allocators must be able to store per
instance state and that state must not acciden
On Sunday, 13 August 2023 at 15:25:16 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Mine (-betterC)
https://github.com/Project-Sidero/basic_memory/tree/main/source/sidero/base/allocators
Similar scope to one in Phobos.
On that note I'm still waiting a year+ for Atila to get back to
me about t
Mine (-betterC)
https://github.com/Project-Sidero/basic_memory/tree/main/source/sidero/base/allocators
Similar scope to one in Phobos.
On that note I'm still waiting a year+ for Atila to get back to me about
talking about where to go for std.experimental.allocators.
On Sunday, 13 August 2023 at 11:44:50 UTC, IchorDev wrote:
I feel like I can't possibly be the first to ask, but I
couldn't find any prior discussion of this:
When is `std.experimental.allocator` going to be moved out of
`experimental`? Is there any roadmap for it? Is it just in
l
I feel like I can't possibly be the first to ask, but I couldn't
find any prior discussion of this:
When is `std.experimental.allocator` going to be moved out of
`experimental`? Is there any roadmap for it? Is it just in limbo?
On Saturday, 26 December 2020 at 19:36:24 UTC, ag0aep6g wrote:
On 26.12.20 13:59, ag0aep6g wrote:
Looks like a pretty nasty bug somewhere in
std.experimental.allocator or (less likely) the GC. Further
reduced code:
[...]
Apparently, something calls deallocateAll on a Mallocator
On 26.12.20 13:59, ag0aep6g wrote:
Looks like a pretty nasty bug somewhere in std.experimental.allocator or
(less likely) the GC. Further reduced code:
[...]
Apparently, something calls deallocateAll on a Mallocator instance after
the memory of that instance has been recycled by
ry reduced
example of an issue I am facing.
Looks like a pretty nasty bug somewhere in std.experimental.allocator or
(less likely) the GC. Further reduced code:
import core.memory: GC;
import core.stdc.stdlib: malloc;
import std.experimental.allocator: allocatorObje
Try to compile in debug mode, maybe you breach some contract.
est case seems to work in all the cases
I've tested so far, maybe it can help diagnose the issue. If we
use a pointer to construct the allocator, it seems to work fine:
void main() {
import std.experimental.allocator: allocatorObject,
expandArray;
On Thursday, 24 December 2020 at 23:46:58 UTC, Elronnd wrote:
reduced version:
Further reduction: Alloc1 can just be ‘AllocatorList!(n =>
Region!Mallocator(MB))’.
On Thursday, 24 December 2020 at 16:12:31 UTC, Saurabh Das wrote:
This causes a segfault when run with rdmd -gx:
*snip*
First, here's a reduced version:
void main() {
import std.experimental.allocator: allocatorObject, expandArray;
i
On Thursday, 24 December 2020 at 16:12:31 UTC, Saurabh Das wrote:
This causes a segfault when run with rdmd -gx:
[...]
On my machine its a "realloc(): invalid pointer".
From what does the allocator know, that `p' is somehow an array?
This causes a segfault when run with rdmd -gx:
void main()
{
import std.experimental.allocator : allocatorObject,
expandArray;
import
std.experimental.allocator.building_blocks.allocator_list :
AllocatorList;
import std.experimental.allocator.building_blocks.region :
Region
On Monday, 26 August 2019 at 01:06:55 UTC, James Blachly wrote:
The documentation for std.experimental.allocator is a little
dense and I wanted to make sure I am understanding composition
correctly.
[...]
Yes, you are correct.
Edi
The documentation for std.experimental.allocator is a little dense and I
wanted to make sure I am understanding composition correctly.
Suppose I have the following, taken more-or-less direct from the docs:
auto batchAllocator = AllocatorList!(
(size_t n) => Region!Mallocator(ma
On Thursday, 11 January 2018 at 21:57:28 UTC, MrSmith wrote:
http://dpldocs.info/experimental-docs/std.experimental.allocator.makeArray.4.html
Thanks!
On Thursday, 11 January 2018 at 21:09:01 UTC, Nordlöw wrote:
Is there no equivalent of `calloc()` for
`std.experimental.allocator`, something like
Allocator.zeroAllocate(size_t numberOfElements)
?
http://dpldocs.info/experimental-docs/std.experimental.allocator.makeArray.4.html
Is there no equivalent of `calloc()` for
`std.experimental.allocator`, something like
Allocator.zeroAllocate(size_t numberOfElements)
?
On Saturday, 2 September 2017 at 11:23:00 UTC, Igor wrote:
I realize these are not yet stable but I would like to know if
I am doing something wrong or is it a lib bug.
My first attempt was to do this:
theAllocator = allocatorObject(Region!MmapAllocator(1024*MB));
If I got it right th
I realize these are not yet stable but I would like to know if I
am doing something wrong or is it a lib bug.
My first attempt was to do this:
theAllocator = allocatorObject(Region!MmapAllocator(1024*MB));
If I got it right this doesn't work because it actually does this:
1. Create Re
On Wednesday, 8 March 2017 at 12:28:13 UTC, Jacob Carlborg wrote:
On 2017-03-08 12:59, Guillaume Piolat wrote:
Is it possible to use std.experimental.allocator without the
runtime or
with the runtime disabled?
I had a quick look through the imports, I could not find
anything that I know
On 2017-03-08 12:59, Guillaume Piolat wrote:
Is it possible to use std.experimental.allocator without the runtime or
with the runtime disabled?
I had a quick look through the imports, I could not find anything that I
know uses the runtime. Although it does use exceptions and asserts in
some
Is it possible to use std.experimental.allocator without the
runtime or with the runtime disabled?
It would be ideal for allocating audio buffers in the audio
thread. malloc is tolerated but using a pre-allocated area with a
fallback on malloc would be way better and faster too.
On Sunday, 18 September 2016 at 01:44:10 UTC, Ryan wrote:
I think it works because each time you call dispose it tells
the GC to mark that memory as available, without the GC needing
to do a collection sweep. This could be a really useful tip in
the allocators section, as I see converting to IA
On Wednesday, 19 October 2016 at 08:34:57 UTC, Benjamin Thaut
wrote:
Lets assume I have a allocator which cains together multiple
building blocks from std.experimental.allocator and at the end
there is a mallocator providing the underlying memory. Now I
alloacte a type which contains a pointer
Lets assume I have a allocator which cains together multiple
building blocks from std.experimental.allocator and at the end
there is a mallocator providing the underlying memory. Now I
alloacte a type which contains a pointer into GC memory.
Obviously the memory of the mallocator is not
I've been learning about allocators in D. Much easier than C++,
and this little program shows a really easy optimization. Just
use the IAllocator interface with the GC.
---
import std.datetime;
import std.experimental.allo
I was trying to use allocators in a @nogc function.
I tried FreeList!Mallocator and it works fine. But
AllocatorList!Mallocator doesn't work. dmd complains that
AllocatorList.allocate is not @nogc, even when
BookkeepingAllocator is NullAllocator. But if I add '@nogc' to
AllocatorList.allocate
On Tuesday, 7 June 2016 at 15:43:34 UTC, Adam D. Ruppe wrote:
On Tuesday, 7 June 2016 at 15:39:59 UTC, jmh530 wrote:
My sense is that putting it on the GC heap gives the struct
reference semantics.
It doesn't matter what heap it is on, you are just using a
pointer here.
Struct pointers in D
On Tuesday, 7 June 2016 at 15:39:59 UTC, jmh530 wrote:
My sense is that putting it on the GC heap gives the struct
reference semantics.
It doesn't matter what heap it is on, you are just using a
pointer here.
Struct pointers in D will automatically dereference with a.x, so
no need for the *
I modified one of the first examples from
std.experimental.allocator to put a struct on the heap (below).
My sense is that putting it on the GC heap gives the struct
reference semantics. I was struck by two things. First, I didn't
have to use (*a).x, I could just use a.x. Also, when I a
Can somebody give me a quick example of how to combine the
MMapAllocator with the AllocatorList and the BitmapBlock objects
together?
Lets assume I want to be able to swap in and out allocators none of
which will be the gc_allocator...
What is best practice for using std.experimental.allocator in @nogc code?
On Friday, 20 November 2015 at 12:49:02 UTC, Rikki Cattermole
wrote:
Dunno if its been fixed in ~master (doubt it), but all you need
to do in your code, is copy it in.
Cool, that worked.
I've personally marked (well voted anyway) for this bug to be
critical.
It seems I'm the only one who thin
On Friday, 20 November 2015 at 12:31:37 UTC, Tofu Ninja wrote:
On Tuesday, 10 November 2015 at 11:39:56 UTC, Rikki Cattermole
wrote:
One already exists.
I've confirmed it in the build scripts. It only effects
Windows.
Any fix for this right now?
No, https://issues.dlang.org/show_bug.cgi?id=
On 21/11/15 1:31 AM, Tofu Ninja wrote:
On Tuesday, 10 November 2015 at 11:39:56 UTC, Rikki Cattermole wrote:
One already exists.
I've confirmed it in the build scripts. It only effects Windows.
Any fix for this right now?
Dunno if its been fixed in ~master (doubt it), but all you need to do
On Tuesday, 10 November 2015 at 11:39:56 UTC, Rikki Cattermole
wrote:
One already exists.
I've confirmed it in the build scripts. It only effects Windows.
Any fix for this right now?
On 11/11/15 5:17 PM, Dustin Walker wrote:
On Monday, 9 November 2015 at 14:42:01 UTC, ref2401 wrote:
Hello
I wrote a small hello world app and imported the
`std.experimental.allocator` module.
I'm getting the following optlink error:
---
OP
On Monday, 9 November 2015 at 14:42:01 UTC, ref2401 wrote:
Hello
I wrote a small hello world app and imported the
`std.experimental.allocator` module.
I'm getting the following optlink error:
---
OPTLINK (R) for Win32 Release 8.00.17
Copy
On 11/11/15 12:05 AM, uiop wrote:
On Tuesday, 10 November 2015 at 10:34:56 UTC, ref2401 wrote:
On Tuesday, 10 November 2015 at 08:48:37 UTC, ref2401 wrote:
On Tuesday, 10 November 2015 at 01:04:16 UTC, uiop wrote:
Can you find the sources in your setup ? Any chance that that
phobos.lib is stil
On Tuesday, 10 November 2015 at 10:34:56 UTC, ref2401 wrote:
On Tuesday, 10 November 2015 at 08:48:37 UTC, ref2401 wrote:
On Tuesday, 10 November 2015 at 01:04:16 UTC, uiop wrote:
Can you find the sources in your setup ? Any chance that that
phobos.lib is still the the one distributed with dmd
On Tuesday, 10 November 2015 at 08:48:37 UTC, ref2401 wrote:
On Tuesday, 10 November 2015 at 01:04:16 UTC, uiop wrote:
Can you find the sources in your setup ? Any chance that that
phobos.lib is still the the one distributed with dmd 2.068 ?
How can I do that?
When you setup dmd 2.069, did y
On Tuesday, 10 November 2015 at 01:04:16 UTC, uiop wrote:
Can you find the sources in your setup ? Any chance that that
phobos.lib is still the the one distributed with dmd 2.068 ?
When you setup dmd 2.069, did you use the 7z or installer ?
i have the same issue. i used the installer. i only h
On Tuesday, 10 November 2015 at 01:04:16 UTC, uiop wrote:
Can you find the sources in your setup ? Any chance that that
phobos.lib is still the the one distributed with dmd 2.068 ?
How can I do that?
When you setup dmd 2.069, did you use the 7z or installer ?
Installer always
btw. Thanks f
On Monday, 9 November 2015 at 18:07:39 UTC, ref2401 wrote:
On Monday, 9 November 2015 at 14:42:01 UTC, ref2401 wrote:
Hello
I wrote a small hello world app and imported the
`std.experimental.allocator` module.
I'm getting the following optlink
On Monday, 9 November 2015 at 14:42:01 UTC, ref2401 wrote:
Hello
I wrote a small hello world app and imported the
`std.experimental.allocator` module.
I'm getting the following optlink error:
---
OPTLINK (R) for Win32 Release 8.00.17
Copy
Hello
I wrote a small hello world app and imported the
`std.experimental.allocator` module.
I'm getting the following optlink error:
---
OPTLINK (R) for Win32 Release 8.00.17
Copyright (C) Digital Mars 1989-2013 All rights reserved.
Can I call theAllocator.dispose from a struct destructor? None
of the things pointed to by the root will be allocated directly
by GC.
Laeeth.
54 matches
Mail list logo
