Am 06.01.2013 13:23, schrieb Jacob Carlborg:
> On 2013-01-06 13:19, Benjamin Thaut wrote:
>
>> Here is the full implementation if you are interested:
>> https://github.com/Ingrater/druntime/blob/master/src/rtti.d
>
> Thanks. Is that possible to do without having to modify the runtime?
>

No. The template has to be known inside of object_.d/object.di so it is not possible without modifing the runtime. Also you usually want to have RTTI info for druntime/phobos too.

Am Sun, 06 Jan 2013 13:14:39 +0100
schrieb David <d@dav1d.de>:

> > I guess when we have custom allocators we can also provide toString methods templated on allocators.
> > 
> 
> Custom allocators released together with HL3?

A lot of things are blocked by custom allocators and this is indeed an issue. It wouldn't make much sense to redefine toString without custom allocators though.

BTW: I guess the Duke Nukem Forever joke doesn't work anyore ;-)

06-Jan-2013 14:37, Benjamin Thaut пишет:
> Am 05.01.2013 05:24, schrieb ixid:
>> On Monday, 31 December 2012 at 14:40:48 UTC, Benjamin Thaut wrote:
>>> Am 31.12.2012 15:02, schrieb DypthroposTheImposter:
>>>>   Do you find that D without GC is more effective than C++? Seems like
>>>> you would be stuck using structs which seems somewhat limiting, even
>>>> compared to C++...
>>>>
>>>>  UE4 has similar reloading capabilities(using DLLs), though they use
>>>> C++ and rely more on the ability to serialize everything
>>>>
>>>
>>> Why should I be stuck with structs? Its the exact same as in C++. I
>>> did build my own new and delete operators (as templates). It's not
>>> that hard and works pretty well, only the syntax is not ideal in some
>>> cases. I can use everything you can use with D+GC. Sometimes you have
>>> to be carefull with implict allocations (e.g. closures, array
>>> literals) but I have a leak detector that points me to these directly
>>> and usually its easy to free these manually.
>>>
>>> And I'm quite a bit more productive then in C++. Module constructors
>>> with a defined order instead of random static initalizers,
>>> code generation isnstead of huge amounts of boilerplate code and many
>>> other features are the cause of this.
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>
>> Is D moving away from your sort of use? Games and bioinformatics
>> would seem to be the areas the language should be trying to get
>> people to start using it in. The features you're using seem very
>> much like they should be a part and mode of using the language.
>
> I wouldn't say its moving away from it. Some recent changes to druntime
> have made it significantly less leaking. But on the other hand a API
> design like toString() which pretty much does leak in almost all cases
> don't exactly help a GC free D. In Summary it feels to me that GC free D
> is not important to the community or the active contributors.

Regarding toString there is a better signature that avoids useless allocations:

void toString(scope void delegate(const (char)[]) sink);

It takes a delegate to output string representation directly to the destination via 'sink' delegate (that may e.g. write chars to file). Plus the 'scope' part of declaration avoids allocating the said delegate on the heap.

I'd even say that string toString(); is an artifact of the past, instead to!string should be used (if allocating a string is fine).

>
> I also see D's biggest chances in becoming popular in the performance
> critical fields of programming. Which would be systems programming,
> Gaming and others. For programming fields in which a GC is applicable
> people tend to use languages like C# or Java, because they are truly
> safe (see the recent "ref is unsafe" discussion in the newsgroup), they
> have nice productivity features like runtime code changing through the
> VM and have a way better GC because the language was designed from the
> beginning to support a advanced GC.
>
> Kind Regards
> Benjamin Thaut


-- 
Dmitry Olshansky

On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky <dmitry.olsh@gmail.com>wrote:

> Regarding toString there is a better signature that avoids useless allocations:
>
> void toString(scope void delegate(const (char)[]) sink);
>
> It takes a delegate to output string representation directly to the destination via 'sink' delegate (that may e.g. write chars to file). Plus the 'scope' part of declaration avoids allocating the said delegate on the heap.
>
> I'd even say that string toString(); is an artifact of the past, instead
> to!string should be used (if allocating a string is fine).


I know you explained that already, but see, that again slipped my mind. This toString(sink) thingy seems cool, but is there a documentation on it somewhere? Without a related doc, I fear no one will know this exists.

06-Jan-2013 23:55, Philippe Sigaud пишет:
> On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky <dmitry.olsh@gmail.com
> <mailto:dmitry.olsh@gmail.com>> wrote:
>
>     Regarding toString there is a better signature that avoids useless
>     allocations:
>
>     void toString(scope void delegate(const (char)[]) sink);
>
>     It takes a delegate to output string representation directly to the
>     destination via 'sink' delegate (that may e.g. write chars to file).
>     Plus the 'scope' part of declaration avoids allocating the said
>     delegate on the heap.
>
>     I'd even say that string toString(); is an artifact of the past,
>     instead to!string should be used (if allocating a string is fine).
>
>
> I know you explained that already, but see, that again slipped my mind.
> This toString(sink) thingy seems cool, but is there a documentation on
> it somewhere? Without a related doc, I fear no one will know this exists.
>

Guess I need to find the original on toString and bit-blit it over with this new sink thingy ;)

-- 
Dmitry Olshansky

Am 06.01.2013 20:55, schrieb Philippe Sigaud:
> On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky <dmitry.olsh@gmail.com
> <mailto:dmitry.olsh@gmail.com>> wrote:
>
>     Regarding toString there is a better signature that avoids useless
>     allocations:
>
>     void toString(scope void delegate(const (char)[]) sink);
>
>     It takes a delegate to output string representation directly to the
>     destination via 'sink' delegate (that may e.g. write chars to file).
>     Plus the 'scope' part of declaration avoids allocating the said
>     delegate on the heap.
>
>     I'd even say that string toString(); is an artifact of the past,
>     instead to!string should be used (if allocating a string is fine).
>
>
> I know you explained that already, but see, that again slipped my mind.
> This toString(sink) thingy seems cool, but is there a documentation on
> it somewhere? Without a related doc, I fear no one will know this exists.
>

There was a language change request for it in the wiki, but I can't find it anymore.

Kind Regards
Benjamin Thaut

07-Jan-2013 00:02, Dmitry Olshansky пишет:
> 06-Jan-2013 23:55, Philippe Sigaud пишет:
>> On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky <dmitry.olsh@gmail.com
>> <mailto:dmitry.olsh@gmail.com>> wrote:
>>
>>     Regarding toString there is a better signature that avoids useless
>>     allocations:
>>
>>     void toString(scope void delegate(const (char)[]) sink);
>>
>>     It takes a delegate to output string representation directly to the
>>     destination via 'sink' delegate (that may e.g. write chars to file).
>>     Plus the 'scope' part of declaration avoids allocating the said
>>     delegate on the heap.
>>
>>     I'd even say that string toString(); is an artifact of the past,
>>     instead to!string should be used (if allocating a string is fine).
>>
>>
>> I know you explained that already, but see, that again slipped my mind.
>> This toString(sink) thingy seems cool, but is there a documentation on
>> it somewhere? Without a related doc, I fear no one will know this exists.
>>
>
> Guess I need to find the original on toString and bit-blit it over with
> this new sink thingy ;)
>

There is a short note in object.d:
...
string toString();
		Convert Object to a human readable string.
...

That is any class may override it.

However the real relevant golden bit of information is buried after a row of formatValue templates (that hardly makes any sense to newcomers) at the bottom of std.format page:
(http://dlang.org/phobos/std_format.html)

Aggregates (struct, union, class, and interface) are basically formatted by calling toString.

toString should have one of the following signatures:
const void toString(scope void delegate(const(char)[]) sink, FormatSpec fmt);
const void toString(scope void delegate(const(char)[]) sink, string fmt);
const void toString(scope void delegate(const(char)[]) sink);
const string toString();


So it's quite flexible. Even better then I've been advertising it.
Note that classes are covered. I bet it can call virtual functions through base reference if base defines the new variation of toString.


The problem is if it's going to be extended to wchar/dchar... At least wchar is useful on Windows.

But the real fun is that I fail to find any real description of toString in the docs for d-p-l website!

The only files in d-p-l site where it is found in are:

- errors.dd:
... class Error has a pure virtual a function called toString() which produces a char[] with a human readable description of the error.)

Nothing useful and it's out of date! It returns a string (immutable) these days.

- lazy-evaluation.dd uses as an example of expensive computation and has the form of toString(i) where i is an int (wtf?!).

Probably horribly out of date as it should use either format or to!string.

- tempalte.dd uses std.string.toString as an example (same as in lazy?) and it's again an out of date piece of crap.

And a couple more files call it here and there (e.g. windows.dd to display exception message box).


-- 
Dmitry Olshansky