Reputation
5,716
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
2 18 33
Newest
 Nice Answer
Impact
~350k people reached

1d
awarded  Nice Answer
Aug
28
comment Why use an opaque “handle” that requires casting in a public API rather than a typesafe struct pointer?
@JonathonReinhart: Note that I created two different struct, and specifically avoided plain typedef.
Aug
28
comment Why use an opaque “handle” that requires casting in a public API rather than a typesafe struct pointer?
@rwong: It's only an issue in naive scheme; you can easily integrate an epoch counter, for example, so that when an old handle is specified, you'll get an epoch mismatch.
Aug
28
comment Why use an opaque “handle” that requires casting in a public API rather than a typesafe struct pointer?
@JonathonReinhart: Well, since the library already provides handles, I did not feel the need to expand. Indeed there are multiple approaches, from simply converting the pointer to the integer to having a "pool" and using the IDs as keys. You can even switch approach between Debug (ID + lookup, for validation) and Release (just converted pointer, for speed).
Aug
28
answered Why use an opaque “handle” that requires casting in a public API rather than a typesafe struct pointer?
Aug
22
awarded  Nice Answer
Aug
21
reviewed Approve arm tag wiki excerpt
Aug
21
reviewed Approve Automatically reverting commits that fail the build
Aug
21
answered Automatically reverting commits that fail the build
Aug
21
comment Automatically reverting commits that fail the build
@CarlosCampderrós: I would personally never have a setup that attempts to revert commits; much too complicated.
Aug
21
comment Automatically reverting commits that fail the build
What if the build succeeds on the feature branch, but fails after the merge?
Aug
20
awarded  Good Answer
Aug
18
awarded  Great Answer
Aug
17
comment Is it better to call a function that doesn't have an effect at that point, IF it improves code clarity?
@Tonny: I don't know if encouraging the use of a global variable is "doing it right", but indeed if you know exactly which was active before, you need only update two views. Another solution is for each view to remember its visibility and for setVisibility not to do anything if the visibility is already the one requested, which moves the responsibility down.
Aug
17
awarded  Guru
Aug
17
awarded  Good Answer
Aug
17
awarded  Mortarboard
Aug
17
comment Is it better to call a function that doesn't have an effect at that point, IF it improves code clarity?
@Kevin: It depends really. Sometimes you can solve the issue by iterating over a collection, sometimes not, but the key principle is to avoid duplication and to make it easy to preserve invariants. The more "manual" actions need be remembered for things to work properly, the less chances you have that things will work properly. I hate to be vague here, but there are so many different situations that I am afraid a "generic" rule would just lead you astray.
Aug
17
awarded  Nice Answer
Aug
17
answered Is it better to call a function that doesn't have an effect at that point, IF it improves code clarity?