On Monday, 1 January 2018 at 16:47:40 UTC, Adam D. Ruppe wrote: On Monday, 1 January 2018 at 16:13:37 UTC, Muld wrote: If you use .ptr then you get zero detection, even in debug builds. It is limited to the one expression where you wrote it, instead of on the ENTIRE program like the build switches do. It is a lot easier to check correctness in an individual expression than it is to check the entire program, including stuff you didn't even realize might have been a problem. With the .ptr pattern, it is correct by default and you individually change ones you (should) look carefully at. With -boundscheck, it is wrong by default and most people don't even look at it - people suggest it to newbies as an optimization without mentioning how nasty it is. It won't be just one line though. When you pretty much have to use it EVERYWHERE to get the optimization you want. It makes more sense to just turn off the check for the entire program and use your own asserts() where they are actually needed. That way you still get the checks in debug builds and have asserts where they are actually necessary. I'd rather there be a potential bug than the program running to slow to be usable That's a ridiculous exaggeration. In this program, I saw a < 1% time difference using those flags. -O -inline make a 50x bigger difference! Read the sentence right before this.. Jesus. People only read what they want. or have zero debugging for indices in debug builds. You shouldn't be using .ptr until after you've carefully checked and debugged the line of code where you are writing it. That's the beauty of the pattern: it only affects one line of code, so you can test it before you use it without affecting the rest of the program. It won't just be one line, and that's not beautiful. What happens when code gets refactored? You are constantly going to be flip-flopping the source code rather than a compiler flag or using multiple build configurations? How long are you even going to test for? The error that might happen for the code is probably difficult to detect, if it wasn't then having bounds checking at all wouldn't be necessary. Just test your code, that's the beauty of testing!
On Monday, 1 January 2018 at 15:54:33 UTC, Adam D. Ruppe wrote: On Monday, 1 January 2018 at 15:29:28 UTC, user1234 wrote: dmd mandelbrot.d -O -release -inline -boundscheck=off -O and -inline are OK, but -release and -boundscheck are harmful and shouldn't be used. Yeah, you can squeeze a bit of speed out of them, but there's another way to do it - `.ptr` on the individual accesses or versioning out unwanted `assert` statements - and those avoid major bug and security baggage that -release and -boundscheck=off bring. If you use .ptr then you get zero detection, even in debug builds. In this program, I didn't see a major improvement with the boundscheck skipping... and in this program, it seems to be written without the bugs, but still, I am against that switch on principle. It is so so so easy to break things with them. In this program, it's relatively small and doesn't look like it does its calculations in realtime. I'd rather there be a potential bug than the program running to slow to be usable, or have zero debugging for indices in debug builds.
On Friday, 29 December 2017 at 22:32:01 UTC, Tony wrote: In DLang Tour:Arrays https://tour.dlang.org/tour/en/basics/arrays there is: --- int size = 8; // run-time variable int arr = new int[size]; The type of arr is int, which is a slice. --- In "D Slices" https://dlang.org/d-array-article.html there is: --- int a; // a is a slice Based on those two web pages it appears that the name for a dynamic array
in D is "slice". That is, anytime you have a dynamic array (even a null reference version) it is called a slice. Is that correct? Not really, cause you can take a "slice" of a linked list (though inefficiently), but a linked list isn't an array. You can also take a "slice" of a stack allocated array.
On Saturday, 23 December 2017 at 07:25:34 UTC, IM wrote: The following expression: import std.math : sqrt; sqrt(400); produces the following compiler error: std.math.sqrt called with argument types (int) matches both: /usr/include/dmd/phobos/std/math.d(1592,7): std.math.sqrt(float x) and: /usr/include/dmd/phobos/std/math.d(1598,6): std.math.sqrt(real x) Shouldn't it just pick one according to some defined rules? C++ complains the same between float and double. Just put 400.0f or whatever precision you want to use. I think it's better that it doesn't just pick one.