On Fri, Apr 28, 2017 at 09:01:03AM +0000, Moritz Maxeiner via Digitalmars-d wrote:
> On Friday, 28 April 2017 at 07:35:00 UTC, Ben wrote:
[...]
> > Is it so hard for developers when you declare a variable, to later also clean it up???
> > 
> > var x = 1;
> > // Do work
> > x.free;
> 
> If you write it like that, yes, because often it's not just one such
> make/dispose pair per scope, but multiple, possibly overlapping ones
> and people make mistakes. And the more complex a piece of code gets
> the harder it becomes to decipher such pairs and/or decide if the
> "closing" dispose is missing.
> This is one of the reasons why scope guards are good:
> 
> var x = 1;
> scope (exit) x.free
> // Do work
> 
> This, as code becomes more complex, allows for much easier reading
> (and understanding) of lifetimes.
[...]

Elephant in the room: D lets you call the C library's malloc() and free(). If you absolute insist that you don't want to use the GC, go right ahead and import core.c.stdlib, and malloc and free away.  As mentioned above, D's scope guards will even help you avoid mistakes by keeping allocation and free in the same scope together, i.e., instead of writing:

	auto x = malloc(...);
	// do stuff
	// and more stuff
	// and more stuff
	// so many pages of stuff you forgot about x
	free(x);	// very likely you'll forget this by now

you could save yourself the bug by writing:

	auto x = malloc(...);
	scope(exit) free(x);
	// ... however many pages of stuff you want, you don't have to
	// remember to write free() afterwards!

Yes, D comes with a GC... doesn't mean you have to use it if you don't want to, though!


T

-- 
Doubt is a self-fulfilling prophecy.

On Friday, 28 April 2017 at 14:59:46 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 28 April 2017 at 09:40:07 UTC, Moritz Maxeiner wrote:
>> I'm sorry, but that's just plain wrong. D does not have ownership pointers because nobody that wants them has stepped up and
>> 1) Done the work of drafting an informal proposal that *actually deals with _all_ of the issues involved*
>
> Wrong. This has been discussed and hashed out to death over and over again. The solutions are on the table.

No. Every single thread I read in the last couple of years ended with Walter pointing out issues that need to be "hashed out" and then nobody doing it.

>
> Walter's position has always been that having more than a single pointer type is a disaster.

None of the threads I've read in the last couple of years regarding that support that claim.

>
> That makes further work on it pointless.

What you consider worth working on is your business, of course :)

On Friday, 28 April 2017 at 15:23:18 UTC, H. S. Teoh wrote:

> you could save yourself the bug by writing:
>
> 	auto x = malloc(...);
> 	scope(exit) free(x);
> 	// ... however many pages of stuff you want, you don't have to
> 	// remember to write free() afterwards!
>
> Yes, D comes with a GC... doesn't mean you have to use it if you don't want to, though!

I usually use the GC, so I have limited knowledge in this area. How common is this pattern in D code? Is it better than using reference counted structs? Is there any advantage to using the GC in this scenario?

I would like to add this info to the wiki (I don't seen it there).

On Friday, 28 April 2017 at 16:03:18 UTC, bachmeier wrote:
>
> I usually use the GC, so I have limited knowledge in this area. How common is this pattern in D code? Is it better than using reference counted structs? Is there any advantage to using the GC in this scenario?
>
> I would like to add this info to the wiki (I don't seen it there).

You can also use automem
https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/

On Friday, 28 April 2017 at 17:06:51 UTC, jmh530 wrote:
> On Friday, 28 April 2017 at 16:03:18 UTC, bachmeier wrote:
>>
>> I usually use the GC, so I have limited knowledge in this area. How common is this pattern in D code? Is it better than using reference counted structs? Is there any advantage to using the GC in this scenario?
>>
>> I would like to add this info to the wiki (I don't seen it there).
>
> You can also use automem
> https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/

I'm hoping to put all information in one place. Then when someone on Reddit or HN or here starts making claims about the GC, I can give them one link that shows all of their options. There's this page:
https://wiki.dlang.org/Memory_Management
but that isn't comprehensive or as to-the-point as it needs to be.

On Friday, 28 April 2017 at 17:42:18 UTC, bachmeier wrote:
> I'm hoping to put all information in one place. Then when someone on Reddit or HN or here starts making claims about the GC, I can give them one link that shows all of their options.

That's nice. Just get your hopes up for it having an effect. One of the key points of having it in the core distribution (compiler) is for library interoperability. Using multiple solutions ends up in chaos in real world projects...

On Fri, Apr 28, 2017 at 04:03:18PM +0000, bachmeier via Digitalmars-d wrote:
> On Friday, 28 April 2017 at 15:23:18 UTC, H. S. Teoh wrote:
> 
> > you could save yourself the bug by writing:
> > 
> > 	auto x = malloc(...);
> > 	scope(exit) free(x);
> > 	// ... however many pages of stuff you want, you don't have to
> > 	// remember to write free() afterwards!
> > 
> > Yes, D comes with a GC... doesn't mean you have to use it if you don't want to, though!
> 
> I usually use the GC, so I have limited knowledge in this area. How common is this pattern in D code? Is it better than using reference counted structs? Is there any advantage to using the GC in this scenario?

To be honest, in my own D code I'm not overly concerned with the GC, and even when I am, and want to control when / how often the GC collects, I usually just use GC.disable() and then GC.collect() explicitly.  I've seen performance gains of about 30-40% just by carefully reducing the frequency of GC collections (IMO the default is a bit too eager), but of course that depends on exactly what your application is doing.  In my case, that was in the context of batch-oriented, CPU-intensive computations that allocate often and mostly keeps live data.  YMMV if your program is doing something else or has other patterns of memory access.

But my point was that, if you really wanted to, you *could* use C-style memory management in D code. D won't stop you from doing that. The malloc heap is distinct from the GC heap so you won't run into conflicts.  Of course, that also means you can't use D features that currently require the GC, such as closures and dynamic arrays. But if you're doing C-style memory management you probably already want to implement your own way of handling array allocations and closure functionality anyway. You can still pass slices of things around to things like Phobos range algorithms (excepting the few that might allocate -- hence marking your code with @nogc for the compiler to enforce this), so generally a decent chunk of Phobos should still be usable.

Even Phobos itself uses malloc/free directly in several places, for various reasons, so I wouldn't say it's exactly a foreign thing to do in D code.


> I would like to add this info to the wiki (I don't seen it there).

That would be very nice, thanks!


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.

On Friday, 28 April 2017 at 15:43:22 UTC, Moritz Maxeiner wrote:
> On Friday, 28 April 2017 at 14:59:46 UTC, Ola Fosheim Grøstad wrote:
>> Walter's position has always been that having more than a single pointer type is a disaster.
>
> None of the threads I've read in the last couple of years regarding that support that claim.

He has restated this position many many times... Random snippets:

«Microsoft's Managed C++ had two pointer types, and it went over like a lead zeppelin.
»

http://forum.dlang.org/post/mclqt1$1e5n$1@digitalmars.com


«Back in the old DOS days, there were multiple pointer types (near and far). Programmers put up with that because it was the only way, but they HATED HATED HATED it.»

http://forum.dlang.org/post/mcnv9u$e8p$1@digitalmars.com


You can easily find more... No point in trying to get that into the core language (but it is necessary to get proper destruction of GC managed objects in a reasonable way).

On Friday, 28 April 2017 at 17:48:47 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 28 April 2017 at 17:42:18 UTC, bachmeier wrote:
>> I'm hoping to put all information in one place. Then when someone on Reddit or HN or here starts making claims about the GC, I can give them one link that shows all of their options.
>
> That's nice. Just get your hopes up for it having an effect.

Typo, I meant "don't"... Sloppy of me. Documentation is nice, but:

1. People will complain that it isn't possible.

2. When possible people will complain that it isn't in the standard library.

3. When in "std" people will complain that not enough libraries use it.

4. When libraries use it people will complain that it doesn't work with older libs.

5. When older libs have been rewritten to support it they will complain that it is better in Rust and C++ and not compatible with Rust and C++.

Anyway, my main point is that programmers coming from such languages will most certainly complain if it isn't in the standard library because of interoperability between libraries, but that is basically just the bottom of the hill that you have to climb to get to a level where people stop complaining.

On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 28 April 2017 at 15:43:22 UTC, Moritz Maxeiner wrote:
>> On Friday, 28 April 2017 at 14:59:46 UTC, Ola Fosheim Grøstad wrote:
>>> Walter's position has always been that having more than a single pointer type is a disaster.
>>
>> None of the threads I've read in the last couple of years regarding that support that claim.
>
> He has restated this position many many times... Random snippets:
>
> «Microsoft's Managed C++ had two pointer types, and it went over like a lead zeppelin.
> »
>
> http://forum.dlang.org/post/mclqt1$1e5n$1@digitalmars.com
>
>
> «Back in the old DOS days, there were multiple pointer types (near and far). Programmers put up with that because it was the only way, but they HATED HATED HATED it.»
>
> http://forum.dlang.org/post/mcnv9u$e8p$1@digitalmars.com
>

I had not read these, thank you :)
Both of these, however, show only that he doesn't seem to personally like multiple pointer types (and consequently doesn't seem to have any interest in working on them himself); that's not the same as him claiming that it "is a disaster" (in general, which is what you were implying).

>
> You can easily find more... No point in trying to get that into the core language (but it is necessary to get proper destruction of GC managed objects in a reasonable way).

What you consider not pointless is your business, again, but if you don't try to get it in the core language, you have no foundation to complain that's it's not in there.