Am Thu, 06 Feb 2014 19:08:39 +0000
schrieb "Adam D. Ruppe" <destructionator@gmail.com>:

> On Thursday, 6 February 2014 at 18:52:21 UTC, fra wrote:
> > Hey, wait a second. How do you throw without allocating?
> 
> I think exceptions should be ok. You optimize the typical path, and exceptions are (by definition) an exceptional path. If they are also unacceptable, you could restrict yourself to nothrow functions. (Which can still throw Errors... but meh they are even *more* exceptional)

That depends on your situation. For games and other applications on normal computers it's OK.

For games on systems like embedded gaming systems (think like NintendoDS, 4MB ram) you might not have a GC but still want to use exception handling.

06-Feb-2014 22:15, Andrej Mitrovic пишет:
> On 2/6/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> Thanks. I guess we'd need to cross-reference to function names from there.
>
> Updated to include function names.
>
Hm.
Somehow diffing this with coverage report may help filter out CTFE.
Some bugs are features :)

-- 
Dmitry Olshansky

On Thursday, 6 February 2014 at 19:32:11 UTC, Johannes Pfau wrote:
> For games on systems like embedded gaming systems (think like
> NintendoDS, 4MB ram) you might not have a GC but still want to use exception handling.

Yeah, when I toyed with bare metal D, I did exceptions with manual memory management - malloc when throwing (well, I did malloc in _d_newclass so it was transparent to the throwing code), free when catching.

But I think a program written for a special environment will have different coding standards from top to bottom, including the need to free in an exception handler and the option to hack druntime.

On Thursday, 6 February 2014 at 18:52:21 UTC, fra wrote:
> On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu wrote:
>>> One interesting point is that module that were written with avoiding
>>> allocations in mind usually still allocate when throwing exceptions.
>>
>> Good point, we need to address that as well.
>
> Hey, wait a second. How do you throw without allocating?

Does this case even matter?  Exceptions are not a normal function of execution, and so should happen rarely to never.  And it's a time when I'd expect a delay anyway.

On Thu, Feb 06, 2014 at 11:39:30PM +0400, Dmitry Olshansky wrote:
> 06-Feb-2014 22:15, Andrej Mitrovic пишет:
> >On 2/6/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> >>Thanks. I guess we'd need to cross-reference to function names from there.
> >
> >Updated to include function names.
> >
> Hm.
> Somehow diffing this with coverage report may help filter out CTFE.
> Some bugs are features :)
[...]

I thought *all* bugs are features... unintentional features. :-P


T

-- 
Bomb technician: If I'm running, try to keep up.

On 2/6/14, 11:54 AM, Sean Kelly wrote:
> On Thursday, 6 February 2014 at 18:52:21 UTC, fra wrote:
>> On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu wrote:
>>>> One interesting point is that module that were written with avoiding
>>>> allocations in mind usually still allocate when throwing exceptions.
>>>
>>> Good point, we need to address that as well.
>>
>> Hey, wait a second. How do you throw without allocating?
>
> Does this case even matter?  Exceptions are not a normal function of
> execution, and so should happen rarely to never.  And it's a time when
> I'd expect a delay anyway.

I think it's okay to put this on the backburner and revisit it later.

Andrei

07-Feb-2014 00:15, H. S. Teoh пишет:
> On Thu, Feb 06, 2014 at 11:39:30PM +0400, Dmitry Olshansky wrote:
>> 06-Feb-2014 22:15, Andrej Mitrovic пишет:
>>> On 2/6/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>> Thanks. I guess we'd need to cross-reference to function names from
>>>> there.
>>>
>>> Updated to include function names.
>>>
>> Hm.
>> Somehow diffing this with coverage report may help filter out CTFE.
>> Some bugs are features :)
> [...]
>
> I thought *all* bugs are features... unintentional features. :-P
>

O.T. From a pragmatic point of view any specific property of a system that is useful to the enduser is a feature. Not all bugs are useful ;)

> T
>


-- 
Dmitry Olshansky

Johannes Pfau:

> Here's some example output for
> std.uuid/digest/path/range/algorithm/curl:
> http://dpaste.dzfl.pl/96d3725b06e2

> ./dmd -vgc ~/Dokumente/d/phobos/std/range.d -c -unittest
> /home/jpf/Dokumente/d/phobos/std/range.d(7307): vgc: Array literals cause gc allocation

Since some time in some cases dynamic array literals don't allocate.

And there's also this:
https://github.com/D-Programming-Language/dmd/pull/2952
the [1, 2]s syntax guarantees no heap allocation.

Bye,
bearophile

On Thursday, 6 February 2014 at 20:40:28 UTC, bearophile wrote:
> Johannes Pfau:
>
>> Here's some example output for
>> std.uuid/digest/path/range/algorithm/curl:
>> http://dpaste.dzfl.pl/96d3725b06e2
>
>> ./dmd -vgc ~/Dokumente/d/phobos/std/range.d -c -unittest
>> /home/jpf/Dokumente/d/phobos/std/range.d(7307): vgc: Array literals cause gc allocation
>
> Since some time in some cases dynamic array literals don't allocate.
>
> And there's also this:
> https://github.com/D-Programming-Language/dmd/pull/2952
> the [1, 2]s syntax guarantees no heap allocation.
>
> Bye,
> bearophile
My pull was not perfect. And I have no time to finish the type[$] and auto[$] pull. :/

On Thursday, 6 February 2014 at 18:52:21 UTC, fra wrote:
> Hey, wait a second. How do you throw without allocating?

Throw pre-allocated thread-local exception. And make a deep copy for it if it is going to be put into exception chain to avoid modifying one already in chain.

I have been told in that PR that some of language features assume exception instances are always unique and rely on it. It sounds like major language design flaw that will block usage of Phobos in memory-caring code even if other issues are taken care of. Probably language spec should be relaxed to fix this.