On Saturday, 18 August 2012 at 11:26:01 UTC, Peter Alexander
wrote:
const on its own provides no guarantees, it just imposes
restrictions so that immutable can provide guarantees.
While in context with the original question this is fine, but I
do not like this use of guarantee.
What I
On Sunday, 19 August 2012 at 19:26:58 UTC, Jesse Phillips wrote:
On Saturday, 18 August 2012 at 11:26:01 UTC, Peter Alexander
wrote:
const on its own provides no guarantees, it just imposes
restrictions so that immutable can provide guarantees.
While in context with the original question
On Sunday, 19 August 2012 at 19:42:20 UTC, Peter Alexander wrote:
On Sunday, 19 August 2012 at 19:26:58 UTC, Jesse Phillips wrote:
While in context with the original question this is fine, but
I do not like this use of guarantee.
What I mean is, const does provide guarantees by itself. And
On Sunday, 19 August 2012 at 19:58:11 UTC, Era Scarecrow wrote:
On Sunday, 19 August 2012 at 19:42:20 UTC, Peter Alexander
wrote:
On Sunday, 19 August 2012 at 19:26:58 UTC, Jesse Phillips
wrote:
While in context with the original question this is fine, but
I do not like this use of guarantee.
On Sunday, August 19, 2012 22:14:49 Peter Alexander wrote:
You only have that guarantee if there are no other mutable
references to the data. const *on its own* does not provide that
guarantee.
Yeah. If you really want to get down to the nitty gritty of when exactly the
compiler can guarantee
On Sunday, 19 August 2012 at 20:14:50 UTC, Peter Alexander wrote:
class Foo
{
static Foo sneaky;
this() { sneaky = this; }
void bar() const { sneaky.x++; }
int x = 0;
}
const(Foo) f = new Foo();
assert(f.x == 0);
f.bar();
assert(f.x == 1);
You only have that guarantee if there
On Saturday, 18 August 2012 at 04:18:33 UTC, Jesse Phillips wrote:
On Friday, 17 August 2012 at 22:05:56 UTC, Walter Bright wrote:
On 8/17/2012 2:34 PM, Mehrdad wrote:
On Friday, 17 August 2012 at 20:46:02 UTC, Walter Bright
wrote:
On 8/16/2012 6:43 PM, Mehrdad wrote:
On Friday, 17 August
On Saturday, August 18, 2012 13:25:56 Peter Alexander wrote:
In D, const without immutable is meaningless.
That's not quite true. There _are_ cases where const by itself is enough to
provide guarantees (and I give such an example elsewhere in this thread).
However, the situations where that's
On 8/18/2012 9:59 AM, Jonathan M Davis wrote:
That's not quite true. There _are_ cases where const by itself is enough to
provide guarantees (and I give such an example elsewhere in this thread).
However, the situations where that's the case are quite limited, because the
compiler has to be able
On Saturday, 18 August 2012 at 11:26:01 UTC, Peter Alexander
wrote:
In D, const without immutable is meaningless.
lol, that was the whole point of this question... the whole point
of Jon's example was to show it's not meaningless even without
immutable. :)
On Saturday, 18 August 2012 at 20:22:59 UTC, Mehrdad wrote:
On Saturday, 18 August 2012 at 11:26:01 UTC, Peter Alexander
wrote:
In D, const without immutable is meaningless.
lol, that was the whole point of this question... the whole
point of Jon's example was to show it's not meaningless
On Saturday, 18 August 2012 at 22:04:21 UTC, Peter Alexander
wrote:
On Saturday, 18 August 2012 at 20:22:59 UTC, Mehrdad wrote:
On Saturday, 18 August 2012 at 11:26:01 UTC, Peter Alexander
wrote:
In D, const without immutable is meaningless.
lol, that was the whole point of this question...
On 8/18/2012 4:28 PM, Mehrdad wrote:
Right, most optimizations are not applicable to general cases.
That's pretty much always true with optimizations.
On Friday, 17 August 2012 at 02:14:22 UTC, Jonathan M Davis
wrote:
What I meant is that you know that nothing was altered through
the reference that the getter returned. You don't have any
such guarantee in C++.
Please reread what Jonathan has written above and look at my
example below:
On 8/16/2012 5:51 PM, Torarin wrote:
The C++ standard, section 7.1.6.1:
Except that any class member declared mutable (7.1.1) can be modified,
any attempt to modify a const
object during its lifetime (3.8) results in undefined behavior.
That applies to a const object, i.e. an object
On 8/16/2012 6:43 PM, Mehrdad wrote:
On Friday, 17 August 2012 at 01:25:18 UTC, Chris Cain wrote:
Yeah. Again, you can't modify __the const view__.
Isn't that kinda useless, if it tells you nothing about the object itself?
It means you can write code that can process both mutable and
On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
If you did, then the code would be invalid, and the compiler
could simply format your C: drive instead of modifying the
object.
This is probably the worst discussion point when people talk of
why undefined behavior is bad.
It is
On Friday, 17 August 2012 at 20:46:02 UTC, Walter Bright wrote:
On 8/16/2012 6:43 PM, Mehrdad wrote:
On Friday, 17 August 2012 at 01:25:18 UTC, Chris Cain wrote:
Yeah. Again, you can't modify __the const view__.
Isn't that kinda useless, if it tells you nothing about the
object itself?
It
On Friday, 17 August 2012 at 21:25:31 UTC, Jesse Phillips wrote:
On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
If you did, then the code would be invalid, and the compiler
could simply format your C: drive instead of modifying the
object.
This is probably the worst discussion
On 8/17/2012 2:34 PM, Mehrdad wrote:
On Friday, 17 August 2012 at 20:46:02 UTC, Walter Bright wrote:
On 8/16/2012 6:43 PM, Mehrdad wrote:
On Friday, 17 August 2012 at 01:25:18 UTC, Chris Cain wrote:
Yeah. Again, you can't modify __the const view__.
Isn't that kinda useless, if it tells you
On Friday, 17 August 2012 at 22:05:56 UTC, Walter Bright wrote:
I don't know what you're driving at.
Sorry... I tried to put it in the title. :\
On Friday, 17 August 2012 at 21:33:28 UTC, Mehrdad wrote:
On Friday, 17 August 2012 at 21:25:31 UTC, Jesse Phillips wrote:
On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
If you did, then the code would be invalid, and the compiler
could simply format your C: drive instead of
On Friday, 17 August 2012 at 22:05:56 UTC, Walter Bright wrote:
On 8/17/2012 2:34 PM, Mehrdad wrote:
On Friday, 17 August 2012 at 20:46:02 UTC, Walter Bright wrote:
On 8/16/2012 6:43 PM, Mehrdad wrote:
On Friday, 17 August 2012 at 01:25:18 UTC, Chris Cain wrote:
Yeah. Again, you can't modify
Something I'm having trouble undertanding/remembering (sorry,
you've probaby already explained it a billion times)...
I remember being told many times that D's 'const' provides
stronger guarantees than C++'s 'const'.
I just wanted to clarify, is that true for 'const' itself, or is
that
I remember being told many times that D's 'const' provides
stronger guarantees than C++'s 'const'.
I also remember being told that the compiler considers it UB to
cast away const-ness in references, unlike in C++, which gives
you more guarantees.
But I'm having trouble coming up with a
On Thursday, 16 August 2012 at 22:14:31 UTC, Mehrdad wrote:
Something I'm having trouble undertanding/remembering (sorry,
you've probaby already explained it a billion times)...
I remember being told many times that D's 'const' provides
stronger guarantees than C++'s 'const'.
If it's the
On Thursday, 16 August 2012 at 23:18:08 UTC, Jesse Phillips wrote:
Note that stronger guarentees does not translate to inferences
done by the compiler.
I remember being told (correct me if I'm wrong) that D's const
lets the compiler perform better optimizations than C++, which
i.e. means the
On Friday, August 17, 2012 01:35:46 Mehrdad wrote:
The main thing given is transitivity.
Sure, but what kind of an advantage does that provide compared to
C++?
(As in, a code sample would be awesome -- it's so much easier to
explain with an example to compare, rather than with words.)
In
Mehrdad:
On the note of casting away const, I don't believe that is the
operation which is undefined, however modifying const is
undefined as it could be pointing to immutable data.
Oh, then that's not what I'd understood. Seems just like C++
then.
Are you sure?
bye,
bearophile
On Friday, 17 August 2012 at 00:32:03 UTC, Mehrdad wrote:
Not correct, as far as I understand.
C++ only lets you cast away _const references_ to _mutable_
objects.
If the object happens to have been const _itself_, then that's
undefined behavior.
Er, minor correction:
By casting away const
On Friday, 17 August 2012 at 00:10:52 UTC, Jonathan M Davis wrote:
In C++, if you have
const vectorT* getStuff() const;
which returns a member variable, then as long as const isn't
cast away, you know that the container itself won't have any
elements added or removed from it, but you have
On Friday, 17 August 2012 at 00:13:58 UTC, bearophile wrote:
Mehrdad:
On the note of casting away const, I don't believe that is
the operation which is undefined, however modifying const is
undefined as it could be pointing to immutable data.
Oh, then that's not what I'd understood. Seems
On Friday, August 17, 2012 02:32:01 Mehrdad wrote:
C++ makes no such guarantees, because you're free to cast away
const and modifiy objects
Not correct, as far as I understand.
C++ only lets you cast away _const references_ to _mutable_
objects.
If the object happens to have been const
On Friday, 17 August 2012 at 00:32:03 UTC, Mehrdad wrote:
On Friday, 17 August 2012 at 00:10:52 UTC, Jonathan M Davis
wrote:
In contrast, in D,
const ref Array!(T*) getStuff() const;
you would _know_ that not only is the container not altered,
but you know that the elements aren't altered
2012/8/17 Jonathan M Davis jmdavisp...@gmx.com
On Friday, August 17, 2012 02:32:01 Mehrdad wrote:
C++ makes no such guarantees, because you're free to cast away
const and modifiy objects
Not correct, as far as I understand.
C++ only lets you cast away _const references_ to _mutable_
On Friday, 17 August 2012 at 00:44:20 UTC, Chris Cain wrote:
Also, D's const is _not_ a guarantee that there are no mutable
references to something. That'd be immutable.
And, by the way, I'd call this a bug (not sure if reported yet):
int yourGlobalCounter;
struct S
{
int*[] items;
On Friday, 17 August 2012 at 00:44:20 UTC, Chris Cain wrote:
On Friday, 17 August 2012 at 00:32:03 UTC, Mehrdad wrote:
On Friday, 17 August 2012 at 00:10:52 UTC, Jonathan M Davis
wrote:
In contrast, in D,
const ref Array!(T*) getStuff() const;
you would _know_ that not only is the container
On Friday, 17 August 2012 at 00:51:55 UTC, Torarin wrote:
The C++ standard, section 7.1.6.1:
Except that any class member declared mutable (7.1.1) can be
modified, any attempt to modify a const object during its
lifetime (3.8) results in undefined behavior.
Torarin
+1 thanks for taking
On Friday, 17 August 2012 at 01:17:19 UTC, Mehrdad wrote:
How?
Jon said you know that the elements aren't altered either - or
anything which the elements point to.
I just showed that the const-ness of getStuff() tells you
_nothing_ about that fact.
Did I miss something?
Yeah. Again,
Just to be abundantly clear about his point.
// v is a const vector, but holds pointers ...
*v[0] = 5; // legal in C++, illegal in D (except in constructors
which will allow this, ATM)
Transitivity gives you more information and guarantees about what
you can and can't do with your view.
On Friday, 17 August 2012 at 01:25:18 UTC, Chris Cain wrote:
Yeah. Again, you can't modify __the const view__.
Isn't that kinda useless, if it tells you nothing about the
object itself?
Also note that Jon __clearly__ said:
you know that the elements aren't altered either anything which
the elements point to.
He was clearly _not_ talking about modifying the pointer.
He said you cannot alter the elements pointed TO.
Given that, I have no idea how that is supposed to be
On Friday, 17 August 2012 at 01:43:03 UTC, Mehrdad wrote:
Isn't that kinda useless, if it tells you nothing about the
object itself?
Not sure what your point is. It tells you enough about how you
work with that object itself and sets (real) boundaries which
is unlike C++'s const which tells
On Friday, 17 August 2012 at 01:45:27 UTC, Mehrdad wrote:
He was clearly _not_ talking about modifying the pointer.
He said you cannot alter the elements pointed TO.
Given that, I have no idea how that is supposed to be saying
you can't modify the const _view_. He's clearly talking about
the
On Friday, 17 August 2012 at 01:33:29 UTC, Chris Cain wrote:
Also, if the only view of the data you have is that const view,
it's effectively the same as immutable (it couldn't be changed
by any valid code).
So you're saying casting away a const _pointer_ is undefined,
even if the target
On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
So you're saying casting away a const _pointer_ is undefined,
even if the target was originally created as mutable.
(Otherwise, the code would certainly be valid, just like in
C++.)
Which means you can effectively _never_ cast away
On Friday, August 17, 2012 03:52:38 Chris Cain wrote:
On Friday, 17 August 2012 at 01:45:27 UTC, Mehrdad wrote:
He was clearly _not_ talking about modifying the pointer.
He said you cannot alter the elements pointed TO.
Given that, I have no idea how that is supposed to be saying
On Friday, August 17, 2012 03:51:36 Mehrdad wrote:
On Friday, 17 August 2012 at 01:33:29 UTC, Chris Cain wrote:
Also, if the only view of the data you have is that const view,
it's effectively the same as immutable (it couldn't be changed
by any valid code).
So you're saying casting away
On Friday, August 17, 2012 03:00:34 Chris Cain wrote:
On Friday, 17 August 2012 at 00:44:20 UTC, Chris Cain wrote:
Also, D's const is _not_ a guarantee that there are no mutable
references to something. That'd be immutable.
And, by the way, I'd call this a bug (not sure if reported yet):
On Friday, 17 August 2012 at 01:50:02 UTC, Chris Cain wrote:
On Friday, 17 August 2012 at 01:43:03 UTC, Mehrdad wrote:
Isn't that kinda useless, if it tells you nothing about the
object itself?
Not sure what your point is. It tells you enough about how you
work with that object itself
Are
On Friday, 17 August 2012 at 02:02:56 UTC, Jonathan M Davis wrote:
How is it a bug? The variable that you're altering is not part
of the object.
It doesn't need to be.
What you said was:
If you have a const object, then you have the guarantee that
none of what it contains or refers to
On Friday, 17 August 2012 at 01:59:03 UTC, Chris Cain wrote:
On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
So you're saying casting away a const _pointer_ is undefined,
even if the target was originally created as mutable.
(Otherwise, the code would certainly be valid, just like in
On Friday, August 17, 2012 02:32:01 Mehrdad wrote:
On Friday, 17 August 2012 at 00:10:52 UTC, Jonathan M Davis wrote:
In C++, if you have
const vectorT* getStuff() const;
which returns a member variable, then as long as const isn't
cast away, you know that the container itself won't
On Friday, August 17, 2012 03:59:01 Chris Cain wrote:
If you're absolutely 100% completely totally certain that the
data is mutable (i.e., you have confirmed either through good,
sound reasoning OR you have some method of seeing exactly where
it is stored in your RAM and you've checked that
On Friday, 17 August 2012 at 02:02:51 UTC, Jonathan M Davis wrote:
Because there are plenty of functions which take mutable
objects but don't actually alter them - particularly when
interacting with C code.
Ah, so that explains that, thanks.
So to clarify, modifying a mutable object
On Friday, 17 August 2012 at 02:09:09 UTC, Mehrdad wrote:
On Friday, 17 August 2012 at 02:02:56 UTC, Jonathan M Davis
wrote:
How is it a bug? The variable that you're altering is not part
of the object.
It doesn't need to be.
Not to say it /can't/ be, of course... a const method can
On Friday, August 17, 2012 04:12:10 Mehrdad wrote:
On Friday, 17 August 2012 at 02:02:51 UTC, Jonathan M Davis wrote:
Because there are plenty of functions which take mutable
objects but don't actually alter them - particularly when
interacting with C code.
Ah, so that explains that,
On Friday, 17 August 2012 at 02:25:22 UTC, Jonathan M Davis wrote:
Yeah. It's more than C++, but it's still pretty limited without
pure, and if even with pure, the optimizations can still be
pretty limited.
Yeah, I'm only worried about the language here, not the
implementation.
On
On Friday, 17 August 2012 at 02:01:11 UTC, Mehrdad wrote:
...snip...
Are you sure?
I've already responded to something that is equivalent to what
you just posted. I'm not sure if you're intentionally being
obtuse (I'll give you the benefit of the doubt) or if your eyes
are glossing over
On Friday, August 17, 2012 04:30:42 Mehrdad wrote:
So unless you're expecting the compiler to have the
implementation for the entire class available in order for it to
be able to do any kind of optimization (in which case, it would
have to do a whole bunch of inference to figure out the
On Friday, 17 August 2012 at 02:02:56 UTC, Jonathan M Davis wrote:
How is it a bug? The variable that you're altering is not part
of the object.
That's part of why having pure with const in so valuable. It
prevents stuff
like what you're doing here.
- Jonathan M Davis
Notice that I'm
On Friday, 17 August 2012 at 02:33:46 UTC, Chris Cain wrote:
I've already responded to something that is equivalent to what
you just posted. I'm not sure if you're intentionally being
obtuse (I'll give you the benefit of the doubt)
Thanks... I promise I'm not __ I'm just having trouble seeing
On Friday, 17 August 2012 at 02:49:45 UTC, Jonathan M Davis wrote:
But take this code for example:
auto i = new int;
*i = 5;
const c = i;
writeln(c);
func(c); //obviously takes const or it wouldn't compile
writeln(c);
The compiler _knows_ that c is the same before and after the
call to func,
Well, since I'm not describing how const works anymore (although,
it's still different than C++ due to the mutable keyword in C++,
but I digress), I'll go ahead and jump in for this one...
On Friday, 17 August 2012 at 02:30:45 UTC, Mehrdad wrote:
So unless you're expecting the compiler to have
On Friday, 17 August 2012 at 03:36:28 UTC, Chris Cain wrote:
Combine const and pure
Yes, I 100% realize 'pure' and 'immutable' are advantages over
C++.
The question was about 'const' by itself, though, because
otherwise that's not a fair comparison. (The goal is comparing
C++ const to D
On Friday, 17 August 2012 at 03:42:23 UTC, Mehrdad wrote:
On Friday, 17 August 2012 at 03:36:28 UTC, Chris Cain wrote:
Combine const and pure
Yes, I 100% realize 'pure' and 'immutable' are advantages over
C++.
The question was about 'const' by itself, though, because
otherwise that's not a
On Friday, 17 August 2012 at 03:42:23 UTC, Mehrdad wrote:
Yes, I 100% realize 'pure' and 'immutable' are advantages over
C++.
The question was about 'const' by itself, though, because
otherwise that's not a fair comparison. (The goal is comparing
C++ const to D const, not C++ const to D const
On Friday, August 17, 2012 05:11:49 Mehrdad wrote:
On Friday, 17 August 2012 at 02:49:45 UTC, Jonathan M Davis wrote:
But take this code for example:
auto i = new int;
*i = 5;
const c = i;
writeln(c);
func(c); //obviously takes const or it wouldn't compile
writeln(c);
The
On Friday, August 17, 2012 04:46:34 Chris Cain wrote:
Notice that I'm making an immutable(S) in that example.
I missed that. It's a known bug and in bugzilla somewhere. I'd have to go
digging to find the exact bug# though. const constructors have the same
problem.
- Jonathan M Davis
On Friday, 17 August 2012 at 03:57:21 UTC, Chris Cain wrote:
On Friday, 17 August 2012 at 03:42:23 UTC, Mehrdad wrote:
Yes, I 100% realize 'pure' and 'immutable' are advantages over
C++.
The question was about 'const' by itself, though, because
otherwise that's not a fair comparison. (The goal
On Friday, 17 August 2012 at 03:44:38 UTC, Mehrdad wrote:
To clarify... the motivation for this question in the first
place was the fact that I've been consistently told (and have
read) that D const provides more guarantees than C++ const, so
I was trying to figure out how.
If what you're
On Friday, 17 August 2012 at 04:17:05 UTC, Jonathan M Davis wrote:
On Friday, August 17, 2012 05:11:49 Mehrdad wrote:
On Friday, 17 August 2012 at 02:49:45 UTC, Jonathan M Davis
wrote:
But take this code for example:
auto i = new int;
*i = 5;
const c = i;
writeln(c);
func(c);
On Friday, 17 August 2012 at 04:17:33 UTC, Mehrdad wrote:
Okay so basically, the conclusion I'm drawing is that you have
to combine it with pure/immutable in order to get much more out
of it than compared with C++; otherwise, it's not really
different.
Thanks!
You posted this before seeing
On Friday, 17 August 2012 at 04:25:42 UTC, Chris Cain wrote:
On Friday, 17 August 2012 at 04:17:33 UTC, Mehrdad wrote:
Okay so basically, the conclusion I'm drawing is that you have
to combine it with pure/immutable in order to get much more
out of it than compared with C++; otherwise, it's
74 matches
Mail list logo
