On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg wrote:
>
> Very impressive :)

Thanks.

I just got the following code to compile and execute correctly.

bool strEq(string a, string b)
{
    if (a.length != b.length)
    {
        return false;
    }
    uint length = cast(uint) a.length;

    while(length--)
    {
        auto c1 = a[length];
        auto c2 = b[length];
        if (c1 != c2)
        {
            return false;
        }
    }

    return true;
}

static assert(!strEq("Hello","World"));
static assert(strEq("World","World"));

I used the generated bytecode to make == for strings work.

On Wednesday, 26 October 2016 at 03:58:05 UTC, Stefam Koch wrote:
> On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg wrote:
>>
>> Very impressive :)
>
> Thanks.
>
> I just got the following code to compile and execute correctly.
>
> bool strEq(string a, string b)
> {
>     if (a.length != b.length)
>     {
>         return false;
>     }
>     uint length = cast(uint) a.length;
>
>     while(length--)
>     {
>         auto c1 = a[length];
>         auto c2 = b[length];
>         if (c1 != c2)
>         {
>             return false;
>         }
>     }
>
>     return true;
> }
>
> static assert(!strEq("Hello","World"));
> static assert(strEq("World","World"));
>
> I used the generated bytecode to make == for strings work.

Why did you cast size_t to uint in this example?

On Wednesday, 26 October 2016 at 08:19:46 UTC, Andrea Fontana wrote:
> On Wednesday, 26 October 2016 at 03:58:05 UTC, Stefam Koch wrote:
>> On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg wrote:
>>>
>>> Very impressive :)
>>
>> Thanks.
>>
>> I just got the following code to compile and execute correctly.
>>
>> bool strEq(string a, string b)
>> {
>>     if (a.length != b.length)
>>     {
>>         return false;
>>     }
>>     uint length = cast(uint) a.length;
>>
>>     while(length--)
>>     {
>>         auto c1 = a[length];
>>         auto c2 = b[length];
>>         if (c1 != c2)
>>         {
>>             return false;
>>         }
>>     }
>>
>>     return true;
>> }
>>
>> static assert(!strEq("Hello","World"));
>> static assert(strEq("World","World"));
>>
>> I used the generated bytecode to make == for strings work.
>
> Why did you cast size_t to uint in this example?

Currently I am limited to 32bit Arithmetic.
Changing this is on the Table but I have not gotten to it yet.

Who can guess what this code does ?


char[] obfuscatedFn(string a, string b, uint aLength = 0, uint bLength = 0, uint cLength = 0, uint pos = 0, uint bPos = 0, char[] result = [])
{
    aLength = cast(uint)a.length;
    bLength = cast(uint)a.length;
    cLength = aLength + bLength;
    result.length = cLength;
    while(aLength--)
    {
        result[pos] = a[pos];
        ++pos;
    }
    while(bLength--)
    {
        result[pos] = b[bPos++];
        ++pos;
    }

    return result;
}

On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote:
>     bLength = cast(uint)a.length;

Reads past the end of b if b is shorter than a.

On Wednesday, 26 October 2016 at 15:38:30 UTC, Kagamin wrote:
> On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote:
>>     bLength = cast(uint)a.length;
>
> Reads past the end of b if b is shorter than a.

you are right.
Thanks for spotting it :)

On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote:
> Who can guess what this code does ?
>
>
> char[] obfuscatedFn(string a, string b, uint aLength = 0, uint bLength = 0, uint cLength = 0, uint pos = 0, uint bPos = 0, char[] result = [])
> {
>     aLength = cast(uint)a.length;
>     bLength = cast(uint)a.length;
>     cLength = aLength + bLength;
>     result.length = cLength;
>     while(aLength--)
>     {
>         result[pos] = a[pos];
>         ++pos;
>     }
>     while(bLength--)
>     {
>         result[pos] = b[bPos++];
>         ++pos;
>     }
>
>     return result;
> }

Shouldn't
> cLength = aLength + bLength;

actually be
> cLength = aLength + bLength + pos;
?
Otherwise when pos is > 0 it writes past the end of result.

Same problem in the first and second loop, where the legths should probably be

>     aLength = cast(uint)a.length - pos;
>     bLength = cast(uint)a.length - bPos;

If you fix the a and b Length then cLength is fine.

Or am I missing something?

On Wednesday, 26 October 2016 at 16:24:49 UTC, MakersF wrote:
> On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote:
>> Who can guess what this code does ?
>>
>>
>> char[] obfuscatedFn(string a, string b, uint aLength = 0, uint bLength = 0, uint cLength = 0, uint pos = 0, uint bPos = 0, char[] result = [])
>> {
>>     aLength = cast(uint)a.length;
>>     bLength = cast(uint)a.length;
>>     cLength = aLength + bLength;
>>     result.length = cLength;
>>     while(aLength--)
>>     {
>>         result[pos] = a[pos];
>>         ++pos;
>>     }
>>     while(bLength--)
>>     {
>>         result[pos] = b[bPos++];
>>         ++pos;
>>     }
>>
>>     return result;
>> }
>
> Shouldn't
>> cLength = aLength + bLength;
>
> actually be
>> cLength = aLength + bLength + pos;
> ?
> Otherwise when pos is > 0 it writes past the end of result.
>
> Same problem in the first and second loop, where the legths should probably be
>
>>     aLength = cast(uint)a.length - pos;
>>     bLength = cast(uint)a.length - bPos;
>
> If you fix the a and b Length then cLength is fine.
>
> Or am I missing something?

Ah the default paramters are never touched.
The reason they are there is because of the way the ctfe engine lowers parameters.
It's easier to create byte-code macros if all used variables are function paramters :)

Another update on CTFE.

I have found a few errors in my handling of switch-statments.
An efficient solution for this is still pending,

Futhermore I have begun to work on ctfe handling refernces.
These are a little bit harder to do in bytecode and do pessimise performance if overused.

I hope to make another leap at the end of this month.

We should have string Concat-support fairly soon.

Cheers,
stefan

On Friday, 28 October 2016 at 16:52:46 UTC, Stefan Koch wrote:
> Another update on CTFE.
>
> I have found a few errors in my handling of switch-statments.
> An efficient solution for this is still pending,
>
> Futhermore I have begun to work on ctfe handling refernces.
> These are a little bit harder to do in bytecode and do pessimise performance if overused.
>
> I hope to make another leap at the end of this month.
>
> We should have string Concat-support fairly soon.
>
> Cheers,
> stefan

I just made progress on another fundamental feature,
function call support.

It's does not work yet, but it shows promise.