Reputation
6,410
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
2 21 39
Newest
 Nice Answer
Impact
~436k people reached

17h
comment Encrypted content in games
@Christer: Sucks having that ruined by someone just looking through the game assets. => this is solvable by using secret files to describe the place indeed (reusing existing textures mostly), once the secret is out once though, it's out...
18h
revised Encrypted content in games
added 127 characters in body
18h
answered Encrypted content in games
Feb
4
comment Why is chaining setters unconventional?
@BoristheSpider: In C++, T& getSelf() cannot be virtual (you cannot mix compile-time and run-time polymorphism). Also, static_cast checks at compile-time that T inherits from your base, which also helps; you can eliminate the risk of error by using dynamic_cast (but it has a performance penalty).
Feb
4
comment Why is chaining setters unconventional?
@BoristheSpider: Okay, so that's something CRTP could do in C++ indeed T& set(...) { ...; return static_cast<T&>(*this); }.
Feb
3
comment Why is chaining setters unconventional?
@Useless: Ah, it might. Given that we were talking OO I was expecting virtual methods, in which case the derived class can use a more distinct return type (covariance) however the if you have a reference to the base class you cannot call any derived class setter and I was wondering how Java would make it possible :)
Feb
3
comment Why is chaining setters unconventional?
@BoristheSpider: I don't see how it would translate in C++ or Rust... sounds quite specific :x
Feb
3
comment Why is chaining setters unconventional?
@BoristheSpider: what is this getSelf() thing? Is this specific to a particular language?
Jan
30
comment What's the point of running unit tests on a CI server?
Since you have plenty of good reasons already, might I suggest adding the infamous "oops, I forgot to commit that..."? It's easy to push an incomplete change, the CI server will catch that.
Jan
30
comment Should a C++ program catch all exceptions and prevent exceptions from bubbling up past main()?
@Praxeolitic: I am saying that not all crashes unwind the stack, for example std::abort does not and thus failed assertions don't either. It's also worthwhile to note that on modern OSes, the OS itself will cleanup a lot of resources (memory, file handles, ...) which are tied to the process ID. Finally, I was also hinting at "Defense in Depth": it's unreliable to expect that all other processes are bug-proof and will always release the resources they acquired (sessions, nicely finish writing files, ...) you have to plan for it...
Jan
30
comment Should a C++ program catch all exceptions and prevent exceptions from bubbling up past main()?
If you have some resource that really needed to be restored by a destructor call, you're in a pickle... => Given that (unfortunately) C++ is quite crash-prone, and that's without mentioning that the OS might decide to kill your program at any time (OOM killer in Unix for example), your program (and its environment) need be tailored to support crashes.
Jan
30
comment Should a C++ program catch all exceptions and prevent exceptions from bubbling up past main()?
but crashing is completely unprofessional and unacceptable => spending time working on useless features is unprofessional: crashing only matters if it matters to the end user, if it does not, then letting it crash (and getting a crash report, with a memory dump) is more economical.
Jan
30
answered Should a C++ program catch all exceptions and prevent exceptions from bubbling up past main()?
Jan
29
comment How did you become a const correctness convert?
@Giorgio: I've explored it, even went so far as buying "Real World Haskell". To be honest I am not thrilled with laziness by default and the many cryptic operators that have sprung up.
Jan
27
comment How can we be certain that the lower components of computer programming like compilers, assemblers, machine instructions, etc. are flawless?
@MilesRout: My point is that Open Source is certainly a necessary condition, but that it is insufficient in itself.
Jan
21
comment If a number is too big does it spill over to the next memory location?
@hobbs: The problem is that when the compilers mangle the program because of Undefined Behavior, actually running the program will indeed produce an unexpected behavior, comparable in effect to overwriting memory.
Jan
21
awarded  Nice Answer
Jan
20
comment If a number is too big does it spill over to the next memory location?
@Deduplicator: According to Introduction to the Mill CPU Programming Model there are different opcodes for signed addition and unsigned addition; I expect that both opcodes would support the 4 modes (and be able to operate on various bit-width and scalar/vectors). Then again, it's vapor hardware for now ;)
Jan
20
answered If a number is too big does it spill over to the next memory location?
Jan
20
comment If a number is too big does it spill over to the next memory location?
If you are working on a system with 4-byte ints, and you set an int variable to 2,147,483,647 and then add 1, the variable will contain -2147483648. => No, it's Undefined Behavior, so it might loop around or it might do something else entirely; I've seen compilers optimizing checks based on the absence of overflow and got infinite loops for example...