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