www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - nogc with assoc array

reply "Jonathan Marler" <johnnymarler gmail.com> writes:
Why is the 'in' operator nogc but the index operator is not?

void main()  nogc
{
     int[int] a;
     auto v = 0 in a; // OK
     auto w = a[0];   // Error: indexing an associative
                      // array in  nogc function main may
                      // cause GC allocation
}
Feb 16 2015
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Monday, 16 February 2015 at 17:55:42 UTC, Jonathan Marler 
wrote:

 Why is the 'in' operator nogc but the index operator is not?

 void main()  nogc
 {
     int[int] a;
     auto v = 0 in a; // OK
     auto w = a[0];   // Error: indexing an associative
                      // array in  nogc function main may
                      // cause GC allocation
 }


Might throw.
Feb 16 2015
prev sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 16.02.2015 um 18:55 schrieb Jonathan Marler:

 Why is the 'in' operator nogc but the index operator is not?

 void main()  nogc
 {
      int[int] a;
      auto v = 0 in a; // OK
      auto w = a[0];   // Error: indexing an associative
                       // array in  nogc function main may
                       // cause GC allocation
 }


Because the index operator throws a OutOfRange exception and throwing 
exceptions allocates, maybe?
Feb 16 2015
next sibling parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 16 February 2015 at 17:58:10 UTC, Benjamin Thaut wrote:

 Because the index operator throws a OutOfRange exception and 
 throwing exceptions allocates, maybe?


Oh...I hadn't thought of that!  Thanks for the quick response.
Feb 16 2015
prev sibling parent reply FG <home fgda.pl> writes:
On 2015-02-16 at 18:58, Benjamin Thaut wrote:

 Am 16.02.2015 um 18:55 schrieb Jonathan Marler:

 Why is the 'in' operator nogc but the index operator is not?

 void main()  nogc
 {
      int[int] a;
      auto v = 0 in a; // OK
      auto w = a[0];   // Error: indexing an associative
                       // array in  nogc function main may
                       // cause GC allocation
 }


 Because the index operator throws a OutOfRange exception and throwing
exceptions allocates, maybe?


Range violation is an Error, but never mind that. The real question is: given
all the work related to  nogc, wouldn't it be better for such common Errors to
be preallocated and only have file and line updated when they are thrown?

 nogc already, because they simply cast typeid(OutOfMemoryError).init or
typeid(InvalidMemoryOperationError).init:
extern (C) void onOutOfMemoryError(void* pretend_sideffect = null)  trusted
pure nothrow  nogc
extern (C) void onInvalidMemoryOperationError(void* pretend_sideffect = null)
 trusted pure nothrow  nogc

Could be made  nogc with one object of each kind preallocated:
extern (C) void onAssertError( string file = __FILE__, size_t line = __LINE__ )
nothrow
extern (C) void onRangeError( string file = __FILE__, size_t line = __LINE__ )
 safe pure nothrow
extern (C) void onSwitchError( string file = __FILE__, size_t line = __LINE__ )
 safe pure nothrow
Feb 16 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 16 February 2015 at 19:12:45 UTC, FG wrote:

 Range violation is an Error, but never mind that. The real 
 question is: given all the work related to  nogc, wouldn't it 
 be better for such common Errors to be preallocated and only 
 have file and line updated when they are thrown?

  nogc already, because they simply cast 
 typeid(OutOfMemoryError).init or 
 typeid(InvalidMemoryOperationError).init:
 extern (C) void onOutOfMemoryError(void* pretend_sideffect = 
 null)  trusted pure nothrow  nogc
 extern (C) void onInvalidMemoryOperationError(void* 
 pretend_sideffect = null)  trusted pure nothrow  nogc

 Could be made  nogc with one object of each kind preallocated:
 extern (C) void onAssertError( string file = __FILE__, size_t 
 line = __LINE__ ) nothrow
 extern (C) void onRangeError( string file = __FILE__, size_t 
 line = __LINE__ )  safe pure nothrow
 extern (C) void onSwitchError( string file = __FILE__, size_t 
 line = __LINE__ )  safe pure nothrow


This could be a good idea for some types of exceptions.  I 
believe OutOfMemory is already pre-allocated (it has to be since 
you can't allocate it once you are out of memory).  The problem 
with your suggestion is that if you allow the exception to be 
updated with the line number/filename(it isn't immutable), then 
you have to store it in TLS memory.  That may be an acceptable 
tradeoff, but you have to take that into consideration.  Also if 
you have a chain of exceptions you wouldn't be able to include 
the same exception more then once in the chain.

The problem D has with exceptions and GC memory is complex and 
will have different optimal solutions in different cases.  In 
some cases, it would be better for D to support non-GC heap 
allocated exceptions.  Maybe these types of exceptions could be 
derived from another class so the user code will know that the 
memory needs to be freed.  There are also other ideas but my 
point is we should make a plan about what solutions we think 
would be good to implement and determine which ones we want to 
tackle first.
Feb 16 2015
parent reply FG <home fgda.pl> writes:
On 2015-02-16 at 22:12, Jonathan Marler wrote:

 On Monday, 16 February 2015 at 19:12:45 UTC, FG wrote:

 Range violation is an Error, but never mind that. The real question is: given
all the work related to  nogc, wouldn't it be better for such common Errors to
be preallocated and only have file and line updated when they are thrown?

  nogc already, because they simply cast typeid(OutOfMemoryError).init or
typeid(InvalidMemoryOperationError).init:
 extern (C) void onOutOfMemoryError(void* pretend_sideffect = null)  trusted
pure nothrow  nogc
 extern (C) void onInvalidMemoryOperationError(void* pretend_sideffect = null)
 trusted pure nothrow  nogc

 Could be made  nogc with one object of each kind preallocated:
 extern (C) void onAssertError( string file = __FILE__, size_t line = __LINE__
) nothrow
 extern (C) void onRangeError( string file = __FILE__, size_t line = __LINE__ )
 safe pure nothrow
 extern (C) void onSwitchError( string file = __FILE__, size_t line = __LINE__
)  safe pure nothrow


 This could be a good idea for some types of exceptions.  I believe OutOfMemory
is already pre-allocated (it has to be since you can't allocate it once you are
out of memory).  The problem with your suggestion is that if you allow the
exception to be updated with the line number/filename(it isn't immutable), then
you have to store it in TLS memory.  That may be an acceptable tradeoff, but
you have to take that into consideration.  Also if you have a chain of
exceptions you wouldn't be able to include the same exception more then once in
the chain.

 The problem D has with exceptions and GC memory is complex and will have
different optimal solutions in different cases.  In some cases, it would be
better for D to support non-GC heap allocated exceptions.  Maybe these types of
exceptions could be derived from another class so the user code will know that
the memory needs to be freed.  There are also other ideas but my point is we
should make a plan about what solutions we think would be good to implement and
determine which ones we want to tackle first.


Yes, they would be in TLS. I know exceptions in general are a complex problem,
therefore I limited the comment only to errors, because forbidding the use of
`aa[key]` in  nogc seemed odd (although I do think that `aa.get(key, default)`
and `key in aa` are superior to `aa[key]`). I have seen a few examples of
Exception chaining, but not Error chaining, and since Error trumps Exception,
whatever else was raised was of less importance to me, so I didn't give much
thought to that.

And as for the extra non-GC exception class, maybe, I'm not sure, but it should
nevertheless be a subclass of Exception to allow for a simple catch-all.
Feb 16 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Tuesday, 17 February 2015 at 00:00:54 UTC, FG wrote:

 Yes, they would be in TLS. I know exceptions in general are a 
 complex problem, therefore I limited the comment only to 
 errors, because forbidding the use of `aa[key]` in  nogc seemed 
 odd (although I do think that `aa.get(key, default)` and `key 
 in aa` are superior to `aa[key]`). I have seen a few examples 
 of Exception chaining, but not Error chaining, and since Error 
 trumps Exception, whatever else was raised was of less 
 importance to me, so I didn't give much thought to that.


I'm not sure what you mean by Errors?  Are you talking about 
asserts?
Feb 16 2015
parent FG <home fgda.pl> writes:
On 2015-02-17 at 03:35, Jonathan Marler wrote:

 On Tuesday, 17 February 2015 at 00:00:54 UTC, FG wrote:

 Yes, they would be in TLS. I know exceptions in general are a complex problem,
therefore I limited the comment only to errors, because forbidding the use of
`aa[key]` in  nogc seemed odd (although I do think that `aa.get(key, default)`
and `key in aa` are superior to `aa[key]`). I have seen a few examples of
Exception chaining, but not Error chaining, and since Error trumps Exception,
whatever else was raised was of less importance to me, so I didn't give much
thought to that.


 I'm not sure what you mean by Errors?  Are you talking about asserts?


Asserts among them. I was talking about the two classes of Throwable: Error and
Exception.

Errors: AssertError, FinalizeError, HiddenFuncError,
InvalidMemoryOperationError, InvalidPointerError, NotImplementedError,
OutOfMemoryError, ParallelForeachError, RangeError, SwitchError, SysError,
ThreadError.

Exceptions: Base64Exception, CSVException, ConvException, CurlException,
EncodingException, ErrnoException, FiberException,
FileException, FormatException, GetOptException, JSONException,
OverflowException, ...
Feb 16 2015