What compiler options is that with?
I used DMD and compiler flags -O -inline -release on x86_64 linux.
On Wed, May 2, 2012 at 9:38 AM, jerro a...@a.com wrote:
What compiler options is that with?
I used DMD and compiler flags -O -inline -release on x86_64 linux.
It may be slow relative to incrementing a integer:
65 seconds without any command line options.
54 seconds with -O -inline
On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
A little write-up I just did on something I thought was pretty
cool:
Combine Coroutines and Input Ranges for Dead-Simple D Iteration
SomeDude lovelyd...@mailmetrash.com wrote in message
news:ypakkndfsibcbgelj...@forum.dlang.org...
On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
A little write-up I just did on something I thought was pretty cool:
Combine Coroutines and Input Ranges for Dead-Simple D Iteration
It may be slow relative to incrementing a integer:
The opApply isn't just incrementing an integer - it's
calling a function through a pointer. A loop that just
increments an integer is an order of magnitude faster.
This code (I used assembly because a compiler would
optimize away such a simple
Nick Sabalausky seewebsitetocontac...@semitwist.com wrote in message
news:jnr241$nh1$1...@digitalmars.com...
SomeDude lovelyd...@mailmetrash.com wrote in message
news:ypakkndfsibcbgelj...@forum.dlang.org...
On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
A little write-up I
This project is finally published and documented, so here's an
announcement.
https://github.com/JakobOvrum/bootDoc
bootDoc is a configurable DDoc theme, with advanced JavaScript
features like a package tree and module tree, as well as fully
qualified symbol anchors. The style itself and
On 02.05.2012 22:26, Jakob Ovrum wrote:
Note about noscript: JavaScript is used to get around the static nature
of DDoc. The sidebar does not work without JavaScript, and neither do
fully qualified anchor names. However, anchors with ambiguous names
(such as those usable for symbols on
On 2012-05-02 20:26, Jakob Ovrum wrote:
This project is finally published and documented, so here's an
announcement.
https://github.com/JakobOvrum/bootDoc
bootDoc is a configurable DDoc theme, with advanced JavaScript features
like a package tree and module tree, as well as fully qualified
On Wednesday, 2 May 2012 at 18:26:11 UTC, Jakob Ovrum wrote:
This project is finally published and documented, so here's an
announcement.
https://github.com/JakobOvrum/bootDoc
bootDoc is a configurable DDoc theme, with advanced JavaScript
features like a package tree and module tree, as
While it would be nice if the nav tree were still there w/o JS, and I'm not
personally a fan of CSS(or HTML)-based frames, this is definitely a very
nice, clean, great-looking theme!
Am 01.05.2012 23:46, schrieb Sönke Ludwig:
I made a post with Steve Teale's MySQL driver as an example:
http://vibed.org/blog/posts/writing-native-db-drivers
There were some hidden gotchas, but I hope the current port doesn't
break anything from the original code.
Looks good. Unfortunately I
On Wednesday, 2 May 2012 at 21:42:21 UTC, Nick Sabalausky wrote:
While it would be nice if the nav tree were still there w/o JS,
and I'm not
personally a fan of CSS(or HTML)-based frames, this is
definitely a very
nice, clean, great-looking theme!
Alright, with some effort, I made it so that
On Wednesday, 2 May 2012 at 18:26:11 UTC, Jakob Ovrum wrote:
This project is finally published and documented, so here's an
announcement.
https://github.com/JakobOvrum/bootDoc
bootDoc is a configurable DDoc theme, with advanced JavaScript
features like a package tree and module tree, as
On 5/3/12 1:26 AM, Jakob Ovrum wrote:
This project is finally published and documented, so here's an
announcement.
https://github.com/JakobOvrum/bootDoc
bootDoc is a configurable DDoc theme, with advanced JavaScript features
like a package tree and module tree, as well as fully qualified
Chris Cain wrote in message news:nqgwunggifrgmwwhk...@forum.dlang.org...
What about the object do you want const? How should this object normally
change things? It looks like the way you've coded it, your connection will
get information off of a server.
I don't think you answered my
In C++, the compiler can't use it to provide any real guarantees, because
the programmer is free to violate const at any time via mutable or casting
away const.
Maybe I'm being stupid, but how is the case any different in D?
On Tuesday, May 01, 2012 23:14:06 Mehrdad wrote:
In C++, the compiler can't use it to provide any real guarantees, because
the programmer is free to violate const at any time via mutable or casting
away const.
Maybe I'm being stupid, but how is the case any different in D?
D's type
On Wednesday, 2 May 2012 at 05:25:40 UTC, Andrej Mitrovic wrote:
On 5/2/12, Andrei Alexandrescu seewebsiteforem...@erdani.org
wrote:
struct S { int x, y; }
S s = { 1, 2 };
I think we should remove
this feature.
But not this, right:
S s = { x : 1, y : 2 }; ?
Yes, these are named
On Tuesday, May 01, 2012 23:10:04 Mehrdad wrote:
Chris Cain wrote in message news:nqgwunggifrgmwwhk...@forum.dlang.org...
What about the object do you want const? How should this object normally
change things? It looks like the way you've coded it, your connection will
get information
On Tuesday, 1 May 2012 at 21:03:35 UTC, foobar wrote:
vote++
I like your POV that operators are useful shortcuts (syntax
sugar) meant for the end user whereas library authors should use
the full function names for generic code. IIRC C++'s STL does
the
same - for instance the map::operator[]
In the world of OOP, when would guaranteeing (so to speak) 'physical'
const-ness ever be handy?
Wouldn't physical const-ness be an implementation detail of the object,
and therefore, impossible to determine by the user of the object?
You said:
In C++, the compiler can't use it to provide any real **guarantees**...
Now you're telling me D doesn't guarantee it either.
And then go on telling me about how D uses const-ness to make assumptions
and improve performance.
Isn't your answer orthogonal to your claim? o.O
Whether
... i.e. doesn't prevent casting it away)
Typo, I meant DOES prevent
On Tuesday, May 01, 2012 23:44:30 Mehrdad wrote:
You said:
In C++, the compiler can't use it to provide any real **guarantees**...
Now you're telling me D doesn't guarantee it either.
And then go on telling me about how D uses const-ness to make assumptions
and improve performance.
Isn't
On Tuesday, May 01, 2012 23:48:29 Mehrdad wrote:
In the world of OOP, when would guaranteeing (so to speak) 'physical'
const-ness ever be handy?
Wouldn't physical const-ness be an implementation detail of the object,
and therefore, impossible to determine by the user of the object?
No, it's
Whoa, what?
So you're saying
X results in UB
means
Compiler guarantees X
?
By that philosophy, C and C++ are orders of magnitude better than D, given
how many so-called guarantees they make about your code...
On Wednesday, May 02, 2012 00:10:33 Mehrdad wrote:
Whoa, what?
So you're saying
X results in UB
means
Compiler guarantees X
?
By that philosophy, C and C++ are orders of magnitude better than D, given
how many so-called guarantees they make about your code...
I don't
On Wednesday, 2 May 2012 at 06:44:30 UTC, Mehrdad wrote:
Whether the compiler makes **GUARANTEES** about code is
_irrelevant_ to whether or not the language uses 'const' to
improve performance.
You could very well have a language which **enforces**
const-ness (i.e. doesn't prevent casting it
You can replace signed integer overflow with pretty much whatever
'guarantee' in C that suits your fancy.
See below.
Jonathan M Davis wrote in message
news:mailman.207.1335944070.24740.digitalmar...@puremagic.com...
I don't follow.
Let's see if this is better.
The D compiler guarantees
Wouldn't physical const-ness be an implementation detail of the
object, and therefore, impossible to determine by the user of the
object?
No, it's not an implementation detail. When you mark an object as being
physically const, then you're guaranteeing that you will not alter it
through
On 05/02/2012 08:48 AM, Mehrdad wrote:
In the world of OOP,
interface Readonly{
auto read(){ ... }
}
class Mutable{
auto read(){ ... }
void write(int x){ ... }
Readonly getReadonly(){ ... }
}
private class Adapter: Readonly{
Mutable field;
auto read(){ return
On Wednesday, May 02, 2012 01:12:15 Mehrdad wrote:
Wouldn't physical const-ness be an implementation detail of the
object, and therefore, impossible to determine by the user of the
object?
No, it's not an implementation detail. When you mark an object as being
physically const,
On Wednesday, May 02, 2012 01:06:47 Mehrdad wrote:
You can replace signed integer overflow with pretty much whatever
'guarantee' in C that suits your fancy.
See below.
Jonathan M Davis wrote in message
news:mailman.207.1335944070.24740.digitalmar...@puremagic.com...
I don't follow.
On 05/02/2012 10:26 AM, Jonathan M Davis wrote:
All of that might hold if the compiler could actually make optimizations based
on the knowledge that an integer wouldn't overflow. But what optimizations
could it make?
x+1 x == true
On 05/02/2012 04:14 AM, Mehrdad wrote:
Yes, that non-global issue was the exact issue I was referring to. It
drives me nuts whenever I try to give in and use templates.
Regarding your fix:
Is it *really* intended that user should say
arr.filter((typeof(some_random_expression) x) = x y);
On Tue, 2012-05-01 at 21:31 +0200, Joseph Rushton Wakeling wrote:
On 01/05/12 18:23, Russel Winder wrote:
On Tue, 2012-05-01 at 17:12 +0100, Russel Winder wrote:
I will put in a bug report but it would be good if this were followed up
by representations from the LDC bosses...
Sam Morris
Maybe we should just start to use a forum software where threads
can be moderated.
No, it is not an O(1) operation, it is *close* to O(1) (as much
sense as that statement can make). I don't know why you
associate any particular complexity with 'in' in the first
place. And I do think we're crippling the language, considering
Python (and probably other languages) has had
On 05/02/12 04:11, Mehrdad wrote:
More problems... similar, but this time related to templates.
struct Filter(R) { this(R) { } }
template filter(R) { alias Filter!(R).__ctor filter; }
void main() { filter([1, 2, 3]); }
Error: template linq.filter(R) is not a function template
Why?
On 05/02/12 03:08, ixid wrote:
Wouldn't it be better to make breaking changes sooner rather than later?
Yes, it would.
artur
On Wednesday, 2 May 2012 at 06:10:04 UTC, Mehrdad wrote:
I don't think you answered my question.
What I said (or meant to ask) was this:
- OK, FINE, let's say I don't know what D's const() means,
then. Maybe it isn't suitable for what I need. I just want to
know:
_How do you specify that the
On Tuesday, 1 May 2012 at 16:12:31 UTC, Russel Winder wrote:
I will put in a bug report but it would be good if this were
followed up
by representations from the LDC bosses...
The maintainer of the Debian package is Arthur Loiret, so I'm not
sure what we as LDC devs can do about that. I'm
On Wednesday, 2 May 2012 at 11:48:32 UTC, David Nadlinger wrote:
(and apparently it ships with Ubuntu, at least:
https://launchpad.net/ubuntu/+source/libconfig)
Oh well – I guess you know what I meant…
Andrei Alexandrescu:
It's a bit inappropriate to bind Walter to such a social
contract upon having asked an informal question.
Those comments weren't required, but they improve the quality of
this community. So it's work and time well spent. Every person
attracted to work on D development
On Tuesday, 1 May 2012 at 16:15:58 UTC, so wrote:
Have you ever used a C api, say OpenGL?
What are they using preprocessor for? other than enum and alias?
It is that damn simple. I am not talking about supporting Boost
level preprocessor exploit. I am talking about mature C
libraries.
Oh
On Tue, 01 May 2012 22:11:18 -0400, Mehrdad wfunct...@hotmail.com wrote:
More problems... similar, but this time related to templates.
struct Filter(R) { this(R) { } }
template filter(R) { alias Filter!(R).__ctor filter; }
void main() { filter([1, 2, 3]); }
Error: template
On Tue, 01 May 2012 23:30:27 -0400, Mehrdad wfunct...@hotmail.com wrote:
Also, I think you didn't notice the other problem.
The other problem was with IConnection, whose send() wasn't 'const',
which also gives you an error due to the transitivity of const (which
I've also claimed is
On 2012-05-02 13:41, Chris Cain wrote:
If that's what you want, then that's precisely what D does. According
to the public interface of Student, none of the methods I will use will
modify the object. As opposed to C++'s method of According to the
public interface of student, these methods have
On Wednesday, 2 May 2012 at 12:19:35 UTC, Jacob Carlborg wrote:
For D, it's not limited to the public interface. The rules
apply to ALL methods and fields.
Indeed. I may have forgot to add in any way shape form or
fashion to that particular line, but it's important to node that
const means
On Wednesday, 2 May 2012 at 11:56:51 UTC, David Nadlinger wrote:
On Tuesday, 1 May 2012 at 16:15:58 UTC, so wrote:
Have you ever used a C api, say OpenGL?
What are they using preprocessor for? other than enum and
alias?
It is that damn simple. I am not talking about supporting
Boost level
On Wed, 2012-05-02 at 13:48 +0200, David Nadlinger wrote:
[...]
The maintainer of the Debian package is Arthur Loiret, so I'm not
sure what we as LDC devs can do about that. I'm also not quite
sure what the problem with the package is in the first place? Was
libconfig kicked out of the
On 5/1/12 11:38 PM, Adam D. Ruppe wrote:
On Wednesday, 2 May 2012 at 03:22:02 UTC, Andrei Alexandrescu wrote:
One feature to remove stands out - the struct initialization:
S s = { 1, 2 };
I could live without that one, because D has an alternative:
auto s = S(1, 2);
And I'd be sad if you
On 5/2/12 12:20 AM, Jakob Ovrum wrote:
S(...) does not exhibit the same problem as {...} exactly because it has
constructors and static opCall. If you change the order of fields in S,
you can write a constructor preserving the old behaviour.
Good observation. So indeed the { ... } case is
On 5/2/12 3:10 AM, Mehrdad wrote:
Whoa, what?
So you're saying
X results in UB
means
Compiler guarantees X
?
By that philosophy, C and C++ are orders of magnitude better than D,
given how many so-called guarantees they make about your code...
Casting away const should be statically
On 5/2/12 6:15 AM, Tobias Pankrath wrote:
No, it is not an O(1) operation, it is *close* to O(1) (as much sense
as that statement can make). I don't know why you associate any
particular complexity with 'in' in the first place. And I do think
we're crippling the language, considering Python
On 5/2/12 7:52 AM, bearophile wrote:
Andrei Alexandrescu:
FWIW there is little agreement among answers.
Right, but a thread like this is comparable to the first phase of a
Brainstorming process, where ideas are produced freely, where agreement
is not required.
Sorry, here I meant agreement
On 05/02/2012 04:01 PM, Andrei Alexandrescu wrote:
On 5/2/12 6:15 AM, Tobias Pankrath wrote:
No, it is not an O(1) operation, it is *close* to O(1) (as much sense
as that statement can make). I don't know why you associate any
particular complexity with 'in' in the first place. And I do
Mehrdad:
Lazy-loading and caching aren't exactly obscure or
rarely-used concepts -- which seems to be the way they are
portrayed here. They are *bound* to be used in any nontrivial
program.
Right.
- - - - - - - - - -
Andrei Alexandrescu:
Casting away const should be statically
On May 2, 2012, at 3:04 AM, Tobias Pankrath tob...@pankrath.net wrote:
Maybe we should just start to use a forum software where threads can be
moderated.
Usenet can be moderated too. It's just work for somebody.
On Wed, May 02, 2012 at 09:57:58AM -0400, Andrei Alexandrescu wrote:
[...]
Casting away const should be statically disallowed in @safe code.
[...]
Doesn't it already?
T
--
Everybody talks about it, but nobody does anything about it! -- Mark Twain
Yes, 'const' is part of the interface.
The trouble is that when you make it part of the interface, you're making
the assumption that **no one** who derives from your class will need mutable
state.
How can you ever guarantee that?
On Wed, May 02, 2012 at 07:41:54AM -0700, Sean Kelly wrote:
[...]
Usenet can be moderated too.
[...]
Yikes! When I read that I didn't know whether to laugh or to cry.
Usenet? Moderation? Wow...
Anyway, back on topic, I have this suspicion that a lot of the
complaints about the forums is due to
H. S. Teoh:
Doesn't it already?
Right, this:
class Foo {}
void main() @safe {
const f1 = new Foo;
auto f2 = cast(Foo)f1;
}
Gives:
test.d(5): Error: cast from const(Foo) to test.Foo not allowed in
safe code
Bye,
bearophile
All of that might hold if the compiler could actually make optimizations
based on the knowledge that an integer wouldn't overflow. But what
optimizations could it make?
Look for signed integer overflow here.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
Steven Schveighoffer wrote in message
news:op.wdokh6vteav7ka@localhost.localdomain...
There are two solutions, both are horrible.
That's what scares me lol
There is a possible 3rd solution. Don't use immutable/const, instead use
information hiding.
In other words, Your class is already
On Wed, May 02, 2012 at 05:16:26PM +0200, bearophile wrote:
H. S. Teoh:
Doesn't it already?
Right, this:
class Foo {}
void main() @safe {
const f1 = new Foo;
auto f2 = cast(Foo)f1;
}
Gives:
test.d(5): Error: cast from const(Foo) to test.Foo not allowed in
safe code
On 5/2/12 10:20 AM, Timon Gehr wrote:
The interface is different:
void main(){
int[] a = [0,0,0];
a[2] = 3;
assert(2 !in a);
}
vs.
void main(){
int[int] aa;
aa[2] = 3;
assert(2 in aa);
}
The syntactic interface is the same. That would be the semantic
interface, which makes the idea twice
Chris Cain wrote in message news:wyqyigxytaqwwmhfh...@forum.dlang.org...
If you want just to specify that (and not ask the compiler to check for
you), documentation will do.
Heh, if only the world was so ideal...
That's _any_ kind of modification of state. If you change state, you can't
use
Could someone mention a case where it is __necessary__ to cast away const()?
How about immutable()?
How about shared()?
On 2012-05-02 15:13:43 +, Mehrdad wfunct...@hotmail.com said:
Yes, 'const' is part of the interface.
The trouble is that when you make it part of the interface, you're
making the assumption that **no one** who derives from your class will
need mutable state.
How can you ever guarantee
When you're making the object 'const', you're not making the assumption
that no one who derives from this class need mutable state.
What you're doing is asserting that bits belonging to this object needs to
be 'const' to preserve sequential consistency across threads or for other
reasons.
On Wednesday, 2 May 2012 at 13:16:04 UTC, Russel Winder wrote:
Downstream folk building a friendly
and constructive relationship with Debian maintainers generally
helps everyone.
Huh? You mean »upstream«?
Is Arthur a sole maintainer or is he part of a team.
I don't know – as far as I'm
On Wednesday, 2 May 2012 at 13:16:04 UTC, Russel Winder wrote:
Downstream folk building a friendly
and constructive relationship with Debian maintainers generally
helps everyone.
Huh? You mean »upstream«?
Is Arthur a sole maintainer or is he part of a team.
I don't know – as far as I'm
On Wednesday, 2 May 2012 at 12:36:03 UTC, so wrote:
Why don't you give a link to the source where they use
preprocessor heavily?
Like many other C libraries, OpenSSL implements quite a few
functions in terms of macros for performance reasons, so that
they can be inlined (like [1]).
On Wednesday, 2 May 2012 at 15:21:31 UTC, Mehrdad wrote:
Steven Schveighoffer wrote in message
news:op.wdokh6vteav7ka@localhost.localdomain...
But many languages that *don't* have const/immutable do well
with this pattern (think Java strings).
Java strings are pretty poor for performance
On 02-05-2012 17:58, Mehrdad wrote:
Could someone mention a case where it is __necessary__ to cast away
const()?
How about immutable()?
How about shared()?
shared? Almost always in any non-trivial application. shared is only
useful if you're dealing with templatized functions that can
On Wednesday, 2 May 2012 at 16:52:33 UTC, Alex Rønne Petersen
wrote:
shared? Almost always in any non-trivial application. shared is
only useful if you're dealing with templatized functions that
can actually handle it, which is not the case as often as one
would like.
Additionally, shared is
H. S. Teoh:
One area where I'd like const to be improved, though, is a way
to indicate that const-ness depends on the arguments,
specifically, on the behaviour of a delegate argument.
There was a long discussion about this, with proposals like
@pure(compile_time_predicate) to define a
On Wed, May 02, 2012 at 07:21:46PM +0200, bearophile wrote:
H. S. Teoh:
One area where I'd like const to be improved, though, is a way to
indicate that const-ness depends on the arguments, specifically, on
the behaviour of a delegate argument.
There was a long discussion about this, with
On Wednesday, 2 May 2012 at 16:23:28 UTC, David Nadlinger wrote:
Well, after more or less telling Alex that he has no clue what
he's talking about,
With no reason, right? Could you go back and read why i did what
you said i did? I might sometimes sound rude. You can blame my
temper, nature
This is a false choice. The performance of Java strings (BTW, which I
don't think is that bad) is not tied to whether they are immutable or not.
Oh yes, I think you're right. If I remember, someone told me Java strings
don't re-copy data when you substring; I forgot about that.
But that's
But that's definitely not the case in C#.
(which, I should clarify, was what implicitly came to my mind as an example
of immutable strings)
On Wed, 2012-05-02 at 18:07 +0200, David Nadlinger wrote:
[...]
Huh? You mean »upstream«?
I guess so ;-)
[...]
I don't know – as far as I'm aware, he is just a D user who
thought it would be nice to have LDC packaged (thanks a lot for
that, btw).
To get into the Debian repository a
On 05/02/2012 05:25 PM, Andrei Alexandrescu wrote:
On 5/2/12 10:20 AM, Timon Gehr wrote:
The interface is different:
void main(){
int[] a = [0,0,0];
a[2] = 3;
assert(2 !in a);
}
vs.
void main(){
int[int] aa;
aa[2] = 3;
assert(2 in aa);
}
The syntactic interface is
On 2012-05-02 18:01, Mehrdad wrote:
When you're making the object 'const', you're not making the
assumption that no one who derives from this class need mutable state.
What you're doing is asserting that bits belonging to this object
needs to be 'const' to preserve sequential consistency across
good bye
you won't be missed
Er, I guess I didn't say what I actually meant to say, my bad. x_x
What I meant that you're assuming that derived classes won't need mutable
state in an const method that they overrode.
On 02/05/12 18:08, David Nadlinger wrote:
On Wednesday, 2 May 2012 at 13:16:04 UTC, Russel Winder wrote:
Downstream folk building a friendly
and constructive relationship with Debian maintainers generally helps everyone.
Huh? You mean »upstream«?
Is Arthur a sole maintainer or is he part of
On Wednesday, May 02, 2012 11:58:41 Mehrdad wrote:
Er, I guess I didn't say what I actually meant to say, my bad. x_x
What I meant that you're assuming that derived classes won't need mutable
state in an const method that they overrode.
If a const function needs mutable member variables or
On Wednesday, 2 May 2012 at 18:27:18 UTC, agitator wrote:
good bye
you won't be missed
I am just trying to find a better tool to ease the work i do, not
trying to be one as yourself. So as long as D rocks, i ll be
following. Just not post on forums as it won't do much good when
you have
On Wednesday, 2 May 2012 at 15:35:15 UTC, Mehrdad wrote:
I guess this answers my question then: const/immutable are
useful for multithreading.
Indeed, const/immutable makes multithreading much better. It
provides restrictions which make it much easier to think about
problems. If I pass a const
On 5/2/12 1:04 PM, so wrote:
Sorry everyone!
I can't restrain the urge to answer such posts.
I feel the presence of some higher powers, yes! they are trying to tell
me... something, perhaps warning me in a way? I keep hearing voices
along the lines NNTP error: 400 loadav [innwatch:load] 2084 gt
On Wednesday, 2 May 2012 at 20:04:30 UTC, so wrote:
I keep hearing voices along the lines NNTP error: 400 loadav
[innwatch:load] 2084 gt 1500. yet i... must... click Send!
I might suffer from the same type of schizophrenia ;)
David
On Wednesday, 2 May 2012 at 17:52:07 UTC, so wrote:
So enum, alias has nothing to do with #define?
Or D requires syntax to support the things i mentioned?
#define can be used for manifest constants and aliases, yes, but
also for many other things, as in the examples from popular
libraries that
On 05/02/2012 08:58 PM, Mehrdad wrote:
mutable state in an const method
=O
Okay thanks for the replies, that clears up a bunch of things for me.
Regarding the last part:
Yes, it 'works'. The only trouble is that you can never set the interface
methods to be 'const', because any sort of indirection can screw you over
later. This is why const is less useful than it
Timon Gehr wrote in message news:jns5du$64q$1...@digitalmars.com...
On 05/02/2012 08:58 PM, Mehrdad wrote:
mutable state in an const method
=O
a*
On Wednesday, 2 May 2012 at 20:30:10 UTC, Mehrdad wrote:
Okay thanks for the replies, that clears up a bunch of things
for me.
No problem, I'm glad it's helping.
Regarding the last part:
Yes, it 'works'. The only trouble is that you can never set the
interface methods to be 'const',
On 2012-05-02 20:58, Mehrdad wrote:
Er, I guess I didn't say what I actually meant to say, my bad. x_x
What I meant that you're assuming that derived classes won't need
mutable state in an const method that they overrode.
Yes, that would be the assumption. It's not possible without subverting
1 - 100 of 160 matches
Mail list logo
