tomnj

6 ms·

31.
by tomnj 7y ago
Sanitizers are not compile-time: they're runtime checks (aka dynamic analysis). For some strengths of valgrind compared to sanitizers, see my other comment in this thread.
32.
by tomnj 7y ago
Due to the memory unsafety of C++, memory debuggers are absolutely used, including valgrind's memcheck and the Google sanitizers. Memory leaks and double frees are easier to avoid in C++ than C even without tooling, but use-after-free
33.
by tomnj 7y ago
Valgrind's memcheck is still useful: it doesn't require recompiling, can handle external (binary-only) libraries, handles inline asm or jitted code, and provides uninitialized memory read instrumentation (yes, memsan does this, bu
34.
by tomnj 7y ago
As a C++ programmer dabbling in Rust I don’t find it strange. Many of the core ideas were motivated by C++. But I also like Haskell too :)
35.
by tomnj 7y ago
C++ is for sure extremely complicated, but I’d argue that a full understanding of value categories (glvalues, xrvalues, etc) isn’t necessary to be productive with the language.
36.
An Implementation of Lisp in C++ Template Metaprogramming(github.com)
3 points by tomnj 8y ago|0 comments
37.
by tomnj 8y ago
Completely? I’m not sure. I need to try more Rust. But not having to write another CMakeList sounds pretty good for starters :)
38.
by tomnj 8y ago
I love C++ (though it often frustrates me), and I think Rust is doing some awesome things (though I don’t work in it). A few clarifications: Your point about iterators and composability: you’re right, the STL suffers a bit here, but Eric Ne
39.
by tomnj 8y ago
> boost is not high quality This is just false.
40.
by tomnj 8y ago
Nothing comes for free though. While we can easily write list comprehensions in Haskell or Python, their implementations are complicated. In the case of Haskell and Python, lists and comprehensions are language features, and for C++ ranges,
41.
by tomnj 8y ago
This is library code which most users of the range library will not themselves need to write. Using ranges absolutely leads to shorter and more elegant code. The implementation of the library is complicated. Much of what’s likely unfamiliar
42.
by tomnj 8y ago
False. Like for any language, C and C++ programmers (should) put very high value on correctness. Incorrect code can be written in safe languages too, but clearly C/C++ make it much easier to kill your program spectacularly. Discipline,
43.
by tomnj 9y ago
here are a few reasons: 1) anything GUI related is a pain 2) interacting with the host filesystem has to be explicitly enabled 3) containers are still somewhat heavyweight
44.
by tomnj 9y ago
We tried #6 at ufora: "make a large number of CPUs look to the developer like one very fast CPU." https://github.com/ufora/ufora