www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to check if an array is a manifest constant?

reply simendsjo <simen.endsjo pandavre.com> writes:
The behavior for manifest constant arrays is different from regular arrays and
const/immutable
arrays. The problem is that typeof() returns T[]. How can I see if the array is
a manifest
constant?


	void g(int[] x) { }

	const c = [1,2,3];
	static assert(is(typeof(c) == const(int[])));
	// cannot convert const(int[]) to int[]
	static assert(!__traits(compiles, g(c)));
	auto carr = c;
	static assert(is(typeof(carr) == const(int[])));
	assert(carr.ptr == c.ptr); // referenced

	immutable i = [1,2,3];
	static assert(is(typeof(i) == immutable(int[])));
	// cannot convert immutable(int[]) to int[]
	static assert(!__traits(compiles, g(i)));
	auto iarr = i;
	static assert(is(typeof(iarr) == immutable(int[])));
	assert(iarr.ptr == i.ptr); // referenced

	enum e = [1,2,3];
	// e is reported as int[] even if it's an enum
	static assert(is(typeof(e) == int[]));
	//static assert(is(typeof(e) == enum)); // not an enum (as expected)
	// it can be passed to funtions taking dynamic arrays
	void f(int[] x) {
		assert(e.ptr != x.ptr); // then the content is copied
	}
	f(e);
	// the behavior is different from other assignments
	// as the content is copied
	auto earr = e;
	assert(earr.ptr != e.ptr); // content is copied
Apr 03 2011
next sibling parent =?UTF-8?B?QWxla3NhbmRhciBSdcW+acSNacSH?= <ruzicic.aleksandar gmail.com> writes:
As far as I understand, manifest constants and enums only share the
same keyword (enum) and are completely different things.
Enumerations (like enum A { a,b, c}) define new type, while manifest
constants (like enum N =3D 42;) are just constant values with type
inferred from value (unless specified after enum keyword).

On Sun, Apr 3, 2011 at 5:29 PM, simendsjo <simen.endsjo pandavre.com> wrote=
:
 The behavior for manifest constant arrays is different from regular array=

 arrays. The problem is that typeof() returns T[]. How can I see if the ar=

 constant?


 =C2=A0 =C2=A0 =C2=A0 =C2=A0void g(int[] x) { }

 =C2=A0 =C2=A0 =C2=A0 =C2=A0const c =3D [1,2,3];
 =C2=A0 =C2=A0 =C2=A0 =C2=A0static assert(is(typeof(c) =3D=3D const(int[])=

 =C2=A0 =C2=A0 =C2=A0 =C2=A0// cannot convert const(int[]) to int[]
 =C2=A0 =C2=A0 =C2=A0 =C2=A0static assert(!__traits(compiles, g(c)));
 =C2=A0 =C2=A0 =C2=A0 =C2=A0auto carr =3D c;
 =C2=A0 =C2=A0 =C2=A0 =C2=A0static assert(is(typeof(carr) =3D=3D const(int=

 =C2=A0 =C2=A0 =C2=A0 =C2=A0assert(carr.ptr =3D=3D c.ptr); // referenced

 =C2=A0 =C2=A0 =C2=A0 =C2=A0immutable i =3D [1,2,3];
 =C2=A0 =C2=A0 =C2=A0 =C2=A0static assert(is(typeof(i) =3D=3D immutable(in=

 =C2=A0 =C2=A0 =C2=A0 =C2=A0// cannot convert immutable(int[]) to int[]
 =C2=A0 =C2=A0 =C2=A0 =C2=A0static assert(!__traits(compiles, g(i)));
 =C2=A0 =C2=A0 =C2=A0 =C2=A0auto iarr =3D i;
 =C2=A0 =C2=A0 =C2=A0 =C2=A0static assert(is(typeof(iarr) =3D=3D immutable=

 =C2=A0 =C2=A0 =C2=A0 =C2=A0assert(iarr.ptr =3D=3D i.ptr); // referenced

 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum e =3D [1,2,3];
 =C2=A0 =C2=A0 =C2=A0 =C2=A0// e is reported as int[] even if it's an enum
 =C2=A0 =C2=A0 =C2=A0 =C2=A0static assert(is(typeof(e) =3D=3D int[]));
 =C2=A0 =C2=A0 =C2=A0 =C2=A0//static assert(is(typeof(e) =3D=3D enum)); //=

 =C2=A0 =C2=A0 =C2=A0 =C2=A0// it can be passed to funtions taking dynamic=

 =C2=A0 =C2=A0 =C2=A0 =C2=A0void f(int[] x) {
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assert(e.ptr !=3D =

 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
 =C2=A0 =C2=A0 =C2=A0 =C2=A0f(e);
 =C2=A0 =C2=A0 =C2=A0 =C2=A0// the behavior is different from other assign=

 =C2=A0 =C2=A0 =C2=A0 =C2=A0// as the content is copied
 =C2=A0 =C2=A0 =C2=A0 =C2=A0auto earr =3D e;
 =C2=A0 =C2=A0 =C2=A0 =C2=A0assert(earr.ptr !=3D e.ptr); // content is cop=


Apr 03 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-04-03 08:29, simendsjo wrote:
 The behavior for manifest constant arrays is different from regular arrays
 and const/immutable arrays. The problem is that typeof() returns T[]. How
 can I see if the array is a manifest constant?
 
 
 	void g(int[] x) { }
 
 	const c = [1,2,3];
 	static assert(is(typeof(c) == const(int[])));
 	// cannot convert const(int[]) to int[]
 	static assert(!__traits(compiles, g(c)));
 	auto carr = c;
 	static assert(is(typeof(carr) == const(int[])));
 	assert(carr.ptr == c.ptr); // referenced
 
 	immutable i = [1,2,3];
 	static assert(is(typeof(i) == immutable(int[])));
 	// cannot convert immutable(int[]) to int[]
 	static assert(!__traits(compiles, g(i)));
 	auto iarr = i;
 	static assert(is(typeof(iarr) == immutable(int[])));
 	assert(iarr.ptr == i.ptr); // referenced
 
 	enum e = [1,2,3];
 	// e is reported as int[] even if it's an enum
 	static assert(is(typeof(e) == int[]));
 	//static assert(is(typeof(e) == enum)); // not an enum (as expected)
 	// it can be passed to funtions taking dynamic arrays
 	void f(int[] x) {
 		assert(e.ptr != x.ptr); // then the content is copied
 	}
 	f(e);
 	// the behavior is different from other assignments
 	// as the content is copied
 	auto earr = e;
 	assert(earr.ptr != e.ptr); // content is copied

There should be _no_ difference between arrays which are manifest constants and regular arrays which are immutable except that they're computed at compile time. However, there is currently a bug in CTFE which makes it so that an array is copied _every_ time that it is accessed in CTFE (which, among other things, causes a massive memory leak). I don't remember what the bug report is for it, but Don is currently overhauling CTFE so that this won't be the case anymore. So, this _should_ be fixed by the next release. But there should be no need to worry about whether something is a manifest constant or not. If there is, you're either doing something funny/wrong, or it's because of a bug like the one that Don is fixing. - Jonathan M Davis
Apr 03 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 But there should be no need to worry about whether something is a manifest 
 constant or not.

I'd like in DMD a way to know if something is a compile-time constant. There is a GCC extension that sometimes is able to do it, named __builtin_constant_p: http://www.delorie.com/gnu/docs/gcc/gcc_81.html#IDX629 Bye, bearophile
Apr 03 2011
prev sibling parent reply simendsjo <simen.endsjo pandavre.com> writes:
But there is a difference in how they behave, and I have no way of checking
this behavior.
Consider the following little snippet:

void f(int[] a) {
    a[0] = -1;
}

void main() {
    int[] a = [1,2,3];
    static assert(is(typeof(a) == int[]));
    f(a);
    assert(a[0] == -1); // a passed by reference, a[0] changed

    enum b = [1,2,3];
    static assert(is(typeof(b) == int[])); // a regular int[] you say?
    f(b);
    assert(b[0] == -1); // b passed by value, b[0] unchanged
}
Apr 04 2011
parent simendsjo <simen.endsjo pandavre.com> writes:
 What use case do you have for wanting to know whether a variable is an enum or
not?

The same reason I'd like to check if it's const/immutable; if an algorithm requires a modifiable array. void sortInPlace(int[] array) { array.sort; } void main() { int[] a = [3,2,1]; sortInPlace(a); assert(a == [1,2,3]); auto i = [3,2,1].idup; //sortInPlace(i); // Fails at compile time enum e = [3,2,1]; sortInPlace(e); assert(e == [1,2,3]); // fails at runtime } I can check the type for const or immutable with template constraits or static if's, but I cannot check for enum. I can use ref int[] as a parameter to get a compile time error, but that's misleading as I often don't want to reassign the parameter. Cannot the type of enum e = [1] be immutable(int[])? Or is that wrong? Or am I missing something crucial because of CTFE or other stuff? I've just started looking into D2, so theres a good possibility my reasoning is wrong.
Apr 04 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-04-03 11:03, Aleksandar Ru=C5=BEi=C4=8Di=C4=87 wrote:
 As far as I understand, manifest constants and enums only share the
 same keyword (enum) and are completely different things.
 Enumerations (like enum A { a,b, c}) define new type, while manifest
 constants (like enum N =3D 42;) are just constant values with type
 inferred from value (unless specified after enum keyword).

They're the same and they're not. A named enum creates a new type of sorts = and=20 namespaces the values in it, whereas a manifest constant does not create a = new=20 type and its values (be it one or many) go directly in the namespace that i= t's=20 declared in. But even a named enum doesn't exactly create a new type. It's= =20 really its base type everywhere it's used, but extra restrictions are put o= n=20 it to help ensure that only valid values are used with it. For example, wit= h=20 std.datetime.Month, you either have to use Month.jan, Month.feb, etc. or ca= st=20 an integral value to a Month - e.g. cast(Month)12. However, it's still only= a=20 ubyte when it's compiled in, because Month is an enum of the type ubyte. So, manifest constants and named enums are not quite the same thing, but=20 they're not drastically differente either. Their values act essentially the= =20 same way. They're just referenced differently, and you can refer to the nam= e=20 of a named enum, using it as a type, whereas there is no name for a manifes= t=20 constant. Their values are pretty much identical when they're used though. =2D Jonathan M Davis
Apr 03 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-04-03 17:25, bearophile wrote:
 Jonathan M Davis:
 But there should be no need to worry about whether something is a
 manifest constant or not.

I'd like in DMD a way to know if something is a compile-time constant. There is a GCC extension that sometimes is able to do it, named __builtin_constant_p: http://www.delorie.com/gnu/docs/gcc/gcc_81.html#IDX629

To what end? Why would you care? It matters whether a value is mutable, const, or immutable, but what does it matter if it was calculated at compile time or not? Unless it's a property, it's definitely going to have been calculated before you use it. The only reason that I see that it matters at the moment is due to bugs in dmd. Once those are fixed, it should be irrelevant. - Jonathan M Davis
Apr 03 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-04-04 01:16, simendsjo wrote:
 But there is a difference in how they behave, and I have no way of checking
 this behavior. Consider the following little snippet:
 
 void f(int[] a) {
     a[0] = -1;
 }
 
 void main() {
     int[] a = [1,2,3];
     static assert(is(typeof(a) == int[]));
     f(a);
     assert(a[0] == -1); // a passed by reference, a[0] changed
 
     enum b = [1,2,3];
     static assert(is(typeof(b) == int[])); // a regular int[] you say?
     f(b);
     assert(b[0] == -1); // b passed by value, b[0] unchanged
 }

Okay. I just re-read the appropriate section in TDPL, and it's clear from the book that it's definitely intended that a new copy of the enum value be created every time that it's used (I was under the impression that that was buggy behavior, but apparently that's not true - though the fact that accessing any array during CTFE results in a copy of that array _is_ buggy behavior and should be fixed by Don before the next release). Regardless of that, however, enum values shouldn't be used in any place where they're going to be altered. So, passing such a value to a function which is intended to alter the value that it's passed to is just plain a bug on the part of the caller. It shouldn't matter to the function being called. That being the case, I don't see why you would need to determine whether a value that you're dealing with is an enum or not using template constraints or static if or whatnot. You should know whether the variable that you're using is an enum or not. If it is, don't alter it until you've set it to a variable - then you alter the variable. What use case do you have for wanting to know whether a variable is an enum or not? - Jonathan M Davis
Apr 04 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-04-04 03:11, simendsjo wrote:
 What use case do you have for wanting to know whether a variable is an
 enum or not?

The same reason I'd like to check if it's const/immutable; if an algorithm requires a modifiable array. void sortInPlace(int[] array) { array.sort; } void main() { int[] a = [3,2,1]; sortInPlace(a); assert(a == [1,2,3]); auto i = [3,2,1].idup; //sortInPlace(i); // Fails at compile time enum e = [3,2,1]; sortInPlace(e); assert(e == [1,2,3]); // fails at runtime } I can check the type for const or immutable with template constraits or static if's, but I cannot check for enum. I can use ref int[] as a parameter to get a compile time error, but that's misleading as I often don't want to reassign the parameter. Cannot the type of enum e = [1] be immutable(int[])? Or is that wrong? Or am I missing something crucial because of CTFE or other stuff? I've just started looking into D2, so theres a good possibility my reasoning is wrong.

Apparently, part of the point of using enums is to have them be replaced with the value without having any kind of address. So, they're _supposed_ to be a copy and therefore don't have to be const or immutable. Generally, it should be clear whether a function alters its arguments or not. You can't use const or immutable arrays with a function which alters its array argument or the elements of its array argument, because the array itself can't be altered. In the case of enums, it _can_ be altered, because when you use it, you get a copy. It literally copies and pastes the value of the enum where you use it. So, there's _nothing_ wrong with passing an enum which is an array to a function which alters the elements of its array argument. It's perfectly legal. It's just generally a bad idea, since it's a temporary. There's no need to check whether a function's argument is an enum anymore than there's a need to check whether the argument is a temporary. Both are perfectly legal, just generally pointless. If a slice of the array is returned or saved in a global variable or whatnot, then it's not pointless. But if it's just altering the function's argument, then it is. But the function doesn't need to worry about it. It's still perfectly legal. It's up to the caller to actually pass an array that's worth altering. And since the function should be clear on whether it alters its arguments, it shouldn't be a problem that it's up to the caller to use it correctly with regards to temporaries and enums - just like it's up to the caller not to be stupid and pass any other array that it doesn't actually want to alter. So, really there's no reason to stop an enum from working with a function that alters the elements of an array. All temporaries have the same issue. If you really want to prevent it, then just make the argument a ref. It also makes it clear that you're altering the array. If you don't want to make it a ref, then just make the documentation clear, and it's up to the caller to use the function appropriately. For instance, it should be obvious to the caller that passing an enum to a function like sortInPlace would be just stupid. - Jonathan M Davis
Apr 04 2011