Re: std.experimental.allocator

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 betterC and WebASM

Re: std.experimental.allocator

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.

Re: std.experimental.allocator

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 limbo

Re: std.experimental.allocator

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

Re: std.experimental.allocator

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.

Re: std.experimental.allocator

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

Re: std.experimental.allocator

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

Re: std.experimental.allocator

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.

Re: std.experimental.allocator

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 limbo? We

std.experimental.allocator

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?

[Issue 20813] std.experimental.allocator add fault injecting allocator

https://issues.dlang.org/show_bug.cgi?id=20813 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --

[Issue 19737] [std.experimental.allocator] link table in docs has missing symbols

|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #8604 "Improve std.experimental.allocator docs" was merged into master: - 9ceb63dbfc3eac45460a9eed52f464736448cbd4 by Nick Treleaven: Fix Issue 19737 - [std.experimental.allocator] link table in docs has missi

[Issue 19737] [std.experimental.allocator] link table in docs has missing symbols

updated dlang/phobos pull request #8604 "Improve std.experimental.allocator docs" fixing this issue: - Fix Issue 19737 - [std.experimental.allocator] link table in docs has missing symbols https://github.com/dlang/phobos/pull/8604 --

[Issue 19737] [std.experimental.allocator] link table in docs has missing symbols

|[std.experimental.allocator |[std.experimental.allocator |] has undocumented symbols |] link table in docs has ||missing symbols --

[Issue 22660] New: std.experimental.allocator randomly fails unittest

https://issues.dlang.org/show_bug.cgi?id=22660 Issue ID: 22660 Summary: std.experimental.allocator randomly fails unittest Product: D Version: D2 Hardware: x86_64 OS: Mac OS X Status: NEW Severity: blocker

Re: Surprising behaviour of std.experimental.allocator

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

Re: Surprising behaviour of std.experimental.allocator

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

Re: Surprising behaviour of std.experimental.allocator

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

Re: Surprising behaviour of std.experimental.allocator

Try to compile in debug mode, maybe you breach some contract.

Re: Surprising behaviour of std.experimental.allocator

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; imp

Re: Surprising behaviour of std.experimental.allocator

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))’.

Re: Surprising behaviour of std.experimental.allocator

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; import

Re: Surprising behaviour of std.experimental.allocator

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?

Surprising behaviour of std.experimental.allocator

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

[Issue 20813] New: std.experimental.allocator add fault injecting allocator

https://issues.dlang.org/show_bug.cgi?id=20813 Issue ID: 20813 Summary: std.experimental.allocator add fault injecting allocator Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

[Issue 15639] std.experimental.allocator enables abstract class instantiation

https://issues.dlang.org/show_bug.cgi?id=15639 Basile-z changed: What|Removed |Added CC|b2.t...@gmx.com | --

[Issue 18914] std.experimental.allocator randomly fails on Darwin_64_64

https://issues.dlang.org/show_bug.cgi?id=18914 Basile-z changed: What|Removed |Added CC|b2.t...@gmx.com | --

[Issue 16117] std.experimental.allocator does not work with non default constructible types

https://issues.dlang.org/show_bug.cgi?id=16117 Basile-z changed: What|Removed |Added CC|b2.t...@gmx.com | --

Re: Do I understand std.experimental.allocator composition correctly?

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

Do I understand std.experimental.allocator composition correctly?

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

[Issue 19737] New: [std.experimental.allocator] has undocumented symbols

https://issues.dlang.org/show_bug.cgi?id=19737 Issue ID: 19737 Summary: [std.experimental.allocator] has undocumented symbols Product: D Version: D2 Hardware: All URL: http://dlang.org/phobos/ OS: All

Re: More zero-initialization optimizations pending in std.experimental.allocator?

On Saturday, 20 October 2018 at 15:10:38 UTC, Nathan S. wrote: are there more zero-initializations that can be optimized in std.experimental.allocator? I looked and identified low-hanging fruit in std.mutation.initializeAll & moveEmplace and in std.typecons.RefCounted (PR #

Re: More zero-initialization optimizations pending in std.experimental.allocator?

On Saturday, 20 October 2018 at 15:10:38 UTC, Nathan S. wrote: Other opportunities would rely on being able to identify if it's ever more efficient to write `memset(, 0, typeof(x).sizeof)` instead of `x = typeof(x).init` which seems like the kind of optimization that belongs in the compiler

Re: More zero-initialization optimizations pending in std.experimental.allocator?

-initializations that can be optimized in std.experimental.allocator? I looked and identified low-hanging fruit in std.mutation.initializeAll & moveEmplace and in std.typecons.RefCounted (PR #6698), and in std.conv.emplaceInitializer (PR #6461). Other opportunities would rely on being able to iden

More zero-initialization optimizations pending in std.experimental.allocator?

Now that https://github.com/dlang/phobos/pull/6411 has been merged and DMD stable soon has the new __traits(isZeroInit, T) found here https://dlang.org/changelog/2.083.0.html#isZeroInit are there more zero-initializations that can be optimized in std.experimental.allocator?

Re: std.experimental.allocator and const etc.

On 7/15/18 9:06 AM, John Colvin wrote: Currently the API's don't support const(void)[], e.g. import std.experimental.allocator : makeArray, theAllocator, dispose; import std.experimental.allocator.mallocator : Mallocator; void main() {     const a = theAllocator.makeArray!ubyte(100

Re: std.experimental.allocator and const etc.

On Sunday, 15 July 2018 at 13:06:16 UTC, John Colvin wrote: Currently the API's don't support const(void)[], e.g. import std.experimental.allocator : makeArray, theAllocator, dispose; import std.experimental.allocator.mallocator : Mallocator; void main() { const

std.experimental.allocator and const etc.

Currently the API's don't support const(void)[], e.g. import std.experimental.allocator : makeArray, theAllocator, dispose; import std.experimental.allocator.mallocator : Mallocator; void main() { const a = theAllocator.makeArray!ubyte(100); theAllocator.dispose(a); // can't call

[Issue 18937] [REG 2.080.0] std.experimental.allocator: compiling `make` needs an unreasonable amount of memory for structs that contain static arrays

https://issues.dlang.org/show_bug.cgi?id=18937 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18937] [REG 2.080.0] std.experimental.allocator: compiling `make` needs an unreasonable amount of memory for structs that contain static arrays

] std.experimental.allocator: compiling `make` needs an unreasonable amount of memory for structs that contain static arrays https://github.com/dlang/phobos/commit/75feb5726aceb5101823b79d9df7f0a89072b547 Merge pull request #6537 from aG0aep6G/18937 fix issue 18937 - [REG 2.080.0] std.experimental.allocator: compiling… --

[Issue 18937] [REG 2.080.0] std.experimental.allocator: compiling `make` needs an unreasonable amount of memory for structs that contain static arrays

https://issues.dlang.org/show_bug.cgi?id=18937 --- Comment #1 from ag0aep6g --- (In reply to ag0aep6g from comment #0) > I'm looking into fixing this there. Pull request: https://github.com/dlang/phobos/pull/6537 --

[Issue 18937] New: [REG 2.080.0] std.experimental.allocator: compiling `make` needs an unreasonable amount of memory for structs that contain static arrays

https://issues.dlang.org/show_bug.cgi?id=18937 Issue ID: 18937 Summary: [REG 2.080.0] std.experimental.allocator: compiling `make` needs an unreasonable amount of memory for structs that contain static arrays Product: D

[Issue 18914] std.experimental.allocator randomly fails on Darwin_64_64

https://issues.dlang.org/show_bug.cgi?id=18914 Basile B. changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Issue 18914] New: std.experimental.allocator randomly fails on Darwin_64_64

https://issues.dlang.org/show_bug.cgi?id=18914 Issue ID: 18914 Summary: std.experimental.allocator randomly fails on Darwin_64_64 Product: D Version: D2 Hardware: x86_64 OS: Mac OS X Status: NEW

[Issue 18223] std.experimental.allocator uninitializedFillDefault could use memset

https://issues.dlang.org/show_bug.cgi?id=18223 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18223] std.experimental.allocator uninitializedFillDefault could use memset

https://issues.dlang.org/show_bug.cgi?id=18223 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/8777cbf35505704bc2908baa4ae04d988f339bf8 Fix Issue 18223: use memset in

Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

On Friday, 9 February 2018 at 14:38:50 UTC, Seb wrote: On Friday, 9 February 2018 at 14:24:45 UTC, 9il wrote: On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: Hi all, Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation.

Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

On Friday, 9 February 2018 at 14:24:45 UTC, 9il wrote: On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: Hi all, Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes. Awesome! If you

Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: Hi all, Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes. Awesome! If you have any architecture/API drafts they would interesting

Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: So we may switch to ubyte[] Hooray!

Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

On Friday, 1 December 2017 at 02:30:29 UTC, Seb wrote: On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: Hi all, Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes. In order to make

[Issue 18223] std.experimental.allocator uninitializedFillDefault could use memset

https://issues.dlang.org/show_bug.cgi?id=18223 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/phobos/pull/6024 --

[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1

https://issues.dlang.org/show_bug.cgi?id=18239 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/66ede852bf0e76dfdfad7044e475dd147cd0a1e7 Fix Issue 18239: fillWithMemcpy use memset when

[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1

https://issues.dlang.org/show_bug.cgi?id=18239 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1

https://issues.dlang.org/show_bug.cgi?id=18239 --- Comment #2 from Nathan S. --- (In reply to Nathan S. from comment #1) > Could also use wmemset when T.sizeof == wint_t.sizeof Unfortunately core.stdc.wchar_.wmemset isn't marked as pure so this would cause some tests

[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1

https://issues.dlang.org/show_bug.cgi?id=18239 Nathan S. <n8sh.second...@hotmail.com> changed: What|Removed |Added Summary|std.experimental.all

[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset/wmemset for T.sizeof==1 or wint_t.sizeof

https://issues.dlang.org/show_bug.cgi?id=18239 --- Comment #1 from Nathan S. --- Could also use wmemset when T.sizeof == wint_t.sizeof --

[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset/wmemset for T.sizeof==1 or wint_t.sizeof

https://issues.dlang.org/show_bug.cgi?id=18239 Nathan S. <n8sh.second...@hotmail.com> changed: What|Removed |Added Summary|std.experimental.all

[Issue 18239] New: std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1

https://issues.dlang.org/show_bug.cgi?id=18239 Issue ID: 18239 Summary: std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1 Product: D Version: D2 Hardware: All OS: All

Re: calloc for std.experimental.allocator

On Thursday, 11 January 2018 at 21:57:28 UTC, MrSmith wrote: http://dpldocs.info/experimental-docs/std.experimental.allocator.makeArray.4.html Thanks!

Re: calloc for std.experimental.allocator

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

calloc for std.experimental.allocator

Is there no equivalent of `calloc()` for `std.experimental.allocator`, something like Allocator.zeroAllocate(size_t numberOfElements) ?

[Issue 18223] New: std.experimental.allocator uninitializedFillDefault could use memset

https://issues.dlang.org/show_bug.cgi?id=18223 Issue ID: 18223 Summary: std.experimental.allocator uninitializedFillDefault could use memset Product: D Version: D2 Hardware: All OS: All Status

[Issue 15353] std.experimental.allocator cannot free memory in its destructor if the GC is an ancestor

https://issues.dlang.org/show_bug.cgi?id=15353 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to dmd-cxx at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/1113bf1476ca66bac8a25bea4598daf6fb4bd598 fix Issue 15353 - ignore freeing during

Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: Another possible work item was raised by https://github.com/dlang/phobos/pull/5879. Currently, allocators traffic in void[]. When I first designed allocators, I considered using ubyte[] instead. Using void[] is somewhat

Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

On 2017-11-30 20:01, Andrei Alexandrescu wrote: Hi all, Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes. It would be nice if the API and the GCAllocator were CTFE-able. This would allow functions that

Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: Currently, allocators traffic in void[]. When I first designed allocators, I considered using ubyte[] instead. I experimented with using byte[] for opaque buffers, because byte is signed, one can't parse byte[] content

Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: Hi all, Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes. In order to make matters easier for code using allocators, Sebastian

Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: Hi all, Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes. [...] Sounds good! Please consider -betterC on your refactoring. Would

Heads-up: upcoming instabilities in std.experimental.allocator, and what to do

Hi all, Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes. In order to make matters easier for code using allocators, Sebastian Wilzbach created a dub package freezing the existing API:

Re: Problems with std.experimental.allocator

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

Problems with std.experimental.allocator

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: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 15:52:50 UTC, Basile B. wrote: On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: http://code.dlang.org/packages/automem I think

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Monday, 17 April 2017 at 13:21:50 UTC, Kagamin wrote: If we can control memory layout, we can do what shared_ptr does and couple the reference counter with the object, then we can have just one pointer: struct RefCounted(T) { struct Wrapper { int count; T payload; }

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Wednesday, 12 April 2017 at 13:32:36 UTC, Stanislav Blinov wrote: Syntax is not the core of the issue, it's not about just marking a destructor as shared. Making RefCounted itself shared would require implementing some form of synchronization of all the 'dereference' operations, including

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Monday, 10 April 2017 at 08:11:37 UTC, Atila Neves wrote: On Sunday, 9 April 2017 at 13:59:14 UTC, Andrei Alexandrescu wrote: Great. Can RefCounted itself be shared? I learned this is important for composition, i.e. you want to make a RefCounted a field in another object that is itself

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Tuesday, 11 April 2017 at 22:32:51 UTC, Martin Nowak wrote: On Monday, 10 April 2017 at 08:31:28 UTC, Atila Neves wrote: ```d import std.experimental.allocator.mallocator; UniqueArray!(int, Mallocator) a; a ~= [0,1]; ``` So the difference between std.container.Array and UniqueArray is

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Monday, 10 April 2017 at 08:31:28 UTC, Atila Neves wrote: ```d import std.experimental.allocator.mallocator; UniqueArray!(int, Mallocator) a; a ~= [0,1]; ``` So the difference between std.container.Array and UniqueArray is that the latter supports allocators?

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Tuesday, 11 April 2017 at 10:24:08 UTC, Nicholas Wilson wrote: In LDC we have an attribute for that `allocSize` (https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/attributes.d#L16) perhaps this attribute should be used across compilers and be in druntime? Nice, if pure required

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Tuesday, 11 April 2017 at 08:09:15 UTC, Martin Nowak wrote: On Sunday, 9 April 2017 at 10:22:49 UTC, Atila Neves wrote: I did not. Thanks for telling me! The way I wrote it RefCounted!(shared T) works - RefCounted doesn't have to be shared itself, but I guess it could be. I think the

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Tuesday, 11 April 2017 at 09:53:46 UTC, Martin Nowak wrote: I think we might be able to solve this problem in D by making IAllocator.allocate pure, which tells the compiler that this function returns a fresh piece of memory without any side-effect, i.e. enough information to optimize away

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 13:59:14 UTC, Andrei Alexandrescu wrote: . The allocator has to be specified as part of the type: this means the user can choose how to store it in the smart pointer, which for singletons (e.g. Mallocator) or stateless allocators means they can take up zero space. If

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: http://code.dlang.org/packages/automem You might find my own containers interesting, especially https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d Supports all the different ways I could think an array needs to work:

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 10:22:49 UTC, Atila Neves wrote: I did not. Thanks for telling me! The way I wrote it RefCounted!(shared T) works - RefCounted doesn't have to be shared itself, but I guess it could be. I think the other design is slightly more correct, having a single thread own

[Issue 16117] std.experimental.allocator does not work with non default constructible types

https://issues.dlang.org/show_bug.cgi?id=16117 b2.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC|

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 19:04:22 UTC, mogu wrote: On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: [...] Nice! Should UniqueArray be implemented

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 15:52:50 UTC, Basile B. wrote: On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: http://code.dlang.org/packages/automem I think

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 13:59:14 UTC, Andrei Alexandrescu wrote: On 4/9/17 4:56 AM, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: http://code.dlang.org/packages/automem Example: I think

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: [...] Nice! Should UniqueArray be implemented as a overloaded version of Unique? Unique!(Object[]) instead

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: http://code.dlang.org/packages/automem I think that the Array misses - a reservation strategy, something

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On 09/04/2017 2:59 PM, Andrei Alexandrescu wrote: On 4/9/17 4:56 AM, Atila Neves wrote: snip . UniqueArray behaves nearly like a normal array. You can even append to it, but it won't use GC memory (unless, of course, you chose to use GCAllocator)! This may be a great candidate for the

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On 4/9/17 4:56 AM, Atila Neves wrote: Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: http://code.dlang.org/packages/automem Example: I think the code in the README should be enough to understand what's going

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 09:36:53 UTC, Martin Nowak wrote: On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: I benchmarked RefCounted against C++'s std::shared_ptr comparing ldc to clang using both shared and non-shared payloads in D. std::shared_ptr is faster (I've never written a

Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: I benchmarked RefCounted against C++'s std::shared_ptr comparing ldc to clang using both shared and non-shared payloads in D. std::shared_ptr is faster (I've never written a smart pointer before), but the advantage of non-atomic

automem v0.0.7 - C++ style smart pointers using std.experimental.allocator

Using std.experimental.allocator? Tired of writing `scope(exit) allocator.dispose(foo);` in a language with RAII? Me too: http://code.dlang.org/packages/automem Example: I think the code in the README should be enough to understand what's going on. Alpha stuff here but I think the main

Re: Is it possible to use std.experimental.allocator without the runtime or with the runtime disabled?

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

Re: Is it possible to use std.experimental.allocator without the runtime or with the runtime disabled?

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?

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.

Re: @safe containers with std.experimental.allocator

On Sunday, 22 January 2017 at 13:21:41 UTC, Andrei Alexandrescu wrote: -- Andrei After exploring this idea(@safe containers), then looking at std.Array again, it's actually pretty smart. I had concerns about efficiency, but RefCounted seems to force allocation like make_shared<>,

Re: @safe containers with std.experimental.allocator

On Tuesday, 24 January 2017 at 19:38:31 UTC, bitwise wrote: I would, but I'm not sure I can use these allocators. Ran into this: http://forum.dlang.org/post/akohcwiotlcrodemh...@forum.dlang.org As stated in that thread, I can mark the member instance of the allocator in the container as

  1   2   3   4   >