Reputation
4,543
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
10 19
Newest
 Nice Answer
Impact
~396k people reached

  • 0 posts edited
  • 0 helpful flags
  • 195 votes cast
Jan
28
comment Should we avoid language features that C++ has but Java doesn't to increase maintainability?
For awhile, browser support for Java applets was better than for C++ applets. Browser support for JavsScript (no relation to Java), however, has improved enough that it's basically taken over from both.
Jan
28
comment Should we avoid language features that C++ has but Java doesn't to increase maintainability?
Yup. If it becomes necessary to support a platform which supports Java but not C++, parts of the code will almost certainly have to be rewritten from scratch and it won't matter whether those parts had been written using some Java-friendly techniques, since they'll be rewritten anyway. It may be possible to write other parts, however, in a way that would allow them to be migrated without a full rewrite, and in some cases the extra cost required to do so may be minimal.
Jan
28
comment Should we avoid language features that C++ has but Java doesn't to increase maintainability?
Many C++ features can be used in some ways which map nicely to Java concepts, and other ways which don't. Some parts of a program are going to require something outside the overlapping subset of the languages' functionality, and attempting to write such parts as "Java using C++ syntax" is going to yield a horrible mess. On the other hand, many other parts of the code may need anything outside the shared subset, and trying to stay within the shared for those portions of the code where there's no compelling reason to go outside it may be helpful.
Jan
26
comment Can the “level 256 bug” in the game of Pacman be considered an unhandled segfault?
@ardaozkal: Donkey Kong includes code to cap progress at L99, but a bug in the bonus-timer calculations makes it impossible to get that far. Why do you think Pac-Man has such a limit?
Jan
26
comment Can the “level 256 bug” in the game of Pacman be considered an unhandled segfault?
@ardaozkal: I personally can't even get to level 6 on an unmodified machine, much less 256, but so what? Many people can reach level 256 without losing a life on any level prior to that, so there's no need for an "extra life" hack to reach level 256--just to clear it.
Jan
26
comment Can the “level 256 bug” in the game of Pacman be considered an unhandled segfault?
@ardaozkal: How many lives are required to clear the level, and how many lives can a player get on an unmodified machine?
Jan
26
comment Can the “level 256 bug” in the game of Pacman be considered an unhandled segfault?
@Zibbobz: Given unsigned char table[15], an attempt to read a few hundred bytes beyond the end of table would generally only cause a segfault if table happened to be very near the end of a segment. It's likely that code on a modern machine would have used a uint32_t rather than a uint8_t for a counter, and thus overrun the expected loop end by more than 256 iterations, but the only ill-defined aspect of the code was reading past the end of a table. The excess writes hit parts of the screen they weren't expected to, but those areas were perfectly legitimately writable.
Jan
26
comment Can the “level 256 bug” in the game of Pacman be considered an unhandled segfault?
@ardaozkal: The level-draw routine erases more than 100 dots and draws a few. If a player had enough lives, it would eventually be possible to eat enough dots to advance a level, but that would require more than 30 lives.
Jan
26
comment Should we avoid language features that C++ has but Java doesn't to increase maintainability?
My point is that some features in Java aren't included in C++, but rather that some features of Java are fundamentally incompatible with other features that are included in C++, such that no language could have types that support both (languages like C++/CLI have types that support C++ features and types that support Java-ish features, but they effectively inhabit separate universes with limited interoperability).
Jan
25
comment Can the “level 256 bug” in the game of Pacman be considered an unhandled segfault?
@LawrenceC: The level number isn't an index; the problem is with code that basically says "unsigned char n=level; if (n>7) n=7; *src = fruit_shape; *dest = fruit_loc; do { *dest++ = *src++;} while(--n);`. Drawing 256 fruits overwrites part of the screen that should contain dots, but has no other adverse effect.
Jan
25
answered Can the “level 256 bug” in the game of Pacman be considered an unhandled segfault?
Jan
25
comment Should we avoid language features that C++ has but Java doesn't to increase maintainability?
Java offers some features and guarantees which would be unsupportable in a language which offers all the features of C++. A language cannot, for example, allow dynamic type loading and Java's full range of identity-preserving casts while offering the generalized forms of multiple inheritance included in C++.
Jan
25
answered Is it acceptable to copy and paste long but straightforward code instead of wrapping them into a class or function?
Jan
25
awarded  Good Answer
Jan
24
revised If I use locks, can my algorithm still be lock-free?
Corrected "lock-free" versus "non-blocking"
Jan
24
comment If I use locks, can my algorithm still be lock-free?
@MarkoTopolnik: I'll edit the post to fit that then. Do you like the new version?.
Jan
23
comment If I use locks, can my algorithm still be lock-free?
I've seen inconsistent terminology usages, and I don't know of an "official" standard. What's most important is that there are different guarantees an algorithm may be able to offer, and it's important to use an algorithm which offers guarantees sufficient to meet application requirements. Many papers only cover some of the guarantees above, but there are cases where each may be be able to satisfy application requirements more easily than any other guarantees which would meet requirements.
Jan
21
comment If I use locks, can my algorithm still be lock-free?
@BenVoigt: Instead of saying "Excluding acquiring any other lock" should more accurately be written as "Excluding any operation whose completion might require actions by any other thread that can't be relied upon to perform it in bounded time."
Jan
21
revised If I use locks, can my algorithm still be lock-free?
added 316 characters in body
Jan
13
comment When are Getters and Setters Justified
I'd suggest a third type: a mutable container, whose purpose is to hold one or more values; in many cases, a container should not be expected to have much in the way of logic or validation. Code which needs a method to compute six positive integers may pass a container for six integers to the method which will store the results therein. Responsibility for ensuring the numbers are positive should generally lie with either the caller or the called method, not with the container.