digitalmars.D - Overload using nogc
- Jonathan Marler (18/18) Nov 20 2014 Has the idea of function overloading via nogc been explored?
- Daniel Murphy (5/22) Nov 20 2014 I think in most cases either the @nogc version would use different types...
- Piotr Szturmaj (2/19) Nov 22 2014 +1
- Ary Borenszweig (3/20) Nov 22 2014 If you have a version that doesn't use the GC, what's the reason to
- Sativa (53/77) Nov 23 2014 because, say, you can have two versions! Is that not good enough
- Piotr Szturmaj (7/29) Nov 23 2014 Some algorithms (that swap pointers very often) may run faster with GC,
- Kapps (13/31) Nov 23 2014 If you need temporary allocations on the heap, and already have
- Kapps (3/5) Nov 23 2014 More apparent rather. Auto correct messed it up then hit send
- Martin Nowak (2/4) Nov 27 2014 https://issues.dlang.org/show_bug.cgi?id=9511
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
"Daniel Murphy" <yebbliesnospam gmail.com>
"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
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
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
On Saturday, 22 November 2014 at 16:56:58 UTC, Ary Borenszweig wrote:On 11/21/14, 12:36 AM, Jonathan Marler wrote: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.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 23 2014
W dniu 2014-11-22 o 17:56, Ary Borenszweig pisze:On 11/21/14, 12:36 AM, Jonathan Marler wrote: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.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 23 2014
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
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
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