May 17, 2016
On 05/17/2016 08:53 AM, Alex wrote:
> the elements of the slice are accessible just for reading, right, but
> with them I reference the data in other objects.

If the slice's pointer is invalid, then its elements are not accessible at all.
May 17, 2016
On 05/17/2016 10:16 AM, Rene Zwanenburg wrote:
> Additionally, some people recommend never using -release. It depends on
> that type of program you're writing, but the performance gain is often
> not worth the loss in safety. Think of the number of exploits enabled by
> C's lack of bounds checking.

Some more details on this: -release doesn't affect bounds checking in @safe code. It will still be done there. There is another switch that disables bounds checks even in @safe code: -boundscheck=off
May 17, 2016
On 05/17/2016 12:53 PM, Alex wrote:
> 2. If I want to be able to slice a iota, I have to initialize it with
> the last number. But the object, which stores the pointer does not need
> to know anything about this number. So, I rather would not like to pass
> this number only for being able to instantiate the iota struct.

How do you make a slice without the last number? You need two numbers for iota, and you need two numbers for a slice.
May 17, 2016
On Tuesday, 17 May 2016 at 12:24:58 UTC, ag0aep6g wrote:
> On 05/17/2016 12:53 PM, Alex wrote:
>> 2. If I want to be able to slice a iota, I have to initialize it with
>> the last number. But the object, which stores the pointer does not need
>> to know anything about this number. So, I rather would not like to pass
>> this number only for being able to instantiate the iota struct.
>
> How do you make a slice without the last number? You need two numbers for iota, and you need two numbers for a slice.

For a slice I surely need two numbers. But this should all be, what I need for a slice. For a iota, I need a maximum, which is not provided (at least at this moment) to the object containing the pointer/iota thing.
On the other hand, I can't live without a "real" object which I slice, so I need either a iota or a pointer. This is due that all the slices I have are totally ordered.
May 17, 2016
On 05/17/2016 03:14 PM, Alex wrote:
> For a slice I surely need two numbers. But this should all be, what I
> need for a slice. For a iota, I need a maximum, which is not provided
> (at least at this moment) to the object containing the pointer/iota thing.

The slice's length is practically the same as iota's maximum. For slicing a pointer you need the minimum and the maximum, just as with iota. I don't see the difference.

ptr[5 .. 10] vs iota(5, 10) - Surely you need the number 10 in both cases?
May 17, 2016
On Tuesday, 17 May 2016 at 13:25:34 UTC, ag0aep6g wrote:
> On 05/17/2016 03:14 PM, Alex wrote:
>> For a slice I surely need two numbers. But this should all be, what I
>> need for a slice. For a iota, I need a maximum, which is not provided
>> (at least at this moment) to the object containing the pointer/iota thing.
>
> The slice's length is practically the same as iota's maximum. For slicing a pointer you need the minimum and the maximum, just as with iota. I don't see the difference.
>
> ptr[5 .. 10] vs iota(5, 10) - Surely you need the number 10 in both cases?

Ok cool, maybe I oversee something myself. But let think in an example:
There are some objects which make slices. How they make a slice is unimportant here, so it makes either ptr[5 .. 10] or iota(5, 10).
But, if the slicing is made by means of iota, there is no (at least no explicit) dependence between the slices, which could be made by different objects.
I'm ready to admit, that the process will work with independent slicing... In this case, I can omit my void* at all. So, the objects, which make slices, don't do this from some object, they do this just by calling iota. But this is little bit contra intuitive, as I imply a relationship between the sliced parts.
So... at the end of the day this implication exists in my head only...
May 17, 2016
On 05/17/2016 05:33 PM, Alex wrote:
> But, if the slicing is made by means of iota, there is no (at least no
> explicit) dependence between the slices, which could be made by
> different objects.

How is this dependency expressed with slices?

> I'm ready to admit, that the process will work with independent
> slicing... In this case, I can omit my void* at all. So, the objects,
> which make slices, don't do this from some object, they do this just by
> calling iota. But this is little bit contra intuitive, as I imply a
> relationship between the sliced parts.

I'm not sure if I understand.

Is the object the void pointer of the slice? If so, you start the slicing from a null pointer, right? There is no real relationship or dependency between the slices then.

Or is the object some class/struct instance that creates a slice? If so, how does it leave a reference to itself in the slice?

> So... at the end of the day this implication exists in my head only...

May 17, 2016
On Tuesday, 17 May 2016 at 17:25:48 UTC, ag0aep6g wrote:
> On 05/17/2016 05:33 PM, Alex wrote:
>> But, if the slicing is made by means of iota, there is no (at least no
>> explicit) dependence between the slices, which could be made by
>> different objects.
>
> How is this dependency expressed with slices?

By using the single source of slicing, which is the void* or a pre-instantiated iota with the maximum number.

>
>> I'm ready to admit, that the process will work with independent
>> slicing... In this case, I can omit my void* at all. So, the objects,
>> which make slices, don't do this from some object, they do this just by
>> calling iota. But this is little bit contra intuitive, as I imply a
>> relationship between the sliced parts.
>
> I'm not sure if I understand.
>
> Is the object the void pointer of the slice? If so, you start the slicing from a null pointer, right? There is no real relationship or dependency between the slices then.
>
> Or is the object some class/struct instance that creates a slice? If so, how does it leave a reference to itself in the slice?

Here, I'm not sure if I understand the question.
The relation is: some object A contains the pointer/iota/(if at all)
some object B makes slices of the thing, which is in A.
May 17, 2016
On 05/17/2016 07:43 PM, Alex wrote:
> The relation is: some object A contains the pointer/iota/(if at all)
> some object B makes slices of the thing, which is in A.

Ok, so you have some object that stores a void pointer. The pointer is going to be null at all times. Then you slice that pointer. Is that right?

In code:
----
class C
{
    void* ptr = null; /* always going to stay null */
    void[] getSlice(size_t a, size_t b) { return ptr[a .. b]; }
}

void main()
{
    auto c = new C;
    void[] slice1 = c.getSlice(5, 10);
    void[] slice2 = c.getSlice(7, 21);
}
----

Now you see a relation/dependency between slice1 and slice2, because the pointer they slice is the same, and it's stored in the same C object, right?

But when slicing a pointer what matters is the value of the pointer, not where it resides. Where the pointer is stored is completely irrelevant. Like when adding two ints it doesn't matter where they came from; only their values matter.

Calling getSlice(5, 10) on two different C objects will return the exactly same slice (as long as ptr stays null):

----
/* ... class C as above ... */

void main()
{
    auto c1 = new C;
    auto c2 = new C;
    assert(c1 !is c2); /* not the same object */
    assert(c1.getSlice(5, 10) is c2.getSlice(5, 10)); /* but the exact same slice */
}
----

There is no relationship between the slices or between a slice and the object that created it. You can have a free function that returns the exact same slices again:

----
/* ... class C as above */

void[] freeGetSlice(size_t a, size_t b)
{
    void* ptr = null;
    return ptr[a .. b];
}

void main()
{
    auto c = new C;
    assert(c.getSlice(5, 10) is freeGetSlice(5, 10));
}
----

A note on iota: If you use iota instead, you don't need to store the result in the object either. You can call iota on the spot just like you call getSlice.
May 17, 2016
On Tuesday, 17 May 2016 at 18:25:46 UTC, ag0aep6g wrote:
> On 05/17/2016 07:43 PM, Alex wrote:
>> The relation is: some object A contains the pointer/iota/(if at all)
>> some object B makes slices of the thing, which is in A.
>
> Ok, so you have some object that stores a void pointer. The pointer is going to be null at all times. Then you slice that pointer. Is that right?
Yes.
>
> In code:
> ----
> class C
> {
>     void* ptr = null; /* always going to stay null */
>     void[] getSlice(size_t a, size_t b) { return ptr[a .. b]; }
> }
>
> void main()
> {
>     auto c = new C;
>     void[] slice1 = c.getSlice(5, 10);
>     void[] slice2 = c.getSlice(7, 21);
> }
> ----
>
> Now you see a relation/dependency between slice1 and slice2, because the pointer they slice is the same, and it's stored in the same C object, right?
Yes.
>
> But when slicing a pointer what matters is the value of the pointer, not where it resides. Where the pointer is stored is completely irrelevant. Like when adding two ints it doesn't matter where they came from; only their values matter.
>
> Calling getSlice(5, 10) on two different C objects will return the exactly same slice (as long as ptr stays null):

Yes. This is the point where my error in reasoning resides...
>
> ----
> /* ... class C as above ... */
>
> void main()
> {
>     auto c1 = new C;
>     auto c2 = new C;
>     assert(c1 !is c2); /* not the same object */
>     assert(c1.getSlice(5, 10) is c2.getSlice(5, 10)); /* but the exact same slice */
> }
> ----
>
> There is no relationship between the slices or between a slice and the object that created it. You can have a free function that returns the exact same slices again:
>
> ----
> /* ... class C as above */
>
> void[] freeGetSlice(size_t a, size_t b)
> {
>     void* ptr = null;
>     return ptr[a .. b];
> }
>
> void main()
> {
>     auto c = new C;
>     assert(c.getSlice(5, 10) is freeGetSlice(5, 10));
> }
> ----
Yeah... now I see this...
>
> A note on iota: If you use iota instead, you don't need to store the result in the object either. You can call iota on the spot just like you call getSlice.

Thanks for disillusioning :)
1 2 3
Next ›   Last »