www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.experimental.alloctor does not work with non default constructible

reply maik klein <maikklein googlemail.com> writes:
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
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
parent reply maik klein <maikklein googlemail.com> writes:
On Friday, 3 June 2016 at 11:52:52 UTC, Andrei Alexandrescu wrote:

 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


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)
Jun 03 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/3/16 7:57 AM, maik klein wrote:

 On Friday, 3 June 2016 at 11:52:52 UTC, Andrei Alexandrescu wrote:

 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


 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)


That should be fixable, please submit to bugzilla. Thanks! -- Andrei
Jun 03 2016
parent reply maik klein <maikklein googlemail.com> writes:
On Friday, 3 June 2016 at 12:16:54 UTC, Andrei Alexandrescu wrote:

 On 6/3/16 7:57 AM, maik klein wrote:

 On Friday, 3 June 2016 at 11:52:52 UTC, Andrei Alexandrescu 
 wrote:

 On 6/3/16 7:47 AM, maik klein wrote:

 [...]


 Looks like a bug. Do you have a short repro? -- Andrei


 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)


 That should be fixable, please submit to bugzilla. Thanks! -- 
 Andrei


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.
Jun 03 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
prev sibling parent reply Dicebot <public dicebot.lv> writes:
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
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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