November 28, 2018 Re: Struct should be invalid after move | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Wednesday, 28 November 2018 at 19:11:14 UTC, Steven Schveighoffer wrote:
> int *ptr1 = (int *)malloc(sizeof(int));
> int *ptr2 = ptr1;
>
> free(ptr2);
>
> *ptr1 = 5;
>
> If we have a hypothetical C compiler that prevents use of ptr2 after free, it probably doesn't know about the link to ptr1, to make that also unusable.
>
> Indeed the runtime solution is much more possible.
For that (or rather, to prevent that) we have non-copyable types. Like the one in the OP.
|
November 28, 2018 Re: Struct should be invalid after move | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Wed, 28 Nov 2018 14:11:14 -0500, Steven Schveighoffer wrote:
> Not sure what you mean. What I'm talking about is this:
>
> int *ptr1 = (int *)malloc(sizeof(int));
> int *ptr2 = ptr1;
>
> free(ptr2);
>
> *ptr1 = 5;
Yes, and the compiler can't detect this very often (at least not without an ownership / borrowing system like Rust or Vala).
Instead, you can eliminate aliasing, introduce reference counting or a garbage collector to avoid manually freeing, or use indirection to detect when the value is freed.
There are a bunch of solutions that work some of the time. The end result is a bit of code that doesn't fit with any of it and needs special caution.
|
November 28, 2018 Re: Struct should be invalid after move | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Wednesday, 28 November 2018 at 16:58:32 UTC, H. S. Teoh wrote:
> Yeah, this seems to be a not-very-well-known aspect of syntax common across C, C++, Java, and D:
>
> ReturnType myFunc(Args args) {
> int var1;
> someCode();
> {
> int var2;
> someOtherCode();
> }
> // var2 no longer in scope, but var1 still is.
> {
> // Can reuse identifier 'var2' without conflict
> float var2;
> yetMoreCode();
> }
> etcetera();
> }
>
> It's a very useful construct in ensuring that temporaries don't last longer than they ought to. (Syntactically anyway... the compiler may or may not actually translate that directly in the executable. But the point is to avoid programmer slip-ups.)
>
>
> T
Yes, you can get what I asked for using blocks, but there are use cases where you can't always use blocks effectively. Also there is the aesthetic aspect -- all the curly braces and indentation makes code annoying to read.
|
November 30, 2018 Re: Struct should be invalid after move | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Tuesday, 27 November 2018 at 19:28:13 UTC, Steven Schveighoffer wrote:
> Note that complete flow analysis is equivalent to the halting problem. So really, you can never get it perfect, and therefore, there are always going to be some things you can't catch. So it's impossible to fulfill that promise in any compiler.
That's a straw man. I was not talking about complete flow analysis and getting it perfect. Some form of flow analysis is already build into DMD, so I suggest to:
1. At least enable it unconditionally
2. Improve it to account for more complex scenarios than simple null dereferencing
Anyway, the point I am trying to make here is that it's much better to make one compiler smarter, than to rely on many users' not-even-close-to-perfect discipline, and I think C++ proves it. Software development these days is too complex to comprehend without the help of tools, which must become smarter to really have an impact and stay in use.
|
November 30, 2018 Re: Struct should be invalid after move | ||||
---|---|---|---|---|
| ||||
Posted in reply to burjui | On 11/30/18 10:01 AM, burjui wrote: > On Tuesday, 27 November 2018 at 19:28:13 UTC, Steven Schveighoffer wrote: >> Note that complete flow analysis is equivalent to the halting problem. So really, you can never get it perfect, and therefore, there are always going to be some things you can't catch. So it's impossible to fulfill that promise in any compiler. > > That's a straw man. I was not talking about complete flow analysis and getting it perfect. Some form of flow analysis is already build into DMD, so I suggest to: > 1. At least enable it unconditionally I'm not a compiler writer, and don't know the first thing about the requirements, but I would hazard a guess that the reason this is the case is if optimization isn't enabled, some critical pieces needed to do flow analysis aren't present. I don't think it's orthogonal. > 2. Improve it to account for more complex scenarios than simple null dereferencing I think any improvements to the flow analysis would be welcome! The more the compiler can flag as an obvious error, the better. > Anyway, the point I am trying to make here is that it's much better to make one compiler smarter, than to rely on many users' not-even-close-to-perfect discipline, and I think C++ proves it. Software development these days is too complex to comprehend without the help of tools, which must become smarter to really have an impact and stay in use. Best effort to detect problems is generally what we have with D. My point was simply that any time you solve "how come it doesn't detect this", someone will highlight another problem that is harder or impossible to solve. -Steve |
Copyright © 1999-2021 by the D Language Foundation