www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - struct and default constructor

reply deadalnix <deadalnix gmail.com> writes:
Hi,

I wonder why struct can't have a default constructor. TDPL state that it 
is required to allow every types to have a constant .init .

That is true, however not suffiscient. A struct can has a void[constant] 
as a member and this doesn't have a .init . So this limitation does not 
ensure that the benefit claimed is garanteed.

Additionnaly, if it is the only benefit, this is pretty thin compared to 
the drawback of not having a default constructor.

We already have  disable this(); for structs. This cause the struct to 
behave differently and cause the error  initializer required for type 
xxx  when a variable of type xxx is defined without initialization. 
This doesn't prevent the struct to get a constant .init and to use it 
(even if this .init is probably garbage in this case, the whole point of 
the  disable is to force the user to use a constructor or to copy).

The whole stuff seems very unclear and limitations arbitrary.

Note that a static opCall and a  disabel default constructor doesn't do 
the trick as opCall can't be used with new to allocate on the heap. This 
is only a cheap workaround.

Note also that xxx myvar = xxx.init; worls and doesn't trigger postblit. 
So the  disable this(); is also a structure thatd oesn't garantee anything.

The point of classes and struct beeing different in D is slicing. 
Default constructor is unrelated to that problem.

Why not allow both  disable this(); and default constructor construct, 
both triggering the error  initializer required for type xxx  ? This 
would make much more sense. Postblit should also be triggered on 
assiagnation with .init to ensure the consistency of the whole construct.
Nov 27 2011
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
In addition, here is a workaround :

// Wonderfull !
 disable this();

// Default constructor workaround.
this(int dummy = 0) { ... }

But that look very dirty and it feels like working against the language.
Nov 27 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Wait nevermind, I thought you mean't the ctor *actually runs*. What
you meant was disable this() doesn't work with that ctor in place.

On 11/27/11, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 That's not a workaround, that ctor never gets called unless you pass
 an argument.

Nov 27 2011
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 27/11/2011 21:39, Andrej Mitrovic a crit :
 That's not a workaround, that ctor never gets called unless you pass
 an argument.

So if you disable this(); you shouldn't get an error. Actually, you have an implicit constructor, even if it's only to set the variable as equal to .init property of the struct.
Nov 27 2011
prev sibling next sibling parent reply =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Sun, 27 Nov 2011 21:19:38 +0100, deadalnix <deadalnix gmail.com> wrote:

 In addition, here is a workaround :

 // Wonderfull !
  disable this();

 // Default constructor workaround.
 this(int dummy = 0) { ... }

 But that look very dirty and it feels like working against the language.

I believe your "workaround" will disappoint you, as it simply does not run. import std.stdio; struct A { int value; disable this(); this(int dummy = 0) { value = 3; writeln("Hello from struct default constructor!"); // Never happens. } } void main() { A a = A(); writeln( a.value ); // Writes 0 } More importantly, this shows a bug in DMD - namely that structs with disabled default constructors can be created without a call to any constructor and with no error message. In fact, if one removes the constructor with dummy arguments, the program still compiles. http://d.puremagic.com/issues/show_bug.cgi?id=7021
Nov 27 2011
parent deadalnix <deadalnix gmail.com> writes:
Le 27/11/2011 22:24, Simen Kjærås a écrit :
 On Sun, 27 Nov 2011 21:19:38 +0100, deadalnix <deadalnix gmail.com> wrote:

 In addition, here is a workaround :

 // Wonderfull !
  disable this();

 // Default constructor workaround.
 this(int dummy = 0) { ... }

 But that look very dirty and it feels like working against the language.

I believe your "workaround" will disappoint you, as it simply does not run. import std.stdio; struct A { int value; disable this(); this(int dummy = 0) { value = 3; writeln("Hello from struct default constructor!"); // Never happens. } } void main() { A a = A(); writeln( a.value ); // Writes 0 } More importantly, this shows a bug in DMD - namely that structs with disabled default constructors can be created without a call to any constructor and with no error message. In fact, if one removes the constructor with dummy arguments, the program still compiles. http://d.puremagic.com/issues/show_bug.cgi?id=7021

So that is even worse that what I though. This struct situation is very messy and inconsistent. We should definie what we want for that and have a descent spec. I just found something new : if you disable this(this), then opAssign should be allowed (it is allowed, according to the website, when implicit cast doesn't exists). The copy don't work with opAssign and disabled postblit . . .
Nov 27 2011
prev sibling parent Steve Teale <steve.teale britseyeview.com> writes:
On Sun, 27 Nov 2011 21:39:05 +0100, Andrej Mitrovic wrote:

 That's not a workaround, that ctor never gets called unless you pass an
 argument.

But it lets you pass a Range test.
Nov 28 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
That's not a workaround, that ctor never gets called unless you pass
an argument.
Nov 27 2011
prev sibling next sibling parent "dcrepid" <dcrepid none.com> writes:
On Sunday, 27 November 2011 at 19:50:24 UTC, deadalnix wrote:
 Hi,

 I wonder why struct can't have a default constructor...

I know this is an old thread, but I've run into this same problem recently and search yielded this result. I myself have tried working around the default-constructor problem with things like this(bool bInit = true) - which of course doesn't get invoked with MyStruct(), even with disable this. This seems like a language limitation to me. I have a few templated resource management objects that rely on RAII, but sometimes there's no real use for arguments, especially if a template defines what needs to be created. But now I'm forced to both disable the default constructor AND to require unnecessary parameters. Why? Another workaround is to use some object factory mechanism, but that's just extra code to maintain. Also, apparently doing cleanup in class object destructors is a big no-no as resources that it may need to clean up could potentially already be destroyed, depending on when the GC kicks in and what objects are cleared by it. So no possibility of using objects as resource acquire/release mechanisms. I assume using scoped with class objects will have a similar problem..
Oct 09 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Fri, 10 Oct 2014 01:32:51 +0000
dcrepid via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 This seems like a language limitation to me.

well-defined initial value". the thing is that struct must have initial value that can be calculated without executing any code. i.e. `T.init`. with default struct constructor we can't have such initial state anymore. this is highly unsafe. yet compiler ignores constructor with default args when creating struct. i.e. for this: struct A { disable this (); this (int v=3D42) { ... } ... } ... auto a =3D A(); compiler will not call this(42), but will generate error. i'm not sure if this must be changed though, 'cause `this (int)` now becames default constructor and we have no well-defined initial value anymore.
 So no possibility of using=20
 objects as resource acquire/release mechanisms.
 I assume using scoped with class objects will have a similar=20
 problem..

to will not be destroyed until stack object is alive. so destructor of stack-allocated object *can* be used for doing cleanup. but you can use templates to build your "anchor" structs. it's hard to say without concrete code samples.
Oct 10 2014
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 10 October 2014 at 01:32:54 UTC, dcrepid wrote:
 On Sunday, 27 November 2011 at 19:50:24 UTC, deadalnix wrote:
 Hi,

 I wonder why struct can't have a default constructor...

I know this is an old thread, but I've run into this same problem recently and search yielded this result. I myself have tried working around the default-constructor problem with things like this(bool bInit = true) - which of course doesn't get invoked with MyStruct(), even with disable this.

You can use `static opCall` as a workaround. The following prints "S(0)" and "S(3)": struct S { int x; static S opCall() { S s; s.x = 3; return s; } } void main() { import std.stdio; S s; writeln(s); S t = S(); writeln(t); } But if you add a constructor with parameters, you get an error: struct S { int x; static S opCall() { ... } this(int y) { x = y; } } xx.d(4): Error: struct xx.S static opCall is hidden by constructors and can never be called xx.d(4): Please use a factory method instead, or replace all constructors with static opCall. IMO this is too restrictive, as obviously, the static opCall is _not_ hidden by the constructor.
Oct 10 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/27/2011 11:53 AM, deadalnix wrote:
 I wonder why struct can't have a default constructor. TDPL state that it is
 required to allow every types to have a constant .init .

Having a .init instead of a default constructor has all kinds of useful properties: 1. the default object is trivially constructable and cannot fail 2. an easy way for other constructors to not have overlooked field initializers, so they get garbage initialized like in C++ 3. generic code can rely on the existence of trivial construction that cannot fail 4. dummy objects can be created, useful for "does this compile" semantics 5. an object can be "destroyed" by overwriting it with .init (overwriting with 0 is not the same thing) 6. when you see: T t; in code, you know it is trivially constructed and will succeed 7. objects can be created using TypeInfo Default constructors are baked into C++. I can't escape the impression that the desire for D default constructors comes from more or less trying to write C++ style code in D. I feel that non-trivial default construction is a bad idea, as are the various methods people try to get around the restriction. For non-trivial construction, one can easily just make a constructor with an argument, or call a factory method that returns a constructed object.
Oct 10 2014
next sibling parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Friday, 10 October 2014 at 09:58:54 UTC, Walter Bright wrote:
 On 11/27/2011 11:53 AM, deadalnix wrote:
 I wonder why struct can't have a default constructor. TDPL 
 state that it is
 required to allow every types to have a constant .init .

Having a .init instead of a default constructor has all kinds of useful properties: 1. the default object is trivially constructable and cannot fail 2. an easy way for other constructors to not have overlooked field initializers, so they get garbage initialized like in C++ 3. generic code can rely on the existence of trivial construction that cannot fail 4. dummy objects can be created, useful for "does this compile" semantics 5. an object can be "destroyed" by overwriting it with .init (overwriting with 0 is not the same thing) 6. when you see: T t; in code, you know it is trivially constructed and will succeed 7. objects can be created using TypeInfo Default constructors are baked into C++. I can't escape the impression that the desire for D default constructors comes from more or less trying to write C++ style code in D.

Bit OT: What is The D code style then? It would be very useful for those coming from C++ to have a wiki/article on how to translate C++ idioms and practices to D. I too am writing D code like I do my C++ and often find myself puzzled (deterministic d-tors being perfect example). Missing default struct c-tor is also one of such examples - and adding opCall() feels hacky.
Oct 10 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 3:23 AM, Szymon Gatner wrote:
 Bit OT: What is The D code style then? It would be very useful for those coming
 from C++ to have a wiki/article on how to translate C++ idioms and practices to
 D. I too am writing D code like I do my C++ and often find myself puzzled
 (deterministic d-tors being perfect example). Missing default struct c-tor is
 also one of such examples - and adding opCall() feels hacky.

You're right, but it's a bit of a difficult question to answer. Other examples that cause people grief: 1. using ref as a type constructor 2. multiple inheritance 3. using a struct as both a value and a polymorphic type These are idiomatic C++ usages that need to be rethought for D.
Oct 10 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 3:25 AM, ketmar via Digitalmars-d wrote:
 people also keep forgetting about default values and want
 default constructors to simulate this:

    struct {
      int n = 42;
      string s = "default string";
    }

That's a good observation.
Oct 10 2014
prev sibling next sibling parent reply "Simon A" <simon_a example.com> writes:
On Friday, 10 October 2014 at 09:58:54 UTC, Walter Bright wrote:
 On 11/27/2011 11:53 AM, deadalnix wrote:
 I wonder why struct can't have a default constructor. TDPL 
 state that it is
 required to allow every types to have a constant .init .

Having a .init instead of a default constructor has all kinds of useful properties: 1. the default object is trivially constructable and cannot fail 2. an easy way for other constructors to not have overlooked field initializers, so they get garbage initialized like in C++ 3. generic code can rely on the existence of trivial construction that cannot fail 4. dummy objects can be created, useful for "does this compile" semantics 5. an object can be "destroyed" by overwriting it with .init (overwriting with 0 is not the same thing) 6. when you see: T t; in code, you know it is trivially constructed and will succeed 7. objects can be created using TypeInfo Default constructors are baked into C++. I can't escape the impression that the desire for D default constructors comes from more or less trying to write C++ style code in D. I feel that non-trivial default construction is a bad idea, as are the various methods people try to get around the restriction. For non-trivial construction, one can easily just make a constructor with an argument, or call a factory method that returns a constructed object.

I've often thought that most of the hidden pain of arbitrary constructors in C++ could be avoided if C++ could take advantage of functional purity. D has native functional purity. Couldn't you get the same benefits that you listed by allowing default constructors but requiring them to be pure? Of course, you can get the same outcome by initialising members using static pure functions or various other helpers, so you could say that pure default constructors are just syntactic sugar. Pure default constructors do have some advantages for more complex construction, though. For the sake of example, say I have a struct that uses a table of complex numbers, and for unrelated reasons the real and imaginary parts are stored in separate arrays. I.e., I have to initialise multiple members using one calculation. Adding pure default constructors to D would allow this to be implemented more cleanly and more intuitively.
Oct 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 5:25 PM, Simon A wrote:
 D has native functional purity.  Couldn't you get the same
 benefits that you listed by allowing default constructors but
 requiring them to be pure?

I suspect that CTFE can accomplish most of that today - with the exception that CTFE will not allocate runtime memory for you.
Oct 10 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/10/2014 9:43 PM, Dicebot wrote:
 On Saturday, 11 October 2014 at 04:41:52 UTC, Walter Bright wrote:
 On 10/10/2014 5:25 PM, Simon A wrote:
 D has native functional purity.  Couldn't you get the same
 benefits that you listed by allowing default constructors but
 requiring them to be pure?

I suspect that CTFE can accomplish most of that today - with the exception that CTFE will not allocate runtime memory for you.

There is ER somewhere in bugzilla AFAIR about allowing CTFE-only struct default constructors.

Note that you can do (as pointed out upthread): struct S { int x = 7; string s = "hello"; } which then has default initialization. Of course, CTFE will work on those rvalues.
Oct 10 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 11 October 2014 at 04:41:52 UTC, Walter Bright wrote:
 On 10/10/2014 5:25 PM, Simon A wrote:
 D has native functional purity.  Couldn't you get the same
 benefits that you listed by allowing default constructors but
 requiring them to be pure?

I suspect that CTFE can accomplish most of that today - with the exception that CTFE will not allocate runtime memory for you.

There is ER somewhere in bugzilla AFAIR about allowing CTFE-only struct default constructors.
Oct 10 2014
prev sibling next sibling parent "dcrepid" <dcrepid none.com> writes:
Okay, I'm still kind of new to this language, so forgive me if I 
see things a little differently than long time users..

Here's what I see though.

With Walter's description of what structures should be, it seems 
to me to be slightly at odds with what D structures are capable 
of, and in fact what they are being used for in a number of 
places ('fixing' GC, adding reference counting, providing RAII, 
etc).

Structs are classically POD types, as we know from C. But with D 
you've added overloaded constructors, destructors, member 
functions etc. To me that more or less defines an object, albeit 
one with special limits.  If you don't want to call them objects, 
thats fine. But the fact that they have customizable behavior in 
creation, copying, moving, and destruction means that they are 
much more than just a plain old data type with generic T.init 
states. They are a kind of living object, yea?

And it seems to me that the default constructor is just the last 
component left to cement the structure as an object. It seems 
curious that you would allow the ability to disable default 
construction and copy construction, and allow hiding of 
constructors, etc.. but then determine that default constructors 
are going too far?

Sure, having a guarantee that a struct will always be created 
without a fail state is a great concept.  But why then haven't 
they just been kept as a collection of data types, and another 
'scope object' been created instead?

It seems what has happened is a FrankenStruct monster was created 
in the midst of trying to find some midway point between D 
objects and 'scope objects'..

I would myself love to use objects all the time, but I see these 
problems that currently only the FrankenStructs resolve:

1. Objects are basically pointers, and can be null pointers at 
that! (To me, that's C-levels of safety there)
    However: Structs are always created.
2. Without assigning something to an object, there's obviously no 
real initialization.
    However: Structs are initialized on creation.
3. Object Destructors are called 'sometime in the future' when GC 
runs. Cleaning up resources is discouraged as those resources 
might have been cleaned up by the GC?
    However: Struct destructors run when they are out of scope.
4. Objects always have at least one level of indirection (and a 
lot of extra data)
    Structs are there where you define them. (with no extra data)

I may not be 100% on all of this, I'm still learning. But many 
times browsing the forums, reading the D books etc, I see the 
solutions to D object problems becoming this: wrap it with a 
struct.  So whether its something like RefCounted, Scoped, 
NonNullable, UniqueArray etc.. the problems with D objects are 
fixed by relying on the guarantees provided by structures to 
solve them.

I dunno, to me it all seems a bit discordant with what Walter 
seems to want them to be?

(Sorry in advance if any of this comes off as mean or provoking.. 
I'm just sharing how I view the language design)
Oct 11 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 11 Oct 2014 08:53:08 +0000
dcrepid via Digitalmars-d <digitalmars-d puremagic.com> wrote:

structs also can't be inherited and can't have virtual methods
(obviously, as they have no VMT). just a comment. ;-)

ah, and don't forget another great aspect of structs: confusing C++
users! ;-)
Oct 11 2014
prev sibling parent "dcrepid" <dcrepid none.com> writes:
On Saturday, 11 October 2014 at 09:19:47 UTC, ketmar via 
Digitalmars-d wrote:
 On Sat, 11 Oct 2014 08:53:08 +0000
 dcrepid via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 structs also can't be inherited and can't have virtual methods
 (obviously, as they have no VMT). just a comment. ;-)

Yeah, thats one of the things I meant by "with special limits". =)
Oct 11 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Fri, 10 Oct 2014 02:58:39 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Default constructors are baked into C++. I can't escape the
 impression that the desire for D default constructors comes from more
 or less trying to write C++ style code in D.

default constructors to simulate this: struct { int n =3D 42; string s =3D "default string"; }
Oct 10 2014
prev sibling next sibling parent "dcrepid" <dcrepid none.com> writes:
On Friday, 10 October 2014 at 08:03:49 UTC, ketmar via 
Digitalmars-d wrote:
 On Fri, 10 Oct 2014 01:32:51 +0000
 dcrepid via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 So no possibility of using objects as resource acquire/release 
 mechanisms.
 I assume using scoped with class objects will have a similar 
 problem..

reference to will not be destroyed until stack object is alive. so destructor of stack-allocated object *can* be used for doing cleanup. but you can use templates to build your "anchor" structs. it's hard to say without concrete code samples.

What I mean with the scoped objects is that you still need to provide a constructor with parameters, yes? I will have to try this out myself, but I've avoided it since some people seem to indicate this is going to be deprecated.. Basically what I was doing code-wise was creating a 'FixedBuffer' structure, which would have its size passed as a template parameter. The constructor would do a malloc on it, and all the checks for bounds would only need to rely on that template parameter. Net result is that the cost of having a pretty safe bounds-checked buffer was just the size of one pointer. I *sorta* get the whole concept of being able to easily reason and work with structures in D, but why then does it have a destructor and a way to disable a default constructor, along with operator overloads and whatnot. It seems to me its trying to be object-like and POD-like at the same time which doesn't mesh well. As far as the 'scoped' object, I was referring to default construction - is it possible? Or do I need to use Walter's factory production workaround everytime I want something with deterministic create/destroy properties in this context? I would very readily accept using objects over structs if they had a guarantee of when they are destroyed, and weren't as risky to pass around as C pointers (i.e. possibility of them being null).
Oct 10 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Fri, 10 Oct 2014 18:50:29 +0000
dcrepid via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 What I mean with the scoped objects is that you still need to=20
 provide a constructor with parameters, yes? I will have to try=20
 this out myself, but I've avoided it since some people seem to=20
 indicate this is going to be deprecated..

concept. you just have to write it this now: import std.typecons : scoped; // yep, it's in a library now ... class A { this () { ... } ~this () { ... } } ... { // allocate class instance on the stack auto a =3D scoped!A(); ... } // here destructor for 'a' will be called just be careful and don't let 'a' escape the scope. ;-)
 Basically what I was doing code-wise was creating a 'FixedBuffer'=20
 structure, which would have its size passed as a template=20
 parameter.  The constructor would do a malloc on it, and all the=20
 checks for bounds would only need to rely on that template=20
 parameter. Net result is that the cost of having a pretty safe=20
 bounds-checked buffer was just the size of one pointer.

struct A(size_t asize) { private ubyte* mData/* =3D null*/; // '=3Dnull' is the default private enum mSize =3D asize; disable this (this); ~this () { import core.stdc.stdlib; if (mData !is null) free(mData); } // and allocate memory for data in getter property auto data () { import core.stdc.stdlib; if (mData is null) { import core.exception : onOutOfMemoryError; mData =3D cast(typeof(mData))malloc(mSize); if (mData is null) onOutOfMemoryError(); } return mData[0..mSize]; } property size_t length () const safe pure nothrow nogc { return mSiz= e; } size_t opDollar () const safe pure nothrow nogc { return mSize; } ubyte opIndex (size_t ofs) trusted { import core.exception : RangeError; if (ofs >=3D mSize) throw new RangeError(); return data[ofs]; } ubyte opIndexAssign (ubyte v, size_t ofs) trusted { import core.exception : RangeError; if (ofs >=3D mSize) throw new RangeError(); return (data[ofs] =3D v); } } but then you will not be able to copy it (or you'll need additional field to keep "don't free" flag, and with it you can use slice instead, 'cause they both will not fit into the pointer). and you will not be able to pass it to functions anyway, this will not work: void doSomethingOnBuffer (ref A buf); only this: void doSomethingOnBuffer (ref A!1024 buf); i.e. you'll have to write the size in function args.
 I *sorta* get the whole concept of being able to easily reason=20
 and work with structures in D, but why then does it have a=20
 destructor and a way to disable a default constructor, along with=20
 operator overloads and whatnot.  It seems to me its trying to be=20
 object-like and POD-like at the same time which doesn't mesh well.

another is object-like, with methods, destructors and so on. this may be confusing a little. ;-) just don't mix 'em.
 As far as the 'scoped' object, I was referring to default=20
 construction - is it possible?

instance anywhere, 'cause it will be overwritten with another data after exiting the scope and all hell breaks loose.
 I would very readily accept using objects over structs if they=20
 had a guarantee of when they are destroyed, and weren't as risky=20
 to pass around as C pointers (i.e. possibility of them being=20
 null).

Oct 10 2014
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 27 November 2011 at 19:50:24 UTC, deadalnix wrote:
 Hi,

 I wonder why struct can't have a default constructor. TDPL 
 state that it is required to allow every types to have a 
 constant .init .

 That is true, however not suffiscient. A struct can has a 
 void[constant] as a member and this doesn't have a .init . So 
 this limitation does not ensure that the benefit claimed is 
 garanteed.

 Additionnaly, if it is the only benefit, this is pretty thin 
 compared to the drawback of not having a default constructor.

Think the argument is that declaring `T t;` must be CTFE, which kind of implies a T.init state (which may have non-deterministic values in the presence of " = void"). This is mostly for declaring things static, and the whole "constructors are run after the .init blit". But even then: T t; //value is T.init, if not disable this() T t = T(); //Potentially run-time I've started threads and tried to start discussions about this before, but to no avail. It's a relativelly recurrent complain, especially from "newer" C++ users. The older D users have either of thrown in the towel, or implemented "workarounds".
Oct 10 2014
parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 10/10/2014 22:19, monarch_dodra wrote:
 Think the argument is that declaring `T t;` must be CTFE, which kind of
 implies a T.init state (which may have non-deterministic values in the
 presence of " = void").

 This is mostly for declaring things static, and the whole "constructors
 are run after the .init blit".

 But even then:
 T t; //value is T.init, if not  disable this()
 T t = T(); //Potentially run-time

 I've started threads and tried to start discussions about this before,
 but to no avail. It's a relativelly recurrent complain, especially from
 "newer" C++ users.

Totally agree, and it doesn't help that some D proponents ignore this point and just repeat "it doesn't work with the design of D". Whenever there is a weak explanation for something it will damage D, to some extent. In those cases it would be much better if a convincing argument can be written up as a website FAQ, or at least state that more research is needed before a solution can be tried.
Oct 12 2014
prev sibling next sibling parent "dcrepid" <dcrepid none.com> writes:
On Friday, 10 October 2014 at 20:25:16 UTC, ketmar via 
Digitalmars-d wrote:
 On Fri, 10 Oct 2014 18:50:29 +0000
 dcrepid via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 What I mean with the scoped objects is that you still need to 
 provide a constructor with parameters, yes? I will have to try 
 this out myself, but I've avoided it since some people seem to 
 indicate this is going to be deprecated..

the whole concept. you just have to write it this now: import std.typecons : scoped; // yep, it's in a library now ... class A { this () { ... } ~this () { ... } } ... { // allocate class instance on the stack auto a = scoped!A(); ... } // here destructor for 'a' will be called just be careful and don't let 'a' escape the scope. ;-)

Great, thanks for the tips!
 it's better to use slices for that. you can create struct like 
 this:
 (snipped)

Thanks for the effort of providing a proof of concept, even though I don't agree with what the data property should do. Shouldn't properties not mutate the data? But more than that I think its a waste to check whether the buffer is there every time you need to access it. Its better to allocate at the start, throw an exception if it can't be allocated, then provide access to it without any wasteful checks between. At least, this is the RAII type of idiom I'm after. How I am currently using it is using either .ptr, .data, or slices to create the necessary access or D slices. It works pretty well for what I'm using it for. I'm interfacing with the Windows API with the .ptr property, and then when I need to use it with D functions I typically use opSlice since the data is often variable lengths. I've pasted most of the struct I've been using here: http://dpaste.dzfl.pl/15381d5828f8 I would use it in say, a call to Windows' WinHttpReadData() using OutBuffer.ptr, then work with the received data (stored in dwDownloaded) using OutBuffer[0 .. dwDownloaded], for example. It works pretty nicely even if its not up to D's standards. About escaping scope - I'm aware this is possible, but the idea is that this is supposed to be used temporarily in a certain scope, then discarded (as the Scope prefix indicates).. there's better methods to doing it safely, for sure. But to do the same with only a single pointer? I think I like the idea of the factory method now though, as I've learned you can hide a struct inside a function, and then call the function to set the struct up properly and return it. At least, I'm sure I've seen code that does that..
  It seems to me its trying to be object-like and POD-like at 
 the same time which doesn't mesh well.

POD, and another is object-like, with methods, destructors and so on. this may be confusing a little. ;-) just don't mix 'em.

Haha.. I'll try not to (I think?)
 I would very readily accept using objects over structs if they 
 had a guarantee of when they are destroyed, and weren't as 
 risky to pass around as C pointers (i.e. possibility of them 
 being null).


I thought ref gives us the same guarantee that C++'s references do? Pointers are so.. 90's =P But yeah, the nullable object thing has bitten my ass a few times as I'm learning D, which really frustrates me =\ Thanks for your time
Oct 10 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Fri, 10 Oct 2014 21:45:32 +0000
dcrepid via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Great, thanks for the tips!

 Thanks for the effort of providing a proof of concept, even=20
 though I don't agree with what the data property should do.=20
 Shouldn't properties not mutate the data?

property is acceptable. maybe not the best style, but acceptable. yet i may be wrong, of course.
 I think its a waste to check whether the buffer is there every time=20
 you need to access it.

time you need it for some lengthy operation anyway, so checking cost can be ignored. and you can do `auto mypointer =3D a.data.ptr;` to avoid further checks. actually, it's meant to be used like this: auto d =3D a.data; // here we'll work with d, so no more checks
 Its better to allocate at the start, throw=20
 an exception if it can't be allocated, then provide access to it=20
 without any wasteful checks between. At least, this is the RAII=20
 type of idiom I'm after.

at arbitrary place (where you'll first access .data), not when you declaring buffer this can be bad 'cause you may already execute some preparation code thinking that you have your buffer at hand.
 I've pasted most of the struct I've been using here:
 http://dpaste.dzfl.pl/15381d5828f8

btw, i'm used to call core.exception.onOutOfMemoryError when malloc() fails. We can't be sure that we still have memory to construct new Error object. sure, we'll lose linenumber info this way. it's not a rule of thumb, though (Phobos tend to throw new OutOfMemoryError instances, for example). but if we are working with memory on such low level...
 better methods to doing it safely, for sure. But to do the same=20
 with only a single pointer?

sort of tricks to pack alot of data in single pointer, but i can't see any practical sense in it. today when smartphones have gigabytes of RAM, i'll trade some more pointers for ease of using and safety.
 I think I like the idea of the factory method now though, as I've=20
 learned you can hide a struct inside a function, and then call=20
 the function to set the struct up properly and return it. At=20
 least, I'm sure I've seen code that does that..

auto thatWhoCantBeNamed () { static struct A { ... } return A(); } voila. you have type that you can use but cannot create without factory. but you need to have postblit enabled with this.
 you can pass pointers to structs. pointers can be null. ;-)

do? Pointers are so.. 90's =3DP But yeah, the nullable object=20 thing has bitten my ass a few times as I'm learning D, which=20 really frustrates me =3D\

it (and about ~80% of Phobos for that matter ;-).
 Thanks for your time

too.
Oct 10 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 10 October 2014 at 09:14:16 UTC, Marc Schütz wrote:
 You can use `static opCall` as a workaround.

Please don't. It is never worth the gain. Never.
Oct 10 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, October 10, 2014 22:49:13 Walter Bright via Digitalmars-d wrote:
 On 10/10/2014 9:43 PM, Dicebot wrote:
 There is ER somewhere in bugzilla AFAIR about allowing CTFE-only struct
 default constructors.

Note that you can do (as pointed out upthread): struct S { int x = 7; string s = "hello"; } which then has default initialization. Of course, CTFE will work on those rvalues.

The only reason that I can think of to have default constructors for filling in the member variables during CTFE would be if you wanted to calculate some of the values based on other values, and while that might be nice upon occasion, I don't think that not having it is much of a loss. - Jonathan M Davis
Oct 10 2014
prev sibling next sibling parent "Nicolas Sicard" <dransic gmail.com> writes:
On Friday, 10 October 2014 at 22:34:45 UTC, ketmar via
Digitalmars-d wrote:
 I think I like the idea of the factory method now though, as 
 I've learned you can hide a struct inside a function, and then 
 call the function to set the struct up properly and return it. 
 At least, I'm sure I've seen code that does that..

auto thatWhoCantBeNamed () { static struct A { ... } return A(); } voila. you have type that you can use but cannot create without factory. but you need to have postblit enabled with this.

It's not a "Voldemort type" if the struct A is static, is it? You can just alias A = typeof(thatWhoCantBeNamed()); and then create a new object of the same type. -- Nicolas
Oct 11 2014
prev sibling next sibling parent "dcrepid" <dcrepid none.com> writes:
On Friday, 10 October 2014 at 22:34:45 UTC, ketmar via 
Digitalmars-d wrote:
 On Fri, 10 Oct 2014 21:45:32 +0000
 Shouldn't properties not mutate the data?

property is acceptable. maybe not the best style, but acceptable. yet i may be wrong, of course.

Ah, I see. Lazy initialization is a nice approach to some things. But I'm not entirely sure it belongs in the structure or object itself.. however, if I were too I might put it in a 'length' or 'rezise' member function.. but that'd be better for a resizable object..
 better methods to doing it safely, for sure. But to do the 
 same with only a single pointer?

all sort of tricks to pack alot of data in single pointer, but i can't see any practical sense in it. today when smartphones have gigabytes of RAM, i'll trade some more pointers for ease of using and safety.

Actually, I think memory efficiency and speed are pretty key today, especially with embedded systems, server farms, and mobile devices. And it doesn't just have to do with available memory, but cache lines, register usage, etc. But that's another debate for another time. As far as the safety tradeoff though.. I prevent copying and default construction, so at least two problems should theoretically be solved. The possibility of using ranges or pointers outside of the function or scope is the only thing that would need to be controlled for. And there I suppose the GC or reference counting mechanisms would be the only other options. But hopefully if I document it right, and suggest the correct alternatives to use, I can prevent careless programmers from making those mistakes. (I think std.container.array.Array is a nice fallback)
 ah, yes, it's "Voldemort type". ;-)

Ah, I had wondered why/where/what context I heard that under! Makes more sense now. =) Also, thanks for the other pointers (I didnt quote everything here)
Oct 11 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 11 Oct 2014 08:41:15 +0000
Nicolas Sicard via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Friday, 10 October 2014 at 22:34:45 UTC, ketmar via
 Digitalmars-d wrote:
 I think I like the idea of the factory method now though, as=20
 I've learned you can hide a struct inside a function, and then=20
 call the function to set the struct up properly and return it.=20
 At least, I'm sure I've seen code that does that..

auto thatWhoCantBeNamed () { static struct A { ... } return A(); } voila. you have type that you can use but cannot create without factory. but you need to have postblit enabled with this.

It's not a "Voldemort type" if the struct A is static, is it? You can just alias A =3D typeof(thatWhoCantBeNamed()); and then create a new object of the same type.

compiler can remove for me that my code is polluted with it. thank you.
Oct 11 2014