www.digitalmars.com         C & C++   DMDScript  

D - initialization of static fields

reply "Sean L. Palmer" <spalmer iname.com> writes:
Just wondering what everybody thinks about being able to initialize static
fields like so:

class A
{
  static int x = 0;
  static int y = 3;
  static this() {} // the above two initializations actually happen just
before entry to static this()
}

In C++, ambiguities with the pure syntax and with module initialization
order and linking problems cause this to not work.  Seems simple enough
though.  Of course, the default static this is usually empty, but the
compiler could tack on the initializations.

What about a similar syntax for initializing regular member fields?

class A
{
  int x = 0;
  int y = 3;
  this() {}  // the above two initializations actually happen just before
entry to this()
}

Of course the constructors are free to override these "defaults".  I'm sure
it's easy enough for the compiler to figure out if the defaults aren't
needed, and obviously the programmer won't have to specify a default.  It
might be nice to have the compiler warn about fields that are initialized in
more than one way, to prevent the situations like when one programmer
modifies the initialization inside the ctor and the other programmer
modifies the initialization at point of field declaration.

What about fields in structs?  Can they have defaults?  If structs could
have even "compiler-generated" constructors, it'd be real nice.

Sean
Nov 08 2001
parent reply "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9sdq5c$2bts$1 digitaldaemon.com...


 Just wondering what everybody thinks about being able to initialize static
 fields like so:

 class A
 {
   static int x = 0;
   static int y = 3;
   static this() {} // the above two initializations actually happen just
 before entry to static this()
 }


From D specification:

    D makes this simple. All member initializations must be determinable by
    the compiler at compile time, hence there is no order-of-evaluation
    dependency for member initializations, and it is not possible to read a
    value that has not been initialized. Dynamic initialization is performed
    by a static constructor, defined with a special syntax static this().
	class Foo
	{
	    static int a;		// default initialized to 0
	    static int b = 1;
	    static int c = b + a;	// error, not a constant initializer

	    static this()		// static constructor
	    {
		a = b + 1;		// a is set to 2
		b = a * 2;		// b is set to 4
	    }
	}

 What about a similar syntax for initializing regular member fields?


And once again, D specs:    In the class definition, the programmer can
supply a static initializer to    be used instead of the default: 	class Abc
	{
		long bar = 7;		// set default initialization
	}

 might be nice to have the compiler warn about fields that are initialized


in> more than one way, to prevent the situations like when one programmer>
modifies the initialization inside the ctor and the other programmer>
modifies the initialization at point of field declaration.
I like the idea. When thing like that happens, it's very likely a bug,
in fact, so issue a warning for this seems logical.


 What about fields in structs?  Can they have defaults? If structs could
 have even "compiler-generated" constructors, it'd be real nice.


Didn't found anything on this topic, so let's wait for the Guru's word =)
Nov 08 2001
parent "Walter" <walter digitalmars.com> writes:
"Pavel "EvilOne" Minayev" <evilone omen.ru> wrote in message news:9se608> >
What about fields in structs?  Can they have defaults? If structs could

 have even "compiler-generated" constructors, it'd be real nice.


 Didn't found anything on this topic, so let's wait for the Guru's word =)


<guru>
yes
</guru>
Nov 08 2001