Re: dmd 1.062 and 2.047 release
On 6/15/2010 5:58 AM, Jacob Carlborg wrote: On 2010-06-14 04:10, Eric Poggel wrote: On 6/13/2010 9:30 AM, Lutger wrote: Great, thank you! I noticed both std.concurrency and std.json are not (yet?) included in the documentation. Does that have any bearing on their status, are they usable and / or stable? There are some other modules without documentation like std.openrj and std.perf. Is there a page somewhere that documents their fate? I could only find this one: http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel Speaking of std.json, has anyone looked at the Orange library on dsource? http://www.dsource.org/projects/orange/ I haven't used it (yet), but it looks to support a back-end serialization engine that supports different front-ends, with xml currently being implemented. It's also Boost licensed. I would but it the other way around, a serialization front end with support for different back ends (archive types). I hope to add support for Phobos soon. Maybe I'm calling the front-end the back-end. Orange provides a reflection/serialization engine and allows for plugable serialization types--xml being the only one implemented so far.
Re: dmd 1.062 and 2.047 release
On 6/15/2010 7:58 PM, strtr wrote: == Quote from BCS (n...@anon.com)'s article Hello Walter, strtr wrote: It's the optimization :) Without -O compilation took only a few seconds! Well, that explains it! Little attempt is made in the optimizer to make it compile faster if that would interfere with generating faster code. How does 1.061 w/ -O compare to 1.062 w/ -O? If 62 is much slower that might be of interest. That is exactly what I mentioned :? Or did you mean w/o ? In that case I don't much care it takes 5 or 10 seconds for thousands of lines of code :) (or, I don't know how to time dmd more precise than with my stopwatch when called through bud :D) Anyway, I kind of like that it takes longer now with optimization. I haven't checked whether things actually got any faster, but it feels a bit like in older games when it said: Optimizing X for your computer or Generating A.I. :) Reticulating Splines was always my favorite.
Re: dmd 1.062 and 2.047 release
== Quote from Eric Poggel (dnewsgr...@yage3d.net)'s article On 6/15/2010 5:58 AM, Jacob Carlborg wrote: On 2010-06-14 04:10, Eric Poggel wrote: On 6/13/2010 9:30 AM, Lutger wrote: Great, thank you! I noticed both std.concurrency and std.json are not (yet?) included in the documentation. Does that have any bearing on their status, are they usable and / or stable? There are some other modules without documentation like std.openrj and std.perf. Is there a page somewhere that documents their fate? I could only find this one: http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel Speaking of std.json, has anyone looked at the Orange library on dsource? http://www.dsource.org/projects/orange/ I haven't used it (yet), but it looks to support a back-end serialization engine that supports different front-ends, with xml currently being implemented. It's also Boost licensed. I would but it the other way around, a serialization front end with support for different back ends (archive types). I hope to add support for Phobos soon. Maybe I'm calling the front-end the back-end. Orange provides a reflection/serialization engine and allows for plugable serialization types--xml being the only one implemented so far. Yes, regardless of what the parts are called you description is correct. I'm working now on creating an XML document abstraction layer so I can support both Tango and Phobos. (replying using the Web interface, this particular post didn't have any content in my news reader) /Jacob Carlborg
Re: enforce()?
bearophile wrote: I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming? I can see two benefits: 1) enforce throws object.Exception, which is the root of the exception hierarchy; hence enforce errors can be caught with the same general catch(Exception) clause [*]. On the other hand, assert throws a type that is out of the Exception hierarchy: core.exception.AssertError 2) As a bonus, the word 'enforce' fits the purpose better than 'assert' 3) (the other 2 :p) The format of the message of the uncaught exceptions is a little better (e.g. no @ sign before the file name) Ali * Note: Actually, Throwable is at the top of the exception hierarchy, but I've heard before that the top exception class should be taken to be Exception; perhaps for user applications?
Re: enforce()?
You need to read TDPL for that :o). Please don't start replying to queries in this fashion. Not everyone has the wherewithal to get a copy of a book such as TDPL. Especially seeing as you're the author, this kind of reply just looks like whoring for the book. I'm not saying that's what it is, just what it can look like. I've got TDPL on the way from Amazon, by the way. I just don't want to see this reply, and wanted to express my distaste.
Re: enforce()?
Bernard Helyer wrote: You need to read TDPL for that :o). Please don't start replying to queries in this fashion. Not everyone has the wherewithal to get a copy of a book such as TDPL. Especially seeing as you're the author, this kind of reply just looks like whoring for the book. I'm not saying that's what it is, just what it can look like. I've got TDPL on the way from Amazon, by the way. I just don't want to see this reply, and wanted to express my distaste. All right, all right. Basically there's a marked difference between contract checking (which verifies the architectural integrity of a program) and error handling (which deals with errors that occur in correct programs). Contracts help with the former, enforce helps with the latter. The differences are marked enough that TDPL dedicates a separate chapter to each. Andrei
Re: enforce()?
On Wed, 16 Jun 2010 00:18:03 -0700, Andrei Alexandrescu wrote: Bernard Helyer wrote: You need to read TDPL for that :o). Please don't start replying to queries in this fashion. Not everyone has the wherewithal to get a copy of a book such as TDPL. Especially seeing as you're the author, this kind of reply just looks like whoring for the book. I'm not saying that's what it is, just what it can look like. I've got TDPL on the way from Amazon, by the way. I just don't want to see this reply, and wanted to express my distaste. All right, all right. Basically there's a marked difference between contract checking (which verifies the architectural integrity of a program) and error handling (which deals with errors that occur in correct programs). Contracts help with the former, enforce helps with the latter. I think any confusion regarding this may stem from the fact that enforce () resides in std.contracts. Personally, I think it's worth moving it to object.d, but maybe it's too late for that? Anyway, I love enforce() -- it's become my standard error handling tool. -Lars
Re: std.container / tightArray / class (de)allocators
On 16.06.2010 08:59, Andrei Alexandrescu wrote:
Robert M. Münch wrote:
On 2010-06-15 09:49:29 +0200, Robert M. Münch said:
Hi, since std.container is now part of the DMD compiler and class
allocators/deallocaters are no longer part of the language, the way
to go now, as far as I understand now, it to use tightArray.
So, how to use tightArray to allocate structs and classes from a
specific memory pool? Will such allocations be under GC control or not?
For example: How do I ensure that an allocation is done from a
memory-mapped file area?
Has noone a tipp for me how to make use an own allocator?
Sorry for being slow on that. Currently TightArray (renamed to Array)
uses hardcoded calls to malloc and free. I'd be glad to use a better
design if one came along.
Andrei
Btw. I downloaded the new dmd(2047) and tried to use this new Array
template. But it does not seem to work:
import std.container;
void main()
{
Array!(int) a;
}
//src\phobos\std\container.d(1660): Error: function
core.stdc.stdlib.free (void* ptr) is not callable using argument types
(int[])
//src\phobos\std\container.d(1660): Error: cannot implicitly convert
expression ((*this._data)._payload) of type int[] to void*
is it my fault? does anyone else have this problem?
Re: Signed word lengths and indexes
On 15.06.2010 19:41, Walter Bright wrote: 3. The compiler could be easily modified to add a switch that prevents such features from being used. This is no different from the customizations done to C compilers for kernel dev. Why not make such a change in a future release of the official version ?
Re: std.container / tightArray / class (de)allocators
On 2010-06-16 08:59:47 +0200, Andrei Alexandrescu said: Sorry for being slow on that. Currently TightArray (renamed to Array) uses hardcoded calls to malloc and free. I'd be glad to use a better design if one came along. Hi Andrei, ok. At least it's a chart. I'm going to take a look and first try to replace malloc/free with my versions and than we can see how to make these functions replace-able at compile/run-time. --- Robert M. Münch http://www.robertmuench.de
Re: Signed word lengths and indexes
Stephan wrote: On 15.06.2010 19:41, Walter Bright wrote: 3. The compiler could be easily modified to add a switch that prevents such features from being used. This is no different from the customizations done to C compilers for kernel dev. Why not make such a change in a future release of the official version ? It's pretty low on the priority list, because the absence of such a switch would not prevent you from using D as a better C compiler.
Re: Signed word lengths and indexes
Walter Bright wrote: Stephan wrote: On 15.06.2010 19:41, Walter Bright wrote: 3. The compiler could be easily modified to add a switch that prevents such features from being used. This is no different from the customizations done to C compilers for kernel dev. Why not make such a change in a future release of the official version ? It's pretty low on the priority list, because the absence of such a switch would not prevent you from using D as a better C compiler. I would move it up in the priority if there was a serious project that needed it, as opposed to being a convenient excuse to not use D. One reason that dmd comes with source is so that people can try out things like this.
Re: enforce()?
Andrei Alexandrescu wrote: Basically there's a marked difference between contract checking (which verifies the architectural integrity of a program) and error handling (which deals with errors that occur in correct programs). Contracts help with the former, enforce helps with the latter. The differences are marked enough that TDPL dedicates a separate chapter to each. Yes, I agree it is extremely important to separate the concepts of contract checking from error handling.
Re: enforce()?
Ali Çehreli wrote: bearophile wrote: I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming? I can see two benefits: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated.
Re: enforce()?
On 06/16/2010 04:15 PM, Walter Bright wrote: Ali Çehreli wrote: bearophile wrote: I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming? I can see two benefits: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. Could you please explain them? There are many people here that don't understand the difference between these two concepts (including me). So maybe we are too dumb, maybe those concepts are not generally known or maybe the explanation is not very well clear in the documentation.
Re: std.container / tightArray / class (de)allocators
On Wed, 16 Jun 2010 10:04:05 +0200, Stephan wrote:
Btw. I downloaded the new dmd(2047) and tried to use this new Array
template. But it does not seem to work:
import std.container;
void main()
{
Array!(int) a;
}
//src\phobos\std\container.d(1660): Error: function
core.stdc.stdlib.free (void* ptr) is not callable using argument types
(int[])
//src\phobos\std\container.d(1660): Error: cannot implicitly convert
expression ((*this._data)._payload) of type int[] to void*
is it my fault? does anyone else have this problem?
It's a bug (and a strange one at that). I've checked in a fix, see:
http://d.puremagic.com/issues/show_bug.cgi?id=4327
-Lars
Re: std.container / tightArray / class (de)allocators
On 16.06.2010 11:39, Lars T. Kyllingstad wrote:
On Wed, 16 Jun 2010 10:04:05 +0200, Stephan wrote:
Btw. I downloaded the new dmd(2047) and tried to use this new Array
template. But it does not seem to work:
import std.container;
void main()
{
Array!(int) a;
}
//src\phobos\std\container.d(1660): Error: function
core.stdc.stdlib.free (void* ptr) is not callable using argument types
(int[])
//src\phobos\std\container.d(1660): Error: cannot implicitly convert
expression ((*this._data)._payload) of type int[] to void*
is it my fault? does anyone else have this problem?
It's a bug (and a strange one at that). I've checked in a fix, see:
http://d.puremagic.com/issues/show_bug.cgi?id=4327
-Lars
thanks for that, i hope its in the next release.
Re: enforce()?
On Tue, 15 Jun 2010 22:23:15 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: bearophile wrote: I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming? You need to read TDPL for that :o). And what are the purposes of std.contracts.AssumeSorted()? Is it useful for something? AssumeSorted was an experiment. I think it has drawbacks that I don't know how to address, so I'll retire it. Hm... what are the drawbacks (besides it not being enforced)? I thought it was a good solution. -Steve
Re: enforce()?
On Wed, 16 Jun 2010 05:28:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: On 06/16/2010 04:15 PM, Walter Bright wrote: Ali Çehreli wrote: bearophile wrote: I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming? I can see two benefits: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. Could you please explain them? There are many people here that don't understand the difference between these two concepts (including me). So maybe we are too dumb, maybe those concepts are not generally known or maybe the explanation is not very well clear in the documentation. I think of enforce as a convenient way translating an error in an expectation to an exception in a single expression. For example, take some system call that returns -1 on error, you could do this: if(result 0) throw new Exception(oops!); or you could do this: enforce(result = 0, oops!); Think of enforce as throw if And in fact, I think there's an errnoEnforce which throws a standard exception with the string error from the system. I'd say the difference between enforce and assert is exactly what Andrei said -- enforce is meant to catch errors that can occur during normal operation. Assert is meant to catch errors that are not expected during normal operation. Assert's more like a sanity check. Also, assert is turned off in release mode, enforce is left on. -Steve
Re: enforce()?
On Wed, 16 Jun 2010 06:55:21 -0400, Steven Schveighoffer wrote: On Wed, 16 Jun 2010 05:28:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: On 06/16/2010 04:15 PM, Walter Bright wrote: Ali Çehreli wrote: bearophile wrote: I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming? I can see two benefits: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. Could you please explain them? There are many people here that don't understand the difference between these two concepts (including me). So maybe we are too dumb, maybe those concepts are not generally known or maybe the explanation is not very well clear in the documentation. I think of enforce as a convenient way translating an error in an expectation to an exception in a single expression. For example, take some system call that returns -1 on error, you could do this: if(result 0) throw new Exception(oops!); or you could do this: enforce(result = 0, oops!); Think of enforce as throw if It also adds a file and a line number to the error message, so the problem is easier to track down. Very handy. :) And in fact, I think there's an errnoEnforce which throws a standard exception with the string error from the system. That's right, and there's even an enforceEx() which lets you specify which exception type to throw: http://digitalmars.com/d/2.0/phobos/std_contracts.html#enforceEx -Lars
Re: Signed word lengths and indexes
Walter Bright: Changing the sign of size_t from unsigned to signed when going from 32 to 64 bits will cause a difference in behavior. I have proposed to use a signed word on both 32 and 64 bits systems. So where's the difference in behaviour? A memory manager sees the address space as 0..N, not -N/2..0..N/2 If D arrays use signed words as indexes on 32 bit systems then only half of the original length can be used. The numbers in 0..N/2 are a subset of half of the unsigned number range. Bye, bearophile
Re: D const enables multi-reader synchronization
On Tue, 15 Jun 2010 14:47:08 -0400, Jérôme M. Berger jeber...@free.fr wrote: Robert Jacques wrote: On Mon, 14 Jun 2010 15:17:57 -0400, Tomek Sowiński j...@ask.me wrote: This is a continuation of a recent thread Synchronized const methods on D.learn. Currently only one thread at a time can execute a synchronized method. But think about D's const -- it's deep, so if a method is const, it can't possibly mutate its object. So many synchronized const method calls could safely look-but-not-touch the same object at the same time. The chain of questions that stems from the above is: 1. Is letting many readers in on an object really safe? Know any multi-threading quirk that would make sh*t hit the fan? 2. If answer to 1. is yes, would there be room in the current implementation of synchronized keyword for a readers-writer lock? 3. If answer to 2. is yes, how do we tackle write-starvation? In a read-mostly scenario the mutating thread may be held up forever. More on readers-writer lock: http://en.wikipedia.org/wiki/Readers-writer_lock Tomek This has been suggested before and has been rejected. The major issue is that CREW (concurrent-read exclusive-write) locks are known to be not composite and therefore its trivial to write code which results in a deterministic dead-lock. The problem lies in that the const method can have access to a non-const reference to its object via method arguments and/or globals. Thus, a read-lock can be obtained first and then later a write lock is attempted. Since the first read lock will never be released, the write lock can never be taken and a deadlock occurs. Unless the write lock can be acquired when the only thread holding the read lock is the same as the one wanting the write lock. Something similar is already done for the standard lock used by synchronized methods (otherwise, a synchronized method would be unable to call another synchronized method without deadlocking). Jerome Correct in theory, wrong in practice. There's an elegant way of storing this information at zero cost in the case of simple locks; there's no equivalent for CREW locks.
Re: Signed word lengths and indexes
On 06/15/2010 05:43 PM, Walter Bright wrote: One example of this is transitive immutability. Nobody asked for it. I find this hard to believe. I seem to recall that you were personally against const for a very long time. Did none of the people advocating for const suggest a deep const? Should I dig through the archives?
Re: std.container / tightArray / class (de)allocators
On 16/06/2010 10:50, Robert M. Münch wrote: On 2010-06-16 08:59:47 +0200, Andrei Alexandrescu said: Sorry for being slow on that. Currently TightArray (renamed to Array) uses hardcoded calls to malloc and free. I'd be glad to use a better design if one came along. Hi Andrei, ok. At least it's a chart. I'm going to take a look and first try to replace malloc/free with my versions and than we can see how to make these functions replace-able at compile/run-time. --- Robert M. Münch http://www.robertmuench.de HM How to bring a (Tight)Array designed as memory watch dog and a fixed sized, but chunked, memory mapped file together. I am curious .. (to say the least)
Re: enforce()?
On 2010-06-16 05:15:24 -0400, Walter Bright newshou...@digitalmars.com said: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. True. Yet, enforce is inside std.contracts. If that isn't conflating the two concepts I wonder what it is. :-) -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: enforce()?
Steven Schveighoffer wrote: Think of enforce as throw if So why not concatenating the two and rename it to exactly 'throwif'? Self descriptive is better than cryptic 'enforce'. -- Alex Makhotin, the founder of BITPROX, http://bitprox.com
Re: enforce()?
Steven Schveighoffer, el 16 de junio a las 06:55 me escribiste: On Wed, 16 Jun 2010 05:28:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: On 06/16/2010 04:15 PM, Walter Bright wrote: Ali Çehreli wrote: bearophile wrote: I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming? I can see two benefits: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. Could you please explain them? There are many people here that don't understand the difference between these two concepts (including me). So maybe we are too dumb, maybe those concepts are not generally known or maybe the explanation is not very well clear in the documentation. I think of enforce as a convenient way translating an error in an expectation to an exception in a single expression. For example, take some system call that returns -1 on error, you could do this: if(result 0) throw new Exception(oops!); or you could do this: enforce(result = 0, oops!); Think of enforce as throw if So maybe throw_if() would be a better name =) Anyway, I think enforce() is poisson, because it make the programmer to not think about errors at all, just add and enforce() and there you go. But when you need to be fault tolerant, is very important to know what's the nature of the error, but thanks to enforce(), almost every error is a plain Exception, no hierarchy, no extra info, all you can do to get a little more info about what happened is to parse the exception string, and that's not really an option. And in fact, I think there's an errnoEnforce which throws a standard exception with the string error from the system. That's the only useful case of enforce, because it includes the *important* information (the actual errno). There is also enforceEx!(), to use a custom exception, which practically nobody uses (I counted only 4 uses in phobos). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Y será el día en que la electricidad deje de ser rayo y sea depilador femenino. -- Ricardo Vaporeso
Re: Price drop for TDPL on Amazon to $41.10eom
Hello MIURA, Received a collector's edition from Amazon Japan, here in Tokyo! Has anyone gotten a non-collectors edition yet? (I'm getting mine via BN, should ship today :) -- ... IXOYE
Re: enforce()?
Michel Fortin wrote: On 2010-06-16 05:15:24 -0400, Walter Bright newshou...@digitalmars.com said: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. True. Yet, enforce is inside std.contracts. If that isn't conflating the two concepts I wonder what it is. :-) You're right! I think Lars' suggestion is sensible - we should move enforce to object. Better yet we should find a better name for std.contracts. Ideas? Andrei
Re: enforce()?
Alex Makhotin wrote: Steven Schveighoffer wrote: Think of enforce as throw if So why not concatenating the two and rename it to exactly 'throwif'? Self descriptive is better than cryptic 'enforce'. Well throwif describes mechanism and enforce describes intent. After all assert is not abortif :o). Andrei
Re: enforce()?
Leandro Lucarella wrote: Steven Schveighoffer, el 16 de junio a las 06:55 me escribiste: On Wed, 16 Jun 2010 05:28:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: On 06/16/2010 04:15 PM, Walter Bright wrote: Ali Çehreli wrote: bearophile wrote: I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming? I can see two benefits: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. Could you please explain them? There are many people here that don't understand the difference between these two concepts (including me). So maybe we are too dumb, maybe those concepts are not generally known or maybe the explanation is not very well clear in the documentation. I think of enforce as a convenient way translating an error in an expectation to an exception in a single expression. For example, take some system call that returns -1 on error, you could do this: if(result 0) throw new Exception(oops!); or you could do this: enforce(result = 0, oops!); Think of enforce as throw if So maybe throw_if() would be a better name =) Anyway, I think enforce() is poisson, Indeed it is a bit fishy :o). because it make the programmer to not think about errors at all, just add and enforce() and there you go. But when you need to be fault tolerant, is very important to know what's the nature of the error, but thanks to enforce(), almost every error is a plain Exception, no hierarchy, no extra info, all you can do to get a little more info about what happened is to parse the exception string, and that's not really an option. I think there is no real need for exception hierarchies. I occasionally dream of eliminating all of the useless exceptions defined left and right in Phobos. And in fact, I think there's an errnoEnforce which throws a standard exception with the string error from the system. That's the only useful case of enforce, because it includes the *important* information (the actual errno). There is also enforceEx!(), to use a custom exception, which practically nobody uses (I counted only 4 uses in phobos). I'd be hard pressed to find good examples of exception hierarchy use. Everybody talks about them but I've seen none. The fact that the coder doesn't need to think hard to use enforce() effectively is a plus, not a minus. An overdesigned enforce that adds extra burden to its user would have been a mistake. Andrei
Re: enforce()?
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Everybody talks about them but I've seen none. The fact that the coder doesn't need to think hard to use enforce() effectively is a plus, not a minus. An overdesigned enforce that adds extra burden to its user would have been a mistake. Andrei IMHO the presence of a simple method of handling errors, even if it's far from perfect, is a good thing. If you have to think about a whole exception hierarchy every time you hit a possible error condition in your code, you tend to put this tedious task off until forever, leading to programs that fail for unknown reasons because some error condition was never reported. Well-designed exception hierarchies are nice, but forcing their use all the time would be making the perfect the enemy of the good. Furthermore, I love enforce() because sometimes I want just some subset of assertions checked in release mode, usually whichever ones can be checked at negligible performance cost. I tend to use it a lot as an assert-even-in-release-mode function.
Re: enforce()?
On 2010-06-16 10:53:12 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org said: Leandro Lucarella wrote: Steven Schveighoffer, el 16 de junio a las 06:55 me escribiste: On Wed, 16 Jun 2010 05:28:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: On 06/16/2010 04:15 PM, Walter Bright wrote: Ali Çehreli wrote: bearophile wrote: I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming? I can see two benefits: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. Could you please explain them? There are many people here that don't understand the difference between these two concepts (including me). So maybe we are too dumb, maybe those concepts are not generally known or maybe the explanation is not very well clear in the documentation. I think of enforce as a convenient way translating an error in an expectation to an exception in a single expression. For example, take some system call that returns -1 on error, you could do this: if(result 0) throw new Exception(oops!); or you could do this: enforce(result = 0, oops!); Think of enforce as throw if So maybe throw_if() would be a better name =) Anyway, I think enforce() is poisson, Indeed it is a bit fishy :o). because it make the programmer to not think about errors at all, just add and enforce() and there you go. But when you need to be fault tolerant, is very important to know what's the nature of the error, but thanks to enforce(), almost every error is a plain Exception, no hierarchy, no extra info, all you can do to get a little more info about what happened is to parse the exception string, and that's not really an option. I think there is no real need for exception hierarchies. I occasionally dream of eliminating all of the useless exceptions defined left and right in Phobos. The need is not really for a hierarchy. The hierarchy serves the need, which is to: 1. Be able to programatically check the kind of the error and so your program can act appropriately. 2. Propagate additional information related to the error and the context it occured. Displaying a proper error message to a user and offering relevant recovery choices often need both. Sometime, a program won't ask the user and attempt something by itself as a recovery. In both cases, you need to know the kind of error, and may need context information. And in fact, I think there's an errnoEnforce which throws a standard exception with the string error from the system. That's the only useful case of enforce, because it includes the *important* information (the actual errno). There is also enforceEx!(), to use a custom exception, which practically nobody uses (I counted only 4 uses in phobos). I'd be hard pressed to find good examples of exception hierarchy use. Everybody talks about them but I've seen none. The need is not really for a hierarchy. The hierarchy serves the need, which is to: 1. Programatically check the kind of the error and so your program can act appropriately. 2. Propagate additional information related to the error and the context in which it occurred. Displaying a proper error message to a user and offering relevant recovery choices often need both. Sometime, a program won't ask the user and attempt something by itself as a recovery. In both cases, you need to know the kind of error, and may need context information. That said, hierarchies are often abused, and aren't universally useful. But exceptions should provide the above information in a way or another when useful. Think about a GUI program, if an exception is thrown somewhere during a complex operation (say, reading a lot of files), I could catch it as some level, create a wrapper exception with the context (file=hello.d error=access denied) and rethrow it to unwind until reatching the GUI error handler. Or the file function could throw a useful exception from the start. In either cases, the code in charge of that operation can display a message such as Creating the archive failed. File 'hello.d' could not be read because you do not have read permissions to it. with options Retry as Administrator, Exclude 'hello.d' or Cancel. Knowing programatically what has gone wrong is important in many cases. The fact that the coder doesn't need to think hard to use enforce() effectively is a plus, not a minus. An overdesigned enforce that adds extra burden to its user would have been a mistake. That's indeed true. Throwing an Exception with no info is still better than not throwing at all, and creating useful exceptions isn't always easy, nor economically rewarding. What's important is to make it easy to improve the thrown exception when it becomes relevant. For instance // first version:
Re: std.container / tightArray / class (de)allocators
On 2010-06-16 15:33:40 +0200, BLS said: How to bring a (Tight)Array designed as memory watch dog and a fixed sized, but chunked, memory mapped file together. I am curious .. (to say the least) The idea is quite simple (not so much dependend on Array): - implement a memory-allocator and manager that manages the free space in a memory mapped file (MMF) - implement a based pointer type to have address independent pointers inside the MMF - provide a way to allocate data-structures using based pointers via this memory manager in the memory mapped file - use these data-structures at run-time The run-time objects will be persistent by default. The based pointer ensures that links between such objects are pesistent. The memory manager keeps track of the free areas and used areas of the MMF much like a file-system. As I don't want to mirror all D runtime stuff I'm seeking for a way to gently exchange/swap the normal GC memory allocator through a MMF allocator, without impacting the normal types, classes etc. -- Robert M. Münch http://www.robertmuench.de
Re: Signed word lengths and indexes
Jeff Nowakowski wrote: On 06/15/2010 05:43 PM, Walter Bright wrote: One example of this is transitive immutability. Nobody asked for it. I find this hard to believe. I seem to recall that you were personally against const for a very long time. Did none of the people advocating for const suggest a deep const? Should I dig through the archives? Andrei explained transitivity to me and convinced me of its utility.
Re: Signed word lengths and indexes
bearophile wrote: Walter Bright: Changing the sign of size_t from unsigned to signed when going from 32 to 64 bits will cause a difference in behavior. I have proposed to use a signed word on both 32 and 64 bits systems. So where's the difference in behaviour? If we go back in the thread, the argument for the signed size_t argument was for 64 bit address spaces. With 32 bit address spaces, objects larger than 31 bits are needed.
Re: enforce()?
Michel Fortin wrote: On 2010-06-16 05:15:24 -0400, Walter Bright newshou...@digitalmars.com said: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. True. Yet, enforce is inside std.contracts. If that isn't conflating the two concepts I wonder what it is. :-) I agree completely. enforce must move.
Associative array dup property?
I needed a duplicate of associative array so I wrote myDict.dup, which failed to compile (I use DMD 2.046). So I looked into the official language spec, which doesn't mention dup property for associative arrays. The only trace I found on the Internet is in the preview of 4th chapter of TDPL (I'm still waiting for my copy from amazon.co.uk, which I hope will be dispatched before August), which, at the top of page 124, claims: To create a duplicate of an associative array, use .dup, which works the same as for 10 arrays. So... is it a bug or is this feature missing intentionally? What would you recommend for concise, fast and safe surrogate? AM
Re: enforce()?
Ary Borenszweig wrote: On 06/16/2010 04:15 PM, Walter Bright wrote: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. Could you please explain them? There are many people here that don't understand the difference between these two concepts (including me). So maybe we are too dumb, maybe those concepts are not generally known or maybe the explanation is not very well clear in the documentation. It has nothing to do with being dumb, as it is not obvious. Contracts are for verifying that your program is in a state that it is designed to be in. A contract failure is defined as a program bug. Errors, on the other hand, are things that can go wrong at run time, like your disk is full when trying to write a file. These are NOT program bugs. Another way to look at it is your program should continue to operate correctly if all the contracts are removed. This is not true of removing all error checking and handling. Furthermore, errors are something a program can recover from and continue operating. Contract failures are ALWAYS fatal. A common newbie (and some expert) misconception is that contract failures can or even must be recovered. This comes from a misunderstanding of the basic principles of engineering a safe and reliable system.
Re: enforce()?
Walter Bright wrote: Michel Fortin wrote: On 2010-06-16 05:15:24 -0400, Walter Bright newshou...@digitalmars.com said: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. True. Yet, enforce is inside std.contracts. If that isn't conflating the two concepts I wonder what it is. :-) I agree completely. enforce must move. Where to? Andrei
Re: enforce()?
Andrei Alexandrescu, el 16 de junio a las 07:53 me escribiste:
because it make the programmer to
not think about errors at all, just add and enforce() and there you go.
But when you need to be fault tolerant, is very important to know what's
the nature of the error, but thanks to enforce(), almost every error is
a plain Exception, no hierarchy, no extra info, all you can do to get
a little more info about what happened is to parse the exception string,
and that's not really an option.
I think there is no real need for exception hierarchies. I
occasionally dream of eliminating all of the useless exceptions
defined left and right in Phobos.
Exception hierarchy is only one way to discriminate error types. Extra
info, is another (like an error code). I agree that a *large* exception
hierarchy hurts more than it helps.
And in fact, I think there's an errnoEnforce which throws a standard
exception with the string error from the system.
That's the only useful case of enforce, because it includes the
*important* information (the actual errno).
There is also enforceEx!(), to use a custom exception, which practically
nobody uses (I counted only 4 uses in phobos).
I'd be hard pressed to find good examples of exception hierarchy
use. Everybody talks about them but I've seen none.
I think Python has a good one. I find myself discriminating between
ValueError, IndexError, KeyError, OSError and IOError all the time.
The fact that the coder doesn't need to think hard to use enforce()
effectively is a plus, not a minus. An overdesigned enforce that
adds extra burden to its user would have been a mistake.
That is, if you don't care on handling errors and let the program crash
with a backtrace, or add a big try {} catch (Exception) in the main. If
that's not the case, it only produce a false feeling that D (standard
library) is good handling errors when it's not, it's just a binary
there is an error - there is no errors.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
The average person laughs 13 times a day
Re: Associative array dup property?
Adrian Matoga:
So... is it a bug or is this feature missing intentionally?
I have asked for a .dup for AAs something like three years ago, and probably
other people have asked for it years before. I think it will be added, but I
presume nobody has implemented it yet.
What would you recommend for concise, fast and safe surrogate?
This is a possible version (untested):
TV[TK] dup(TK, TV)(TV[TK] aa) {
TV[TK] result;
foreach (k, v; aa)
result[k] = v;
return result;
}
Bye,
bearophile
Re: help with bind
== Repost the article of jspencer (spenc...@sbcglobal.net)
== Posted at 2010/06/16 12:55 to digitalmars.D.learn
I�talked�to�Tom�Stachowiak,�who�couldn't�spot�anything�wrong�with�the
code.��I�believe�this�is�a�bug�in�std.bind�(or�maybe�std.traits.)��Has
anyone�else�seen�this?
With�2.047:
import�std.bind;
import�std.stdio;
void�g�(int�a,�int�b)
{
���int�c�=�a�+�b;
}
void�main()
{
���auto�g1�=�bind(g,�_0,�_0);
���writeln(typeid(typeof(g1)));
}
---
gives
C:\tools\dmd2\windows\bin\..\..\src\phobos\std\bind.d(977):�Error:
template�instance�ParameterTypeTuple!(const(EmptySlot)*)�does�not
match�template�declaration�ParameterTypeTuple(dg...)�if�(dg.length�==
1��isCallable!(dg))
Re: enforce()?
Lutger wrote: bearophile wrote: I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming? I'd think of it this way: enforce() is part of defensive programming, and contracts are related to software testing. That's probably a pretty good way of putting it. It's essentially the difference between when you use assertions and when you use exceptions. Assertions assert that something is _always_ true and that if it isn't, the program is wrong, while exceptions are for exceptional circumstances (as opposed to _never_) and indicate an error of some kind which is likely outside the control of the program - such as something happening with the file system, user input, or the amount of available memory. enforce() appears to effectively be the exception equivalent to assert(). You use it when you want an exception thrown rather than when you want to kill your program due to an error. Unfortunately, the difference between when assertions should be used and when exceptions should be used is one that is just subtle enough that it often trips people up, even though in theory it should be fairly straightforward. - Jonathan M Davis
Re: Associative array dup property?
I also solved it with foreach but the way you wrapped it into a handy template makes it worth keeping for the future use. Thanks, bearophile!
Re: Signed word lengths and indexes
Walter Bright: If we go back in the thread, the argument for the signed size_t argument was for 64 bit address spaces. I was asking for signed word lengths and indexes on both 32 and 64 bit systems. Sorry for not being more clear from the start. With 32 bit address spaces, objects larger than 31 bits are needed. I don't fully understand what you mean. On 32 bit systems I can accept arrays and lists and collections (or a call to malloc) with only 2_147_483_648 items/bytes. On a 32 bit Windows with 3 GB RAM (and Windows itself set to use 3 GB) DMD allows me to allocate only a part of those. In practice you can't allocate more than 2 GB in a single block. On a 32 bit system I can desire arrays with something like 3_000_000_000 items only when the array items are single bytes (ubyte, char, byte, bool), and such situations are not so common (and probably 32bit Windows will not allow me to do it). (I am still writing a comment to another answer of yours, I am not so fast, please be patient :-) ) Bye, bearophile
Re: Associative array dup property?
== Quote from bearophile (bearophileh...@lycos.com)'s article
Adrian Matoga:
So... is it a bug or is this feature missing intentionally?
I have asked for a .dup for AAs something like three years ago, and probably
other people have asked for it years before. I think it will be added, but I
presume nobody has implemented it yet.
What would you recommend for concise, fast and safe surrogate?
This is a possible version (untested):
TV[TK] dup(TK, TV)(TV[TK] aa) {
TV[TK] result;
foreach (k, v; aa)
result[k] = v;
return result;
}
Bye,
bearophile
Of course that works, but you can probably do it more efficiently if you work
at a
lower level, inside aaA.d. For example, in terms of unnecessary memory
allocations your function is roughly equivalent to using the following for
duplicating a regular array:
T[] dup(T)(T[] arr) {
T[] ret;
foreach(elem; arr) {
ret ~= elem;
}
return ret;
}
Re: enforce()?
Andrei Alexandrescu wrote: Anyway, I think enforce() is poisson, Indeed it is a bit fishy :o). LOL. My thoughts exactly. because it make the programmer to not think about errors at all, just add and enforce() and there you go. But when you need to be fault tolerant, is very important to know what's the nature of the error, but thanks to enforce(), almost every error is a plain Exception, no hierarchy, no extra info, all you can do to get a little more info about what happened is to parse the exception string, and that's not really an option. I think there is no real need for exception hierarchies. I occasionally dream of eliminating all of the useless exceptions defined left and right in Phobos. And in fact, I think there's an errnoEnforce which throws a standard exception with the string error from the system. That's the only useful case of enforce, because it includes the *important* information (the actual errno). There is also enforceEx!(), to use a custom exception, which practically nobody uses (I counted only 4 uses in phobos). I'd be hard pressed to find good examples of exception hierarchy use. Everybody talks about them but I've seen none. The fact that the coder doesn't need to think hard to use enforce() effectively is a plus, not a minus. An overdesigned enforce that adds extra burden to its user would have been a mistake. Andrei I think that exception hierarchies can be quite useful, but in most cases, I haven't seen projects bother with them. I do think that certain types of exceptions can be useful as separate types as long as they inherit from the base exception type and you therefore don't _have_ to worry about the hierarchy. A good example of a useful exception type IMO is Java's IOException. It makes good sense to handle them in a specific way separate from general exceptions. You can frequently recover just fine from them, and it allows you to handle I/O-related exceptions gracefully while other exceptions might be considered fatal. However, those other exceptions - especially those which are from more or less unrecoverable errors NullPointerExceptions or OutOfMemoryExceptions - don't necessarily gain much from an exception hierarchy. So, I think that it really depends on the exception. I do think, however, that there are certain types of exceptions which can benefit from having their own type because it allows you to handle them in a specific manner separate from general and/or unrecoverable exceptions. - Jonathan M Davis
Re: Signed word lengths and indexes
== Quote from bearophile (bearophileh...@lycos.com)'s article Walter Bright: If we go back in the thread, the argument for the signed size_t argument was for 64 bit address spaces. I was asking for signed word lengths and indexes on both 32 and 64 bit systems. Sorry for not being more clear from the start. With 32 bit address spaces, objects larger than 31 bits are needed. I don't fully understand what you mean. On 32 bit systems I can accept arrays and lists and collections (or a call to malloc) with only 2_147_483_648 items/bytes. On a 32 bit Windows with 3 GB RAM (and Windows itself set to use 3 GB) DMD allows me to allocate only a part of those. In practice you can't allocate more than 2 GB in a single block. On a 32 bit system I can desire arrays with something like 3_000_000_000 items only when the array items are single bytes (ubyte, char, byte, bool), and such situations are not so common (and probably 32bit Windows will not allow me to do it). (I am still writing a comment to another answer of yours, I am not so fast, please be patient :-) ) Bye, bearophile That's because Win32 reserves the upper half of the address space for kernel address space. If you use the 3GB switch, then you get 3GB for your program and 1GB for the kernel, but only if the program is large address space aware. If you use Win64, you get 4 GB of address space for your 32-bit programs, but again only if they're large address space aware. Programs need to be explicitly be made large address space aware because some legacy programs assumed it would never be possible to have more than 2GB of address space, and thus used the most significant bit of pointers creatively or used ints for things that size_t should be used for would break in unpredictable ways if the program could suddenly see more than 2GB of address space. You can make a program large address space aware by using editbin (http://msdn.microsoft.com/en-us/library/d25ddyfc%28v=VS.80%29.aspx).
Re: enforce()?
Andrei Alexandrescu wrote: Walter Bright wrote: Michel Fortin wrote: On 2010-06-16 05:15:24 -0400, Walter Bright newshou...@digitalmars.com said: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. True. Yet, enforce is inside std.contracts. If that isn't conflating the two concepts I wonder what it is. :-) I agree completely. enforce must move. Where to? Andrei I would point out that pretty much nothing in std.contracts actually relates to contracts. Rather, it relates to error handling. So, it would probably be a good idea to simply rename the module - perhaps to std.error. - Jonathan M Davis
Re: enforce()?
Andrei Alexandrescu wrote: Walter Bright wrote: Michel Fortin wrote: On 2010-06-16 05:15:24 -0400, Walter Bright newshou...@digitalmars.com said: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. True. Yet, enforce is inside std.contracts. If that isn't conflating the two concepts I wonder what it is. :-) I agree completely. enforce must move. Where to? Dunno.
Re: enforce()?
Walter Bright wrote: Andrei Alexandrescu wrote: Walter Bright wrote: Michel Fortin wrote: On 2010-06-16 05:15:24 -0400, Walter Bright newshou...@digitalmars.com said: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. True. Yet, enforce is inside std.contracts. If that isn't conflating the two concepts I wonder what it is. :-) I agree completely. enforce must move. Where to? Dunno. import std.dunno; Works for me.
Re: Signed word lengths and indexes
Walter Bright wrote: Jérôme M. Berger wrote: Actually, that problem already occurs in C. I've had problems when porting code from x86 to x86_64 because some unsigned operations don't behave the same way on both... How so? I thought most 64 bit C compilers were specifically designed to avoid this problem. I can't isolate it to a minimal test case, but at my job, we make an image processing library. Since negative image dimensions don't make sense, we decided to define width and height as unsigned int. Now, we have code that works fine on 32-bit platforms (x86 and arm) but segfaults on x86_64. Simply adding an (int) cast in front of the image dimensions in a couple of places fixes the issue (tested with various versions of gcc on linux and windows). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: enforce()?
I think about it roughly this way (in reverse priority): Contracts/assertions concern problems in the program(ming) domain. Exceptions concern problems in the system domain. Problems in the actual problem domain should be modeled in the design and have their own abstractions. These interact a little bit, so I have an excuse to bend my rules whenever I want :) For instance, if the system is part of your problem domain (e.g. embedded code), then exceptions are probably not the right approach. That's why I indicate a false idea of priority. Jason
Re: enforce()?
On 2010-06-16 14:10:17 -0400, Jonathan M Davis jmdavisp...@gmail.com said: I would point out that pretty much nothing in std.contracts actually relates to contracts. Rather, it relates to error handling. So, it would probably be a good idea to simply rename the module - perhaps to std.error. I concur: the module is misnamed. The only things not related to error handling are assumeUnique and assumeSorted, and I fail to see the link with design by contract for either one. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: enforce()?
On 2010-06-16 14:44:29 -0400, Michel Fortin michel.for...@michelf.com said: On 2010-06-16 14:10:17 -0400, Jonathan M Davis jmdavisp...@gmail.com said: I would point out that pretty much nothing in std.contracts actually relates to contracts. Rather, it relates to error handling. So, it would probably be a good idea to simply rename the module - perhaps to std.error. I concur: the module is misnamed. The only things not related to error handling are assumeUnique and assumeSorted, and I fail to see the link with design by contract for either one. Oh, forgot about pointsTo too. What's the link with contracts, or error handling? -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: enforce()?
Michel Fortin wrote: On 2010-06-16 14:44:29 -0400, Michel Fortin michel.for...@michelf.com said: On 2010-06-16 14:10:17 -0400, Jonathan M Davis jmdavisp...@gmail.com said: I would point out that pretty much nothing in std.contracts actually relates to contracts. Rather, it relates to error handling. So, it would probably be a good idea to simply rename the module - perhaps to std.error. I concur: the module is misnamed. The only things not related to error handling are assumeUnique and assumeSorted, and I fail to see the link with design by contract for either one. Oh, forgot about pointsTo too. What's the link with contracts, or error handling? Certain functions (notably swap) must make sure that there's no mutual aliasing between two objects. Andrei
Re: Signed word lengths and indexes
On 06/16/2010 12:33 PM, Walter Bright wrote: Jeff Nowakowski wrote: On 06/15/2010 05:43 PM, Walter Bright wrote: One example of this is transitive immutability. Nobody asked for it. I find this hard to believe. I seem to recall that you were personally against const for a very long time. Did none of the people advocating for const suggest a deep const? Should I dig through the archives? Andrei explained transitivity to me and convinced me of its utility. Ok, but lots of people have been talking about const correctness for years (including yourself), stemming from the known C++ problems, and I don't see how transitive immutability (a deep const) is a new idea that nobody asked for. The only thing new here is that you guys came up with an implementation for D, and lots of people were glad to have it, even if many were also against it.
Re: enforce()?
Ali Çehreli acehr...@yahoo.com wrote:
To further confuse the issue, assert throws too:
import std.stdio;
import std.algorithm;
void main()
{
try {
assert(false);
} catch (Throwable) {
writeln(an assertion failed);
}
}
The difference is just the exception that is thrown. Throwable seems to
be most general.
Seeing as how Error is supposed to be unrecoverable, and Exception might
be recoverable, and both inherit from Throwable, one should only very very
rarely catch Exception, and by extension, Throwable. One might in fact
argue that Error and Exception should have no common ancestor but Object.
From what I've read so far, I take enforce as a replacement to what it
exactly is:
if (condition) {
throw /* ... */;
}
That is indeed basically what it is.
--
Simen
Re: Signed word lengths and indexes
Jérôme M. Berger wrote:
Walter Bright wrote:
Jérôme M. Berger wrote:
Actually, that problem already occurs in C. I've had problems when
porting code from x86 to x86_64 because some unsigned operations
don't behave the same way on both...
How so? I thought most 64 bit C compilers were specifically designed to
avoid this problem.
I can't isolate it to a minimal test case, but at my job, we make
an image processing library. Since negative image dimensions don't
make sense, we decided to define width and height as unsigned int.
Now, we have code that works fine on 32-bit platforms (x86 and arm)
but segfaults on x86_64. Simply adding an (int) cast in front of the
image dimensions in a couple of places fixes the issue (tested with
various versions of gcc on linux and windows).
Gotcha! See the attached test case. I will post the explanation for
the issue as a reply to give everyone a chance to try and spot the
error...
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
#include assert.h
#include stdio.h
int main (int argc, char** argv) {
char*data = argv[0]; /* Just to get a valid pointer */
unsigned int offset = 3;
printf (Original: %p\n, data);
data += offset;
printf (+3 : %p\n, data);
data += -offset;
printf (-3 : %p\n, data);
assert (data == argv[0]);/* Works on 32-bit systems, fails on 64-bit */
return 0;
}
signature.asc
Description: OpenPGP digital signature
Re: Signed word lengths and indexes
Jérôme M. Berger wrote:
Jérôme M. Berger wrote:
Walter Bright wrote:
Jérôme M. Berger wrote:
Actually, that problem already occurs in C. I've had problems when
porting code from x86 to x86_64 because some unsigned operations
don't behave the same way on both...
How so? I thought most 64 bit C compilers were specifically designed to
avoid this problem.
I can't isolate it to a minimal test case, but at my job, we make
an image processing library. Since negative image dimensions don't
make sense, we decided to define width and height as unsigned int.
Now, we have code that works fine on 32-bit platforms (x86 and arm)
but segfaults on x86_64. Simply adding an (int) cast in front of the
image dimensions in a couple of places fixes the issue (tested with
various versions of gcc on linux and windows).
Gotcha! See the attached test case. I will post the explanation for
the issue as a reply to give everyone a chance to try and spot the
error...
Jerome
Whoa! That's indeed unfortunate. Allow me some more whoring for TDPL:
==
\indexes{surprising behavior!of unary \lstinline{-}}%
One surprising behavior of unary minus is that, when applied to an
unsigned value, it still yields an unsigned value (according to the
rules in~\S~\vref{sec:typing-of-ops}). For example,\sbs @-55u@ is\sbs
@4_294_967_241@, which is\sbs \ccbox{uint.max - 55 + 1}.
\indexes{unsigned type, natural number, two's complement, overflow}%
The fact that unsigned types are not really natural numbers is a fact
of life. In\sbs\dee and many other languages, two's complement
arithmetic with its simple overflow rules is an inescapable reality
that cannot be abstracted away. One way to think \mbox{of} @-val@ for
any integral val...@val@ is to consider it a short form \mbox{of}$\,$
\cc{\~val + 1}; in other words, flip every bit in @val@ and then add
@1@ to the result. This manipulation does not raise particular
questions about the signedness o...@val@.
==
(This heavily adorned text also shows what sausage making looks like...)
Andrei
Re: Signed word lengths and indexes
Jérôme M. Berger wrote: Jérôme M. Berger wrote: Walter Bright wrote: Jérôme M. Berger wrote: Actually, that problem already occurs in C. I've had problems when porting code from x86 to x86_64 because some unsigned operations don't behave the same way on both... How so? I thought most 64 bit C compilers were specifically designed to avoid this problem. I can't isolate it to a minimal test case, but at my job, we make an image processing library. Since negative image dimensions don't make sense, we decided to define width and height as unsigned int. Now, we have code that works fine on 32-bit platforms (x86 and arm) but segfaults on x86_64. Simply adding an (int) cast in front of the image dimensions in a couple of places fixes the issue (tested with various versions of gcc on linux and windows). Gotcha! See the attached test case. I will post the explanation for the issue as a reply to give everyone a chance to try and spot the error... The problem comes from the fact that an unsigned int is 32 bits, even on 64 bits architecture, so what happens is: - Some operation between signed and unsigned ints gives a negative result. Because of the automatic type conversion rules, this is converted to an unsigned 32-bit int; - The result is added to a pointer. On 32-bit systems, the operation simply wraps around and works. On 64-bit systems, the result is extended to 64 bits by adding zeroes (since it is unsigned) and the resulting pointer is wrong. That's reasonably easy to spot in this simple example. It's a lot more difficult on real world code. We had the problem because we were moving a pointer through the image data. As soon as the movement depended on the image dimensions (say: move left by 1/4 the width), then the program crashed. Every other kind of move worked just fine... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: enforce()?
Don wrote: import std.dunno; Works for me. cut print.
Re: enforce()?
Don wrote: import std.dunno; Works for me. Or std.poisson... :p Ali
Re: Signed word lengths and indexes
Jérôme M. Berger wrote: Jérôme M. Berger wrote: Walter Bright wrote: Jérôme M. Berger wrote: Actually, that problem already occurs in C. I've had problems when porting code from x86 to x86_64 because some unsigned operations don't behave the same way on both... How so? I thought most 64 bit C compilers were specifically designed to avoid this problem. I can't isolate it to a minimal test case, but at my job, we make an image processing library. Since negative image dimensions don't make sense, we decided to define width and height as unsigned int. Now, we have code that works fine on 32-bit platforms (x86 and arm) but segfaults on x86_64. Simply adding an (int) cast in front of the image dimensions in a couple of places fixes the issue (tested with various versions of gcc on linux and windows). Gotcha! See the attached test case. I will post the explanation for the issue as a reply to give everyone a chance to try and spot the error... Easy. offset should be a size_t, not an unsigned.
Re: Signed word lengths and indexes
Jeff Nowakowski wrote: On 06/16/2010 12:33 PM, Walter Bright wrote: Jeff Nowakowski wrote: On 06/15/2010 05:43 PM, Walter Bright wrote: One example of this is transitive immutability. Nobody asked for it. I find this hard to believe. I seem to recall that you were personally against const for a very long time. Did none of the people advocating for const suggest a deep const? Should I dig through the archives? Andrei explained transitivity to me and convinced me of its utility. Ok, but lots of people have been talking about const correctness for years (including yourself), stemming from the known C++ problems, and I don't see how transitive immutability (a deep const) is a new idea that nobody asked for. The only thing new here is that you guys came up with an implementation for D, and lots of people were glad to have it, even if many were also against it. I've talked with C++ experts for years about const. Not one of them ever mentioned transitivity, let alone asked for it or thought it was a desirable property. After we designed transitive const for D, I presented it to several C++ experts. My first job was to explain what transitive meant - none of them were familiar with the idea. Next, it took a lot of convincing of them that this was a good idea. They all insisted that a const pointer to mutable data was terribly important. While it is true that C++ people have talked about const-correctness since const was introduced to C++, it does not at all imply any concept or understanding of transitivity. Transitivity is an orthogonal idea. The people who do understand transitive const and need no convincing are the functional programming crowd. What's interesting are the languages which claim to offer FP features, as that's the latest bandwagon, but totally miss transitive const.
Re: Signed word lengths and indexes
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
Jérôme M. Berger wrote:
Walter Bright wrote:
Jérôme M. Berger wrote:
Actually, that problem already occurs in C. I've had problems when
porting code from x86 to x86_64 because some unsigned operations
don't behave the same way on both...
How so? I thought most 64 bit C compilers were specifically designed to
avoid this problem.
I can't isolate it to a minimal test case, but at my job, we make
an image processing library. Since negative image dimensions don't
make sense, we decided to define width and height as unsigned int.
Now, we have code that works fine on 32-bit platforms (x86 and arm)
but segfaults on x86_64. Simply adding an (int) cast in front of the
image dimensions in a couple of places fixes the issue (tested with
various versions of gcc on linux and windows).
Gotcha! See the attached test case. I will post the explanation for
the issue as a reply to give everyone a chance to try and spot the
error...
Jerome
Whoa! That's indeed unfortunate. Allow me some more whoring for TDPL:
==
\indexes{surprising behavior!of unary \lstinline{-}}%
One surprising behavior of unary minus is that, when applied to an
unsigned value, it still yields an unsigned value (according to the
rules in~\S~\vref{sec:typing-of-ops}). For example,\sbs @-55u@ is\sbs
@4_294_967_241@, which is\sbs \ccbox{uint.max - 55 + 1}.
\indexes{unsigned type, natural number, two's complement, overflow}%
The fact that unsigned types are not really natural numbers is a fact
of life. In\sbs\dee and many other languages, two's complement
arithmetic with its simple overflow rules is an inescapable reality
that cannot be abstracted away. One way to think \mbox{of} @-val@ for
any integral val...@val@ is to consider it a short form \mbox{of}$\,$
\cc{\~val + 1}; in other words, flip every bit in @val@ and then add
@1@ to the result. This manipulation does not raise particular
questions about the signedness o...@val@.
==
(This heavily adorned text also shows what sausage making looks like...)
In the original code, the problem didn't come from an unary minus.
The rhs expression was quite a bit more complicated than that (not
counting the fact that it was hidden in a preprocessor macro...).
Note moreover that the problem doesn't come from the unary minus
since the code works as expected on 32-bit platforms...
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: Signed word lengths and indexes
Walter Bright wrote: The people who do understand transitive const and need no convincing are the functional programming crowd. What's interesting are the languages which claim to offer FP features, as that's the latest bandwagon, but totally miss transitive const. I wish to add that I've not heard any proposal or discussion of adding transitive const to C++0x, Java, or C#.
Re: Signed word lengths and indexes
Walter Bright wrote: Jérôme M. Berger wrote: Jérôme M. Berger wrote: Walter Bright wrote: Jérôme M. Berger wrote: Actually, that problem already occurs in C. I've had problems when porting code from x86 to x86_64 because some unsigned operations don't behave the same way on both... How so? I thought most 64 bit C compilers were specifically designed to avoid this problem. I can't isolate it to a minimal test case, but at my job, we make an image processing library. Since negative image dimensions don't make sense, we decided to define width and height as unsigned int. Now, we have code that works fine on 32-bit platforms (x86 and arm) but segfaults on x86_64. Simply adding an (int) cast in front of the image dimensions in a couple of places fixes the issue (tested with various versions of gcc on linux and windows). Gotcha! See the attached test case. I will post the explanation for the issue as a reply to give everyone a chance to try and spot the error... Easy. offset should be a size_t, not an unsigned. And what about image width and height? Sure, in hindsight they could probably be made into size_t too. Much easier and safer to make them into signed ints instead, since we don't manipulate images bigger than 2_147_483_648 on a side anyway... Which is more or less bearophile's point: unless you're *really* sure that you know what you're doing, use signed ints even if negative numbers make no sense in a particular context. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
An Introduction
I've been lurking on the forum for awhile, but thought I would join and say hello. I've primarily been working with enterprise Java for the past 10 years, but have a personal project better suited for a systems language. After a cursory review of D, I am quite excited by what it offers and means that it does so, particularly the expressiveness and cleanliness. Well done Walter, et. al. Andrei, your book is excellent. I've found what I was hoping for in it after dabbling with the language, the source, and the online docs. It's a nice comprehensive and coherent presentation. I will give you a review on Amazon after I write a bit more code and can make some deeper demands of the book. Todd V.
Re: enforce()?
Le 16/06/10 22:36, Ali Çehreli a écrit : Don wrote: import std.dunno; Works for me. Or std.poisson... :p Better name it std.fishy, because std.poisson could be mistaken for a statistical distribution module!
Re: enforce()?
Ali Çehreli wrote:
Jonathan M Davis wrote:
Assertions assert that something is _always_ true and that if it
isn't, the
program is wrong, while exceptions are for exceptional circumstances
Makes sense.
You use [enforce] when you want an exception thrown rather than when
you want to
kill your program due to an error.
To further confuse the issue, assert throws too:
import std.stdio;
import std.algorithm;
void main()
{
try {
assert(false);
} catch (Throwable) {
writeln(an assertion failed);
}
}
The difference is just the exception that is thrown. Throwable seems to
be most general.
From what I've read so far, I take enforce as a replacement to what it
exactly is:
if (condition) {
throw /* ... */;
}
Since I never use assert for that purpose, I take enforce as a shortcut
for the above.
Ali
Well, in a sense, the fact that assertions throw is an implementation detail
since that's not the case in all languages. The concepts of assertions and
exceptions are distinctly different.
However, while assertions do throw in D, they throw AssertErrors which are
Errors and not exceptions, albeit both are Throwable. So, they're still
different. You _can_ catch Errors, but you probably shouldn't. I believe
that they're intended for pretty much unrecoverable errors. The fact that
they're thrown likely makes it easier to exit the program semi-gracefully -
or at least makes it easier for the generated program to properly indicate
an error rather than simply dying - but they're still distinctly separate
from exceptions and shouldn't generally be caught. I suppose that it's kind
of like the difference between checked and unchecked exceptions in Java. You
generally only worry about the checked ones.
You are right though in that the fact that Errors are Throwable does muddle
things somewhat.
- Jonathan M Davis
Re: An Introduction
Todd VanderVeen wrote: I've been lurking on the forum for awhile, but thought I would join and say hello. I've primarily been working with enterprise Java for the past 10 years, but have a personal project better suited for a systems language. After a cursory review of D, I am quite excited by what it offers and means that it does so, particularly the expressiveness and cleanliness. Well done Walter, et. al. Andrei, your book is excellent. I've found what I was hoping for in it after dabbling with the language, the source, and the online docs. It's a nice comprehensive and coherent presentation. I will give you a review on Amazon after I write a bit more code and can make some deeper demands of the book. Todd V. Dank u wel! Andrei
Re: Go Programming talk [OT] - C is simple enough!???
Walter Bright wrote: nobody wrote: Linus Torvalds shows his opinion about why he chooses C here: http://www.realworldtech.com/forums/index.cfm?action=detailid=110618threadid=110549roomid=2 He wants a language that context-free, simple, down to the metal. He dislikes C++ b/c it has many abstraction. This is another interesting point of view by Linus: http://www.realworldtech.com/forums/index.cfm?action=detailid=110699threadid=110549roomid=2 Most of his complaints seem to be about OOP. I particularly like the line: Complicated problems don't have some simple strictly hierarchical data structures. I've read comments from Stepanov which criticise OOP and many of the other features of C++, for exactly the same reasons which Linus gives. It's interesting that their conclusions are so different.
Re: enforce()?
Walter Bright wrote: Ary Borenszweig wrote: On 06/16/2010 04:15 PM, Walter Bright wrote: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. Could you please explain them? There are many people here that don't understand the difference between these two concepts (including me). So maybe we are too dumb, maybe those concepts are not generally known or maybe the explanation is not very well clear in the documentation. It has nothing to do with being dumb, as it is not obvious. Contracts are for verifying that your program is in a state that it is designed to be in. A contract failure is defined as a program bug. Errors, on the other hand, are things that can go wrong at run time, like your disk is full when trying to write a file. These are NOT program bugs. Another way to look at it is your program should continue to operate correctly if all the contracts are removed. This is not true of removing all error checking and handling. Furthermore, errors are something a program can recover from and continue operating. Contract failures are ALWAYS fatal. A common newbie (and some expert) misconception is that contract failures can or even must be recovered. This comes from a misunderstanding of the basic principles of engineering a safe and reliable system. I am not so sure about this last point, usually you want to fail but perhaps not always. This is about what to do after detection of a program bug vs how to handle an exceptional condition. Suppose for example (actually this is from real life) there is an important operation which, as a service, also sends an e-mail notification as part of that operation. It is very bad if the operation fails, but a failed notification is not that bad. What to do in case of a bug with the e-mail notification? 1. crash (gracefully), do not complete the operation. 2. log the error for the devs to look into (or crash) *after* the operation is complete, let the operation go through without the e-mail notification. Option 1 is annoying and prevents people from getting work done due to a 'minor' bug. Option 2 however probably results in this bug either not getting noticed quite early enough or ignored in the face of other issues that always seems to have higher priority. Choosing for option 2 can also lead to bugs being swallowed silently or mistaken for exceptional conditions, which is more dangerous. I don't mean to split hairs, I bet a lot of software has these kind of cases.
Re: enforce()?
Lutger lutger.blijdest...@gmail.com wrote: Suppose for example (actually this is from real life) there is an important operation which, as a service, also sends an e-mail notification as part of that operation. It is very bad if the operation fails, but a failed notification is not that bad. What to do in case of a bug with the e-mail notification? 1. crash (gracefully), do not complete the operation. 2. log the error for the devs to look into (or crash) *after* the operation is complete, let the operation go through without the e-mail notification. Option 1 is annoying and prevents people from getting work done due to a 'minor' bug. Option 2 however probably results in this bug either not getting noticed quite early enough or ignored in the face of other issues that always seems to have higher priority. Choosing for option 2 can also lead to bugs being swallowed silently or mistaken for exceptional conditions, which is more dangerous. I don't mean to split hairs, I bet a lot of software has these kind of cases. How did you end up with an email system that is so horribly broken that it spits Errors instead of Exceptions when things are not quite the way it wants them to be? If it cannot send the email, it may throw an Exception. If you try and pass it a handwritten letter, it should throw an Error. Basically, throwing an Exception means 'Your attention please, reactor 5 has a cooling problem you might want to look at', whereas an Error means 'Explosion imminent, get the fuck off outta here!'. -- Simen
Re: enforce()?
Simen kjaeraas wrote:
Lutger lutger.blijdest...@gmail.com wrote:
Suppose for example (actually this is from real life) there is an
important
operation which, as a service, also sends an e-mail notification as part
of that
operation. It is very bad if the operation fails, but a failed
notification is
not that bad. What to do in case of a bug with the e-mail notification?
1. crash (gracefully), do not complete the operation.
2. log the error for the devs to look into (or crash) *after* the
operation is
complete, let the operation go through without the e-mail notification.
Option 1 is annoying and prevents people from getting work done due to a
'minor'
bug. Option 2 however probably results in this bug either not getting
noticed
quite early enough or ignored in the face of other issues that always
seems to
have higher priority. Choosing for option 2 can also lead to bugs being
swallowed silently or mistaken for exceptional conditions, which is more
dangerous.
I don't mean to split hairs, I bet a lot of software has these kind of
cases.
How did you end up with an email system that is so horribly broken that
it spits Errors instead of Exceptions when things are not quite the way
it wants them to be?
Not Errors, it is not in D and does not distinguish between Errors and
Exceptions. It was an example, a (design) question. It's very simple:
sendEmail()
// possibly die here because something relatively unimportant thing is buggy
vs:
try
{
sendEmail()
}
catch(BadShitThatCanHappen)
{
RecoverFromBadShitThatCanHappen() // ok, this is good and according to spec
}
catch(Exception ex)
{
logError()
// now crash? assume we know this must be programmer's fault
}
If it cannot send the email, it may throw an Exception. If you try and
pass it a handwritten letter, it should throw an Error.
Basically, throwing an Exception means 'Your attention please, reactor 5
has a cooling problem you might want to look at', whereas an Error means
'Explosion imminent, get the fuck off outta here!'.
No, an Error means the program has a bug. Programs have thousands of bugs, this
is not related to how critical it is. An Exception can be way more important to
fix than a bug. WebServerDownException for example, is often not a bug in the
code that drives websites, but for sure I will contact the sysadmin before even
thinking of going back to work. The question is how to proceed after the fact.
Re: enforce()?
Simen kjaeraas wrote: ... If it cannot send the email, it may throw an Exception. If you try and pass it a handwritten letter, it should throw an Error. This is the question: should I segfault on a handwritten letter even if it is not such an important letter and could just go on operating?
Re: enforce()?
Lutger wrote: Walter Bright wrote: Furthermore, errors are something a program can recover from and continue operating. Contract failures are ALWAYS fatal. A common newbie (and some expert) misconception is that contract failures can or even must be recovered. This comes from a misunderstanding of the basic principles of engineering a safe and reliable system. I am not so sure about this last point, usually you want to fail but perhaps not always. This is about what to do after detection of a program bug vs how to handle an exceptional condition. First you need to decide if it is a program bug or not. If it is not a program bug, it shouldn't be done with contracts. If it is a program bug, then the only proper thing to do is exit the program. The program cannot decide if it is a minor bug or not, nor can it decide if it is recoverable. It is, by definition, in an unknown state, and continuing to execute may cause anything to happen. (For example, malware may have installed itself and that may get executed.) If you need notifications that the program failed, a separate monitor program should be used. This is how people who design safe systems do it. People who believe that programs can recover from bugs design systems that fail, sometimes with terrible consequences. My articles on the topic: http://www.drdobbs.com/blog/archives/2009/10/safe_systems_fr.html http://www.drdobbs.com/blog/archives/2009/11/designing_safe.html
Re: enforce()?
Lutger wrote: The assumption one makes when recovering is that it is indeed possible and safe. Even if it may be likely, it is never reliable to count on it. Exactly.
Re: enforce()?
On 2010-06-16 20:45:47 -0400, Michel Fortin michel.for...@michelf.com said: Ok, so you're using pointsTo to check this in a contract? But isn't that just a utility function which can be used for contracts as much as for everything else? Does it really belong in std.contracts because at some place you use it in a contract? I don't think so. But that's something for you to decide. And unfortunately I'm not sure where you put it. Should have concluded by: I'm not sure where you *should* put it either. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: enforce()?
On 2010-06-16 14:59:45 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org said: Michel Fortin wrote: On 2010-06-16 14:44:29 -0400, Michel Fortin michel.for...@michelf.com said: On 2010-06-16 14:10:17 -0400, Jonathan M Davis jmdavisp...@gmail.com said: I would point out that pretty much nothing in std.contracts actually relates to contracts. Rather, it relates to error handling. So, it would probably be a good idea to simply rename the module - perhaps to std.error. I concur: the module is misnamed. The only things not related to error handling are assumeUnique and assumeSorted, and I fail to see the link with design by contract for either one. Oh, forgot about pointsTo too. What's the link with contracts, or error handling? Certain functions (notably swap) must make sure that there's no mutual aliasing between two objects. Ok, so you're using pointsTo to check this in a contract? But isn't that just a utility function which can be used for contracts as much as for everything else? Does it really belong in std.contracts because at some place you use it in a contract? I don't think so. But that's something for you to decide. And unfortunately I'm not sure where you put it. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Signed word lengths and indexes
On 06/16/2010 04:48 PM, Walter Bright wrote: Walter Bright wrote: The people who do understand transitive const and need no convincing are the functional programming crowd. What's interesting are the languages which claim to offer FP features, as that's the latest bandwagon, but totally miss transitive const. I wish to add that I've not heard any proposal or discussion of adding transitive const to C++0x, Java, or C#. I know the Javari paper was mentioned here by Bruno. Also, the idea of deep immutability just isn't rocket science and has occurred to many people, and is why many people have started looking into Haskell given the new focus on concurrency. However, you're right in that as far as I know D is the only language to take the ball and run with it.
Re: enforce()?
On 06/16/2010 11:44 PM, Walter Bright wrote: Ary Borenszweig wrote: On 06/16/2010 04:15 PM, Walter Bright wrote: The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated. Could you please explain them? There are many people here that don't understand the difference between these two concepts (including me). So maybe we are too dumb, maybe those concepts are not generally known or maybe the explanation is not very well clear in the documentation. It has nothing to do with being dumb, as it is not obvious. Contracts are for verifying that your program is in a state that it is designed to be in. A contract failure is defined as a program bug. Errors, on the other hand, are things that can go wrong at run time, like your disk is full when trying to write a file. These are NOT program bugs. Another way to look at it is your program should continue to operate correctly if all the contracts are removed. This is not true of removing all error checking and handling. Furthermore, errors are something a program can recover from and continue operating. Contract failures are ALWAYS fatal. A common newbie (and some expert) misconception is that contract failures can or even must be recovered. This comes from a misunderstanding of the basic principles of engineering a safe and reliable system. Ah, ok, now I understand. Thanks.
beforeGarbageCollection
I'm thinking of a feature that would improve the memory footprint of D programs. Say druntime provided a function: void beforeGarbageCollection(void delegate() callMe); The runtime would guarantee that callMe gets called before any collection. That would allow modules to clean up caches (e.g. free lists) to improve their memory profile. Any thoughts, please share. Andrei
Re: Class/struct invariants
On Tue, 15 Jun 2010 21:29:27 -0400, bearophile bearophileh...@lycos.com
wrote:
Are D invariants supposed to be so relaxed? They don't get called with
default constructors:
struct Foo {
int x = 0;
this(int xx) { this.x = xx; }
invariant() { assert(x == 1); }
}
struct Bar {
int x = 0;
invariant() { assert(x == 1); }
}
class CFoo {
int x = 0;
this(int xx) { this.x = xx; }
invariant() { assert(x == 1); }
}
class CBar {
int x = 0;
invariant() { assert(x == 1); }
}
void main() {
Foo f1; // no asserts
Foo f2 = Foo(); // no asserts
// Foo f3 = Foo(0); // asserts, good
Bar b1; // no asserts
Bar b2 = Bar(); // no asserts
Bar b3 = Bar(0); // no asserts
//assert(b3);// can't be used
// b3.__invariant(); // asserts
//CFoo f3 = new CFoo(0); // asserts, good
CBar cb2 = new CBar(); // no asserts
//assert(cb2); // asserts, good
}
Default construction for structs is a weird animal in D. A struct can
always be default constructed and is always initialized to s.init. This
allows you to construct for instance an array of structs with simple
memory copying.
During default struct construction, no constructors are run (they aren't
allowed anyways) and no invariants are run. What would be the point of
running an invariant during default construction? The only think it could
possibly do is make code like this:
S s;
Fail without -release, and pass with -release. I don't see the value in
that.
-Steve
Re: Class/struct invariants
Steven Schveighoffer:
During default struct construction, no constructors are run (they aren't
allowed anyways) and no invariants are run. What would be the point of
running an invariant during default construction? The only think it could
possibly do is make code like this:
S s;
Fail without -release, and pass with -release. I don't see the value in
that.
Thank you for your answers, I was trying to understand.
Of all the examples I have shown this can be the worst:
struct Foo {
int x;
invariant() { assert(x 0); }
}
void main() {
Foo f = Foo(-10);
}
Here I'd like the compiler to assert (at compile time or at runtime), or to
refuse an invariant in structs like that, where I think D has no way to enforce
it (unless you call __invariant(), but this is silly).
Later I can write a bug report about this.
Bye,
bearophile
[Issue 4318] compile with flag unittest, depending on the order files, Access Violation
http://d.puremagic.com/issues/show_bug.cgi?id=4318
--- Comment #1 from pavel pa...@psi.cz 2010-06-15 23:26:48 PDT ---
(In reply to comment #0)
uses dmd 2.047
main.d
import std.stdio;
int main(string[] args)
{
int[] a = [1,2,3,4]
writeln(s);
return 0;
}
one.d
module one;
import std.string;
dmd main.d one.d -oftest -unittest //compile is successful
test.exe run and give
1 2 3 4
dmd one.d main.d -oftest -unittest //compile is successful
test.exe run and give
object.Error: Access Violation
misttype writeln(s) - writeln(a) is ok
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4327] New: std.container.Array.Range.~this() tries to call free(T[])
http://d.puremagic.com/issues/show_bug.cgi?id=4327 Summary: std.container.Array.Range.~this() tries to call free(T[]) Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: blocker Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bugzi...@kyllingen.net --- Comment #0 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-06-16 02:18:19 PDT --- Example: Array!int a; Error: std/container.d(1660): Error: function core.stdc.stdlib.free (void* ptr) is not callable using argument types (int[]) std/container.d(1660): Error: cannot implicitly convert expression ((*this._data)._payload) of type int[] to void* The fix is trivial, just add .ptr in line 1660: -free(_data._payload); +free(_data._payload.ptr); But why aren't the unittests picking this up? I've investigated a bit, and found that when Array!int is declared in the std.concurrency unittests, the int[] is implicitly cast to void* in the call to free(). However, this doesn't happen when Array!int is declared in user code. Very strange. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4327] std.container.Array.Range.~this() tries to call free(T[])
http://d.puremagic.com/issues/show_bug.cgi?id=4327 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added AssignedTo|nob...@puremagic.com|bugzi...@kyllingen.net --- Comment #1 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-06-16 02:37:33 PDT --- http://www.dsource.org/projects/phobos/changeset/1651 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4327] std.container.Array.Range.~this() tries to call free(T[])
http://d.puremagic.com/issues/show_bug.cgi?id=4327 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added Status|NEW |ASSIGNED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2810] Bogus forward reference error with auto function
http://d.puremagic.com/issues/show_bug.cgi?id=2810
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #8 from Steven Schveighoffer schvei...@yahoo.com 2010-06-16
06:32:44 PDT ---
I just hit this issue too.
I think the ultimate test for this should be:
auto foo()
{
bar();
return 1;
}
auto bar()
{
foo();
return 1;
}
Is this possible? It may be too complex, even though the above should be
possible.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4322] void initializer has no value on struct/union members initialized to void
http://d.puremagic.com/issues/show_bug.cgi?id=4322
--- Comment #4 from Graham Fawcett graham.fawc...@gmail.com 2010-06-16
06:39:19 PDT ---
Created an attachment (id=664)
proposed patch
When initializing an array, this patch tests whether the initializer
is a VoidInitializer, and if so, avoids the toExpression() call. This
permits arrays to be initialized = void.
This compiles and appears to work as expected:
void main() {
struct foo {
union {
char[100] c = void;
ubyte[100] b
}
ubyte[5] good = 44;
ubyte[5] bad = void;
}
foo f = foo();
writeln(b , f.b);
writeln(c , f.c);
writeln(good , f.good);
writeln(bad , f.bad);
}
good displays as '44 44 44 44 44', but the void attributes appear
uninitialized.
This still fails to compile (as it should):
void main() {
void[1] a;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4329] New: Do not show errors that refer to __error
http://d.puremagic.com/issues/show_bug.cgi?id=4329 Summary: Do not show errors that refer to __error Product: D Version: D1 D2 Platform: Other OS/Version: Linux Status: NEW Keywords: diagnostic Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: nfx...@gmail.com --- Comment #0 from nfx...@gmail.com 2010-06-16 08:02:25 PDT --- dmd should not output error messages like these: Error: function expected before (), not __error of type TOK149 I have never seen an error message that refers to __error, and that I wanted to see. They don't add any additional value, and are only (by definition?) caused by preceding, actual errors. They are only noise and don't add any additional value. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4330] New: std.range.transposed() should be documented
http://d.puremagic.com/issues/show_bug.cgi?id=4330 Summary: std.range.transposed() should be documented Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: dsim...@yahoo.com --- Comment #0 from David Simcha dsim...@yahoo.com 2010-06-16 08:13:40 PDT --- std.range.transposed() has been in Phobos for over a year. It works (at least for rectangular ranges of range; the handling of the non-rectangular case is arbitrary and confusing) and I find it quite useful, but it's completely undocumented. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4329] Do not show error messages that refer to __error
http://d.puremagic.com/issues/show_bug.cgi?id=4329 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2010-06-16 08:50:34 PDT --- (In reply to comment #0) dmd should not output error messages like these: Error: function expected before (), not __error of type TOK149 I have never seen an error message that refers to __error, and that I wanted to see. They don't add any additional value, and are only (by definition?) caused by preceding, actual errors. They are only noise and don't add any additional value. __error is a new improvement to the compiler to supress spurious error messages. (in previous releases, it would have been 'int'). You should never see them. Please post any test cases which produce them. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: help with bind
== Repost the article of jspencer (spenc...@sbcglobal.net)
== Posted at 2010/06/16 12:55 to digitalmars.D.learn
I�talked�to�Tom�Stachowiak,�who�couldn't�spot�anything�wrong�with�the
code.��I�believe�this�is�a�bug�in�std.bind�(or�maybe�std.traits.)��Has
anyone�else�seen�this?
With�2.047:
import�std.bind;
import�std.stdio;
void�g�(int�a,�int�b)
{
���int�c�=�a�+�b;
}
void�main()
{
���auto�g1�=�bind(g,�_0,�_0);
���writeln(typeid(typeof(g1)));
}
---
gives
C:\tools\dmd2\windows\bin\..\..\src\phobos\std\bind.d(977):�Error:
template�instance�ParameterTypeTuple!(const(EmptySlot)*)�does�not
match�template�declaration�ParameterTypeTuple(dg...)�if�(dg.length�==
1��isCallable!(dg))
[Issue 4320] typeof(polymorphic lambda with template alias) is void
http://d.puremagic.com/issues/show_bug.cgi?id=4320
Haruki Shigemori rayerd@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Comment #1 from Haruki Shigemori rayerd@gmail.com 2010-06-16 10:15:43
PDT ---
Sorry!
I want to back down on this issue.
(i){return 1;} is a function template (not delegate literal).
typeof(function template) has not a type (However I do not think this is a type
void. uhmm...).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4331] New: Not called struct invariants
http://d.puremagic.com/issues/show_bug.cgi?id=4331
Summary: Not called struct invariants
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-06-16 10:39:17 PDT ---
Struct invariants are useful to restrict the number of possible states of a
struct instance. But there are situations where they are not calledrun. This
D2 program compiles and runs with no errors with 2.047:
struct Foo {
int x;
invariant() { assert(x 0); }
}
void main() {
Foo f = Foo(-10);
}
To avoid this I can see two possible solutions:
1) When a struct is initialized through the built-in constructor using
user-specified values, as in this case, the compiler can call the invariant()
at the end of the initialization. So this code can assert at run-time (or even
at compile-time if the compiler is smart) and avoid possible bugs.
2) If the precedent option is not possible, then the compiler has no way to
enforce the invariant of this struct Foo (calling f.__invariant() from user
code is not a solution). There is no point to keep an invariant if D never
enforces it, it's bad to give a false sense of security to the programmer. So
the compiler can refuse an invariant at compile-time where it can't be
enforced, with an error message.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4331] Struct invariants not called
http://d.puremagic.com/issues/show_bug.cgi?id=4331 Stewart Gordon s...@iname.com changed: What|Removed |Added Keywords|accepts-invalid |wrong-code CC||s...@iname.com Blocks||2573 Summary|Not called struct |Struct invariants not |invariants |called --- Comment #1 from Stewart Gordon s...@iname.com 2010-06-16 11:27:33 PDT --- The StructBodyDeclaration syntax (both D1 and D2) includes Invariant. Therefore the code is legal, and the bug is that the compiler ignores it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
