On Sunday, February 16, 2014 06:55:36 Stanislav Blinov wrote:
On Sunday, 16 February 2014 at 06:28:45 UTC, Jonathan M Davis
wrote:
On Sunday, February 16, 2014 03:25:08 Stanislav Blinov wrote:
On Saturday, 15 February 2014 at 04:03:51 UTC, Adam D. Ruppe
wrote:
What about a library
IMHO only practically usable logical const alternative in D are
getters (in absence of setters). For all other cases better to
simply abandon the concept, it simply does not fit the type
system.
On Saturday, February 15, 2014 04:03:50 Adam D. Ruppe wrote:
D doesn't have logical const, but sometimes it is useful,
especially with lazy initialization of a field, and we can kinda
fake it with casts or with global variables. Modifying an
immutable object is undefined behavior, so how can
On Saturday, 15 February 2014 at 10:52:25 UTC, Jonathan M Davis
wrote:
If you want logical const, don't use const or immutable at all.
To do so is
undefined as they require physical constness/immutability. So,
if you want
logical const, you need to indicate constness in some other way
that's
If you want logical const in D, you just don't use const. If you
try to hack around it, it will just come back and bite you.
As a result, when writing APIs, don't enforce constness of your
parameters if you require logical const. e.g. a range will not
necessarily have const front and empty
On Saturday, 15 February 2014 at 12:23:54 UTC, Peter Alexander
wrote:
If you want logical const in D, you just don't use const. If
you try to hack around it, it will just come back and bite you.
As a result, when writing APIs, don't enforce constness of your
parameters if you require logical
On 02/15/2014 08:34 PM, Jesse Phillips wrote:
But mutating a mutable address is still valid, so as long as _you_
guarantee the address is not immutable, no it won't format your harddrive.
class C{ bool doit = true; }
void foo(const(C) c)pure{ (cast()C).doit = false; }
void main(){
auto c
On Saturday, 15 February 2014 at 12:23:54 UTC, Peter Alexander
wrote:
If you want logical const in D, you just don't use const. If
you try to hack around it, it will just come back and bite you.
As a result, when writing APIs, don't enforce constness of your
parameters if you require logical
On Saturday, 15 February 2014 at 19:59:07 UTC, Meta wrote:
inout is *sort of* logical const, if the underlying type is
immutable.
I mean mutable, of course.
On Sat, 15 Feb 2014 15:02:44 -0500, Meta jared...@gmail.com wrote:
On Saturday, 15 February 2014 at 19:59:07 UTC, Meta wrote:
inout is *sort of* logical const, if the underlying type is immutable.
I mean mutable, of course.
No, it's not. It's not allowed to mutate with inout.
-Steve
On Sunday, 16 February 2014 at 02:34:36 UTC, Steven Schveighoffer
wrote:
On Sat, 15 Feb 2014 15:02:44 -0500, Meta jared...@gmail.com
wrote:
On Saturday, 15 February 2014 at 19:59:07 UTC, Meta wrote:
inout is *sort of* logical const, if the underlying type is
immutable.
I mean mutable
On Fri, 14 Feb 2014 23:03:50 -0500, Adam D. Ruppe
destructiona...@gmail.com wrote:
D doesn't have logical const, but sometimes it is useful, especially
with lazy initialization of a field, and we can kinda fake it with casts
or with global variables. Modifying an immutable object
of* logical const, if the underlying type is immutable.
I mean mutable, of course.
No, it's not. It's not allowed to mutate with inout.
-Steve
Right, but inout can accept any of mutable, const, and mutable. The
compiler will statically disallow you from mutating an inout variable,
but if you know
logicalConstBump(T)(ref inout(T) t, string
originalMutability)
{
if (originalMutability == mutable)
{
cast(T)t += 1;
}
else
{
assert(0);
}
}
Obviously this is extremely contrived, but inout is effectively
logical const here. Is there no way to know what the original
On Sat, 15 Feb 2014 22:04:25 -0500, Meta jared...@gmail.com wrote:
Obviously this is extremely contrived, but inout is effectively logical
const here. Is there no way to know what the original mutability of t
is at compile-time?
No, because only one version of the function is generated
On Sunday, 16 February 2014 at 03:16:16 UTC, Steven Schveighoffer
wrote:
On Sat, 15 Feb 2014 22:04:25 -0500, Meta jared...@gmail.com
wrote:
Obviously this is extremely contrived, but inout is
effectively logical const here. Is there no way to know what
the original mutability of t
On Saturday, 15 February 2014 at 04:03:51 UTC, Adam D. Ruppe
wrote:
What about a library solution for something like C++-esque
mutable?
struct Mutable(T)
{
private T val;
this(T v) { val = v; }
@property ref T get() const { return *cast(T*)val; }
alias get this;
}
import
On Sat, 15 Feb 2014 22:17:48 -0500, Meta jared...@gmail.com wrote:
On Sunday, 16 February 2014 at 03:16:16 UTC, Steven Schveighoffer wrote:
On Sat, 15 Feb 2014 22:04:25 -0500, Meta jared...@gmail.com wrote:
Obviously this is extremely contrived, but inout is effectively
logical const here
as logical const within that function, as the compiler
doesn't allow you to modify the inout function argument but it is
safe to cast away inout. Do you agree or disagree with this?
pass
mutable data to an inout function, inout effectively acts as logical
const within that function, as the compiler doesn't allow you to modify
the inout function argument but it is safe to cast away inout. Do you
agree or disagree with this?
It is safe if you can guarantee the input
On Sunday, 16 February 2014 at 04:46:34 UTC, Steven Schveighoffer
wrote:
It is safe if you can guarantee the input is ultimately
mutable. But there is no way to enforce such a guarantee. It is
on the caller to make sure that is true.
I don't see why inout should be identified as any different
On Sun, 16 Feb 2014 00:14:07 -0500, Meta jared...@gmail.com wrote:
On Sunday, 16 February 2014 at 04:46:34 UTC, Steven Schveighoffer wrote:
It is safe if you can guarantee the input is ultimately mutable. But
there is no way to enforce such a guarantee. It is on the caller to
make sure that
On Sun, 16 Feb 2014 00:22:33 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
The problem you have to solve is this:
void foo(const(int) t)
Gahh... should have been:
void foo(ref const(int) t)
-Steve
On Sunday, February 16, 2014 03:25:08 Stanislav Blinov wrote:
On Saturday, 15 February 2014 at 04:03:51 UTC, Adam D. Ruppe
wrote:
What about a library solution for something like C++-esque
mutable?
You're casting away const if you do that, and that's precisely what you
shouldn't be doing.
mutable data to an inout function, inout effectively
acts as logical const within that function, as the compiler
doesn't allow you to modify the inout function argument but it is
safe to cast away inout. Do you agree or disagree with this?
And that would be pointless. If a parameter is inout, then you
On Sunday, 16 February 2014 at 06:28:45 UTC, Jonathan M Davis
wrote:
On Sunday, February 16, 2014 03:25:08 Stanislav Blinov wrote:
On Saturday, 15 February 2014 at 04:03:51 UTC, Adam D. Ruppe
wrote:
What about a library solution for something like C++-esque
mutable?
You're casting away const
D doesn't have logical const, but sometimes it is useful,
especially with lazy initialization of a field, and we can kinda
fake it with casts or with global variables. Modifying an
immutable object is undefined behavior, so how can we avoid that,
and if not, try to minimize the problems
I have an idea on how to create logical const without any language or
compiler changes -- it will exist purely in druntime.
The idea is based on this: Whenever you allocate an object, you use a
memory block. An object, by default, has the following memory layout:
monitor - (void
On 14-05-2012 21:51, Steven Schveighoffer wrote:
I have an idea on how to create logical const without any language or
compiler changes -- it will exist purely in druntime.
The idea is based on this: Whenever you allocate an object, you use a
memory block. An object, by default, has
On Mon, May 14, 2012 at 03:51:09PM -0400, Steven Schveighoffer wrote:
I have an idea on how to create logical const without any language
or compiler changes -- it will exist purely in druntime.
[...]
In essence, a const(MyObj) is a pointer to a struct that looks like:
struct
On 14.05.2012 23:51, Steven Schveighoffer wrote:
I have an idea on how to create logical const without any language or
compiler changes -- it will exist purely in druntime.
The idea is based on this: Whenever you allocate an object, you use a
memory block. An object, by default, has
On Mon, 14 May 2012 15:56:37 -0400, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
On 14-05-2012 21:51, Steven Schveighoffer wrote:
It also should be recommended that the scratch space not contain any GC
pointers, since it's *not* participating in the type system properly,
the GC may not
On 14-05-2012 22:13, Steven Schveighoffer wrote:
On Mon, 14 May 2012 15:56:37 -0400, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
On 14-05-2012 21:51, Steven Schveighoffer wrote:
It also should be recommended that the scratch space not contain any GC
pointers, since it's *not*
On 14-05-2012 21:51, Steven Schveighoffer wrote:
I have an idea on how to create logical const without any language or
compiler changes -- it will exist purely in druntime.
The idea is based on this: Whenever you allocate an object, you use a
memory block. An object, by default, has
On 14-05-2012 23:06, Alex Rønne Petersen wrote:
On 14-05-2012 22:13, Steven Schveighoffer wrote:
On Mon, 14 May 2012 15:56:37 -0400, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
On 14-05-2012 21:51, Steven Schveighoffer wrote:
It also should be recommended that the scratch space not
On Mon, 14 May 2012 17:11:14 -0400, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
Another concern I have is that this couples a feature tightly to the
implementation of the GC. What if another GC doesn't use the same
allocation scheme?
newScratchSpace uses GC.malloc to ensure the block is
Schveighoffer
schvei...@yahoo.com wrote:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
[snip]
What do people think about this?
This is what
Kjaeraas
simen.kja...@gmail.com wrote:
On Thu, 29 Sep 2011 16:54:24 +0200, Steven Schveighoffer
schvei...@yahoo.com wrote:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler
Steven Schveighoffer , dans le message (digitalmars.D:145821), a
écrit :
If const must be a part of the signature, then you have lost the typeless
aspect of the context pointer. If we expose the const (or not const)
nature of the pointer, then you lose the interoperability that delegates
Am 29.09.2011, 16:54 Uhr, schrieb Steven Schveighoffer
schvei...@yahoo.com:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
Here's the code
On 2011-09-29 14:54:24 +, Steven Schveighoffer
schvei...@yahoo.com said:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
Here's the code
On Fri, 30 Sep 2011 12:16:03 -0400, Christophe
trav...@phare.normalesup.org wrote:
Steven Schveighoffer , dans le message (digitalmars.D:145821), a
écrit :
If const must be a part of the signature, then you have lost the
typeless
aspect of the context pointer. If we expose the const (or
On Fri, 30 Sep 2011 13:38:31 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2011-09-29 14:54:24 +, Steven Schveighoffer
schvei...@yahoo.com said:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage
On Fri, 30 Sep 2011 13:46:13 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
Simen Kjaeraas and Christophe brought up the same points. I filed a bug
on it:
http://d.puremagic.com/issues/show_bug.cgi?id=6741
Also now:
http://d.puremagic.com/issues/show_bug.cgi?id=6747
-Steve
a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
Here's the code, then I'll talk about the implications:
import std.stdio;
class D
{
D getme() { return this;}
void foo() {writeln
Schveighoffer
schvei...@yahoo.com said:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works
without changes to the current compiler (and requires no casts).
Here's the code, then I'll talk about the implications
On 2011-09-30 18:07:54 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Fri, 30 Sep 2011 14:00:36 -0400, Michel Fortin
michel.for...@michelf.com wrote:
Interesting proposal. You realize if we had a true 'mutable' storage
class for class members it could obey the same rule as you
Steven Schveighoffer , dans le message (digitalmars.D:145850), a
As long as you assume the context pointer is part of the state of the
aggregate, then yes. But I don't see it that way. The context pointer is
part of the state of the delegate, and the delegate reference itself is
the
On Fri, 30 Sep 2011 14:51:19 -0400, Christophe
trav...@phare.normalesup.org wrote:
Steven Schveighoffer , dans le message (digitalmars.D:145850), a
This also doesn't work:
Indeed. The compiler should not allow the implicit conversion of
globalFoo to immutable.
class Foo
{
this(ref
Steven Schveighoffer , dans le message (digitalmars.D:145867), a
écrit :
But ref int _i is the parameter to the constructor. Here is where your
proposal breaks down.
It's entirely feasible for class Foo to be compiled *separately* from the
module that contains globalFoo. And it's also
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
Here's the code, then I'll talk about the implications:
import std.stdio;
class D
{
D getme
On Thu, 29 Sep 2011 16:54:24 +0200, Steven Schveighoffer
schvei...@yahoo.com wrote:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
[snip
of mutable data that the object would require and should
not be cleared (like the parent Widget in the other example you gave).
the mutable member is not marked as shared. It cannot be accessed on a
shared instance. I guess it should be explicitly noted that a logical
const notation
that it
constitutes full logical const, only a limited form of it. More
concretely, it doesn't constitute logical const in in the sense where
you can use that as argument to say logical const already exists,
it's just clunky to use, so let's add it to the language formally.
Like if mutable members where
on this newsgroup, and I argued for
it
for a long time. You will not get any traction with Walter, because
I've already proven that logical const == const, and it still doesn't
change his mind.
Could you detail a bit what do you mean by logical const == const ?
That doesn't sound right to me
any traction with Walter, because
I've already proven that logical const == const, and it still doesn't
change his mind.
Could you detail a bit what do you mean by logical const == const ?
That doesn't sound right to me.
Here is where I show how logical const already exists, it's just clunky
time. You will not get any traction with Walter, because
I've already proven that logical const == const, and it still doesn't
change his mind.
Could you detail a bit what do you mean by logical const == const ?
That doesn't sound right to me.
Here is where I show how logical const already
discussed at length on this newsgroup, and I argued for
it
for a long time. You will not get any traction with Walter, because
I've already proven that logical const == const, and it still doesn't
change his mind.
Could you detail a bit what do you mean by logical const == const ?
That doesn't
On Fri, 03 Dec 2010 08:22:01 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
The above are not trivial differences, so I do not agree that it
constitutes full logical const, only a limited
On 03/12/2010 13:00, Bruno Medeiros wrote:
(if you manage to mutate it without casts in a pure function, it's
because of a compiler bug)
Fresh from this discussion:
http://d.puremagic.com/issues/show_bug.cgi?id=5311
--
Bruno Medeiros - Software Engineer
On 03/12/2010 13:22, Steven Schveighoffer wrote:
On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
The above are not trivial differences, so I do not agree that it
constitutes full logical const, only a limited form of it. More
concretely, it doesn't
that it
constitutes full logical const, only a limited form of it. More
concretely, it doesn't constitute logical const in in the sense where
you can use that as argument to say logical const already exists,
it's just clunky to use, so let's add it to the language formally.
Like if mutable members where just
On 02/12/2010 09:18, Don wrote:
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable
args and again for mutable ones.
Doesn't
that the object would require and should not be cleared (like the parent
Widget in the other example you gave).
the mutable member is not marked as shared. It cannot be accessed on a
shared instance. I guess it should be explicitly noted that a logical
const notation (such as 'mutable') would
On 3-dic-10, at 17:23, Bruno Medeiros wrote:
On 03/12/2010 13:22, Steven Schveighoffer wrote:
On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
The above are not trivial differences, so I do not agree that it
constitutes full logical const, only
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable
args and again for mutable ones.
Doesn't 'inout' do almost the same thing?
lock) in
https://github.com/fawzi/blip/blob/master/blip/parallel/smp/DataFlowVar.d
using D1
I've taken many example use-cases for logical const and added them
as unittests. I think it is fairly reasonable if I could just get an
answer to my question about concurrency and declaring
the widget-renderer relationship outside
the widget. Since each widget has exactly one location where it
lives, this is awkward. Much better to just store the relationship
on each widget.
indeed that is one of the main things that I want from logical const:
being able to store/memoize values
On 01/12/2010 21:09, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 16:53:14 -0500, Walter Bright
newshou...@digitalmars.com wrote:
Steven Schveighoffer wrote:
If you find the above unsurprising, you are in the minority. I find
it surprising, and invalid that anyone would write code this
On Thursday, December 02, 2010 01:18:31 Don wrote:
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable
args and again
On 29/11/2010 23:04, Walter Bright wrote:
Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 15:58:10 -0500, Walter Bright
newshou...@digitalmars.com wrote:
Steven Schveighoffer wrote:
Having a logical const feature in D would not be a convention, it
would be enforced, as much as const
On 29/11/2010 14:56, Steven Schveighoffer wrote:
This has been discussed at length on this newsgroup, and I argued for it
for a long time. You will not get any traction with Walter, because
I've already proven that logical const == const, and it still doesn't
change his mind.
Could you detail
...
Surely I'm not the only person that finds something *incredibly* wrong
with this!?
Indeed, you should not try to use D's const for the use-case of logical
const. Rather, logical const is simply not supported, on a static type
level.
But why is that such a big problem actually? A lot
Don wrote:
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable
args and again for mutable ones.
Doesn't 'inout' do almost the
Jonathan M Davis wrote:
On Thursday, December 02, 2010 01:18:31 Don wrote:
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable
On Thu, 02 Dec 2010 15:25:49 -0500, Don nos...@nospam.com wrote:
Jonathan M Davis wrote:
On Thursday, December 02, 2010 01:18:31 Don wrote:
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
c. But a C
could store some data in a global variable, possibly even uniquely
associated with each instance (I have shown this in a very old post
proving logical const == const). Then logically, the author of C could
consider that data a part of C. I have no way to stop him from editing
?
It guarantees something very focused, and possible to work around without
resorting to unsafe code. That's my point. The guarantee is well-defined
and useful because it helps write correct code, but I don't see how a
logical const guarantee is mythical whereas D's current const guarantee
proven that logical const == const, and it still doesn't
change his mind.
Could you detail a bit what do you mean by logical const == const ? That
doesn't sound right to me.
Here is where I show how logical const already exists, it's just clunky to
use.
BTW, this was before TLS, so
Don Wrote:
Jonathan M Davis wrote:
On Thursday, December 02, 2010 01:18:31 Don wrote:
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once
with Walter, because
I've already proven that logical const == const, and it still doesn't
change his mind.
Could you detail a bit what do you mean by logical const == const ?
That doesn't sound right to me.
Here is where I show how logical const already exists, it's just clunky
to use.
BTW
Steven Schveighoffer wrote:
I have shown examples of how const does not guarantee an object's state
doesn't change.
Yes, as is well documented, const is a read only view. It is not immutable. That
is why immutable is a separate attribute.
On Tue, 30 Nov 2010 15:03:43 -0800
Walter Bright newshou...@digitalmars.com wrote:
Andrew Wiley wrote:
I've been following this thread on and off, but is there a definition
somewhere of exactly what const means in D2 and exactly what that
guaranties or doesn't guaranty?
Const
On Wednesday 01 December 2010 03:13:08 spir wrote:
On Tue, 30 Nov 2010 15:03:43 -0800
Walter Bright newshou...@digitalmars.com wrote:
Andrew Wiley wrote:
I've been following this thread on and off, but is there a definition
somewhere of exactly what const means in D2 and exactly what
On Wed, 1 Dec 2010 03:22:39 -0800
Jonathan M Davis jmdavisp...@gmx.com wrote:
What would be the consequences if D had no const, only immutable (that,
IIUC, removes the latter non-guarantee)?
The biggest problem would be that no function could then work on both a
mutable
and an
On 11/29/2010 11:56 PM, Steven Schveighoffer wrote:
On Sat, 20 Nov 2010 09:21:04 -0500, Peter Alexander
peter.alexander...@gmail.com wrote:
D does not support logical const due to the weak guarantees that it
provides.
So, without logical const, how are D users supposed to provide lazy
Most likely not. How do you say that the 'draw' function switches the
widget to a different parameterized type? With const, you can just slap
a const on the end of the function.
Here is some example of what I mean:
class Widget
{
mutable Window location;
int x, y, width, height;
Since i called it a bad design, i am entitled to introduce a better design.
interface renderer {
void draw(rect rects, size_t n);
}
class widget {
void draw(renderer r) { ... }
}
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
On Wed, 01 Dec 2010 18:38:23 +0200, so s...@so.do wrote:
Since i called it a bad design, i am entitled to introduce a better
design.
interface renderer {
void draw(rect rects, size_t n);
}
class widget {
void draw(renderer r) { ... }
}
Pfft sorry for that abomination!
. It could prevent the modifiable parts from influencing the result, but
then the requested caching isn't possible.
Please let me know if i wrote something that doesn't make sense.
Jordi
I do not believe you will run into issues with casting in a const function if
logical const is truely happening
On Wednesday, December 01, 2010 06:17:56 spir wrote:
On Wed, 1 Dec 2010 03:22:39 -0800
Jonathan M Davis jmdavisp...@gmx.com wrote:
What would be the consequences if D had no const, only immutable (that,
IIUC, removes the latter non-guarantee)?
The biggest problem would be that no
spir wrote:
What would be the consequences if D had no const, only immutable (that, IIUC,
removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable args and
again for mutable ones.
Jonathan M Davis wrote:
Also, a classic example for the use of const which immutable doesn't help you
with it all is returning member variables by reference or which are reference
types when you don't want the caller to be able to modify them. Without const,
you couldn't do that. const is
so Wrote:
One another thing i don't quite get is why cast from immutable/const is
allowed.
Is it because of the cases that we know the function doesn't change
anything but still lacks the immutable/const signature?
Thank you!
I believe it is because cast doesn't do any checking. Cast
(I have shown this in a very old post proving logical
const == const). Then logically, the author of C could consider that data
a part of C. I have no way to stop him from editing that logical part of
C, I'm relying on the author of C not to count mutable state as part of
the state of C
On Wed, 01 Dec 2010 11:09:08 -0500, so s...@so.do wrote:
Most likely not. How do you say that the 'draw' function switches the
widget to a different parameterized type? With const, you can just
slap a const on the end of the function.
Here is some example of what I mean:
class Widget
{
On Wed, 01 Dec 2010 11:49:36 -0500, so s...@so.do wrote:
On Wed, 01 Dec 2010 18:38:23 +0200, so s...@so.do wrote:
Since i called it a bad design, i am entitled to introduce a better
design.
interface renderer {
void draw(rect rects, size_t n);
}
class widget {
void
On Wed, 01 Dec 2010 12:43:38 -0500, Jesse Phillips
jessekphillip...@gmail.com wrote:
Jordi Wrote:
On the other side, in D, it is a hint to the compiler but it will only
use it if is verifiable. If that is the case, why do we need the const
keyword in the first place? The compiler can
2. Why does Widget have a draw function?
Really?
Sorry about that one, it was a misunderstanding on my part, was thinking i
removed that.
And thanks for the reply!
associated with each instance (I have shown this in a very old post
proving logical const == const). Then logically, the author of C could
consider that data a part of C. I have no way to stop him from editing
that logical part of C, I'm relying on the author of C not to count
mutable state as part
1 - 100 of 217 matches
Mail list logo
