Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration
What compiler options is that with? I used DMD and compiler flags -O -inline -release on x86_64 linux.
Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration
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 -release. vs: 3.2 seconds dmd without any command line options. 2.2 seconds with dmd -O -inline -release. And that is for 1000_000_000 Fiber context switches. intel 2600K @ 4.5GHz, gnu/linux, ubuntu 12.04.
Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration
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 https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration Call me stupid, but I've absolutely no idea what you're doing. What problem does the InputVisitor solve ? What are the current solutions ? What is the intent of your code ? What are the supposed advantages ? Your article says nothing about it.
Re: 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 https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration Call me stupid, but I've absolutely no idea what you're doing. What problem does the InputVisitor solve ? What are the current solutions ? What is the intent of your code ? What are the supposed advantages ? Your article says nothing about it. Just an easier-to-read/write alternative to an opApply or an input range. More natural and straightforward than a hand-written input range, and cleaner syntax than opApply (and without opApply's downside of not being usable as a range).
Re: 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 loop) runs in 0.27s on my
machine:
auto sum = 0;
auto n = 1000_000_000;
asm
{
mov EAX, n;
mov EBX, sum;
loop:
dec EAX;
inc EBX;
test EAX, EAX;
jne loop;
mov sum, EBX;
}
Ranges like iota are often as fast as using a for loop.
For example this code:
auto sum = 0;
foreach(i; iota(to!int(args[1])))
sum += i;
runs in 0.52 seconds when compiled with gdc with flags
-O2 -finline-functions -frelease. When compiled with -O3,
gcc uses paddd instruction and it runs in 0.1s.
And that is for 1000_000_000 Fiber context switches.
I'm not saying that D fibers are slow - fiber context
switches are way faster than thread context switches.
When using them for IO, such as in vibe.d, overhead
of fibers is negligible. But when used for iteration,
they are way slower than the alternatives, because in
that case there shouldn't be any context switches at all.
Re: Combine Coroutines and Input Ranges for Dead-Simple D Iteration
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 just did on something I thought was pretty cool: Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration Call me stupid, but I've absolutely no idea what you're doing. What problem does the InputVisitor solve ? What are the current solutions ? What is the intent of your code ? What are the supposed advantages ? Your article says nothing about it. Just an easier-to-read/write alternative to an opApply or an input range. More natural and straightforward than a hand-written input range, and cleaner syntax than opApply (and without opApply's downside of not being usable as a range). Of course, based on the timing results Jerro and Rory reported, Adam's mixin helper for opApply probably hits a better balance of performance vs usability.
bootDoc - advanced DDoc framework using Twitter's Bootstrap
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 some of the components come from Twitter's Bootstrap framework. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ LuaD's official documentation also uses bootDoc http://jakobovrum.github.com/LuaD/ bootDoc is designed to be easily usable with any project. It is used as a git-submodule in both of the above sample scenarios. All project-specific settings are provided by a separate configuration file (settings.ddoc), which is documented on the project's Github wiki. bootDoc includes a general-purpose generation script. See the readme on Github for usage information. The script uses a candyDoc-style modules.ddoc as input, making the transition from candyDoc projects easy. 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 dlang.org) work both with and without JavaScript, with the same limitations. Comments, issues, enhancement requests, questions or rants about JavaScript - all feedback is much appreciated!
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
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 dlang.org) work both with and without JavaScript, with the same limitations. Wooha! remove in std.algorithm finally points to _function_. Impressed :) (BTW It's still points to enum in dlang.org) Comments, issues, enhancement requests, questions or rants about JavaScript - all feedback is much appreciated! -- Dmitry Olshansky
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
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 symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. Looks good. -- /Jacob Carlborg
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
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 well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ LuaD's official documentation also uses bootDoc http://jakobovrum.github.com/LuaD/ bootDoc is designed to be easily usable with any project. It is used as a git-submodule in both of the above sample scenarios. All project-specific settings are provided by a separate configuration file (settings.ddoc), which is documented on the project's Github wiki. bootDoc includes a general-purpose generation script. See the readme on Github for usage information. The script uses a candyDoc-style modules.ddoc as input, making the transition from candyDoc projects easy. 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 dlang.org) work both with and without JavaScript, with the same limitations. Comments, issues, enhancement requests, questions or rants about JavaScript - all feedback is much appreciated! Great! I will try this :) Masahiro
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
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!
Re: Introducing vibe.d!
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 spend some time with MongoDB and I have to say : Amazing db. I thought key/value databases are just toys. At least regarding MongoDB is was completely wrong. I have a problem with diet templates. In order to use dojo dijit I need : div class=mainlayout id=appLayout data-dojo-props=region: 'center', tabPosition: 'bottom' data-dojo-type=dijit.layout.TabContainer /div Is this doable in diet templates ?
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
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 at least a basic module list works without JS. It looks pretty alright with noscript now.
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
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 well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. I would make a minor change that lets you see the function tree near the top. On my laptop screen (about a standard size) I have to scroll down about an entire screen to see it. How this is implemented is up to you, but being able to collapse to module view might be enough. -- James Miller
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
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 symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ Very nice! But why the symbols inside std.algorithm, for instance, are not sorted? http://jakobovrum.github.com/bootdoc-phobos/std.algorithm.html (they are kind of sorted by chunks...) Now if it only had cross references... :-P
Re: Why D const is annoying
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 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 function process1() won't modify its 'student' parameter_? Your response was this: - Does const(Student) mean that it shouldn't write to the server? To which my answer is: - I don't know, you tell me. (?) _Should_ I use 'const' to specify this? Or should I use something else? In other words: Is that not the entire point of saying const(Student) in the first place? You answered that by saying const(Student) means I won't change _anything_ about the object. It's const. So in a sense, you can say that you won't change the fields name, birthday, etc. That means you can't change the fields. The problem with your answer is that it implies D DOESN'T SUPPORT O.O.P. with const!!! If D supported OOP, then why the heck would process1() know (or _care_) how Student works internally? Why (or how) should it know (or care) that Student uses a database connection? Wasn't that information an implementation detail? All process1() needs to know is the *PUBLIC INTERFACE* of Student. And all it cares to say is: According to the public interface of Student, none of the methods I will use will modify the object. process1() has NO IDEA what goes on internally! It has NO IDEA that Student uses a database connection. Maybe it's a network connnection instead. Or maybe it's being unit-tested, and it's actually a dummy object, with no relation to the outside world. Or maybe it's a wrapper/proxy for another object. The point is: _why should the code for process1() depend on this_?! So, I'll ask my question again: How should process1() tell the outside world that it will not be asking its parameter to manipulate itself, WITHOUT breaking the abstraction barrier and 'peeking' into the private world of Student?
Re: Why D const is annoying
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?
Re: Why D const is annoying
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 system assumes that const cannot be altered. As such, the compiler is free to optimize or alter its code generation based on that fact and any code which _does_ alter a variable after casting away const is breaking the type system and risking bugs. As far as the compiler is concerned, you _cannot_ alter a const variable through that variable (though another one might - unlike immutable - meaning that there are times when the compiler can't know that a const variable hasn't been mutated; it often can, however, particularly within a single function). C++ specifically allows for const variables to be altered - either via mutable or casting away const. It _guarantees_ that it work to do so. And since it considers it completely legal to alter a const variable by either of those means, it _cannot_ assume that a const variable hasn't been altered except in very restricted circumstances. So, in general, the _only_ guarantee that C++'s const gives you is that you a const variable will not be altered save by casting away const or by one of its member variables being mutable. So, it all comes down to what the compiler is free to assume and therefore guarantee. With D's type system, it's free to assume that you can never alter a const variable, so it guarantees that and any attempt to subvert that breaks the type system and whatever guarantees it gives you, risking bugs. With C++'s type system, it assumes that const _can_ be mutated via casting or mutable and guarantees that that will work, whereas it then _cannot_ assume that a const variable doesn't get mutated. - Jonathan M Davis
Re: Does D have too many features?
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 parameters.
Andrei's point could be made for just about everything that takes
two (or more) consecutive integers, like a function signature, so
I think it's a bit moot. Unfortunately, only named parameters can
solve this problem, but then comes the problem of accepting both
order of parameters and named parameters at the same time...
Re: Why D const is annoying
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 off of a server. 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 function process1() won't modify its 'student' parameter_? What you're thinking about here is logical const. You want a way to indicate that an object is not logically altered by the function that you're passing it to. With logical const, the inner state of the object _can_ change so long as the state of the object as seen from the outside is constante. However, D's const is _physical_ const. It guarantees that the object isn't altered _at all_. And that _is_ part of the interface, because no non-const function can be called on a const object, and every const function statically guarantees that it doesn't mutate the object that it's on. There is _no_ way in D to indicate that an object won't be altered by a function save for guaranteeing that it won't be altered _at all_ by using const. There is no way to indicate that it won't be altered logically save for comments. And in reality, having the compiler verify that an object's logical state doesn't change even when some of its internal state does is _very_ difficult (if not impossible) to statically verify. As such, the compiler can make no such guarantees. Not even C++ does that. Arguably, C++'s const is a glorified comment. Walter certainly sees it that way and doesn't think that there is _any_ value to C++'s const as a result. What it _does_ guarantee is that you won't accidentally alter the object (since you have to cast away const to alter it, or some of its member variables are going to have to be mutable), so I'd argue that it's still very useful. But it does _not_ actually guarantee that the object won't get mutated by that function. It's effectively just a comment which the compiler partially verifies. It would be _very_ cool to be able to have a compiler-checked, logical const, but it probably isn't realistically possible, except maybe in very restrictive circumstances. - Jonathan M Davis
Re: Does D have too many features?
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[] is a simple wrapper around map's functions. Is this included in D's style guide? vote- If something is a bad idea for a library, I don't see why it could be a good idea for the user code. After all, the standard library IS user code. The fact that it's in a library or not doesn't change anything to the fact that your syntactic sugar is hiding a potential problem.
Re: Why D const is annoying
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?
Re: Why D const is annoying
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 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 away), but which _doesn't_ use it to improve performance. Or which does. The dot product of your answer with my question was zero. :(
Re: Why D const is annoying
... i.e. doesn't prevent casting it away) Typo, I meant DOES prevent
Re: Why D const is annoying
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 your answer orthogonal to your claim? o.O Whether the compiler makes **GUARANTEES** about code is _irrelevant_ to whether or not the language uses 'const' to improve performance. No, what the compiler guarantees is _very_ relevant to using const for improving performance. The _only_ reason that the compiler can use const for any kind of optimizations is because it can guarantee that the variable won't change. If it can't guarantee that, then it _cannot_ use const for optimizations. How could it? What would there be to optimize? Optimizations with const are based on the fact that the variable didn't change, so if the compiler can't guarantee that, how could it make any optimizations based on that? And yes, D's type system _does_ guarantee that a const object doesn't change specifically because casting away const and mutating an object is _undefined_. It goes outside of the type system. You can do it, because D is a systems language, but the compiler is free to make optimizations based on the assumption that you will never mutate a const variable. So, the compiler _can_ make the guarantee that const isn't mutated, and if you do, you _will_ have bugs - just like if you did something screwy like casting an object no void* nad then casting it to a completely different type afterwards could cause bugs. You've thrown away the type system at that point, and it's up to the programmer to maintain the compiler's guarantee in such situations, or you'll get bugs, because the compiler relies on that guarantee. C++, on the other hand, _does_ define what happens when you cast away const and mutate a variable, so its type system has to assume that a const variable _can_ change and therefore can rarely use it for optimizations (i.e. only in cases where it can statically verify that you _didn't_ cast away const and that not mutable variables are involved - which is likely to be rather rather, since even just making a function call would defeat it, since C++ doesn't do cross-function optimizations like that). The difference here is in what the compiler considers to be defined or not and therefore what assumptions it's permitted to make. - Jonathan M Davis
Re: Why D const is annoying
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 not an implementation detail. When you mark an object as being physically const, then you're guaranteeing that you will not alter it through that reference or pointer (and not at all, if it's a value type, because then there can't be another reference or pointer which mutates it). The type system guarantees this, because it disallows any const variable from being mutated. When dealing with a const object, you can only call const functions on its interface. Whatever implementation there is for those interface methods would also have to be const to implement that interface. And the type system would then disallow any non-const functions being called within the implementations of those functions as well as disallowing the mutation of member variables. So, the type system guarantees that the object will not be mutated at all by any const function. And since const is part of the interface of the object, it is very much _not_ an implementation detail. Physical constness is _required_ in order to have immutable ever be converted to const, because immutable objects can _never_ be mutated through _any_ reference or pointer. If D's const were not transitive as well as guarantee that any const reference cannot alter the object it points to, then you couldn't have immutable be convertible to const, because const would not protect it against mutation. So, C++'s const is impossible in D if immutable is going to be convertible to const. It's _logical_ constness that is near-impossible to have the compiler verify, because it has no way of determining that the variables that you mark as mutable or from which you cast away const and mutate don't affect the logical state of the object. _You_ may know, but the compiler can't determine that. - Jonathan M Davis
Re: Why D const is annoying
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...
Re: Why D const is annoying
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 follow. The D compiler guarantees that as long as you don't cast away const, const will never be mutated. If you _do_ cast away const and then mutate the variable, you are doing something which is undefined. As it is undefined behavior, _anything_ could happen if you do it, and the compiler is free to assume that it will never happen. So, it effectively has a guarantee that a const variable will never be mutated (save by another, mutable reference to the same data). It then uses that guarantee for optimizations. To make it 100% iron-clan, casting away const would have to be illegal, but that would be unacceptable in a systems language - particularly when you want to be able to call C functions which may not be properly annotated. So instead, the compiler assumes that its guarantee holds in the case where you cast away const, and is still able to use it for optimizations. C++ _does_ define what happens when you cast away const and mutate a variable, so it guarantees that that behavior will be safe. In so doing however, it is then unable to assume that casting away const will not result in the variable being mutated and is therefore unable to use const for much in the way of optimizations. - Jonathan M Davis P.S. You can check out this stackoverflow question on the subject as well: http://stackoverflow.com/questions/4219600/logical-const-in-d
Re: Why D const is annoying
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 away), but which _doesn't_ use it to improve performance. Or which does. Yes, pure functional languages do provide this kind of guarantee, by simply forbidding immutability at the cost of copying objects. I agree D's solution isn't pure as it must allow mutability, and I suspect it can't be, unless it starts copying objects all over the place. That means that when you use the immutable keyword, you *really* mean it and you *must* think that way. If you want to mutate your object, you have to copy it to another object. Thats how strings are designed. For me, your example doesn't prove that the tool is broken, it proves that you don't know how to use immutability. It's really another paradigm, which has its uses, in particular in concurrent programming.
Re: Why D const is annoying
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 that as long as you don't cast away const, const will never be mutated. The C compiler guarantees that as long as signed integers don't overflow, their results will be correct. If you _do_ cast away const and then mutate the variable, you are doing something which is undefined. If you _do_ overflow signed integers, their results will be undefined. As it is undefined behavior, _anything_ could happen if you do it, and the compiler is free to assume that it will never happen. As it is undefined behavior, the result could be _anything_ if you do it, and the compiler is free to assume that it will never happen. So, it effectively has a guarantee that a const variable will never be mutated (save by another, mutable reference to the same data). It then uses that guarantee for optimizations. So, it effectively has a guarantee that a signed integer will never be overflown. It then uses that guarantee for optimizations. To make it 100% iron-clan, casting away const would have to be illegal, but that would be unacceptable in a systems language - particularly when you want to be able to call C functions which may not be properly annotated. To make it 100% iron-clan, signed overflow would have to be illegal, but that would be unacceptable in a systems language - particularly when you need to depend on system-dependent behavior. So instead, the compiler assumes that its guarantee holds in the case where you cast away const, and is still able to use it for optimizations. So instead, the compiler assumes that its guarantee holds in the case where overflow a signed integer, and is still able to use it for optimizations. C++ _does_ define what happens when you cast away const and mutate a variable, so it guarantees that that behavior will be safe. D _does_ define what happens when you overflow a signed integer, so it guarantees that that behavior will be safe. In so doing however, it is then unable to assume that casting away const will not result in the variable being mutated and is therefore unable to use const for much in the way of optimizations. In so doing however, it is then unable to assume that a signed integer will never be overflown, and is therefore unable to use signed integer overflow for much in the way of optimizations. - Jonathan M Davis Mehrdad
Re: Why D const is annoying
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 that reference or pointer. I think you misunderstood my question. Yes, __IF__ you mark an object as physically const, then the world is beautiful... My question is, __WHEN__ can you ever do that, except in the most trivial situations? As soon as you try to add an extra layer of indirection (be it a proxy, implementing a method in an interface, overriding a base class method, etc.), there is NO WAY for the caller to know what obj.foo() does on obj. How can it possibly know whether obj will stay physically const?
Re: Why D const is annoying
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 field.read(); }
}
when would guaranteeing (so to speak) 'physical'
const-ness ever be handy?
Concurrency?
Wouldn't physical const-ness be an implementation detail of the
object, and therefore,
If it is, don't use the const qualifier.
impossible to determine by the user of the object?
It is possible because 'const' is part of the method interface.
Re: Why D const is annoying
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, then you're guaranteeing that you will not alter it
through that reference or pointer.
I think you misunderstood my question.
Yes, __IF__ you mark an object as physically const, then the world is
beautiful...
My question is, __WHEN__ can you ever do that, except in the most trivial
situations?
As soon as you try to add an extra layer of indirection (be it a proxy,
implementing a method in an interface, overriding a base class method,
etc.), there is NO WAY for the caller to know what obj.foo() does on obj.
How can it possibly know whether obj will stay physically const?h
Because foo must be const, or if can't be called on a const object. And if
it's const, then it can't call any non-const functions or mutate any of its
member variables. If you have
interface I
{
int foo() const;
}
class C : I
{
int foo() const
{...}
}
C's foo _must_ be const, or it's not implementing I's foo, and it won't
compile. And if C's foo is const, then it can't call a non-const function or
mutate any of its member variables. If it were pure on top of that, then it
couldn't mutate any global or class variables either. The same goes for any
derived class which overrides foo. const is part of foo's signature, and no
derived class can escape that. So, _every_ class which implements I, and
_every_ class derived from C will have a const foo which will be unable to
mutate the state of that object.
If instead you did
class D
{
int bar() const
{
return e.bar();
}
E e;
}
then E's bar would have to be const, or it wouldn't be callable from D's bar,
since the e member variable is const inside of D's bar, since D's bar is
const, and you can't call a non-const function on a const variable.
An extra layer of indirection doesn't escape const at all, because that layer
of indirection must use const or it won't be usable by the outer layer. So,
the type system is able to guarantee that when you call a const function, the
object it's being called on - as well as any object that it contains directly
or indirectly - will not be mutated.
- Jonathan M Davis
Re: Why D const is annoying
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. Let's see if this is better. The D compiler guarantees that as long as you don't cast away const, const will never be mutated. The C compiler guarantees that as long as signed integers don't overflow, their results will be correct. If you _do_ cast away const and then mutate the variable, you are doing something which is undefined. If you _do_ overflow signed integers, their results will be undefined. As it is undefined behavior, _anything_ could happen if you do it, and the compiler is free to assume that it will never happen. As it is undefined behavior, the result could be _anything_ if you do it, and the compiler is free to assume that it will never happen. So, it effectively has a guarantee that a const variable will never be mutated (save by another, mutable reference to the same data). It then uses that guarantee for optimizations. So, it effectively has a guarantee that a signed integer will never be overflown. It then uses that guarantee for optimizations. To make it 100% iron-clan, casting away const would have to be illegal, but that would be unacceptable in a systems language - particularly when you want to be able to call C functions which may not be properly annotated. To make it 100% iron-clan, signed overflow would have to be illegal, but that would be unacceptable in a systems language - particularly when you need to depend on system-dependent behavior. So instead, the compiler assumes that its guarantee holds in the case where you cast away const, and is still able to use it for optimizations. So instead, the compiler assumes that its guarantee holds in the case where overflow a signed integer, and is still able to use it for optimizations. C++ _does_ define what happens when you cast away const and mutate a variable, so it guarantees that that behavior will be safe. D _does_ define what happens when you overflow a signed integer, so it guarantees that that behavior will be safe. In so doing however, it is then unable to assume that casting away const will not result in the variable being mutated and is therefore unable to use const for much in the way of optimizations. In so doing however, it is then unable to assume that a signed integer will never be overflown, and is therefore unable to use signed integer overflow for much in the way of optimizations. 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? Regardless, I don't see how it's particularly relevant. Even if there were optimizations which C/C++ could make which D can't (which may or may not be the case), that wouldn't have any bearing on how D's const works. D's const and C/C++'s const have different goals and different pros and cons. D's const is physical const, whereas C/C++'s const is an attempt at logical const (though it isn't really logical const either, because it makes no guarantees that the logical state of the object remains the same - only that you don't directly mutate any const variables). - Jonathan M Davis
Re: Why D const is annoying
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
Re: More bugs...
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); instead of arr.filter(x = x y); ? I think it's pretty obvious why that doesn't really work in practice... I agree that it should be fixed, but it is technically not a bug in the implementation.
Re: LDC and the Debian Repository
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 already reported this, but it appears that some pressure is needed to get a rebuild of the package so it is installable. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23664876 Ditto Ubuntu: https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/941549 I grabbed a copy of the missing shared object from the Debian snapshots repository and installed it in my local Debian repository so I got a valid installation. But this is hacking of a not nice sort :-( Does Ubuntu have a similar history repository? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: An observation
Maybe we should just start to use a forum software where threads can be moderated.
Re: Does D have too many features?
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 this feature since forever. I'm seriously worried. It seems to me like we're trying to cater to people who can't reason about the types in their program and the complexities of performing various operations on them. Since when did algorithmic complexity become a reason to take away syntax sugar? +1 I do argee. opIn is handy for arrays, too. That the complexity would be linear and thus it should be disallowed is not a valid argument in my opinion, because with the exact same argument you could kick std.algorithm.find out of phobos. It is just obvious to every trained programmer that finding an element in an unordered list takes O(n).
Re: More bugs...
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?
Because it isn't? Where would 'R' come from in your example?...
auto filter(R)(R r) { return Filter!R(r); }
artur
Re: D3 is potentially damaging
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
Re: Why D const is annoying
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 function process1() won't modify
its 'student' parameter_?
If you want just to specify that (and not ask the compiler to
check for you), documentation will do.
Your response was this:
- Does const(Student) mean that it shouldn't write to the
server?
To which my answer is:
- I don't know, you tell me. (?) _Should_ I use 'const' to
specify this? Or should I use something else?
I can't tell you what you want. You have to tell me. But no, you
shouldn't use const to specify this. const means you're object
won't be changed by you. Here's a decision tree for if you can
use const and immutable
Will the object (including all of its fields) ever change?
no - immutable (END)
yes -
Will the object (including all of its fields) be changed by you?
no - const (END)
yes - No qualifier
That's _any_ kind of modification of state. If you change state,
you can't use immutable/const (nor would you really want to).
The problem with your answer is that it implies D DOESN'T
SUPPORT O.O.P. with const!!!
If D supported OOP, then why the heck would process1() know (or
_care_) how Student works internally?
Why (or how) should it know (or care) that Student uses a
database connection?
When you say const(Student) you're saying that whatever Student
does, you want to know whatever you do won't change its internal
state.
I'm not sure you're using OOP properly. If you want to use OOP to
solve the problem, my suggestion is closer to OOP than using
const. If you don't want to talk about database connections and
everything (i.e., you don't want to use D's outrageously nice
templates), you can just have it be an interface instead. In fact
an interface would probably be more appropriate.
interface ROStudent {
getName();
getAddress();
...
}
process1(ROStudent student);
Effectively, though, it's the same sort of thing.
D's const/immutable require a different way of thinking of it.
What are they useful for? Consider a multithreaded program where
some threads depend on information that others have. They need
the information but they won't change state (which makes it much
safer/faster to work with because locking isn't as necessary ...
with immutable locking is actually silly). That's what
const/immutable is for.
In C++, you'd be foolish to not have locks set up even for const
variables because they can change at any time for any reason.
It's hardly a guarantee and it's so common to violate (look at
yourself, for instance) that it means _nothing_. I liked how it
was described as a glorified comment, because that's precisely
how I think of it.
Wasn't that information an implementation detail?
All process1() needs to know is the *PUBLIC INTERFACE* of
Student.
And all it cares to say is: According to the public interface
of Student, none of the methods I will use will modify the
object.
process1() has NO IDEA what goes on internally! It has NO IDEA
that Student uses a database connection. Maybe it's a network
connnection instead. Or maybe it's being unit-tested, and it's
actually a dummy object, with no relation to the outside world.
Or maybe it's a wrapper/proxy for another object.
The point is: _why should the code for process1() depend on
this_?!
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 comments that say that they say they won't change
the object, but I can't tell if it does or not.
Again, using an interface ROStudent/StudentReader/etc is really
your OOP solution.
So, I'll ask my question again:
How should process1() tell the outside world that it will not
be asking its parameter to manipulate itself, WITHOUT breaking
the abstraction barrier and 'peeking' into the private world of
Student?
I'll respond again: It depends on what you want. If you won't be
changing the object, then const/immutable does that. If you will
be changing the object, but you want guarantees that it won't
write to some external source/data structure, you'll have to come
up with the more precise way you want to define that. I gave you
two potential approaches.
Really though, the C++ way is a complete and total minefield in
this regard anyway. Consider Student defined like so:
Student {
name, id, address, phone_number;
connection;
getName() const {
if(!name) {
// cast away const
thisnonconst.name = connection.get(name);
}
return name;
}
writeName() {
connection.set(name, name);
}
}
Now this follows one particular
Re: LDC and the Debian Repository
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 also not quite sure what the problem with the package is in the first place? Was libconfig kicked out of the Debian repositories? Seems unlikely… (and apparently it ships with Ubuntu, at least: https://launchpad.net/ubuntu/+source/libconfig) David
Re: LDC and the Debian Repository
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…
Re: Does D have too many features?
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 is a chance to increase
significantly the development speed.
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.
Later there is a phase of selection, that needs to be based on
the quality of the single ideas; because technology/science
decisions can't be based (too much) on popularity.
Eliminating today's semantics of comma inevitably underlies the
hope that it can be retrofitted for something else, which I
think is near impossible without changing semantics of working
code.
Removing/restricting the usage of the comma operator is probably
able to avoid some bugs (and increase syntax uniformity in D code
written by different programmers), so it has a usefulness even if
later they are not used for tuple syntax. How much important such
bugs are, is a judgement.
One feature to remove stands out - the struct initialization:
struct S { int x, y; }
S s = { 1, 2 };
This, was noted, makes the order of members effectively part of
the struct's interface, which is subtly dangerous. I think we
should remove this feature.
It's a partially redundant feature, and it's able to introduce
some long-term rigidity in the code. On the other hand when you
have to write many struct literals, nested inside other literals
of different structs, repeating the names introduces a bit of
extra redundant code.
Thank you for the answers,
bye,
bearophile
Re: luajit-ffi
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 _come on_, that's just plain wrong. For example, have you ever heard of that library called OpenSSL? David
Re: More bugs...
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 linq.filter(R) is not a function template
It's an annoying limitation. IFTI specifically *only* works with
functions. Not aliases, not types, not anything else. Functions only.
-Steve
Re: Why D const is annoying
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 broken). And how could it? It's just a connection, not a server, so it doesn't parse the input... and it probably changes the state of the connection, since connections often have internal buffers they need to modify (if not prioritization, etc.). So, what is D's solution for _that_ problem? There are two solutions, both are horrible. 1. Cast. Coder beware. 2. Store conn outside the instance (i.e. in a hash lookup). Horrible. There is a possible 3rd solution. Don't use immutable/const, instead use information hiding. In other words, Your class is already technically immutable, since name will never mutate beyond the first setting. This requires coder discipline, and has no help from the compiler. But many languages that *don't* have const/immutable do well with this pattern (think Java strings). I have periodically mulled the idea of making a library-based solution for logical const. I think it would work, but you would have to be extremely cautious, and you lose some compiler guarantees for it. The most difficult part to deal with is how to prevent concurrent access, when an immutable object is always implicitly sharable. I have another idea which gets around the problem in a different way. I think it's essential to bringing arbitrary ranges in line with current array features. When I have some time to flesh it out, I'll propose it. I think we absolutely can't be finished with ranges until this is implemented. -Steve
Re: Why D const is annoying
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 comments that say that they say they won't change the object, but I can't tell if it does or not. For D, it's not limited to the public interface. The rules apply to ALL methods and fields. -- /Jacob Carlborg
Re: Why D const is annoying
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 it won't change anything about the object (which includes fields). Which makes much more sense than logical const which has completely arbitrary meaning in almost every case I've seen.
Re: luajit-ffi
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 preprocessor exploit. I am talking about mature C libraries. Oh _come on_, that's just plain wrong. For example, have you ever heard of that library called OpenSSL? David Why don't you give a link to the source where they use preprocessor heavily? And even if they do, did i say all libraries? Yes you managed to come up with a library which includes tons of header files in the sea of mature C libraries.
Re: LDC and the Debian Repository
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 Debian repositories? Seems unlikely… (and apparently it ships with Ubuntu, at least: https://launchpad.net/ubuntu/+source/libconfig) Debian maintainers are often overworked folk who miss the occasional thing and need a gentle heads up. Downstream folk building a friendly and constructive relationship with Debian maintainers generally helps everyone. I found this with Groovy and Gant. The original Debian maintainers had lost motivation so by constructive discussion with them and others from the Java maintenance team a very satisfactory situation for all arose and now Groovy, Gant, etc. seem to get packaged just a few hours after a release! Is Arthur a sole maintainer or is he part of a team. gdc presumably is part of the GCC suite. ldc could be part of the LLVM suite? The particular problem for Debian Unstable is that libconfig++8 has gone from amd64 Debian Unstable because libconfig++9 has replaced it. The ldc package however mandates libconfig++8. I suspect it just need a trivial edit and repackage -- assuming libconfig++8 and libconfig++9 are the same as far as ldc is concerned. The problem in Ubuntu seems to be a different one, but of the same type. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Does D have too many features?
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 took that out, as I use it a lot, especially
for trivial types:
struct Html { string src; }
struct Text { string src; }
struct Point { int x; int y; }
struct Size { int width; int height; }
which I like because then we can use the types for overloading,
static checks, etc., and it is very very simple to drop in and
use.
I guess there could be opCalls or constructors, but poo, it
works now without that and I like it.
Well, so probably we shouldn't remove that feature either :o).
Andrei
Re: Does D have too many features?
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 inferior because there's
no reasonable way for the library writer to defend against.
Andrei
Re: Why D const is annoying
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 disallowed in @safe code. Andrei
Re: Does D have too many features?
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 (and probably other languages) has had this feature since forever. I'm seriously worried. It seems to me like we're trying to cater to people who can't reason about the types in their program and the complexities of performing various operations on them. Since when did algorithmic complexity become a reason to take away syntax sugar? +1 I do argee. opIn is handy for arrays, too. That the complexity would be linear and thus it should be disallowed is not a valid argument in my opinion, because with the exact same argument you could kick std.algorithm.find out of phobos. It is just obvious to every trained programmer that finding an element in an unordered list takes O(n). The problem here is making complexity an implementation detail of a uniform interface (e.g. over hashes and linear containers). That is fail. Andrei
Re: Does D have too many features?
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 in the statistical sense, i.e. there's not a lot of clear collection of features we should remove; for most features that some wanted to get rid of, others had gainful uses. Andrei
Re: Does D have too many features?
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 think
we're crippling the language, considering Python (and probably other
languages) has had this feature since forever.
I'm seriously worried. It seems to me like we're trying to cater to
people who can't reason about the types in their program and the
complexities of performing various operations on them. Since when did
algorithmic complexity become a reason to take away syntax sugar?
+1
I do argee. opIn is handy for arrays, too. That the complexity would be
linear and thus it should be disallowed is not a valid argument in my
opinion, because with the exact same argument you could kick
std.algorithm.find out of phobos. It is just obvious to every trained
programmer that finding an element in an unordered list takes O(n).
The problem here is making complexity an implementation detail of a
uniform interface (e.g. over hashes and linear containers). That is fail.
Andrei
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);
}
Re: Why D const is annoying
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 disallowed in @safe code. I agree. Bye, bearophile
Re: An observation
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.
Re: Why D const is annoying
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
Re: Why D const is annoying
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?
Re: An observation
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 not using a forum/mail reader that has adequate threading facilities. I use Mutt, and I have no problem at all following threads that I'm interested in and ignoring threads I'm not interested in. Mutt shows the full thread tree of the discussion, and allows you to delete an entire subthread with a single keystroke, so all you have to do when you see the beginning of an uninteresting thread is to hit D, and it all goes away. Or just navigate past the uninteresting subtree of the discussion. This is within a single discussion, of course. The thread-delete function is also eminently useful for unrelated threads that you aren't interested in: just thread-delete the entire tree with the uninteresting subject line, and you're done. Mutt can also expand/collapse threads so that you don't drown in the sea of giant thread trees. It isn't perfect in this area (ideally it should let you do the same with subtrees) but it's pretty dang good. Not that I'm advocating Mutt, but I do recommend taking the time to learn to use a threading mail/news reader. It will help you keep up with very high traffic mailing lists/forums, and not just the D forums. (D's forums are relatively tame, comparatively speaking. I've been on mailing lists where traffic is measured in units of hundreds per day. And I used to be subscribed to several of them. Never had a problem keeping up. Just delete tree whenever it's tl;dr. :-)) T -- Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
Re: Why D const is annoying
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
Re: Why D const is annoying
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
Re: Why D const is annoying
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 technically immutable, since name will never mutate beyond the first setting. This requires coder discipline, and has no help from the compiler. Yup. But many languages that *don't* have const/immutable do well with this pattern (think Java strings). Java strings are pretty poor for performance though. :\ You shouldn't be forced to choose between O(1) performance (versus O(n)) and the correctness of your program. I have periodically mulled the idea of making a library-based solution for logical const. I think it would work, but you would have to be extremely cautious, and you lose some compiler guarantees for it. The most difficult part to deal with is how to prevent concurrent access, when an immutable object is always implicitly sharable. Yeah, 'shared' also suffers from similar limitations... I have another idea which gets around the problem in a different way. I think it's essential to bringing arbitrary ranges in line with current array features. When I have some time to flesh it out, I'll propose it. I think we absolutely can't be finished with ranges until this is implemented. Okay nice. I also think this is 100% relevant to the range issue, so I don't think we will see a true fix until this problem is solved.
Re: Why D const is annoying
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
[...]
Thought so.
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. For non-delegate arguments we have
inout (which is also its own minefield, but anyway), but it sucks that
opApply can never be marked @safe, const, or pure because there's no
guarantee at all what the delegate will do. (Forcing the delegate to be
any of the above is not really an option, because what if you *needed*
to call opApply with an impure delegate?)
This on its own is no big deal, but the thing is, const, pure, and @safe
are all viral. All it takes is for a single nested function to call
opApply somewhere, and suddenly the whole function call chain can no
longer be marked const/pure/@safe.
T
--
Let X be the set not defined by this sentence...
Re: Does D have too many features?
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 as bad.
Andrei
Re: Why D const is annoying
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 immutable/const (nor would you really want to). Okay... D's const/immutable require a different way of thinking of it. What are they useful for? Consider a multithreaded program where some threads depend on information that others have. I guess this answers my question then: const/immutable are useful for multithreading. So it means, essentially, they're pretty useless for Objects, but only useful for structs. Why? Objects have **behavior** (not just data), and depending on the _internal details_ of that behavior would be depending on an implementation detail. Sure, the method writer can call the method 'const', but he really has no idea whether someone will override it down the road and get struck by lightning because of that. What D's const seems to be is for *data*, pure and simple (no pun intended). Using it for behavior would be trying to predict the future implementations, and that is pretty damn hard. Because of that, I think we disallow direct instantiation of const() or immutable() Objects altogether, because they're pretty useless. In C++, you'd be foolish to not have locks set up even for const variables because they can change at any time for any reason. Huh? Not if they're instance variables. It's kind of silly to lock against something so you can modify instance variables. It's hardly a guarantee and it's so common to violate (look at yourself, for instance) that it means _nothing_.] I don't think I ever violated C++'s 'const'... (?) I liked how it was described as a glorified comment, because that's precisely how I think of it. More like, a **CHECKED** comment. Big difference.
When is casting const() away actually necessary? (Used to be: Re: Why D const is annoying)
Could someone mention a case where it is __necessary__ to cast away const()? How about immutable()? How about shared()?
Re: Why D const is annoying
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 that? 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. If the derived class casts away const, it breaks that contract. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Why D const is annoying
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. Bits belonging to *this* object? I thought const was transitive... If the derived class casts away const, it breaks that contract. So you're saying the same thing: Derived classes CANNOT have mutable state...
Re: LDC and the Debian Repository
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 aware, he is just a D user who thought it would be nice to have LDC packaged (thanks a lot for that, btw). gdc presumably is part of the GCC suite. ldc could be part of the LLVM suite? Well, LDC is just an open source project which happens to use LLVM, and not affiliated with llvm.org in any way – so a D suite of some kind would probably be a better fit. If the guys maintaining the LLVM packages in Debian also took care of the LDC packages, this would certainly be very welcome, but it's less of a »natural fit« than it might seem. The problem in Ubuntu seems to be a different one, but of the same type. Ubuntu is apparently shipping an ancient version of LDC (which might as well be the lastest release, since for various reasons, there hasn't been a release for quite some time now) – trunk is at LLVM 3.0 now, and we have a 3.1 branch ready. I'll see what we can get done regarding a new release in the next days/weeks. David
Re: LDC and the Debian Repository
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 aware, he is just a D user who thought it would be nice to have LDC packaged (thanks a lot for that, btw). gdc presumably is part of the GCC suite. ldc could be part of the LLVM suite? Well, LDC is just an open source project which happens to use LLVM, and not affiliated with llvm.org in any way – so a D suite of some kind would probably be a better fit. If the guys maintaining the LLVM packages in Debian also took care of the LDC packages, this would certainly be very welcome, but it's less of a »natural fit« than it might seem. The problem in Ubuntu seems to be a different one, but of the same type. Ubuntu is apparently shipping an ancient version of LDC (which might as well be the lastest release, since for various reasons, there hasn't been a release for quite some time now) – trunk is at LLVM 3.0 now, and we have a 3.1 branch ready. I'll see what we can get done regarding a new release in the next days/weeks. David
Re: luajit-ffi
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]). Additionally, the OpenSSL guys also rely on macros to generate things like their ASN1 interface ([2], [3]), collections (»safe stacks«), … And even if they do, did i say all libraries? Yes you managed to come up with a library which includes tons of header files in the sea of mature C libraries. Well, after more or less telling Alex that he has no clue what he's talking about, you implied that most of the »mature« libraries would make only moderate use of the preprocessor for constants. In this generality (»Have you ever used a C api, say OpenGL? What are they using preprocessor for? other than enum and alias?«), this is simply not true. As Alex pointed out, it's often even the other way round: The older and more mature a library is, the more preprocessor macros it uses to deal with various subtle incompatibilities between all the different systems out there… David (These links are to [1] https://github.com/D-Programming-Deimos/openssl/blob/master/C/bn.h#L369 [2] https://github.com/D-Programming-Deimos/openssl/blob/master/C/asn1.h#L301 [3] https://github.com/D-Programming-Deimos/openssl/blob/master/C/asn1t.h#L85
Re: Why D const is annoying
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 though. :\ You shouldn't be forced to choose between O(1) performance (versus O(n)) and the correctness of your program. 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. -Steve
Re: When is casting const() away actually necessary? (Used to be: Re: Why D const is annoying)
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 actually handle it, which is not the case as often as one would like. -- - Alex
Re: When is casting const() away actually necessary? (Used to be: Re: Why D const is annoying)
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 currently little more than a marker for non-TLS data. David
Re: Why D const is annoying
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 conditional purity. But Walter decided for a simpler solutions, where the purity and non-throwness of templates is inferred. Bye, bearophile
Re: Why D const is annoying
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 proposals like @pure(compile_time_predicate) to define a conditional purity. But Walter decided for a simpler solutions, where the purity and non-throwness of templates is inferred. [...] Is that implemented yet? 'cos currently I just get errors about pure functions can't call impure opApply. T -- People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
Re: luajit-ffi
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 or lack of (quite obvious) English language skills, but these never happen without a reason. So enum, alias has nothing to do with #define? Or D requires syntax to support the things i mentioned? Don't i have a right to expect, someone who answers me already understand what i am saying or ask nicely to clear it up? This is not directing Alex but you since i think we settled the issue, yet you jump as a self appointed lawyer. Nothing i hate as much as this, pack behavior in humans. It is time for me to leave this community too, i can stand many things but this. My start on this forum wasn't very bright either. Called troll for a very legitimate question, because a few regulars couldn't comprehend the topic i am talking about and/or my cryptic English. Whatever. you implied that most of the »mature« libraries would make only moderate use of the preprocessor for constants. In this generality (»Have you ever used a C api, say OpenGL? What are they using preprocessor for? other than enum and alias?«), this is simply not true. As Alex pointed out, it's often even the other way round: The older and more mature a library is, the more preprocessor macros it uses to deal with various subtle incompatibilities between all the different systems out there…
Re: Why D const is annoying
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 definitely not the case in C#.
Re: Why D const is annoying
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)
Re: LDC and the Debian Repository
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 qualified Debian Maintainer has to be involved... [...] Well, LDC is just an open source project which happens to use LLVM, and not affiliated with llvm.org in any way – so a D suite of some kind would probably be a better fit. If the guys maintaining the LLVM packages in Debian also took care of the LDC packages, this would certainly be very welcome, but it's less of a »natural fit« than it might seem. I guess the relationship between LDC and LLVM is very different to that of GDC and GCC: I guess the analogy is more LDC and Clang? [...] Ubuntu is apparently shipping an ancient version of LDC (which might as well be the lastest release, since for various reasons, there hasn't been a release for quite some time now) – trunk is at LLVM 3.0 now, and we have a 3.1 branch ready. I'll see what we can get done regarding a new release in the next days/weeks. Given that I doubt the Ubuntu developers do anything other than take Debian for this then that implies that the Debian version is also relatively ancient? Getting Debian Unstable sorted is the fastest way of getting Ubuntu sorted as far as I can see. This also gets Mint sorted as well I guess? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Does D have too many features?
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 the same.
Encapsulation of complexity is a problem if it is not obvious to the
programmer. I am not sure it can even be called such if the semantics is
different.
That would be the semantic interface, which makes the idea twice as bad.
Andrei
I tend to agree, but I think that the two points are mutually exclusive.
Re: Why D const is annoying
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 threads
or for other reasons.
Bits belonging to *this* object? I thought const was transitive...
If the derived class casts away const, it breaks that contract.
So you're saying the same thing: Derived classes CANNOT have mutable
state...
No:
interface Foo
{
void foo () const;
}
class Bar : Foo
{
int x;
void foo () const {}
void bar ()
{
x++;
}
}
void main()
{
auto bar = new Bar;
bar.bar();
writeln(bar.x);
}
--
/Jacob Carlborg
Re: luajit-ffi
good bye you won't be missed
Re: Why D const is annoying
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.
Re: LDC and the Debian Repository
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 a team. 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). You could try pinging Mathias Klose, who as far as I can see was responsible for the last upload in August of last year: https://launchpad.net/ubuntu/+source/ldc/0.9.2+hg1655-0ubuntu4
Re: Why D const is annoying
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 non-const member functions, then it cannot exist. And so if a derived class requires that, then it cannot exist. Putting const on a member function puts certain requirements on it (the same goes for nothrow, pure, and @safe), and any derived class must meet those requirements with its overridden version. It's part of the function's signature just like the return type is. - Jonathan M Davis
Re: luajit-ffi
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 hard time expressing yourself anyway. I pity you, as i believe nothing would be that low on spirit if it wasn't disturbed somehow. 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 1500. yet i... must... click Send!
Re: Why D const is annoying
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 reference into a function, I can be
guaranteed it won't be changed by that function.
So it means, essentially, they're pretty useless for Objects,
but only useful for structs.
Why? Objects have **behavior** (not just data) ...
Structs in D have behavior as well. In fact, I've found most
things I might be forced to use objects/classes in most other
languages can be easily done with D's structs and all of the
behavior and state is encapsulated nicely. Combine that with
templates and you've got some ridiculous power and efficiency.
Sure, the method writer can call the method 'const', but he
really has no idea whether someone will override it down the
road and get struck by lightning because of that.
If the method writer has the method be const, then he's said that
the contract of that method is that it doesn't change the
object's state. This is no different than having a method that
takes a string and complaining that the method writer has no idea
whether someone will want to override it later and want the
method to take an int.
You can overload the method to take an int. And you can overload
the method later down the line so that you have an implementation
which does mutate state and isn't const. Although, you certainly
need to have a version which doesn't mutate state available
still. But that's just part of the contract.
If you're writing a method and you've decided I want whoever
uses this method to not cause any mutation of state when they
call this method (maybe so there's a guarantee of consistency in
execution speed between calls or something), then you mark it
const. Otherwise, it's not really a const method.
Because of that, I think we disallow direct instantiation of
const() or immutable() Objects altogether, because they're
pretty useless.
Why? There's no reason to throw the baby out with the bath water.
There's plenty of need for inheritance for immutable/const
representation of data. Just because we can't use it for objects
whose whole life is caching (which is a clear subset of OOP usage)
doesn't mean it's useless.
Huh? Not if they're instance variables.
It's kind of silly to lock against something so you can modify
instance variables.
Depends. If you're just accessing the instance method directly
(and it's an atomic operation), you can get away with not locking.
However, If you have a C++ const object and you call a getter
method on it in a context where someone else may also be calling
a getter method on it, you must lock it. By your own admission,
you can't depend on implementation of the object. Ergo, the
getter methods may be mutating state (you can't assume it's not),
and you can't tell whether or not they are because const in C++
doesn't say whether it will mutate state. Of course, if you don't
depend on the correctness of the method you're free to not lock...
In D, if I'm sure these const objects aren't being modified
elsewhere, I can absolutely get away with not locking when I call
getter methods. If it's an immutable object, it doesn't even
cross my mind whether I need to lock it or not. You don't have
that kind of peace of mind in C++.
I don't think I ever violated C++'s 'const'... (?)
Well, seeing as C++ const apparently has no meaning ... it's
rather hard to violate it, per say. Honestly, the time my
professors taught me about C++'s const, they said it was for
methods that don't modify state. Evidently that wasn't the case,
but I never got into the mindset that const didn't mean something
that doesn't modify state... so it's rather hard for me to think
of a reason to use const for this. Const to me has always meant
don't mutate state. If you just want a view of the object where
you only use getters, that's really what D's interfaces are for.
More like, a **CHECKED** comment.
Big difference.
Not exactly. It's not checked because const objects can be
changed by anyone at anytime easily and it's common and the
compiler doesn't care. It doesn't mean anything.
Again, what I think you actually want is an interface of the
getters, not const. There's no sense in having both do the same
thing when we can actually use const to mean an object that you
won't mutate.
=-=-=-=
In any case, would the Student-getter style interface method work
for this use case or not?
interface IStudentRO {
string getName();
string getAddress();
real getGPA();
...
}
class Student : IStudentRO {
IConnection conn;
string name;
...
string getName() {
if(!name)
name = conn.get(name);
return name;
}
...
void setName(string newName) {
name = newName;
conn.set(name, newName);
}
...
}
void
Re: luajit-ffi
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 1500. yet i... must... click Send! LOL that one made my day! Glad you're still around :)
Re: luajit-ffi
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
Re: luajit-ffi
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 I and others posted. And for an automatic C importing mechanism to be worth its complexity, it must be able to handle at least the more common variations. Don't i have a right to expect, someone who answers me already understand what i am saying or ask nicely to clear it up? Frankly, no – just as you answered other posts in this thread probably without being absolutely sure what the author was trying to say. Maybe my reply sounded harsher than I intended, I tend to get annoyed too easily when somebody seems to just ignore multiple technically sound replies (which people have spent time writing, after all). I apologize for that. David
Re: Why D const is annoying
On 05/02/2012 08:58 PM, Mehrdad wrote: mutable state in an const method =O
Re: Why D const is annoying
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 could be.
Re: Why D const is annoying
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*
Re: Why D const is annoying
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', because any sort of indirection can screw you over later. This is why const is less useful than it could be. You can set interface methods to be const, but you have to understand that you're saying that method can't mutate state. There's also nothing stopping you from specifying that both const and non-const methods are available, but it would increase the workload of people down the line especially if the const and non-const version differ significantly. I think D's const is as useful as it needs/can be. That said, I can understand why you might feel that way until you start using const/immutable correctly. Once you see how it improves your conceptual model of approaching algorithms, I won't be surprised if you end up as annoyed with C++'s const as I am. It's kind of why I pointed out the whole thing where you should lock your object even when you're just calling getters on a const object. It's actually deceptively incorrect to not do that in C++.
Re: Why D const is annoying
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 the type system. It's like saying I'm overriding this method but I want it to return an int instead of a string. It's part of the interface. -- /Jacob Carlborg
