Hi,

I have a question about Walter's DConf keynote and the Memory DisAllocation pattern.

http://dconf.org/2015/talks/bright.html

The following example is from the slides of Walter's talk.

----

auto toString(uint u) {
  static struct Result {
    this(uint u) {
      idx = buf.length;
      do {
        buf[--idx] = (u % 10) + '0';
        u /= 10;
      } while (u);
    }
    @property bool empty() { return idx == buf.length; }
    @property char front() { return buf[idx]; }
    void popFront() { ++idx; }
    char[uint.sizeof * 3] buf;
    size_t idx;
  }
  return Result(u);
}

import std.stdio;

void main() { writeln(toString(28)); }

----

My question is:

Does use of this pattern in D require that the size of the Result struct be known by the compiler at compile time?

Or, perhaps more precisely:  Does the caller of toString need to know the size of the struct that toString will return?

In the above example, buf's length is uint.sizeof * 3.  But what if buf's length was a function of u (and therefore only known at run-time), rather than a function of uint.sizeof?

Thanks!

-Parke

On 2015-06-26 22:45, Parke via Digitalmars-d wrote:
> Hi,
>
> I have a question about Walter's DConf keynote and the Memory
> DisAllocation pattern.
>
> http://dconf.org/2015/talks/bright.html
>
> The following example is from the slides of Walter's talk.
>
> ----
>
> auto toString(uint u) {
>    static struct Result {
>      this(uint u) {
>        idx = buf.length;
>        do {
>          buf[--idx] = (u % 10) + '0';
>          u /= 10;
>        } while (u);
>      }
>      @property bool empty() { return idx == buf.length; }
>      @property char front() { return buf[idx]; }
>      void popFront() { ++idx; }
>      char[uint.sizeof * 3] buf;
>      size_t idx;
>    }
>    return Result(u);
> }
>
> import std.stdio;
>
> void main() { writeln(toString(28)); }
>
> ----
>
> My question is:
>
> Does use of this pattern in D require that the size of the Result
> struct be known by the compiler at compile time?
>
> Or, perhaps more precisely:  Does the caller of toString need to know
> the size of the struct that toString will return?
>
> In the above example, buf's length is uint.sizeof * 3.  But what if
> buf's length was a function of u (and therefore only known at
> run-time), rather than a function of uint.sizeof?
>
> Thanks!
>
> -Parke
>

What you're asking for is probably type inference. Notice the auto return type? This keyword is actually very advanced and bleeding edge in natively compiled languages.

Internally, when the function is processed by the compiler, all types are evaluated before the instructions are even looked at, and the final size of all types are compiled and automatically put in place.

Afterwards, the instructions must obey consistency, ie. the caller can't use anything but auto or ReturnType!toString to accept an auto type because there's no way you can guess the mangling/size/etc otherwise.

This also means you can choose a ridiculous name or you can change the size of a stack allocated object any time without breaking an interface.

e.g. you could change this without breaking the API to something like:

auto toString(T)(T u) if (isNumeric!T) {
   static struct GenericResult {
     this(T u) {
       ...
    char[T.sizeof * 3] buf;
    ...
}

On Saturday, 27 June 2015 at 02:51:18 UTC, Parke wrote:

> In the above example, buf's length is uint.sizeof * 3.  But what if buf's length was a function of u (and therefore only known at run-time), rather than a function of uint.sizeof?

In this case you have two options:
1) do not store result in a buffer but calculate data in the range methods (front() and popFront())
2) allocate and give up this disallocation pattern

On Saturday, 27 June 2015 at 03:10:51 UTC, Etienne Cimon wrote:

> What you're asking for is probably type inference. Notice the auto return type? This keyword is actually very advanced and bleeding edge in natively compiled languages.

Inference of return type was in ML since 1973. Such bleeding, so edge. ;)

On 2015-06-27 01:06, thedeemon wrote:
> On Saturday, 27 June 2015 at 03:10:51 UTC, Etienne Cimon wrote:
>
>> What you're asking for is probably type inference. Notice the auto
>> return type? This keyword is actually very advanced and bleeding edge
>> in natively compiled languages.
>
> Inference of return type was in ML since 1973. Such bleeding, so edge. ;)

Is there some other natively compiled language that implemented the auto keyword before? Or are you only talking about the theory?

On Saturday, 27 June 2015 at 11:11:31 UTC, Etienne Cimon wrote:
> On 2015-06-27 01:06, thedeemon wrote:

>> Inference of return type was in ML since 1973. Such bleeding, so edge. ;)
>
> Is there some other natively compiled language that implemented the auto keyword before? Or are you only talking about the theory?

ML, SML, OCaml, Haskell, Idris - all of them natively compiled, all can infer return types as well as virtually all the other types.

They don't use "auto" keyword, of course, the syntax is different. You just write

let f x y = x + String.length y

and OCaml (in this case) compiler knows that x is int, y is string and return type is int.

On 6/26/2015 7:45 PM, Parke via Digitalmars-d wrote:
> Or, perhaps more precisely:  Does the caller of toString need to know
> the size of the struct that toString will return?

Yes.

> In the above example, buf's length is uint.sizeof * 3.  But what if
> buf's length was a function of u (and therefore only known at
> run-time), rather than a function of uint.sizeof?

In cases where the size cannot be known in advance, the returned struct can malloc/free the extra space.

On 6/27/15 3:24 PM, Walter Bright wrote:
> On 6/26/2015 7:45 PM, Parke via Digitalmars-d wrote:
>> Or, perhaps more precisely:  Does the caller of toString need to know
>> the size of the struct that toString will return?
>
> Yes.
>
>> In the above example, buf's length is uint.sizeof * 3.  But what if
>> buf's length was a function of u (and therefore only known at
>> run-time), rather than a function of uint.sizeof?
>
> In cases where the size cannot be known in advance, the returned struct
> can malloc/free the extra space.

Be careful with this. You need a reference counted type to do this properly (or make the result not copyable).

Also, malloced data is not scanned for pointers by the GC.

-Steve

On 6/30/2015 6:05 AM, Steven Schveighoffer wrote:
> Be careful with this. You need a reference counted type to do this properly (or
> make the result not copyable).

I presume the person doing such knows what he's doing. It's why malloc/free are @system code.