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