I'm currently trying to use D without a gc and didn't have major problems so far. A minor issues is that struct.toString() returns a string and this will almost allways leak memory when this is called.
The question now is, can I change the return type of struct.toString() somewhere inside druntime or is it hardcoded in the compiler?

It was possible without any problems to change the return type of Object.toString() and therefore every class in D because Object is the baseclass for every class. Is there something similar for structs?

Kind Regards
Benjamin Thaut

On 12/02/2012 18:36, Benjamin Thaut wrote:
> I'm currently trying to use D without a gc and didn't have major problems so far. A minor
> issues is that struct.toString() returns a string and this will almost allways leak memory
> when this is called.
> The question now is, can I change the return type of struct.toString() somewhere inside
> druntime or is it hardcoded in the compiler?
<snip>

If you create a struct, you can declare a method called toString with whatever return type you want.  Though it usually isn't a good idea.

What, exactly, are you planning to do with this non-string string representation of a struct?

Stewart.

On 02/13/2012 01:21 AM, Stewart Gordon wrote:
> On 12/02/2012 18:36, Benjamin Thaut wrote:
>> I'm currently trying to use D without a gc and didn't have major
>> problems so far. A minor
>> issues is that struct.toString() returns a string and this will almost
>> allways leak memory
>> when this is called.
>> The question now is, can I change the return type of struct.toString()
>> somewhere inside
>> druntime or is it hardcoded in the compiler?
> <snip>
>
> If you create a struct, you can declare a method called toString with
> whatever return type you want. Though it usually isn't a good idea.
>
> What, exactly, are you planning to do with this non-string string
> representation of a struct?
>
> Stewart.

I suppose he wants to use a custom string type with deterministic memory management.

On Sun, 12 Feb 2012 12:36:47 -0600, Benjamin Thaut <code@benjamin-thaut.de> wrote:
> I'm currently trying to use D without a gc and didn't have major
> problems so far. A minor issues is that struct.toString() returns a
> string and this will almost allways leak memory when this is called.
> The question now is, can I change the return type of struct.toString()
> somewhere inside druntime or is it hardcoded in the compiler?
>
> It was possible without any problems to change the return type of
> Object.toString() and therefore every class in D because Object is the
> baseclass for every class. Is there something similar for structs?
>
> Kind Regards
> Benjamin Thaut
>

The primary users of toString() methods (struct or otherwise) are in std.format and std.conv, IIRC. I'd imagine that you'd be able to catch most uses via a correctly placed static assert.

On 12.02.2012 19:36, Benjamin Thaut wrote:
> I'm currently trying to use D without a gc and didn't have major
> problems so far. A minor issues is that struct.toString() returns a
> string and this will almost allways leak memory when this is called.
> The question now is, can I change the return type of struct.toString()
> somewhere inside druntime or is it hardcoded in the compiler?
>
> It was possible without any problems to change the return type of
> Object.toString() and therefore every class in D because Object is the
> baseclass for every class. Is there something similar for structs?
>
> Kind Regards
> Benjamin Thaut

I don't know why struct toString() still exists. It's a legacy from the very beginning of D, back when the language didn't even have templates.
std.format doesn't even require it, any more.

Am 13.02.2012 03:21, schrieb Don:
> On 12.02.2012 19:36, Benjamin Thaut wrote:
>> I'm currently trying to use D without a gc and didn't have major
>> problems so far. A minor issues is that struct.toString() returns a
>> string and this will almost allways leak memory when this is called.
>> The question now is, can I change the return type of struct.toString()
>> somewhere inside druntime or is it hardcoded in the compiler?
>>
>> It was possible without any problems to change the return type of
>> Object.toString() and therefore every class in D because Object is the
>> baseclass for every class. Is there something similar for structs?
>>
>> Kind Regards
>> Benjamin Thaut
>
> I don't know why struct toString() still exists. It's a legacy from the
> very beginning of D, back when the language didn't even have templates.
> std.format doesn't even require it, any more.

Well TypeInfo_struct declarers a delegate for the xtostring member which returns a char[]. So I'm curiours if the compiler fills that member, and if it does any checking on the toString() method while doing so.

Basically I have 2 string types now:
1) string = garantueed to be either in static memory or to outlive every object that has a reference to it
2) rcstring = reference counted string (you have to use the most ugly casts you can think of to actually make reference counting possible with the D typesystem)

On 13/02/2012 02:21, Don wrote:
<snip>
> I don't know why struct toString() still exists.
<snip>

What are you talking about?  If you define a struct, it doesn't have any methods other than the ones you put into it.

Stewart.

Am 13.02.2012 13:26, schrieb Stewart Gordon:
> On 13/02/2012 02:21, Don wrote:
> <snip>
>> I don't know why struct toString() still exists.
> <snip>
>
> What are you talking about? If you define a struct, it doesn't have any
> methods other than the ones you put into it.
>
> Stewart.

import std.stdio;

struct fun
{
  string toString()
  {
    return "fun";
  }
}

void main(string[] args)
{
  auto ti = cast(TypeInfo_Struct)typeid(fun);
  fun gun;
  writefln("%d",cast(void*)ti.xtoString);
  writefln("%s",ti.xtoString(&gun));
}

If you change the return type of toString() to int for example the program will crash because ti.xtoString will be null. Therefore the compiler seems to check what type toString() does return and only fills the type info if it actually does return a string.

-- 
Kind Regards
Benjamin Thaut

On Mon, 13 Feb 2012 08:40:20 -0500, Benjamin Thaut <code@benjamin-thaut.de> wrote:

> Am 13.02.2012 13:26, schrieb Stewart Gordon:
>> On 13/02/2012 02:21, Don wrote:
>> <snip>
>>> I don't know why struct toString() still exists.
>> <snip>
>>
>> What are you talking about? If you define a struct, it doesn't have any
>> methods other than the ones you put into it.
>>
>> Stewart.
>
> import std.stdio;
>
> struct fun
> {
>    string toString()
>    {
>      return "fun";
>    }
> }
>
> void main(string[] args)
> {
>    auto ti = cast(TypeInfo_Struct)typeid(fun);
>    fun gun;
>    writefln("%d",cast(void*)ti.xtoString);
>    writefln("%s",ti.xtoString(&gun));
> }
>
> If you change the return type of toString() to int for example the program will crash because ti.xtoString will be null. Therefore the compiler seems to check what type toString() does return and only fills the type info if it actually does return a string.

That is a legacy feature, back when writefln was a D variadic function (not a template), and all you had was the TypeInfo.

It's essentially a hack that the compiler puts several "special" function pointers into the typeinfo to give structs a sort of runtime interface.  I think we can get rid of most, if not all, of those x-functions.  But then we need to get rid of all the usages of those.  It shouldn't be too difficult at this point, it just needs to be done.

-Steve

Am 13.02.2012 15:23, schrieb Steven Schveighoffer:
> On Mon, 13 Feb 2012 08:40:20 -0500, Benjamin Thaut
> <code@benjamin-thaut.de> wrote:
>
>> Am 13.02.2012 13:26, schrieb Stewart Gordon:
>>> On 13/02/2012 02:21, Don wrote:
>>> <snip>
>>>> I don't know why struct toString() still exists.
>>> <snip>
>>>
>>> What are you talking about? If you define a struct, it doesn't have any
>>> methods other than the ones you put into it.
>>>
>>> Stewart.
>>
>> import std.stdio;
>>
>> struct fun
>> {
>> string toString()
>> {
>> return "fun";
>> }
>> }
>>
>> void main(string[] args)
>> {
>> auto ti = cast(TypeInfo_Struct)typeid(fun);
>> fun gun;
>> writefln("%d",cast(void*)ti.xtoString);
>> writefln("%s",ti.xtoString(&gun));
>> }
>>
>> If you change the return type of toString() to int for example the
>> program will crash because ti.xtoString will be null. Therefore the
>> compiler seems to check what type toString() does return and only
>> fills the type info if it actually does return a string.
>
> That is a legacy feature, back when writefln was a D variadic function
> (not a template), and all you had was the TypeInfo.
>
> It's essentially a hack that the compiler puts several "special"
> function pointers into the typeinfo to give structs a sort of runtime
> interface. I think we can get rid of most, if not all, of those
> x-functions. But then we need to get rid of all the usages of those. It
> shouldn't be too difficult at this point, it just needs to be done.
>
> -Steve

So you want every format like function to be a template instead of a variadic function? I actually found it pretty nice that printing structs is possible without templates. I don't want to imagine how big the code bload would be if you actually make format a template instead of a variadic function.

-- 
Kind Regards
Benjamin Thaut