www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - When is a slice not a slice?

reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
In CTFE it seems. Only tested with DMD on Windows though. Is this a 
known limitation, or a bug, I couldn't find anything that seemed to 
match it in the bugzilla.


import std.array;

struct DataAndView
{
	int[] data, view;

	this(int x)
	{
		data = [1, 2, 3, 4, 5];
		view = data[x .. $];
	}
}

unittest
{
	auto a = DataAndView(1);
	assert (sameTail(a.data, a.view));
	enum b = DataAndView(1);
	assert (!sameTail(b.data, b.view));
}
Jun 05 2014
next sibling parent reply Philippe Sigaud via Digitalmars-d-learn writes:
         enum b = DataAndView(1);
         assert (!sameTail(b.data, b.view));
I suppose it's because enums are manifest constants: the value they represent is 'copy-pasted' anew everywhere it appears in the code. So for arrays and associative arrays, it means recreating a new value each and every time. In your case, your code is equivalent to: assert (!sameTail(DataAndView(1).data,DataAndView(1).view)); And the two DataAndView(1), being completely separated, do not have the same tail.
Jun 05 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 05 Jun 2014 15:56:00 -0400, Philippe Sigaud via  
Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:

         enum b = DataAndView(1);
         assert (!sameTail(b.data, b.view));
I suppose it's because enums are manifest constants: the value they represent is 'copy-pasted' anew everywhere it appears in the code. So for arrays and associative arrays, it means recreating a new value each and every time. In your case, your code is equivalent to: assert (!sameTail(DataAndView(1).data,DataAndView(1).view)); And the two DataAndView(1), being completely separated, do not have the same tail.
Yes, this should work (and execute the initializer at compile time): static b = ... -Steve
Jun 05 2014
parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 05/06/2014 8:58 PM, Steven Schveighoffer wrote:
 On Thu, 05 Jun 2014 15:56:00 -0400, Philippe Sigaud via
 Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:

         enum b = DataAndView(1);
         assert (!sameTail(b.data, b.view));
I suppose it's because enums are manifest constants: the value they represent is 'copy-pasted' anew everywhere it appears in the code. So for arrays and associative arrays, it means recreating a new value each and every time. In your case, your code is equivalent to: assert (!sameTail(DataAndView(1).data,DataAndView(1).view)); And the two DataAndView(1), being completely separated, do not have the same tail.
Yes, this should work (and execute the initializer at compile time): static b = ... -Steve
Ah, the problem with static is that I want to use the values at compile time to create other values. Using static puts construction between compile time and run time. Initialising in static this means that the symbols need to be declared without initializers and that means not disabling default construction >< A...
Jun 06 2014
parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Friday, 6 June 2014 at 08:17:43 UTC, Alix Pexton wrote:
 On 05/06/2014 8:58 PM, Steven Schveighoffer wrote:
 On Thu, 05 Jun 2014 15:56:00 -0400, Philippe Sigaud via
 Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:

        enum b = DataAndView(1);
        assert (!sameTail(b.data, b.view));
I suppose it's because enums are manifest constants: the value they represent is 'copy-pasted' anew everywhere it appears in the code. So for arrays and associative arrays, it means recreating a new value each and every time. In your case, your code is equivalent to: assert (!sameTail(DataAndView(1).data,DataAndView(1).view)); And the two DataAndView(1), being completely separated, do not have the same tail.
Yes, this should work (and execute the initializer at compile time): static b = ... -Steve
Ah, the problem with static is that I want to use the values at compile time to create other values. Using static puts construction between compile time and run time. Initialising in static this means that the symbols need to be declared without initializers and that means not disabling default construction
<
A...
Immutables should be usable at compile time and not allocate a new instance on every use when in module scope.
Jun 06 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 06 Jun 2014 06:14:30 -0400, Rene Zwanenburg  
<renezwanenburg gmail.com> wrote:

 On Friday, 6 June 2014 at 08:17:43 UTC, Alix Pexton wrote:
 On 05/06/2014 8:58 PM, Steven Schveighoffer wrote:
 Yes, this should work (and execute the initializer at compile time):

 static b = ...
Ah, the problem with static is that I want to use the values at compile time to create other values. Using static puts construction between compile time and run time.
Not exactly (at least I don't think). The static initializer itself is generated at compile time. But the assignment to the static variable is done at run time.
 Initialising in static this means that the symbols need to be declared  
 without initializers and that means not disabling default construction
<
Immutables should be usable at compile time and not allocate a new instance on every use when in module scope.
I was about to say this. But immutable can have its own set of issues. If you want strictly compile-time generation of data, then immutable is the way to go. But if you want to use it at runtime as well, immutable can hamper some things. I'm sure your example is a very small or reduced snippet of what you are actually doing. -Steve
Jun 06 2014
next sibling parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 06/06/2014 7:39 PM, Steven Schveighoffer wrote:
 On Fri, 06 Jun 2014 06:14:30 -0400, Rene Zwanenburg
 <renezwanenburg gmail.com> wrote:

 Immutables should be usable at compile time and not allocate a new
 instance on every use when in module scope.
I was about to say this. But immutable can have its own set of issues. If you want strictly compile-time generation of data, then immutable is the way to go. But if you want to use it at runtime as well, immutable can hamper some things. I'm sure your example is a very small or reduced snippet of what you are actually doing. -Steve
I re-factored my actual code to not need the slices at all as no matter how I tried to use them at compile time it broke one of my invariants.I now have enums that I can use at compile time to generate more enums (via set operations, etc) and at runtime, so I'm happy. A...
Jun 07 2014
prev sibling parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 06/06/2014 7:39 PM, Steven Schveighoffer wrote:
 On Fri, 06 Jun 2014 06:14:30 -0400, Rene Zwanenburg
 <renezwanenburg gmail.com> wrote:
 Immutables should be usable at compile time and not allocate a new
 instance on every use when in module scope.
I was about to say this. But immutable can have its own set of issues. If you want strictly compile-time generation of data, then immutable is the way to go. But if you want to use it at runtime as well, immutable can hamper some things. I'm sure your example is a very small or reduced snippet of what you are actually doing. -Steve
Something I read in Adam's D Cookbook (somewhere in chapter 9) got me thinking that I am on the wrong track with the code I was talking about here. My new plan is to make the values that are currently passes to the structs' constructors into enums, then make the instances of the structs into static immutables. I'll need some factory methods in my struct but nothing to taxing. Thanks again for your advice.
Jun 16 2014
prev sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 05/06/2014 8:56 PM, Philippe Sigaud via Digitalmars-d-learn wrote:
          enum b = DataAndView(1);
          assert (!sameTail(b.data, b.view));
I suppose it's because enums are manifest constants: the value they represent is 'copy-pasted' anew everywhere it appears in the code. So for arrays and associative arrays, it means recreating a new value each and every time. In your case, your code is equivalent to: assert (!sameTail(DataAndView(1).data,DataAndView(1).view)); And the two DataAndView(1), being completely separated, do not have the same tail.
Ah, Isee, that does kinda make sense ^^ A re-factoring we go... A...
Jun 06 2014
parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 06/06/2014 8:52 AM, Alix Pexton wrote:

 And the two DataAndView(1), being completely separated, do not have
 the same tail.
Ah, Isee, that does kinda make sense ^^ A re-factoring we go...
However, the code that originally tripped over this issue had the call to sameTail in the struct's invariant, and I don't seem to be able to reproduce that with the obvious reduced code... Still, Thanks! A...
Jun 06 2014
prev sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 5 June 2014 at 19:45:59 UTC, Alix Pexton wrote:
 unittest
 {
 	auto a = DataAndView(1);
 	assert (sameTail(a.data, a.view));
 	enum b = DataAndView(1);
 	assert (!sameTail(b.data, b.view));
 }
Just a request of presentation. Please make expected assertions: enum b = DataAndView(1); assert (sameTail(b.data, b.view)); // fails Where the comment could be "fails" "compile error" "ice" "baby" It documents expectations, documents what went wrong, and provides a program which demonstrates the issue.
Jun 17 2014