Re: Visual Studio Community and .NET Open Source
.Net does have a pretty damn good GC. It is both a moving garbage collector (improves locality, reduces heap fragmentation and allows for memory allocation to be a single pointer operation) and a generational garbage collector (reduces garbage collection cost by leveraging heuristic that most collected objects are usually very young). I believe their server GC is even concurrent to avoid long stop the world pauses. The problem is I'm not sure how much of those principles can be applied to D. I can see moving objects being problematic given that D supports unions. Another thing to consider is that .Net's GC is the results of many man years of full time work on a single platform, while D is mostly done by volunteers in their spare time for many platforms. It would probably require a lot of work to port, unless you're volunteering yourself for that work;) On a related note, I've wondered for a long time why D's GC isn't generational and why there's all this discussion on making it concurrent and none on making it generational. It seems to me that making it generational is simpler than making it concurrent and provides a net win in overall performance while concurrent only provides a win for real time systems that can't afford long GC cycles.
Re: Visual Studio Community and .NET Open Source
On Friday, 21 November 2014 at 08:02:07 UTC, philippecp wrote: The problem is I'm not sure how much of those principles can be applied to D. I can see moving objects being problematic given that D supports unions. Unions make up only a small percentage of all objects; a mostly precise GC can be enough. It cannot be fully precise anyway, because of C code (addRoot), and the stack, which is hard to make precise. On a related note, I've wondered for a long time why D's GC isn't generational and why there's all this discussion on making it concurrent and none on making it generational. It seems to me that making it generational is simpler than making it concurrent and provides a net win in overall performance while concurrent only provides a win for real time systems that can't afford long GC cycles. There is some work. For example, Rainer Schuetze presented a precise GC at Dconf, which is a requirement for that. See also this post by deadalnix, who proposes separating the global heap(s) from the thread-local ones: http://forum.dlang.org/thread/kpgilxyyrrluxpepe...@forum.dlang.org
Re: Visual Studio Community and .NET Open Source
On Friday, 21 November 2014 at 08:02:07 UTC, philippecp wrote: .Net does have a pretty damn good GC. It is both a moving garbage collector (improves locality, reduces heap fragmentation and allows for memory allocation to be a single pointer operation) and a generational garbage collector (reduces garbage collection cost by leveraging heuristic that most collected objects are usually very young). I believe their server GC is even concurrent to avoid long stop the world pauses. The problem is I'm not sure how much of those principles can be applied to D. I can see moving objects being problematic given that D supports unions. Another thing to consider is that .Net's GC is the results of many man years of full time work on a single platform, while D is mostly done by volunteers in their spare time for many platforms. It would probably require a lot of work to port, unless you're volunteering yourself for that work;) ... The official .NET runs on x86, x64, ARM (including cortex variants), MIPS. It scales from embedded hardware running with 512KB of flash and 128KB of RAM (http://www.netmf.com/get-started/), all the way up to Azure deployments. http://www.microsoft.com/net/multiple-platform-support -- Paulo
Re: gchunt v0.1.0 is out!
21-Nov-2014 05:18, Piotr Szturmaj пишет: W dniu 2014-11-11 o 23:38, Dmitry Olshansky pisze: gchunt is a tool is to help D developers identify and keep in check the usage of GC in their projects. So far it just postprocesses D compiler's -vgc output into a nice Wiki table. Results looks like this (Phobos): http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage#Labeled_data Nice :) I think I found a -vgc bug: https://github.com/D-Programming-Language/phobos/blob/271c771a57764dcc511ca12ae91d490872d9b500/std/array.d#L419 - this line doesn't allocate, unlike the one below. Can you reduce and file it? Thanks! -- Dmitry Olshansky
Re: On the meaning of string.length
20-Nov-2014 16:50, Adam D. Ruppe пишет: On Wednesday, 19 November 2014 at 21:00:50 UTC, Ary Borenszweig wrote: In Ruby `length` returns the number of unicode characters What is a unicode character? Even in utf-32, one printed character might be made up of two unicode code points. Or sometimes, two printed characters might come from a single code point. Perl goes for grapheme cluster as character. I'd say that's probably the closest thing to it. Sadly being systems language we can't go so far as to create a per process table of cached graphemes, and then use index in that table as character ;) -- Dmitry Olshansky
Re: Dgame 0.3.2
On Saturday, 22 February 2014 at 10:00:46 UTC, Namespace wrote: On a side note, the author in the code is Stewart but it is still me :). It is my middle name, which the auto-header vim script grabs from the login. Yes that I have also seen. Otherwise, I would have used your github name. :) Cheers, ed (stewart) I just saw it up on the website, very cool, thanks :) I have to thank. Another game looks great on the page and it's nice to see that Dgame is used. The Dgame website has been down for a while now ... is it coming back? /uri
Re: 'int' is enough for 'length' to migrate code from x86 to x64
FrankLike wrote in message news:musbvhmuuhhvetovx...@forum.dlang.org... If you compile the dfl Library to 64 bit,you will find error: core.sys.windows.windows.WaitForMultipleObjects(uint nCount,void** lpHandles,) is not callable using argument types(ulong,void**,...) the 'WaitForMultipleObjects' Function is in dmd2/src/druntime/src/core/sys/windows/windows.d the argument of first is dfl's value ,it comes from a 'length' ,it's type is size_t,now it is 'ulong' on 64 bit. So druntime must keep the same as phobos for size_t. Or keep the same to int with WindowsAPI to modify the size_t to int ? I suggest using WaitForMultipleObjects(to!uint(xxx.length), ...) as it will both convert and check for overflow IIRC. I'm just happy D gives you an error here instead of silently truncating the value.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
H. S. Teoh via Digitalmars-d wrote in message news:mailman.2156.1416499421.9932.digitalmar...@puremagic.com... By that logic, using an int to represent an integer is also using the incorrect type, because a signed type is *also* subject to module 2^^n arithmetic -- just a different form of it where the most negative value wraps around to the most positive values. Fixed-width integers in computing are NOT the same thing as unrestricted integers in mathematics. No matter how you try to rationalize it, as long as you use hardware fix-width integers, you're dealing with modulo arithmetic in one form or another. Pretending you're not, is the real source of said subtle bugs. While what you've said is true, the typical range of values stored in an integral type is much more likely to cause unsigned wrapping than signed overflow. So to get the desired 'integer-like' behaviour from D's integral types, you need to care about magnitude for signed types, or both magnitude and ordering for unsigned types. eg 'a b' becoming 'a - b 0' is valid for integers, and small ints, but not valid for small uints unless a b. You will always have to care about the imperfect representation of mathematical integers, but with unsigned types you have an extra rule that is much more likely to affect typical code.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Walter Bright: All you're doing is trading 0 crossing for 0x7FFF crossing issues, and pretending the problems have gone away. I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone. BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. Is this true? Do you have some examples of buggy code? Bye, bearophile
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Walter Bright wrote in message news:m4mggi$e1h$1...@digitalmars.com... BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. 0 crossing bugs tend to show up much sooner, and often immediately. I don't think I have ever written a D program where an array had more than 2^^31 elements. And I'm sure I've never had it where 2^31-1 wasn't enough and yet 2^^32-1 was. Zero, on the other hand, is usually quite near the typical array lengths and differences in lengths.
Re: Why is `scope` planned for deprecation?
Walter Bright: Except that isn't really quicksort. Monads are the workaround functional languages use to deal with things that need mutation. Take also a look at Clean language. It doesn't use monads and it's a very efficient functional language. Bye, bearophile
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Andrei Alexandrescu wrote in message
news:m4l711$1t39$1...@digitalmars.com...
The most difficult pattern that comes to mind is the long arrow operator
seen in backward iteration:
void fun(int[] a)
{
for (auto i = a.length; i -- 0; )
{
// use i
}
}
Over the years most of my unsigned-related bugs have been from screwing up
various loop conditions. Thankfully D solves this perfectly with:
void fun(int[] a)
{
foreach_reverse(i, 0...a.length)
{
}
}
So I never have to write those again.
Re: Why is `scope` planned for deprecation?
On Friday, 21 November 2014 at 02:56:09 UTC, Andrei Alexandrescu wrote: On 11/20/14 5:09 PM, Walter Bright wrote: On 11/20/2014 3:10 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Thursday, 20 November 2014 at 22:47:27 UTC, Walter Bright wrote: On 11/20/2014 1:55 PM, deadalnix wrote: All of this is beautiful until you try to implement a quicksort in, haskell. […] Monads! I think Deadalnix meant that you cannot do in-place quicksort easily in Haskell. That's correct. Non-mutating quicksort is easy, no need for monads: quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter ( p) xs greater = filter (= p) xs https://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell Except that isn't really quicksort. Monads are the workaround functional languages use to deal with things that need mutation. As I like to say, this troika has inflicted a lot of damage on both FP and those beginning to learn it: * Linear-space factorial * Doubly exponential Fibonacci * (Non)Quicksort These losers appear with depressing frequency in FP introductory texts. Andrei Just like the OOP introductory books that still insist in talking about Cars and Vehicles, Managers and Employees, Animals and Bees, always using inheritance as code reuse. Barely talking about is-a and has-a, and all the issues about fragile base classes. -- Paulo
Re: 'int' is enough for 'length' to migrate code from x86 to x64
bearophile wrote in message news:lkcltlokangpzzdzz...@forum.dlang.org...
From my experience in coding in D they are far more unlikely than
sign-related bugs of array lengths.
Here's a simple program to calculate the relative size of two files, that
will not work correctly with unsigned lengths.
module sizediff
import std.file;
import std.stdio;
void main(string[] args)
{
assert(args.length == 3, Usage: sizediff file1 file2);
auto l1 = args[1].read().length;
auto l2 = args[2].read().length;
writeln(Difference: , l1 - l2);
}
The two ways this can fail (that I want to highlight) are:
1. If either file is too large to fit in a size_t the result will (probably)
be wrong
2. If file2 is bigger than file1 the result will be wrong
If length was signed, problem 2 would not exist, and problem 1 would be more
likely to occur. I think it's clear that signed lengths would work for more
possible realistic inputs.
While this is just an example, a similar pattern occurs in real code
whenever array/range lengths are subtracted.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/2014 12:10 AM, Daniel Murphy wrote: Walter Bright wrote in message news:m4mggi$e1h$1...@digitalmars.com... BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. 0 crossing bugs tend to show up much sooner, and often immediately. I don't think I have ever written a D program where an array had more than 2^^31 elements. And I'm sure I've never had it where 2^31-1 wasn't enough and yet 2^^32-1 was. There turned out to be such a bug in one of the examples in Programming Pearls that remained undetected for many years: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html Zero, on the other hand, is usually quite near the typical array lengths and differences in lengths. That's true, that's why they are detected sooner, when it is less costly to fix them.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/2014 12:31 AM, Daniel Murphy wrote:
Here's a simple program to calculate the relative size of two files, that will
not work correctly with unsigned lengths.
module sizediff
import std.file;
import std.stdio;
void main(string[] args)
{
assert(args.length == 3, Usage: sizediff file1 file2);
auto l1 = args[1].read().length;
auto l2 = args[2].read().length;
writeln(Difference: , l1 - l2);
}
The two ways this can fail (that I want to highlight) are:
1. If either file is too large to fit in a size_t the result will (probably) be
wrong
Presumably read() will throw if the size is larger than it can handle. If it
doesn't, this code is not buggy, but read() is.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/2014 12:10 AM, bearophile wrote: Walter Bright: All you're doing is trading 0 crossing for 0x7FFF crossing issues, and pretending the problems have gone away. I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone. I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFF crossing bugs is making the bug count less. BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. Is this true? Do you have some examples of buggy code? http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Walter Bright wrote in message news:m4mu0q$sc5$1...@digitalmars.com... Zero, on the other hand, is usually quite near the typical array lengths and differences in lengths. That's true, that's why they are detected sooner, when it is less costly to fix them. It would be even less costly if they weren't possible.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Daniel Murphy:
void fun(int[] a)
{
foreach_reverse(i, 0...a.length)
{
}
}
Better (it's a workaround for a D design flaw that we're
unwilling to fix):
foreach_reverse(immutable i, 0...a.length)
Bye,
bearophile
Re: Ranges and Exception handling PR 2724
On Saturday, 15 November 2014 at 01:43:07 UTC, Robert burner
Schadek wrote:
This PR
https://github.com/D-Programming-Language/phobos/pull/2724 adds
an generic way of handling Exception in Range processing.
quickfur and Dicebot ask me to start a thread here so the
concept could be discussed.
I actually ran into this problem today when using the dirEntries
function in std.file. I was attempting to iterate all the files
on my C drive and I got an Access Denied error which caused the
DirIterator to throw an exception. There's nothing I could do to
catch the exception and continue. I'm very glad people are aware
of this problem and I'm glad you are trying to do something about
it.
Correct me if I'm wrong, but it appears that the handleXXX
methods allow the user to provide callback functions to finish
the input range when an exception occurs. Finish meaning it
could restore the input range state or provide a whole new input
range, whatever the user wants. Is this correct? If so, I'm not
sure how this could be used to solve the dirEntries case I ran
into. The logic to restore the DirIterator state after an
exception could be quite complicated and error prone.
Maybe this is a naive solution but I thought I would share my
idea to solve the dirEntries case in hopes it will help you solve
the general case. The solution I thought of was to pass a
callback function to dirEntries that would tell it how to handle
errors. An example of the callback could look like this:
// return true to throw an exception, false to skip the file and
continue
alias FileErrorHandler = bool delegate(FileError error,
const(char)[] filename) nothrow;
FileError could be an enum like:
enum FileError { accessDenied, ... }
So the dirEntries function could add an optional parameter
auto dirEntries(string path, SpanMode mode, bool followSymlink =
true, FileErrorHandler errorHandler = null);
It looks similar to your solution with a key difference. The
InputRange is able to figure out how the error is suppose to be
handled before it throws an exception and messes up any state it
currently has (state including function stacks and the
instruction pointer, etc).
I'm not sure how the API would look for the general case, but
somehow the user will need to provide the input range with a
callback. Anyway, I don't know if this is helpful or not but
good luck and I'll be waiting to see how this turns out.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Walter Bright wrote in message news:m4mua1$shh$1...@digitalmars.com... Presumably read() will throw if the size is larger than it can handle. If it doesn't, this code is not buggy, but read() is. You're right, but that's really not the point.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 08:54:40 UTC, Daniel Murphy wrote: Walter Bright wrote in message news:m4mu0q$sc5$1...@digitalmars.com... Zero, on the other hand, is usually quite near the typical array lengths and differences in lengths. That's true, that's why they are detected sooner, when it is less costly to fix them. It would be even less costly if they weren't possible. C# has the checked and unchecked operators (http://msdn.microsoft.com/en-us/library/khy08726.aspx), which allow the programmer to specify if overflows should wrap of fail within an arithmetic expression. That could be a useful addition to D. However, a language that doesn't have unsigned integers and modular arithmetic is IMHO not a system language, because that is how most hardware works internally.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Here's a simple program to calculate the relative size of two
files, that will not work correctly with unsigned lengths.
module sizediff;
import std.file;
import std.stdio;
void main(string[] args)
{
assert(args.length == 3, Usage: sizediff file1 file2);
auto l1 = args[1].read().length;
auto l2 = args[2].read().length;
writeln(Difference: , l1 - l2);
}
This will be ok:
writeln(Difference: , (l1 l2)? (l1 - l2):(l2 - l1));
If 'length''s type is not 'size_t',but is 'int' or 'long', it
will be ok like this:
import std.math;
writeln(Difference: , abs(l1 l2));
Mathematical difference between unsigned value,size comparison
should be done before in the right side of the equal sign
character.
If this work is done in druntime,D will be a real system language.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote: BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. 0 crossing bugs tend to show up much sooner, and often immediately. Wrong. Unsigned integers can hold bigger values, so it takes more to makes them overflow, hence the bug is harder to detect. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html Specifically, it fails if the sum of low and high is greater than the maximum positive int value So it fails sooner for signed integers than for unsigned integers.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Thursday, 20 November 2014 at 21:27:11 UTC, Walter Bright wrote: If that is changed to a signed type, then you'll have a same-only-different set of subtle bugs If people use signed length with unsigned integers, the length with implicitly convert to unsigned and behave like now, no difference. plus you'll break the intuition about these things from everyone who has used C/C++ a lot. C/C++ programmers disagree: http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/ Why do you think they can't handle signed integers?
GSOC Summer 2015 - Second call for Proposals
On Wednesday, November 5, 2014, Craig Dillabaugh via Digitalmars-d digitalmars-d@puremagic.com javascript:_e(%7B%7D,'cvml','digitalmars-d@puremagic.com'); wrote: This is my second Call for Proposals for the 2015 Google Summer of Code. Anyone interested in mentoring, or who has good idea's for a project for 2015 please post here. Um sorry if I'm being noobish here but wouldn't improving or finalising the C++ interfacing support be a high priority? Recently there was a mention that lots of work has gone into the latest DMD versions but due to lack of documentation it is not clear how much exactly. Or if really C++ support has now matured then for me personally it would be a great boon if someone could step up to develop the budding project Smidgen (https://github.com/alynch4047/smidgen) to become more mature and/or use the official methods of interfacing newly introduced. On top of that, I suppose, is the Smidgen Qt binding... -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Mathematical difference between unsigned value,size comparison should be done before in the right side of the equal sign character. such as: l3 = (l1 l2)? (l1 - l2):(l2 - l1); If this work is done in druntime,small bug will be rarely.D will be a real system language. Frank
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Thursday, 20 November 2014 at 16:03:41 UTC, H. S. Teoh via Digitalmars-d wrote: By that logic, using an int to represent an integer is also using the incorrect type, because a signed type is *also* subject to module 2^^n arithmetic -- just a different form of it where the most negative value wraps around to the most positive values. The type is chosen at design time so that it's unlikely to overflow for the particular scenario. Why would you want the count of objects to reset at some point when counting objects? Wrapping of unsigned integers has valid usage for e.g. hash functions, but there they are used as bit arrays, not proper numbers, and arithmetic operators are used for bit shuffling, not for computing some numbers.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/2014 12:16 AM, Daniel Murphy wrote:
Over the years most of my unsigned-related bugs have been from screwing up
various loop conditions. Thankfully D solves this perfectly with:
void fun(int[] a)
{
foreach_reverse(i, 0...a.length)
{
}
}
So I never have to write those again.
I thought everyone hated foreach_reverse!
But, yeah, foreach and ranges+algorithms have virtually eliminated a large
category of looping bugs.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/2014 1:01 AM, Matthias Bentrup wrote: C# has the checked and unchecked operators (http://msdn.microsoft.com/en-us/library/khy08726.aspx), which allow the programmer to specify if overflows should wrap of fail within an arithmetic expression. That could be a useful addition to D. D already has them: https://github.com/D-Programming-Language/druntime/blob/master/src/core/checkedint.d
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Thursday, 20 November 2014 at 16:34:12 UTC, flamencofantasy wrote: My experience is totally the opposite of his. I have been using unsigned for lengths, widths, heights for the past 15 years in C, C++, C# and more recently in D with great success. I don't pretend to be any kind of authority though. C# doesn't encourage usage of unsigned types and warns that they are not CLS-compliant. You're going against established practices there. And signed types for numbers works wonders in C# without any notable problem and makes reasoning about code easier as you don't have to manually check for unsigned conversion bugs everywhere. The article you point to is totally flawed and kinda wasteful in terms of having to read it; the very first code snippet is obviously buggy. That's the whole point: mixing signed with unsigned is bug-prone. Worse, it's inevitable if you force unsigned types everywhere.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 09:37:50 UTC, Walter Bright wrote: I thought everyone hated foreach_reverse! I dislike foreach_reverse; 1. it's a keyword with an underscore in it; 2. complicates implementation of foreach and parsing. 3. key_word with under_score
Re: Why is `scope` planned for deprecation?
On Friday, 21 November 2014 at 02:56:09 UTC, Andrei Alexandrescu wrote: As I like to say, this troika has inflicted a lot of damage on both FP and those beginning to learn it: * Linear-space factorial * Doubly exponential Fibonacci * (Non)Quicksort These losers appear with depressing frequency in FP introductory texts. Be careful with that attitude. It is an excellent strategy to start with the simple implementation and then move on to other techniques in later chapters or more advanced texts. https://www.haskell.org/haskellwiki/The_Fibonacci_sequence https://www.haskell.org/haskellwiki/Memoization Some compilers are even capable of adding memoization/caching behind the scenes which brings naive fibonacci down to O(n) with no change in the source. Also, keep in mind that non-mutating quick sort has the same space/time complexity as the mutating variant. The non-mutating variant is no doubt faster on massively parallel hardware. You can do quicksort on GPUs. The landscape of performance and complexity is not so simple these days.
Re: Thread GC non stop-the-world
On Thursday, 25 September 2014 at 21:59:15 UTC, Sean Kelly wrote: On Thursday, 25 September 2014 at 13:55:42 UTC, Wyatt wrote: The caveat for D being this design requires read and write barriers and I'm pretty sure I recall correctly that those have been vetoed several times for complexity. Pretty much for reasons of being able to call C functions and inline asm code. Memory barriers may still be possible in these scenarios, but they would be extremely expensive. BTW, C usually accepts data only for reading, and writes mostly strings and buffers - plain data without pointers. In both cases it doesn't need to notify GC (as far as I understand write barriers).
Re: 'int' is enough for 'length' to migrate code from x86 to x64
bearophile wrote in message news:rqyuiioyrrjgggctf...@forum.dlang.org... Better (it's a workaround for a D design flaw that we're unwilling to fix): foreach_reverse(immutable i, 0...a.length) I know you feel that way, but I'd rather face the non-existent risk of accidentally mutating the induction variable than write immutable every time.
Re: On heap segregation, GC optimization and @nogc relaxing
What would be the next step to keep this effort going forward ? A POC implementation would be a lot of work but it would also help people detect corner cases or unsuspected interaction with some features of the language.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 09:37:50 UTC, Walter Bright wrote: I thought everyone hated foreach_reverse! Not me. It's ugly but it gets the job done. All I have to do is add '_reverse' and it just works! Stefan Koch wrote in message news:mmvuvkdfnvwezyvtc...@forum.dlang.org... I dislike foreach_reverse; 1. it's a keyword with an underscore in it; So what. 2. complicates implementation of foreach and parsing. The additional complexity is trivial. 3. key_word with under_score Don't care.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Frank Like wrote in message news:zhejapfebcvxnzrez...@forum.dlang.org... If this work is done in druntime,D will be a real system language. Sure, this is obviously the fundamental thing holding D back from being a _real_ system language.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Walter Bright: I thought everyone hated foreach_reverse! I love it! Bye, bearophile
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Daniel Murphy: foreach_reverse(immutable i, 0...a.length) I know you feel that way, but I'd rather face the non-existent risk of accidentally mutating the induction variable than write immutable every time. It's not non-existent :-) (And the right default for a modern language is to have immutable on default and mutable on request. If D doesn't have this quality, better to add immutable every damn time). Bye, bearophile
Re: Type Inference Bug?
On Friday, 21 November 2014 at 07:40:31 UTC, Daniel Murphy wrote:
It doesn't print anything for me. This code seems to have the
desired effect:
shared const int i;
void main()
{
static if (is(typeof(i) : shared(U), U))
{
//Prints const(int)
pragma(msg, U);
}
}
Hmm, do you know why is(typeof(i) == shared(U), U)) might fail? I
wonder why : is required over ==... Doesn't the former check if T
is a subtype of U, rather than check that they're the same type?
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 09:43:04 UTC, Kagamin wrote: On Thursday, 20 November 2014 at 16:34:12 UTC, flamencofantasy C# doesn't encourage usage of unsigned types and warns that they are not CLS-compliant. You're going against established practices there. And signed types for numbers works wonders in C# without any notable problem and makes reasoning about code easier as you don't have to manually check for unsigned conversion bugs everywhere. That's the whole point: mixing signed with unsigned is bug-prone. Worse, it's inevitable if you force unsigned types everywhere. Right. Druntime should have a checksize_t.d Frank
Re: GSOC Summer 2015 - Second call for Proposals
On 2014-11-21 05:38, Craig Dillabaugh wrote: 3. Enhance regular Expressions (2011) Student: Dmitry OlshanskyMentor: Fawzi Mohamed Claim of success based on: https://github.com/DmitryOlshansky/FReD (and recent D-Conf talks if need be). This is now std.regex. 5. Extended unicode support (2012) Student: Dmitry Olshansky Mentor: Andrei Alexandrescu Claim of success based on: Dmitry's continued involvement in phobos development, though I do not have anything on how this project actually progressed. This is now std.uni. Unsure of Status (2012) 1. Removing the global gc lock from common allocations in D. (2012) Student: Antti-Ville Tuunainen Mentor: David Simcha I haven't found much info on this one. Can either David or Antti-Ville comment on how this project went? I can't remember that last time I saw any activity here from either Antti-Ville Tuunainen or David Simcha. -- /Jacob Carlborg
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Druntime's checkint.d should be modify:
uint subu(uint x, uint y, ref bool overflow)
{
if (x y)
return y - x;
else
return x - y;
}
uint subu(ulong x, ulong y, ref bool overflow)
{
if (x y)
return y - x;
else
return x - y;
}
Frank
Re: New std.range submodule
On Wednesday, 19 November 2014 at 18:22:27 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Nov 19, 2014 at 06:06:26PM +, Nick Treleaven via Digitalmars-d wrote: On 14/11/2014 21:52, David Nadlinger wrote: On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote: std.range.checks For this, std.range.constraints would also be perfectly fine. If it's not too late, can we change the name to std.range.traits? It seems better as they can be used in 'static if', not just for template constraints. Plus it's shorter and consistent with std.traits naming. It's not too late until the next release. I prefer std.range.primitives, since it's not just traits, but also includes things like range API for built-in arrays (.front, .empty, .popFront). T I think constraints should be called traits, because that's what it actually is, and the top level module is called traits (eg: isSomeString == isForwardRange). It makes little sense to me for both to have different names. The popFront/moveFront and friends I think belong in primitives. It sounds nice. Also, every package std.range.* should publicly include std.range.constraints too. That's what container does, in that every sub package also includes the the make in std.container.utility.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
D already has them:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/checkedint.d
Druntime's checkint.d should be modify:
uint subu(uint x, uint y, ref bool overflow)
{
if (x y)
return y - x;
else
return x - y;
}
ulong subu(ulong x, ulong y, ref bool overflow)
{
if (x y)
return y - x;
else
return x - y;
}
Frank
Named parameter builder pattern for template parameters
I trust everyone here knows about the builder pattern (http://en.wikipedia.org/wiki/Builder_pattern)? It can be very useful when the number of (optional) arguments in a function start to run rampant, and you know the user only wants to start setting a subset of these. D has phenomenal meta programming possibilities, and I see more and more templates taking more and more parameters. So I thought to myself, why not have a template builder pattern? I was able to throw this together: http://dpaste.dzfl.pl/366d1fc22c9c Which allows things like: alias MyContainerType = ContainerBuilder!int //.setUseGC!??? //Don't care about GCm use default. .setScan!false .setUSomeOtherThing!true .Type; I think this is hugely neat. I'm posting here both to share, and for peer review feedback. I'm also wondering if there is prior literature about this, and if it's something we'd want more of in Phobos?
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 09:43:04 UTC, Kagamin wrote: C# doesn't encourage usage of unsigned types and warns that they are not CLS-compliant. You're going against established practices there. And signed types for numbers works wonders in C# without any notable problem and makes reasoning about code easier as you don't have to manually check for unsigned conversion bugs everywhere. I don't want to be CLS compliant! I make very heavy use of unsafe code, stackalloc and interop to worry about CLS compliance. Actually one of the major reasons I am looking at D for production code is so that I don't have to mix and match Assembly, C/C++ with C#. I want the best of all worlds in one language/runtime :). Anyways, I believe the discussion is about using unsigned for array lengths, not unsigned in general. At this point most people seem to express an opinion - including me, and I certainly hope D stays as it is when it comes to length of an array. I am not convinced in the slightest that signed is the way to go.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Thu, 20 Nov 2014 15:40:39 + Araq via Digitalmars-d digitalmars-d@puremagic.com wrote: Here are some more opinions: http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/ trying to illustrate something with obviously wrong code is very funny. the whole article then reduces to hey, i'm writing bad code, and i can teach you to do the same! won't buy it. signature.asc Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, 21 Nov 2014 08:10:55 + bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote: BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. Is this true? Do you have some examples of buggy code? any code which does something like `if (a-b 0)` is broken. it will work in most cases, but it is broken. you MUST to check values before subtracting. and if you must to do checks anyway, what is the reason of making length signed? signature.asc Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, 21 Nov 2014 09:23:01 + Kagamin via Digitalmars-d digitalmars-d@puremagic.com wrote: C/C++ programmers disagree: http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/ Why do you think they can't handle signed integers? being C programmer i disagree that author of the article is C programmer. signature.asc Description: PGP signature
Re: GSOC Summer 2015 - Second call for Proposals
On Friday, 21 November 2014 at 12:23:58 UTC, Jacob Carlborg wrote: On 2014-11-21 05:38, Craig Dillabaugh wrote: 3. Enhance regular Expressions (2011) Student: Dmitry OlshanskyMentor: Fawzi Mohamed Claim of success based on: https://github.com/DmitryOlshansky/FReD (and recent D-Conf talks if need be). This is now std.regex. 5. Extended unicode support (2012) Student: Dmitry Olshansky Mentor: Andrei Alexandrescu Claim of success based on: Dmitry's continued involvement in phobos development, though I do not have anything on how this project actually progressed. This is now std.uni. Unsure of Status (2012) 1. Removing the global gc lock from common allocations in D. (2012) Student: Antti-Ville Tuunainen Mentor: David Simcha I haven't found much info on this one. Can either David or Antti-Ville comment on how this project went? I can't remember that last time I saw any activity here from either Antti-Ville Tuunainen or David Simcha. Thanks for the info. It will be added to the proposal I am preparing for Google.
Re: GSOC Summer 2015 - Second call for Proposals
On Friday, 21 November 2014 at 09:29:08 UTC, Shriramana Sharma via Digitalmars-d wrote: clip Um sorry if I'm being noobish here but wouldn't improving or finalising the C++ interfacing support be a high priority? Recently there was a mention that lots of work has gone into the latest DMD versions but due to lack of documentation it is not clear how much exactly. Or if really C++ support has now matured then for me personally it would be a great boon if someone could step up to develop the budding project Smidgen (https://github.com/alynch4047/smidgen) to become more mature and/or use the official methods of interfacing newly introduced. On top of that, I suppose, is the Smidgen Qt binding... Sounds reasonable. I should point out I am more of an administrator than a subject expert in these matters. I would like to end up with say 6 to 8 solid proposals. We could go higher if we have 'solid' proposals and mentors in place, but the final list isn't going to be a laundry list of ideas. I am not opposed to any project that has a solid mentor and clear objectives (assuming members of the community don't raise concerns for some reason). You mentioned you were a newbie, so that gives you about 4 months to become a subject expert ... and you can be the mentor :o)
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Thu, 20 Nov 2014 13:28:37 -0800 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote: What *could* be improved, is the prevention of obvious mistakes in *mixing* signed and unsigned types. Right now, D allows code like the following with no warning: uint x; int y; auto z = x - y; BTW, this one is the same in essence as an actual bug that I fixed in druntime earlier this year, so downplaying it as a mistake people make 'cos they confound computer math with math math is fallacious. What about: uint x; auto z = x - 1; ? here z must be `long`. and for `ulong` compiler must emit error. signature.asc Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/14, 5:45 AM, Walter Bright wrote: On 11/21/2014 12:10 AM, bearophile wrote: Walter Bright: All you're doing is trading 0 crossing for 0x7FFF crossing issues, and pretending the problems have gone away. I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone. I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFF crossing bugs is making the bug count less. BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. Is this true? Do you have some examples of buggy code? http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html This bug can manifest itself for arrays whose length (in elements) is 2^30 or greater (roughly a billion elements) How often does that happen in practice?
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, 21 Nov 2014 19:31:23 +1100
Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote:
bearophile wrote in message news:lkcltlokangpzzdzz...@forum.dlang.org...
From my experience in coding in D they are far more unlikely than
sign-related bugs of array lengths.
Here's a simple program to calculate the relative size of two files, that
will not work correctly with unsigned lengths.
module sizediff
import std.file;
import std.stdio;
void main(string[] args)
{
assert(args.length == 3, Usage: sizediff file1 file2);
auto l1 = args[1].read().length;
auto l2 = args[2].read().length;
writeln(Difference: , l1 - l2);
}
The two ways this can fail (that I want to highlight) are:
1. If either file is too large to fit in a size_t the result will (probably)
be wrong
2. If file2 is bigger than file1 the result will be wrong
If length was signed, problem 2 would not exist, and problem 1 would be more
likely to occur. I think it's clear that signed lengths would work for more
possible realistic inputs.
no, the problem 2 just becomes hidden. while the given code works most
of the time, it is still broken.
signature.asc
Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
no, the problem 2 just becomes hidden. while the given code works most of the time, it is still broken. You cannot handle stack overflow in C reliably or out of memory conditions so fails in extreme edge cases is true for every piece of software. broken is not a black-white thing. Works most of the time surely is much more useful than doesn't work. Otherwise you would throw away your phone the first time you get a busy signal.
Re: Ranges and Exception handling PR 2724
Your idea designs an idiom on how to let ranges handle exceptions. My PR is about how to handle exceptions thrown by ranges. Both sort-of do the same thing but at different points. Your design idiom needs source access (needs to be programmed in). Mine can be bolted on later (an additional element in the range chain). Of course fixing an erroneous range might be tricky but than exception handling and recovering is not easy to being with. Back to your problem: If you do the foreach by hand, can you place the part that throws (popFront, front or empty) in an try catch block and still iterate to the next element afterwards?
Re: Named parameter builder pattern for template parameters
On Fri, 21 Nov 2014 13:39:42 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
D has phenomenal meta programming possibilities, and I see more
and more templates taking more and more parameters. So I thought
to myself, why not have a template builder pattern?
i did something similar in my iv.writer (ctfe format string parser).
once i got about ten argumnets to each template (and growing), i moved
everything to structure.
struct WrData {
... fields ...
auto set(string name, T) (in T value)
if (__traits(hasMember, this, name))
{
__traits(getMember, this, name) = value;
return this;
}
}
and then i can pass the struct around, changing only the fields i want,
in pseudo-functional style:
template MyTpl!(WrData data) {
...
MyTpl!(data.set!field0(value0).set!field1(value1));
}
that was a real saver. but now i have to wait for GDC update, 'cause
2.065 frontend is not able to use structs as template args.
signature.asc
Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, 21 Nov 2014 11:17:06 -0300 Ary Borenszweig via Digitalmars-d digitalmars-d@puremagic.com wrote: This bug can manifest itself for arrays whose length (in elements) is 2^30 or greater (roughly a billion elements) How often does that happen in practice? once in almost ten years is too often, as for me. i think that the answer must be never. either no bug, or the code is broken. and one of the worst code is the code that works most of the time, but still broken. signature.asc Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, 21 Nov 2014 14:37:39 + Araq via Digitalmars-d digitalmars-d@puremagic.com wrote: broken is not a black-white thing. Works most of the time surely is much more useful than doesn't work. Otherwise you would throw away your phone the first time you get a busy signal. works most of the time is the worst thing: the bug can be hidden for decades and then suddenly blows up stright into your face, making you wonder what happens with good code. i will chose the code which doesn't work over works most of the time one: the first has a clearly visible problem, and the former has a carefully hidden problem. i prefer visible problems. btw, your phone example is totally wrong, 'case busy is a well-defined state. i for sure will throw the phone away if the phone accepts only *some* incoming calls and silently ignores some others (without me explicitly telling it to do so, of course). that's like a code that works most of the time. but not in that time when they phoning you to tell that your house is on fire. signature.asc Description: PGP signature
Re: Named parameter builder pattern for template parameters
On Friday, 21 November 2014 at 13:39:43 UTC, monarch_dodra wrote: I trust everyone here knows about the builder pattern (http://en.wikipedia.org/wiki/Builder_pattern)? It can be very useful when the number of (optional) arguments in a function start to run rampant, and you know the user only wants to start setting a subset of these. D has phenomenal meta programming possibilities, and I see more and more templates taking more and more parameters. So I thought to myself, why not have a template builder pattern? I was able to throw this together: http://dpaste.dzfl.pl/366d1fc22c9c Which allows things like: alias MyContainerType = ContainerBuilder!int //.setUseGC!??? //Don't care about GCm use default. .setScan!false .setUSomeOtherThing!true .Type; I think this is hugely neat. I'm posting here both to share, and for peer review feedback. I'm also wondering if there is prior literature about this, and if it's something we'd want more of in Phobos? That's pretty awesome. There have been several times where I've been put off adding template parameters when I really wanted to, simply because I didn't want to have long, hard-to-read parameter lists in user code. Ideally I would like to be able to do this: mixin TemplateBuilder!(MyType, PresetTemplateArgs) MyChoiceOfBuilderName; where preset template args is optional and variadic, e.g. T in your example.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 13:59:08 UTC, ketmar via Digitalmars-d wrote: any code which does something like `if (a-b 0)` is broken. it Modify it: https://github.com/D-Programming-Language/druntime/blob/master/src/core/checkedint.d Modify method: subu(uint ...) or subu(ulong ...) if(xy) return y -x ; else return x -y; It will be not broken.
Re: Named parameter builder pattern for template parameters
On Friday, 21 November 2014 at 14:46:00 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 21 Nov 2014 13:39:42 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com
wrote:
D has phenomenal meta programming possibilities, and I see more
and more templates taking more and more parameters. So I
thought
to myself, why not have a template builder pattern?
i did something similar in my iv.writer (ctfe format string
parser).
once i got about ten argumnets to each template (and growing),
i moved
everything to structure.
struct WrData {
... fields ...
auto set(string name, T) (in T value)
if (__traits(hasMember, this, name))
{
__traits(getMember, this, name) = value;
return this;
}
}
and then i can pass the struct around, changing only the fields
i want,
in pseudo-functional style:
template MyTpl!(WrData data) {
...
MyTpl!(data.set!field0(value0).set!field1(value1));
}
that was a real saver. but now i have to wait for GDC update,
'cause
2.065 frontend is not able to use structs as template args.
Hum, use a standard structure combined with CTFE to achieve the
same goal. Smart. BTW, if you use opDispatch, you could probably
have it as:
MyTpl!(data.set_field0(value0).set_field1(value1));
Which may or may not read nicer, depending on how you look at it.
With proper template overloading, you should even be able to
implement this as a backwards compatible template.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, 21 Nov 2014 14:55:45 + FrankLike via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 21 November 2014 at 13:59:08 UTC, ketmar via Digitalmars-d wrote: any code which does something like `if (a-b 0)` is broken. it Modify it: https://github.com/D-Programming-Language/druntime/blob/master/src/core/checkedint.d Modify method: subu(uint ...) or subu(ulong ...) if(xy) return y -x ; else return x -y; It will be not broken. and it will not do the same anymore too. it's not a fix at all. signature.asc Description: PGP signature
Re: Type Inference Bug?
Meta wrote in message news:tyfdmprlmreagrrnb...@forum.dlang.org... Hmm, do you know why is(typeof(i) == shared(U), U)) might fail? I wonder why : is required over ==... Doesn't the former check if T is a subtype of U, rather than check that they're the same type? I have no idea, I tried == first, expecting it to work. And yes, it checks it's a subtype, but you could enforce exact type with something like if (typeof(i) == shared(U), U) is(shared(U) == typeof(i))
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 15:13:22 UTC, ketmar via Digitalmars-d wrote: and it will not do the same anymore too. it's not a fix at all. But it is a part of bugs. Sure,bug which is in mixing sign and unsign values should be fix.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote: On 11/20/2014 7:11 PM, Walter Bright wrote: On 11/20/2014 3:25 PM, bearophile wrote: Walter Bright: If that is changed to a signed type, then you'll have a same-only-different set of subtle bugs, This is possible. Can you show some of the bugs, we can discuss them, and see if they are actually worse than the current situation. All you're doing is trading 0 crossing for 0x7FFF crossing issues, and pretending the problems have gone away. BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. 0 crossing bugs tend to show up much sooner, and often immediately. You're missing the point here. The problem is that people are using 'uint' as if it were a positive integer type. Suppose D had a type 'natint', which could hold natural numbers in the range 0..uint.max. Sounds like 'uint', right? People make the mistake of thinking that is what uint is. But it is not. How would natint behave, in the type system? typeof (natint - natint) == int NOT natint !!! This would of course overflow if the result is too big to fit in an int. But the type would be correct. 1 - 2 == -1. But typeof (uint - uint ) == uint. The bit pattern is identical to the other case. But the type is wrong. It is for this reason that uint is not appropriate as a model for positive integers. Having warnings about mixing int and uint operations in relational operators is a bit misleading, because mixing signed and unsigned is not usually the real problem. Instead, those warnings a symptom of a type system mistake. You are quite right in saying that with a signed length, overflows can still occur. But, those are in principle detectable. The compiler could add runtime overflow checks for them, for example. But the situation for unsigned is not fixable, because it is a problem with the type system. By making .length unsigned, we are telling people that if .length is used in a subtraction expression, the type will be wrong. It is the incorrect use of the type system that is the underlying problem.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, Nov 21, 2014 at 03:36:01PM +, Don via Digitalmars-d wrote: [...] Suppose D had a type 'natint', which could hold natural numbers in the range 0..uint.max. Sounds like 'uint', right? People make the mistake of thinking that is what uint is. But it is not. How would natint behave, in the type system? typeof (natint - natint) == int NOT natint !!! Wrong. (uint.max - 0) == uint.max, which is of type uint. If you interpret it as int, you get a negative number, which is wrong. So your proposal breaks uint in even worse ways, in that now subtracting a smaller number from a larger number may overflow, whereas it wouldn't before. So that fixes nothing, you're just shifting the problem somewhere else. T -- Too many people have open minds but closed eyes.
Re: Why is `scope` planned for deprecation?
On 11/21/14 12:17 AM, Paulo Pinto wrote: On Friday, 21 November 2014 at 02:56:09 UTC, Andrei Alexandrescu wrote: On 11/20/14 5:09 PM, Walter Bright wrote: On 11/20/2014 3:10 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Thursday, 20 November 2014 at 22:47:27 UTC, Walter Bright wrote: On 11/20/2014 1:55 PM, deadalnix wrote: All of this is beautiful until you try to implement a quicksort in, haskell. […] Monads! I think Deadalnix meant that you cannot do in-place quicksort easily in Haskell. That's correct. Non-mutating quicksort is easy, no need for monads: quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter ( p) xs greater = filter (= p) xs https://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell Except that isn't really quicksort. Monads are the workaround functional languages use to deal with things that need mutation. As I like to say, this troika has inflicted a lot of damage on both FP and those beginning to learn it: * Linear-space factorial * Doubly exponential Fibonacci * (Non)Quicksort These losers appear with depressing frequency in FP introductory texts. Andrei Just like the OOP introductory books that still insist in talking about Cars and Vehicles, Managers and Employees, Animals and Bees, always using inheritance as code reuse. The first public example found by google (oop introduction) lists a class Student as the first example of a class: http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep#Object and IOException inheriting Exception as the first example of inheritance: http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep#Inheritance First example for overriding is Complex.ToString: http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep#Overloading Barely talking about is-a and has-a, and all the issues about fragile base classes. Even to the extent those old texts have persisted, they are only poor style. In contrast, the three FP example I mentioned are computationally bankrupt. There is really no excuse for teaching them. Andrei
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 15:36:02 UTC, Don wrote: On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote: On 11/20/2014 7:11 PM, Walter Bright wrote: On 11/20/2014 3:25 PM, bearophile wrote: Walter Bright: If that is changed to a signed type, then you'll have a same-only-different set of subtle bugs, This is possible. Can you show some of the bugs, we can discuss them, and see if they are actually worse than the current situation. All you're doing is trading 0 crossing for 0x7FFF crossing issues, and pretending the problems have gone away. BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. 0 crossing bugs tend to show up much sooner, and often immediately. You're missing the point here. The problem is that people are using 'uint' as if it were a positive integer type. Suppose D had a type 'natint', which could hold natural numbers in the range 0..uint.max. Sounds like 'uint', right? People make the mistake of thinking that is what uint is. But it is not. How would natint behave, in the type system? typeof (natint - natint) == int NOT natint !!! This would of course overflow if the result is too big to fit in an int. But the type would be correct. 1 - 2 == -1. So if i is a natint the expression i-- would change the type of variable i on the fly to int ?
Re: Type Inference Bug?
On Friday, 21 November 2014 at 15:29:05 UTC, Daniel Murphy wrote: but you could enforce exact type with something like if (typeof(i) == shared(U), U) is(shared(U) == typeof(i)) I'm assuming you meant if (typeof(i): shared(U), U) is(shared(U): typeof(i))).
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/14 12:56 AM, Daniel Murphy wrote: Walter Bright wrote in message news:m4mua1$shh$1...@digitalmars.com... Presumably read() will throw if the size is larger than it can handle. If it doesn't, this code is not buggy, but read() is. You're right, but that's really not the point. What is your point? (Honest question.) Are you proposing that we make all array lengths signed? -- Andrei
Re: Why is `scope` planned for deprecation?
Just like the OOP introductory books that still insist in
talking about Cars and Vehicles, Managers and Employees,
Animals and Bees, always using inheritance as code reuse.
Barely talking about is-a and has-a, and all the issues about
fragile base classes.
--
Paulo
Hear, hear. One of the problems with many introductions to
OOP-paradigmed languages such as C++ is that by having to spend a
lot of time explaining how to implement inheritance, the novice
reader thinks that OOP is the 'right' approach to solving many
problems when in fact other techniques ('prefer composition over
inheritance' springs to mind) are far more appropriate. This is
one of the primary problems I find in code of even more
experienced programmers.
Re: the traits trap
On 11/21/14 2:25 AM, Sergei Nosov wrote:
On Friday, 21 November 2014 at 04:08:52 UTC, Steven Schveighoffer wrote:
Can anyone figure out a good solution to this problem? I like template
constraints, but they are just too black-boxy. Would we have to
signify that some enum is actually a trait and so the compiler would
know to spit out the junk of compiling? Would it make sense to add
some __traits function that allows one to signify that this is a
special trait thing?
This is one area that D's templates are very user-unfriendly.
-Steve
I would second this. Personally, I have the same not very pleasant
experience debugging template constraints.
Since more often than not the constraints have the form of:
if (clause1 clause2 clause3 ...)
my naive proposal would be to show which clause was first to be false in
the error message.
That helps, but you still have to figure out why that clause fails.
However, I have no idea if this could be implemented easily.
I think it's a good idea in general. Inevitably, a template constraint
breaks down into a decision tree, and knowing which decisions
contributed to the false at the top is essential. Of course, this is
only needed if it *doesn't* compile.
What I'd like to see is a combination of both determining at the highest
level which part of the if expression caused the failure (this is only
if the thing doesn't compile), and then add a new feature:
static assert(__traits(analyzeTrait, isSomeTrait!x));
The analyzeTrait directive would compile isSomeTrait!x, keeping track of
the decision tree (or optionally, re-compiling it to print the tree),
and whichever pieces caused it to be 0, including __traits(compiles,
...) error messages, and if the result ends up being non-zero, it just
discards that tree. If the result ends up being 0, then the static
assert prints the decision tree.
An example:
enum isFoo(T) = (is(T == int) || is(T == long)) __traits(compiles, (T
t) { blah(t); });
void blah(int x);
static assert(__traits(analyzeTrait, isFoo!int)); // = no messages,
compilation continues
static assert(__traits(analyzeTrait, isFoo!long)); // Compilation stops,
output is:
Error: analyzeTrait returned false for isFoo!(T) where T == long:
is(T == int) = false [1]
is(T == long) = true [2]
[1] || [2] = true [3]
__traits(compiles, ...) = false [4]
Error: no overload of blah for long
[3] [4] = false
Note, the __traits(compiles, ...) line would show the entire compile
expression for reference.
Something like this makes analysis of why the static assert failed so
much better. You could just build this into static assert, but I think
it might be too unwieldy to see all the messages. Sometimes, just
knowing static assert fails some involved test is fine, you don't need
the details.
-Steve
Re: Thread GC non stop-the-world
On Friday, 21 November 2014 at 10:24:09 UTC, Kagamin wrote: On Thursday, 25 September 2014 at 21:59:15 UTC, Sean Kelly wrote: On Thursday, 25 September 2014 at 13:55:42 UTC, Wyatt wrote: The caveat for D being this design requires read and write barriers and I'm pretty sure I recall correctly that those have been vetoed several times for complexity. Pretty much for reasons of being able to call C functions and inline asm code. Memory barriers may still be possible in these scenarios, but they would be extremely expensive. BTW, C usually accepts data only for reading, and writes mostly strings and buffers - plain data without pointers. In both cases it doesn't need to notify GC (as far as I understand write barriers). usually isn't sufficient if you're trying to make a GC that doesn't collect live data. It's possible that we could do something around calls to extern (C) functions that accept a type containing pointers, but I'd have to give this some thought.
Re: Type Inference Bug?
On Friday, 21 November 2014 at 07:40:31 UTC, Daniel Murphy wrote:
It doesn't print anything for me. This code seems to have the
desired effect:
shared const int i;
void main()
{
static if (is(typeof(i) : shared(U), U))
{
//Prints const(int)
pragma(msg, U);
}
}
Now how about this one:
alias Unshared(T: shared U, U) = U;
pragma(msg, Unshared!(shared const int)); //Prints const(int)
Does the `:` denote subtyping as well, or equality? I'm sure that
in this case it's the latter, which makes me more strongly
suspect that
`is(T == shared U, U)` not working is a bug.
Furthermore, I'm starting to get very confused:
enum sameTypes(T, U) = is(T: U) is(U: T);
assert(sameTypes!(const int, immutable int)); //Ok, wtf?
assert(sameTypes!(int, immutable int); //Ok, wtf?
What in the world is going on here? Note that this is from
Dpaste, so it's DMD 2.065, but I doubt there is that much
difference between 2.065 and 2.066.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 15:50:05 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Nov 21, 2014 at 03:36:01PM +, Don via Digitalmars-d wrote: [...] Suppose D had a type 'natint', which could hold natural numbers in the range 0..uint.max. Sounds like 'uint', right? People make the mistake of thinking that is what uint is. But it is not. How would natint behave, in the type system? typeof (natint - natint) == int NOT natint !!! Wrong. (uint.max - 0) == uint.max, which is of type uint. It is not uint.max. It is natint.max. And yes, that's an overflow condition. Exactly the same as when you do int.max + int.max. If you interpret it as int, you get a negative number, which is wrong. So your proposal breaks uint in even worse ways, in that now subtracting a smaller number from a larger number may overflow, whereas it wouldn't before. So that fixes nothing, you're just shifting the problem somewhere else. T This is not a proposal I am just illustrating the difference between what people *think* uint does, vs what it actually does. The type that I think would be useful, would be a number in the range 0..int.max. It has no risk of underflow. To put it another way: natural numbers are a subset of mathematical integers. (the range 0..infinity) signed types are a subset of mathematical integers (the range -int.max .. int.max). unsigned types are not a subset of mathematical integers. They do not just have a restricted range. They have different semantics. The question of what happens when a range is exceeded, is a different question.
Re: Would you trade 0.1% in performance for a better debugging experience?
Am Wed, 19 Nov 2014 08:14:44 + schrieb Kagamin s...@here.lot: On Tuesday, 18 November 2014 at 18:55:43 UTC, Marco Leise wrote: Is it fair if I argue that fixing DWARF info generation is a better solution then? I'm afraid, DWARF is not designed to unwind segfaults, it works only with DWARF exceptions. I don't know if segfaults were ever in the picture. Vladimir was talking about InvalidMemoryOperationErrors thrown by the runtime. -- Marco
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/14 6:03 AM, ketmar via Digitalmars-d wrote: On Thu, 20 Nov 2014 13:28:37 -0800 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote: What *could* be improved, is the prevention of obvious mistakes in *mixing* signed and unsigned types. Right now, D allows code like the following with no warning: uint x; int y; auto z = x - y; BTW, this one is the same in essence as an actual bug that I fixed in druntime earlier this year, so downplaying it as a mistake people make 'cos they confound computer math with math math is fallacious. What about: uint x; auto z = x - 1; ? here z must be `long`. and for `ulong` compiler must emit error. Would you agree that that would break a substantial amount of correct D code? -- Andrei
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Thursday, 20 November 2014 at 20:17:15 UTC, deadalnix wrote: On Thursday, 20 November 2014 at 15:55:21 UTC, H. S. Teoh via Digitalmars-d wrote: Using unsigned types for array length doesn't necessarily lead to subtle bugs, if the language was stricter about mixing signed and unsigned values. Yes, I think that this is the real issue. Thirded. Array lengths are always non-negative integers. This is axiomatic. But the subtraction thing keeps coming up in this thread; what to do? There's probably something fundamentally wrong with this and I'll probably be called an idiot by both sides, but my gut feeling is that if expressions with subtraction simply returned a signed type by default, much of the problem would disappear. It doesn't catch everything and stuff like: uint x = 2; uint y = 4; uint z = x - y; ...is still going to overflow, but maybe you know what you're doing? More importantly, changing it to auto z = x - y; actually works as expected for the majority of cases. (I'm actually on the fence re: pass/warn/error on mixing, but I _will_ note C's promotion rules have bitten me in the ass a few times and I have no particular love for them.) -Wyatt PS: I can't even believe how this thread has blown up, considering how it started.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/14 6:17 AM, Ary Borenszweig wrote: On 11/21/14, 5:45 AM, Walter Bright wrote: On 11/21/2014 12:10 AM, bearophile wrote: Walter Bright: All you're doing is trading 0 crossing for 0x7FFF crossing issues, and pretending the problems have gone away. I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone. I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFF crossing bugs is making the bug count less. BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. Is this true? Do you have some examples of buggy code? http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html This bug can manifest itself for arrays whose length (in elements) is 2^30 or greater (roughly a billion elements) How often does that happen in practice? Every time you read a DVD image :o). I should say that in my doctoral work it was often the case I'd have very large arrays. Andrei
Re: Thread GC non stop-the-world
I believe I have never seen such C function. What can it do to screw managed memory? It usually requires allocation of new memory from GC and assigning it to an old object, but (true) C function is very unlikely to allocate memory from GC.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Thursday, 20 November 2014 at 08:14:41 UTC, Walter Bright wrote: clip For example, in America we drive on the right. In Australia, they drive on the left. When I visit Australia, I know this, but when stepping out into the road I instinctively check my left for cars, step into the road, and my foot gets run over by a car coming from the right. I've had to be very careful as a pedestrian there, as my intuition would get me killed. Don't mess with systems programmers' intuitions. It'll cause more problems than it solves. I live in Quebec and my intuition always tells me to look both ways - because you never know :o)
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, 21 Nov 2014 08:31:13 -0800 Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: Would you agree that that would break a substantial amount of correct D code? -- Andrei i don't think that code with possible int wrapping and `auto` is correct, so the answer is no. bad code must be made bad. signature.asc Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 16:48:35 UTC, CraigDillabaugh wrote: I live in Quebec and my intuition always tells me to look both ways - because you never know :o) While doing my driver's training years ago, my instructor half-jokingly warned us never to jaywalk in Quebec unless we have a death wish and want to hear all about chalices and tabernacles.
Re: Ranges and Exception handling PR 2724
Am Fri, 21 Nov 2014 08:56:17 + schrieb Jonathan Marler johnnymar...@gmail.com: I actually ran into this problem today when using the dirEntries function in std.file. I was attempting to iterate all the files on my C drive and I got an Access Denied error which caused the DirIterator to throw an exception. There's nothing I could do to catch the exception and continue. I'm very glad people are aware of this problem and I'm glad you are trying to do something about it. Yep, that dirEntries Exception is quite the show stopper. You need to be certain that you have access to all directories that it may encounter, which makes it unusable for file system roots, but also breaks way to easily with unreadable directories in user directories when all you need is a list of the _accessible_ files. The bug reports so far: std.file: dirEntries-range crashes, when hitting the system folder System Volume Information https://issues.dlang.org/show_bug.cgi?id=12513 DirEntries throws in foreach https://issues.dlang.org/show_bug.cgi?id=12391 dirEntries throws when encountering a long path on windows https://issues.dlang.org/show_bug.cgi?id=8967 -- Marco
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Am Wed, 19 Nov 2014 10:22:49 + schrieb Dominikus Dittes Scherkl dominikus.sche...@continental-corporation.com: On Wednesday, 19 November 2014 at 09:06:16 UTC, Maroc Leise wrote: Clearly size_t (which I tend to alias with ℕ in my code for brevity and coolness) No, this is far from the implied infinite set. A much better candidate for ℕ is BigUInt (and ℤ for BigInt) How far exactly is it from infinity? And how much closer is BigInt? I wanted a fast ℕ within the constraints of the machine. ;) -- Marco
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, Nov 21, 2014 at 08:31:13AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 11/21/14 6:03 AM, ketmar via Digitalmars-d wrote: On Thu, 20 Nov 2014 13:28:37 -0800 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote: What *could* be improved, is the prevention of obvious mistakes in *mixing* signed and unsigned types. Right now, D allows code like the following with no warning: uint x; int y; auto z = x - y; BTW, this one is the same in essence as an actual bug that I fixed in druntime earlier this year, so downplaying it as a mistake people make 'cos they confound computer math with math math is fallacious. What about: uint x; auto z = x - 1; ? here z must be `long`. and for `ulong` compiler must emit error. What if x==uint.max? Would you agree that that would break a substantial amount of correct D code? -- Andrei Yeah I don't think it's a good idea for subtraction to yield a different type from its operands. Non-closure of operators (i.e., results are of a different type than operands) leads to a lot of frustration because you keep ending up with the wrong type, and inevitably people will just throw in random casts everywhere just to make things work. T -- We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Am Thu, 20 Nov 2014 08:18:23 +
schrieb Don x...@nospam.com:
It's particularly challenging in D because of the widespread use
of 'auto':
auto x = foo();
auto y = bar();
auto z = baz();
if (x - y z) { ... }
This might be a bug, if one of these functions returns an
unsigned type. Good luck finding that. Note that if all
functions return unsigned, there isn't even any signed-unsigned
mismatch.
With those function names I cannot write code.
ℕ x = length();
ℕ y = index();
ℕ z = requiredRange();
if (x - y z) { ... }
Ah, now we're getting somewhere. Yes the code is obviously
correct. You need to be aware of the value ranges of your
variables and write subtractions in a way that the result can
only be = 0. If you realize that you cannot guarantee that
for some case, you just found a logic bug. An invalid program
state that you need to assert/if-else/throw.
I don't get why so many APIs return ints. Must be to support
Java or something where proper unsigned types aren't available.
--
Marco
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/14, 11:29 AM, ketmar via Digitalmars-d wrote:
On Fri, 21 Nov 2014 19:31:23 +1100
Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote:
bearophile wrote in message news:lkcltlokangpzzdzz...@forum.dlang.org...
From my experience in coding in D they are far more unlikely than
sign-related bugs of array lengths.
Here's a simple program to calculate the relative size of two files, that
will not work correctly with unsigned lengths.
module sizediff
import std.file;
import std.stdio;
void main(string[] args)
{
assert(args.length == 3, Usage: sizediff file1 file2);
auto l1 = args[1].read().length;
auto l2 = args[2].read().length;
writeln(Difference: , l1 - l2);
}
The two ways this can fail (that I want to highlight) are:
1. If either file is too large to fit in a size_t the result will (probably)
be wrong
2. If file2 is bigger than file1 the result will be wrong
If length was signed, problem 2 would not exist, and problem 1 would be more
likely to occur. I think it's clear that signed lengths would work for more
possible realistic inputs.
no, the problem 2 just becomes hidden. while the given code works most
of the time, it is still broken.
So how would you solve problem 2?
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/14, 11:47 AM, ketmar via Digitalmars-d wrote: On Fri, 21 Nov 2014 11:17:06 -0300 Ary Borenszweig via Digitalmars-d digitalmars-d@puremagic.com wrote: This bug can manifest itself for arrays whose length (in elements) is 2^30 or greater (roughly a billion elements) How often does that happen in practice? once in almost ten years is too often, as for me. i think that the answer must be never. either no bug, or the code is broken. and one of the worst code is the code that works most of the time, but still broken. You see, if you don't use a BigNum for everything than you will always have hidden bugs, be it with int, uint or whatever. The thing is that with int bugs are much less frequent than with uint. So I don't know why you'd rather have uint than int...
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/14, 1:32 PM, Andrei Alexandrescu wrote: On 11/21/14 6:17 AM, Ary Borenszweig wrote: On 11/21/14, 5:45 AM, Walter Bright wrote: On 11/21/2014 12:10 AM, bearophile wrote: Walter Bright: All you're doing is trading 0 crossing for 0x7FFF crossing issues, and pretending the problems have gone away. I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone. I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFF crossing bugs is making the bug count less. BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. Is this true? Do you have some examples of buggy code? http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html This bug can manifest itself for arrays whose length (in elements) is 2^30 or greater (roughly a billion elements) How often does that happen in practice? Every time you read a DVD image :o). I should say that in my doctoral work it was often the case I'd have very large arrays. Oh, sorry, I totally forgot that when you open a DVD with VLC it reads the whole thing to memory. /sarcasm
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Am Fri, 21 Nov 2014 16:32:20 +
schrieb Wyatt wyatt@gmail.com:
Array lengths are always non-negative integers. This is
axiomatic. But the subtraction thing keeps coming up in this
thread; what to do?
There's probably something fundamentally wrong with this and I'll
probably be called an idiot by both sides, but my gut feeling
is that if expressions with subtraction simply returned a signed
type by default, much of the problem would disappear. [...]
As I said above, I always order my unsigned variables by
magnitude and uint.max - uint.min should result in uint.max
and not -1. In code dealing with lengths or offsets there is
typically some base that is less than the position or an
index that is less than the length.
The expression `base - position` is just wrong. If it is in
fact below base then you will end up with an if-else later
on under guarantee. So why not place it up front:
if (position = base)
{
auto offset = position - base;
}
else
{
…
}
[...]
-Wyatt
PS: I can't even believe how this thread has blown up,
considering how it started.
Exactly my thought, but suddenly I couldn't stop myself from
posting.
--
Marco
Re: 'int' is enough for 'length' to migrate code from x86 to x64
Am Thu, 20 Nov 2014 20:53:31 -0800 schrieb Walter Bright newshou...@digitalmars.com: On 11/20/2014 7:11 PM, Walter Bright wrote: On 11/20/2014 3:25 PM, bearophile wrote: Walter Bright: If that is changed to a signed type, then you'll have a same-only-different set of subtle bugs, This is possible. Can you show some of the bugs, we can discuss them, and see if they are actually worse than the current situation. All you're doing is trading 0 crossing for 0x7FFF crossing issues, and pretending the problems have gone away. BTW, granted the 0x7FFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested robust code. 0 crossing bugs tend to show up much sooner, and often immediately. +1000. This is also the reason we have a special float .init in D. There is no plethora of bugs to show, because they are under the radar. Signed types are only more convenient in the scripting language sense, like using double for everything and array indexing in JavaScript. -- Marco
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, 21 Nov 2014 14:38:26 -0300 Ary Borenszweig via Digitalmars-d digitalmars-d@puremagic.com wrote: You see, if you don't use a BigNum for everything than you will always have hidden bugs, be it with int, uint or whatever. why do you believe that i'm not aware of overflows and don't checking for that? i'm used to think about overflows and do overflow checking in production code since my Z80 days. and i don't believe that infrequent bug is better than frequent bug. both are equally bad. signature.asc Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, 21 Nov 2014 09:08:54 -0800 H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: What about: uint x; auto z = x - 1; ? here z must be `long`. and for `ulong` compiler must emit error. What if x==uint.max? nothing bad, long is perfectly able to represent that. Would you agree that that would break a substantial amount of correct D code? -- Andrei Yeah I don't think it's a good idea for subtraction to yield a different type from its operands. Non-closure of operators (i.e., results are of a different type than operands) leads to a lot of frustration because you keep ending up with the wrong type, and inevitably people will just throw in random casts everywhere just to make things work. not any subtraction, only that with `auto` vardecl. signature.asc Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Fri, 21 Nov 2014 14:36:53 -0300
Ary Borenszweig via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 11/21/14, 11:29 AM, ketmar via Digitalmars-d wrote:
On Fri, 21 Nov 2014 19:31:23 +1100
Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote:
bearophile wrote in message news:lkcltlokangpzzdzz...@forum.dlang.org...
From my experience in coding in D they are far more unlikely than
sign-related bugs of array lengths.
Here's a simple program to calculate the relative size of two files, that
will not work correctly with unsigned lengths.
module sizediff
import std.file;
import std.stdio;
void main(string[] args)
{
assert(args.length == 3, Usage: sizediff file1 file2);
auto l1 = args[1].read().length;
auto l2 = args[2].read().length;
writeln(Difference: , l1 - l2);
}
The two ways this can fail (that I want to highlight) are:
1. If either file is too large to fit in a size_t the result will
(probably)
be wrong
2. If file2 is bigger than file1 the result will be wrong
If length was signed, problem 2 would not exist, and problem 1 would be
more
likely to occur. I think it's clear that signed lengths would work for
more
possible realistic inputs.
no, the problem 2 just becomes hidden. while the given code works most
of the time, it is still broken.
So how would you solve problem 2?
with proper check before doing subtraction. or by switching to some
Scheme compiler with full numeric tower.
signature.asc
Description: PGP signature
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Friday, 21 November 2014 at 16:12:19 UTC, Don wrote:
On Friday, 21 November 2014 at 15:50:05 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Nov 21, 2014 at 03:36:01PM +, Don via
Digitalmars-d wrote:
[...]
Suppose D had a type 'natint', which could hold natural
numbers in
the range 0..uint.max. Sounds like 'uint', right? People
make the
mistake of thinking that is what uint is. But it is not.
How would natint behave, in the type system?
typeof (natint - natint) == int NOT natint !!!
Wrong. (uint.max - 0) == uint.max, which is of type uint.
It is not uint.max. It is natint.max. And yes, that's an
overflow condition.
Exactly the same as when you do int.max + int.max.
If you
interpret it as int, you get a negative number, which is
wrong. So your
proposal breaks uint in even worse ways, in that now
subtracting a
smaller number from a larger number may overflow, whereas it
wouldn't
before. So that fixes nothing, you're just shifting the problem
somewhere else.
T
This is not a proposal I am just illustrating the
difference between what people *think* uint does, vs what it
actually does.
The type that I think would be useful, would be a number in the
range 0..int.max.
It has no risk of underflow.
To put it another way:
natural numbers are a subset of mathematical integers.
(the range 0..infinity)
signed types are a subset of mathematical integers
(the range -int.max .. int.max).
unsigned types are not a subset of mathematical integers.
They do not just have a restricted range. They have different
semantics.
I was under the impression that in D:
uint = { x mod 2^32 | x ∈ Z_0 }
int = { x - 2^31 | x ∈ uint }
which matches the hardware.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/21/2014 10:05 AM, ketmar via Digitalmars-d wrote: why do you believe that i'm not aware of overflows and don't checking for that? i'm used to think about overflows and do overflow checking in production code since my Z80 days. and i don't believe that infrequent bug is better than frequent bug. both are equally bad. Having coded with 16 bit computers for decades, one gets used to thinking about and dealing with overflows :-)
