digitalmars.D - std.experimental.alloctor does not work with non default constructible
- maik klein (14/14) Jun 03 2016 I rely a lot on std.experimental.alloctor for my "game engine". I
- Andrei Alexandrescu (2/14) Jun 03 2016 Looks like a bug. Do you have a short repro? -- Andrei
- maik klein (11/38) Jun 03 2016 import std.experimental.allocator;
- Andrei Alexandrescu (2/39) Jun 03 2016 That should be fixable, please submit to bugzilla. Thanks! -- Andrei
- maik klein (6/35) Jun 03 2016 Thanks, I opened an issue here
- Andrei Alexandrescu (5/10) Jun 03 2016 Great, thanks. That seems to point at an issue in emplace. Surprisingly
- Dicebot (14/30) Jun 03 2016 Do you refer specifically to `makeArray` family of helpers or something
- Jonathan M Davis via Digitalmars-d (13/17) Jun 03 2016 Presumably, what he wants is the equivalent of std.array.uninitializedAr...
I rely a lot on std.experimental.alloctor for my "game engine". I have just finished creating my own version for "Algebraic" and I want to disable to default construction as it would make no sense. I have also created my own containers, the problem is that I can not use my version of "Algebraic" in any of my containers because all of them are using std.experimental.alloctor.makeArray which can not be used with non default constructible types. While I don't want to have any default constructed type of Algebraic, I really don't care for uninitialized values that I will never use anyway. I am sure there is a workaround with unions but it would be nice if makeArray/expandArray would just support non default constructible types. Thoughts?
Jun 03 2016
On 6/3/16 7:47 AM, maik klein wrote:I rely a lot on std.experimental.alloctor for my "game engine". I have just finished creating my own version for "Algebraic" and I want to disable to default construction as it would make no sense. I have also created my own containers, the problem is that I can not use my version of "Algebraic" in any of my containers because all of them are using std.experimental.alloctor.makeArray which can not be used with non default constructible types. While I don't want to have any default constructed type of Algebraic, I really don't care for uninitialized values that I will never use anyway. I am sure there is a workaround with unions but it would be nice if makeArray/expandArray would just support non default constructible types. Thoughts?Looks like a bug. Do you have a short repro? -- Andrei
Jun 03 2016
On Friday, 3 June 2016 at 11:52:52 UTC, Andrei Alexandrescu wrote:On 6/3/16 7:47 AM, maik klein wrote:import std.experimental.allocator; struct Foo{ disable this(); } auto foos = theAllocator.makeArray!Foo(100); Error messsage: ../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocato /package.d(576,34): Error: variable std.experimental.allocator.uninitializedFillDefault!(Foo).uninit alizedFillDefault.t default construction is disabled for type immutable(Foo) ../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocato /package.d(612,36): Error: template instance std.experimental.allocator.uninitializedFillDefault!(Foo) error instantiating source/breeze/util/algebraic.d(91,43): instantiated from here: makeArray!(Foo, IAllocator)I rely a lot on std.experimental.alloctor for my "game engine". I have just finished creating my own version for "Algebraic" and I want to disable to default construction as it would make no sense. I have also created my own containers, the problem is that I can not use my version of "Algebraic" in any of my containers because all of them are using std.experimental.alloctor.makeArray which can not be used with non default constructible types. While I don't want to have any default constructed type of Algebraic, I really don't care for uninitialized values that I will never use anyway. I am sure there is a workaround with unions but it would be nice if makeArray/expandArray would just support non default constructible types. Thoughts?Looks like a bug. Do you have a short repro? -- Andrei
Jun 03 2016
On 6/3/16 7:57 AM, maik klein wrote:On Friday, 3 June 2016 at 11:52:52 UTC, Andrei Alexandrescu wrote:That should be fixable, please submit to bugzilla. Thanks! -- AndreiOn 6/3/16 7:47 AM, maik klein wrote:import std.experimental.allocator; struct Foo{ disable this(); } auto foos = theAllocator.makeArray!Foo(100); Error messsage: ../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/package.d(576,34): Error: variable std.experimental.allocator.uninitializedFillDefault!(Foo).uninitializedFillDefault.t default construction is disabled for type immutable(Foo) ../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/package.d(612,36): Error: template instance std.experimental.allocator.uninitializedFillDefault!(Foo) error instantiating source/breeze/util/algebraic.d(91,43): instantiated from here: makeArray!(Foo, IAllocator)I rely a lot on std.experimental.alloctor for my "game engine". I have just finished creating my own version for "Algebraic" and I want to disable to default construction as it would make no sense. I have also created my own containers, the problem is that I can not use my version of "Algebraic" in any of my containers because all of them are using std.experimental.alloctor.makeArray which can not be used with non default constructible types. While I don't want to have any default constructed type of Algebraic, I really don't care for uninitialized values that I will never use anyway. I am sure there is a workaround with unions but it would be nice if makeArray/expandArray would just support non default constructible types. Thoughts?Looks like a bug. Do you have a short repro? -- Andrei
Jun 03 2016
On Friday, 3 June 2016 at 12:16:54 UTC, Andrei Alexandrescu wrote:On 6/3/16 7:57 AM, maik klein wrote:Thanks, I opened an issue here https://issues.dlang.org/show_bug.cgi?id=16117 I just used makeArray because it was just so convenient to use but I guess I could also switch to the untyped interface if this proves to be a blocker.On Friday, 3 June 2016 at 11:52:52 UTC, Andrei Alexandrescu wrote:That should be fixable, please submit to bugzilla. Thanks! -- AndreiOn 6/3/16 7:47 AM, maik klein wrote:import std.experimental.allocator; struct Foo{ disable this(); } auto foos = theAllocator.makeArray!Foo(100); Error messsage: ../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/package.d(576,34): Error: variable std.experimental.allocator.uninitializedFillDefault!(Foo).uninitializedFillDefault.t default construction is disabled for type immutable(Foo) ../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/package.d(612,36): Error: template instance std.experimental.allocator.uninitializedFillDefault!(Foo) error instantiating source/breeze/util/algebraic.d(91,43): instantiated from here: makeArray!(Foo, IAllocator)[...]Looks like a bug. Do you have a short repro? -- Andrei
Jun 03 2016
On 6/3/16 8:24 AM, maik klein wrote:Thanks, I opened an issue here https://issues.dlang.org/show_bug.cgi?id=16117 I just used makeArray because it was just so convenient to use but I guess I could also switch to the untyped interface if this proves to be a blocker.Great, thanks. That seems to point at an issue in emplace. Surprisingly this recent work by Walter should be able to help: https://github.com/dlang/dmd/pull/5830. It makes "union" essentially a pure layout design tool. -- Andrei
Jun 03 2016
On 06/03/2016 01:47 PM, maik klein wrote:I rely a lot on std.experimental.alloctor for my "game engine". I have just finished creating my own version for "Algebraic" and I want to disable to default construction as it would make no sense. I have also created my own containers, the problem is that I can not use my version of "Algebraic" in any of my containers because all of them are using std.experimental.alloctor.makeArray which can not be used with non default constructible types. While I don't want to have any default constructed type of Algebraic, I really don't care for uninitialized values that I will never use anyway. I am sure there is a workaround with unions but it would be nice if makeArray/expandArray would just support non default constructible types. Thoughts?Do you refer specifically to `makeArray` family of helpers or something more than that? Basic allocator interface is untyped and doesn't do any construction, i.e. https://dlang.org/phobos/std_experimental_allocator.html#.CAllocatorImpl.allocate - even plain `make` helper (https://dlang.org/phobos/std_experimental_allocator.html#.make) accepts optional list of arguments for non-default construction. For `makeArray` I don't see how it can possibly be fixed. Lack of default construction means no valid initial value for array elements, period. I don't know if you can declare plain static array of such structs but you shouldn't be able to. Note that `makeArray` also accepts optional `init` argument to be used instead of default constructed state.
Jun 03 2016
On Friday, June 03, 2016 14:01:57 Dicebot via Digitalmars-d wrote:For `makeArray` I don't see how it can possibly be fixed. Lack of default construction means no valid initial value for array elements, period. I don't know if you can declare plain static array of such structs but you shouldn't be able to.Presumably, what he wants is the equivalent of std.array.uninitializedArray but with allocators. It's not the sort of thing that I'd recommend doing normally, since you're at a high risk of shooting yourself in the foot, but it should be possible. Actually, it's stuff like that and emplace that makes invariants pretty much useless, since opAssign checks the invariant before it's called, meaning that you end up with garbage being checked against the invariant before you give it a proper value. Unfortunately, I couldn't convince Walter that opAssign should stop checking the invariant. :( But while stuff like initializing to void should generally be avoided, it _is_ possible, including with arrays. - Jonathan M Davis
Jun 03 2016