On Tuesday, 22 January 2013 at 19:07:56 UTC, Simen Kjaeraas wrote:
On 2013-01-22, 19:45, Minas Mina wrote:
I have this structure:
struct Scene
{
Array!Surface objects; // objects in the scene
Array!Light lights; // lights in the scene
/*private*/ BVHNode root; // root node of the BVH
tree
@disable this(); // disable the default constructor because
space needs to be reserved for objects and lights
this(size_t objectReserveSpace = 20, size_t lightReserveSpace
= 3)
{
objects.reserve(objectReserveSpace);
lights.reserve(lightReserveSpace);
}
}
auto scene = Scene(); // error about @disabled constructor
Yes, the default constructor is @disabled BUT I am not using
that one. I want to use the other one - the custom
constructor. I guess it signals an error because it has those
defaults parameters. But shouldn't the compiler choose that
one?
You *are* using the default one. The one without parameters
*is* the
default constructor, and you are calling the constructor
without parameters.
One could argue that the compiler should choose the other
constructor, and
even that having default constructors is reasonable. However, D
has gone
the route of not having default constructors for structs.
Instead,
structs are defined to be trivially constructible from T.init.
Which incompatible with the desire of a NonNull construct.
The workaround is to use static opCall:
struct Scene
{
Array!Surface objects;
Array!Light lights;
/*private*/ BVHNode root;
@disable this();
this(size_t objectReserveSpace = 20, size_t lightReserveSpace
= 3)
{
objects.reserve(objectReserveSpace);
lights.reserve(lightReserveSpace);
}
static Scene opCall(size_t objectReserveSpace = 20, size_t
lightReserveSpace = 3)
{
return Scene(objectReserveSpace, lightReserveSpace);
}
}
Cheap workaround as you cannot new.