Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dbaupp
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
77 ms
·
751.
▲
by
dbaupp
10y ago
Something crashing, so an error can be reported and a watchdog can restart it (etc.) is far better than just forging on with corrupt memory and wrong answers. People do not use the sanitisers nearly as much as they should, and nor are the
752.
▲
by
dbaupp
10y ago
Creating a type for it, for each type of array, will require exactly the macro array thing I was talking about. And see the sibling comment for how dynamic arrays/alloca isn't relevant, I'm just talking about static arrays. (
753.
▲
by
dbaupp
10y ago
I think you have a good point. It makes more sense to think and talk about as Rust's implementation of bounds checked indexing syntax as being a zero cost abstraction for writing `if` statements everywhere. I.e. Assuming you want bound
754.
▲
by
dbaupp
10y ago
That approach of a single invocation was what I would personally assume would be done (or put it in the header that defines the data type, for a custom one), but I'm not sure how that solves spaces?
755.
▲
by
dbaupp
10y ago
I would be interested in the specifics of the spaces thing (knowing more about ones tools is good) but "10 minutes" to handle all the various issues and bugs that will inevitably pop up from wrangling macros?
756.
▲
by
dbaupp
10y ago
Oh, yes, I'd forgotten about VLAs... Compile-time constant, except for sometimes.
757.
▲
by
dbaupp
10y ago
I'm not even talking about variably sized arrays, just creating a statically sized one and passing it into functions that take dynamically-sized one. For instance, a read function that fills an existing buffer doesn't care if the
758.
▲
by
dbaupp
10y ago
While "unnecessary"/extra generated code is a trade-off one has to consider when choosing to use the specialize/monomorphise-everything implementation of parametric polymorphism (it isn't the only one), it isn'
759.
▲
by
dbaupp
10y ago
They don't, sizeof is a compile-time constant. On a pointer, sizeof() just reports the size of the pointer itself (i.e. 4 or 8 bytes on most modern platforms), not the size of the data to which it points (and sizeof(*pointer) reports t
760.
▲
by
dbaupp
10y ago
So you want the array to have type foo * ? Ignoring that this doesn't let the compiler help the programmer with arrays (you still have to manually remember to use the accessor, not []), you also have to manually remember which pointers
761.
▲
by
dbaupp
10y ago
Yes, it checks that it's reached the end of the array as part of the loop, in the same place that `for (int i = 0; i < n; i++)` checks whether it's reached the end of the loop. I think this is different to the indexing bounds c
762.
▲
by
dbaupp
10y ago
The lack of generics means your array implementation is either going to either: - be implemented with macros and token pasting, and result in a ton of mental overhead because you'll have a pile of types like array_foo for an array of `
763.
▲
by
dbaupp
10y ago
This is true of every language: e.g. Python has ctypes, Haskell has Foreign, Java has JNI, etc. It's a matter of defaults/conventions rather than something being literally impossible to screw up.
764.
▲
by
dbaupp
10y ago
(FWIW, You could golf that to io::stdin().read_to_end(...), because the Read implementation for Stdin does the same locking internally: https://github.com/rust-lang/rust/blob/8f62c2920077eb5cb8132... .)
765.
▲
by
dbaupp
10y ago
There's two problems with this statement: - index checks aren't intrinsic for all cases where it is done, e.g. https://github.com/rust-lang/rust/blob/8f62c2920077eb5cb8132... - being intrinsic is ab
766.
▲
by
dbaupp
10y ago
As others have said, this is a fairly standard optimisation: compilers (Rust, C, C++, Java, PHP, whatever) will remove branches if they can see that it can never be taken. Iterators are slightly different in that they don't have any in
767.
▲
by
dbaupp
10y ago
When was the last time you heard of Samsung being involved with Rust as a company? I'm fairly sure that is no longer a thing.
768.
▲
by
dbaupp
10y ago
The more strict static checking in Rust means that the compiler can actually be a teaching tool for concepts like RAII and the heap/stack difference: it flags and explains places where the programmer is doing that doesn't make s
769.
▲
by
dbaupp
10y ago
> My point was that in many applications memory safety doesn't rank highly as a separate concern, in addition to computing correct output from expected input Indeed, I was trying to cover that in my comment. I agree that it isn&#x
770.
▲
by
dbaupp
10y ago
Memory safety is important for everything because it is a prerequisite for any other form of correctness. There's no guarantee that a violation of memory safety will result in a crash, memory corruption is just as possible, resulting i
771.
▲
by
dbaupp
10y ago
My understanding is that sanitizers are generally not designed to be deployed in production software, they're written with catching problems in testing in mind (i.e. calling them an implementation of C seems dubious to me), and have pr
772.
▲
by
dbaupp
10y ago
The boxing there is perfectly idiomatic. Your code is likely to result in a pile of unnecessary code bloat, due to monomorphising the generic function twice, rather than just using dynamic dispatch (the overhead of which is likely trivial f
773.
▲
by
dbaupp
10y ago
The equivalent of a function returning Result<T, E> in Rust would be returning something like unique_ptr<ResultBaseClass<T,E>> because the two subclasses have different sizes and thus can't be returned directly (or el
774.
▲
by
dbaupp
10y ago
You're being too enthusiastic/wrong: there is a cost to Result and Option even in the good case. There still has to be a branch to check if there actually was no error. Result and Option are similar to error codes in C and have
775.
▲
by
dbaupp
10y ago
The union avoids requiring an allocation for, say, returning a Result.
776.
▲
by
dbaupp
10y ago
Being safer isn't all or nothing. Even if a getting a guaranteed panic on array out of bounds was nearly as unsafe as the undefined behaviour of C in that case (it isn't, at all), Rust still mitigates many of C's other most d
777.
▲
by
dbaupp
10y ago
Given the history of the web and what I know of the people/companies behind wasm, it seems very likely that there'll be a graceful degradation/shim in the form of a wasm interpreter written in JS/asm.JS (or even a JIT
778.
▲
by
dbaupp
10y ago
LICM is very relevant: it allows hoisting various dimensions of the check up to the loop with the relevant induction variable, meaning LLVM only has to handle things of the pattern: for i in 0..X { if !(i < X) { panic!() } ..
779.
▲
by
dbaupp
10y ago
Why do you still think the compiler can't host those out of loops? LLVM is perfectly capable of doing so in many cases and you've been told as much previously, could you make your claim more specific?
780.
▲
by
dbaupp
10y ago
Fortunately there's no need to have read all of the (very interesting) archives of Niko's blog in this case, as the parent article linked to that post in the relevant section too.
More ›