Consider the following stack region:
struct InSituRegion2(size_t size)
{
// The store will be aligned to realof.align
union
{
private ubyte[size] _store = void;
real _forAlignmentOnly;
}
void* _crt, _end;
void[] allocate(size_t bytes)
{
assert(_crt && _end);
// round up
const rounded = (bytes + real.alignof - 1) / real.alignof;
auto newCrt = _crt + rounded;
if (newCrt > _end) return null;
auto result = _crt[0 .. bytes];
_crt = newCrt;
return result;
}
}
size_t fun2(size_t s)
{
InSituRegion2!(1024 * 64) r;
r._crt = r._store.ptr;
r._end = r._store.ptr + r._store.length;
auto a = cast(uint[]) r.allocate(s);
return a[s / 2];
}
(The code of fun2 has been written to be complex enough to avoid a few elisions effected by optimizers.)
Disassembly reveals that constructing the struct object entails a memcpy of the object's init over the object memory, even though most of the object is deliberately left uninitialized. This undoes the performance gains of defining and using an encapsulated stack region.
The initialization function should either use multiple memcpy calls or individual word assignments.
Comment #1 by public — 2013-10-23T09:26:14Z
Erm, isn't it by spec? `void` initializer is targeted for variables, not member fields. Here it just says that relevant `T.init` part can be garbage.
Fixing this issue would imply that there are no more guaranteed deterministic T.init values for all types.
Comment #2 by andrei — 2013-10-23T09:53:31Z
@Dicebot: yah, it's an enhancement. One of the spec as well :o). The .init value can still exist, but the initialization doesn't need to use it.
Comment #3 by public — 2013-10-23T09:55:29Z
(In reply to comment #2)
> @Dicebot: yah, it's an enhancement. One of the spec as well :o). The .init
> value can still exist, but the initialization doesn't need to use it.
Well, this sounds like quite an important change - I'd prefer this issue description to tell more about possible implications of that spec change than about generated assembly :)
Comment #4 by andrei — 2013-10-23T10:07:14Z
http://dlang.org/struct.html mentions that "Struct instances that are not instantiated with a constructor are default initialized to their .init value." and mentions that S() is "same as auto b = S.init;"
There is no guarantee about the values of the = void members in S.init, but definitely the spec clarifies that two default-constructed objects will compare equal. So we need to change the spec to only guarantee non-=void fields of default-constructed objects to be equal.
Comment #5 by gyroheli — 2016-09-11T21:18:42Z
Is anything being worked on to change this?
Comment #6 by code — 2016-10-10T20:54:00Z
It's almost somewhat of a language fix, b/c they are silently ignored, everybody expects them to work (seen that discussion/mistake several times already, recent occurence https://forum.dlang.org/post/[email protected]).
Until we use that information for more efficient initialization we should probably warn about that = void on a struct field has no effect.
Comment #7 by dfj1esp02 — 2017-08-25T10:06:50Z
*** Issue 15951 has been marked as a duplicate of this issue. ***
Comment #8 by dfj1esp02 — 2017-08-25T10:06:58Z
*** Issue 11817 has been marked as a duplicate of this issue. ***