www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Overload using nogc

reply "Jonathan Marler" <johnnymarler gmail.com> writes:
Has the idea of function overloading via nogc been explored?

void func()  nogc
{
     // logic that does not use GC
}
void func()
{
     // logic that uses GC
}
void main(string[] args) //  nogc
{
     // if main is  nogc, then the  nogc version of func
     // will be called, otherwise, the GC version will be
     func();
}

This could be useful for the standard library to expose different 
implementations based on whether or not the application is using 
the GC.
Nov 20 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jonathan Marler"  wrote in message 
news:huzhibjpuvqjxqnubsog forum.dlang.org...

 Has the idea of function overloading via nogc been explored?

 void func()  nogc
 {
      // logic that does not use GC
 }
 void func()
 {
      // logic that uses GC
 }
 void main(string[] args) //  nogc
 {
      // if main is  nogc, then the  nogc version of func
      // will be called, otherwise, the GC version will be
      func();
 }

 This could be useful for the standard library to expose different 
 implementations based on whether or not the application is using the GC.
I think in most cases either the nogc version would use different types (or it's templated), and therefore you wouldn't need to overload on nogc, or you would simply have only a nogc version.
Nov 20 2014
prev sibling next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 2014-11-21 o 04:36, Jonathan Marler pisze:
 Has the idea of function overloading via nogc been explored?

 void func()  nogc
 {
      // logic that does not use GC
 }
 void func()
 {
      // logic that uses GC
 }
 void main(string[] args) //  nogc
 {
      // if main is  nogc, then the  nogc version of func
      // will be called, otherwise, the GC version will be
      func();
 }

 This could be useful for the standard library to expose different
 implementations based on whether or not the application is using the GC.
+1
Nov 22 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/21/14, 12:36 AM, Jonathan Marler wrote:
 Has the idea of function overloading via nogc been explored?

 void func()  nogc
 {
      // logic that does not use GC
 }
 void func()
 {
      // logic that uses GC
 }
 void main(string[] args) //  nogc
 {
      // if main is  nogc, then the  nogc version of func
      // will be called, otherwise, the GC version will be
      func();
 }

 This could be useful for the standard library to expose different
 implementations based on whether or not the application is using the GC.
If you have a version that doesn't use the GC, what's the reason to prefer one that uses it?
Nov 22 2014
next sibling parent "Sativa" <Sativa Indica.org> writes:
On Saturday, 22 November 2014 at 16:56:58 UTC, Ary Borenszweig 
wrote:
 On 11/21/14, 12:36 AM, Jonathan Marler wrote:
 Has the idea of function overloading via nogc been explored?

 void func()  nogc
 {
     // logic that does not use GC
 }
 void func()
 {
     // logic that uses GC
 }
 void main(string[] args) //  nogc
 {
     // if main is  nogc, then the  nogc version of func
     // will be called, otherwise, the GC version will be
     func();
 }

 This could be useful for the standard library to expose 
 different
 implementations based on whether or not the application is 
 using the GC.
If you have a version that doesn't use the GC, what's the reason to prefer one that uses it?
because, say, you can have two versions! Is that not good enough for you? e.g., you can later on write a nogc version and simply switch between the two implementations by toggling the attribute on main. Benefits? Easy: 1. It allows you to update your library to handle nogc progressively 2. It allows you to more easily debug your code. If it works with gc and not nogc then obviously it's in the nogc code. 3. It reduces code bloat and confusion because one doesn't have to have multiple names of the same function floating around. e.g., allocate_gc, allocate_nogc_heap, etc. The problem here is that such a rule chooses one or the other which reduces its usefulness. If one could simply request nogc functions, say, then void main() request( nogc(heap)) { allocate(); other_overload(); } could attempt to use all nogc overloads, in this case, the above expands to essentially void main() request( nogc(heap)) { allocate_nogc_heap(); // other_overload_gc(); // assuming it exists, if not, it will use whatever overloads exist that } But with all this added complexity I don't think one gets a huge benefit in this case. Simply making the compiler GC agnostic and by using allocators, I think one gets basically the same functionality with more clarity. It may work in other cases though. Essentially the concept is to extend overloading to work with attributes. e.g., void func(...) void func(...) attr1 void func(...) attr2 are all overloads with the attributes also being overloaded. func random(...) calls a random overload(chosen at compile time). func request( attr1)(...) attempts to call func with attr1 but falls back on the non-overloaded ones, etc. func attr1(...) calls the function with attr1 or fails if it doesn't exist. Ultimately, having such a metadata system helps partition similar functions in a program and then do something more complex. Not sure if it would actually be that useful since we can effectively already do this type of stuff, albeit with more work and confusion.
Nov 23 2014
prev sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 2014-11-22 o 17:56, Ary Borenszweig pisze:
 On 11/21/14, 12:36 AM, Jonathan Marler wrote:
 Has the idea of function overloading via nogc been explored?

 void func()  nogc
 {
      // logic that does not use GC
 }
 void func()
 {
      // logic that uses GC
 }
 void main(string[] args) //  nogc
 {
      // if main is  nogc, then the  nogc version of func
      // will be called, otherwise, the GC version will be
      func();
 }

 This could be useful for the standard library to expose different
 implementations based on whether or not the application is using the GC.
If you have a version that doesn't use the GC, what's the reason to prefer one that uses it?
Some algorithms (that swap pointers very often) may run faster with GC, but GC can cause stalls in your real time code. Nogc at main() is about preventing those stalls, even if nogc function will run slower (f.i. because pointer swaping adds some overhead needed to manage ownership - think about RC pointers). But *if* you want to use GC, it's more desirable to use faster GC version.
Nov 23 2014
prev sibling next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Friday, 21 November 2014 at 03:36:30 UTC, Jonathan Marler 
wrote:
 Has the idea of function overloading via nogc been explored?

 void func()  nogc
 {
     // logic that does not use GC
 }
 void func()
 {
     // logic that uses GC
 }
 void main(string[] args) //  nogc
 {
     // if main is  nogc, then the  nogc version of func
     // will be called, otherwise, the GC version will be
     func();
 }

 This could be useful for the standard library to expose 
 different implementations based on whether or not the 
 application is using the GC.
If you need temporary allocations on the heap, and already have an implementation using nogc anyways, it's better to do that even for the GC version. The only difference I can see would be in returning values, and having whether the returned memory is managed by the GC or by the caller be based off the overload seems extremely dangerous. Template functions in particular could be either nogc or not with inference, and making the caller nogc shouldn't make it suddenly leak memory. Instead consider passing in an allocator. Then it's explicit, more flexible, and more different.
Nov 23 2014
parent "Kapps" <opantm2+spam gmail.com> writes:
On Sunday, 23 November 2014 at 08:57:15 UTC, Kapps wrote:
 Instead consider passing in an allocator. Then it's explicit, 
 more flexible, and more different.
More apparent rather. Auto correct messed it up then hit send trying to touch the word to select it. -_-
Nov 23 2014
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 11/21/2014 04:36 AM, Jonathan Marler wrote:
 This could be useful for the standard library to expose different
 implementations based on whether or not the application is using the GC.
https://issues.dlang.org/show_bug.cgi?id=9511
Nov 27 2014