161–170 of 223 posts
Earlier quoted context omitted.
Well, crypto/bitcoin businesses in general tend to be quite lucrative. However lots of risks as well. For a security researcher there are no downside risks as much.
> crypto/bitcoin businesses in general tend to be quite lucrative. That's called a pyramid, or ponzi scheme.
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning" --Rick Cook
Earlier quoted context omitted.
Because old habits die hard. Using 'unmanaged' languages for 'performance' reasons is no longer a good reason, because the likes of C# have shown multiple times that there is no reason to choose C++ over C# if you look at performance alone (difference is neglible).
The difference is not negligible: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Sure, it's silly benchmarks, so I wouldn't take the results as gospel. But the fact is, nobody who writes C# managed to produce a benchmark yet that beats a C++ program. Fast languages like Rust have managed to at least match the performance of C in some benchmarks (and even beat it in others).
No, but I've seen Haskell programs that were much faster than the C++ program they replaced, which is what matters in the real world.
Microbenchmarks measure what happens if you have the time to polish every single line to perfection. If you have infinite developer time then C++ will be faster than most languages. But infinite developer time is a negligible use case.
The point I'm about to make in this comment is so old and has been said so many times that we all are tired of hearing it. But why do we use a language like C++ to implement something where we don't wish to have bugs? C++ is not memory-safe (no GC or whatever Rust does), it's not type safe (in the ML sense), it relies on writing to memory a lot (instead of having pure functions). Had this program been written in Ocam…
As far as I can tell, this bug has nothing to do with memory-safety. And I don't think C++ is to blame here. It's just a lot of untested code. Surely even Ocaml and Haskell need tests.
Earlier quoted context omitted.
Didn't try, but I could imagine that running -Wall over that codebase produces huge amounts of noise rendering it practically useless, until somebody gets to fix all warnings which are not bugs.
> -Wall over that codebase produces huge amounts of noise rendering it practically useless As a c++ developer I would nope the hell out of there or spend a month fixing the warnings - depending on pay. No way would I work with something in that state long term. > until somebody gets to fix all warnings which are not bugs. Code that is filled with ignored warnings generally gets worse, not better. Having little to no…
You might even find some zero days just by addressing all the warnings.
Earlier quoted context omitted.
> C/C++ is memory safe if you turn on dynamic checking. Is anyone here doing this? Would be interesting to hear your experience.
If valgrind counts, then yes.
Earlier quoted context omitted.
Fully agreed. There is absolutely no way that is something a programmer ever intended. In fact I think that just if (condition); Should already be enough to trigger the error. (Any 'if' statement without a body).
There could be an important side-effect in condition. Isn't persistent state fun!?
Earlier quoted context omitted.
Fully agreed. There is absolutely no way that is something a programmer ever intended. In fact I think that just if (condition); Should already be enough to trigger the error. (Any 'if' statement without a body).
There could be an important side-effect in condition. Isn't persistent state fun!?