We do still live in an era where such stupid "performance" question overrule rational hardware and language design.
It's usually insanely difficult to prove that wrapping overflow won't happen. There are exceptions to this, but they usually depend on knowing quite a bit about the higher-level semantics of how the arithmetic operations are being used — for example, it's pretty reasonable to assert that a reference count will never wrap — but you usually can't detect that automatically at the individual operation level except in the trivial case when all the arguments are constants.
That means that once you switch to a non-wrapping strategy for handling overflow, you're either stuck with using saturating arithmetic (which is a useful thing in some cases, approximately equivalent to pegging the meter needle ) or you're having vast numbers of operations become ones that can throw exceptions. Saturating arithmetic is relatively well known in system control software, but is uncommon elsewhere (and requires quite different code to use safely compared to what you're used to) and making everything throw exceptions really stuffs over a lot of optimisations (exceptions are awfully expensive).
So compiler authors dealing with producing code that runs at very high speed are quite reluctant to go that route (as semantics changes and exceptions are both visible and, in the latter case, optimisation-inhibiting). Instead they prefer passing poison values around, representing values that are very problematic if needed, but which will be no problem at all if they can be proved (or asserted!) to never occur. And most of the time that works out for them just fine.
Oh no. That was the MainWindow. There were some more of such abominations in the code base.
I remember such a window in the client program at my first job. I actually brought it up in one of our team meetings. "The Orders form is 15,000 lines of code, and it's basically a big multi-tab interface. It could be made a lot more manageable by refactoring each tab out into a Frame."
Cue panicky reactions by the manager and the architect. "It works; don't touch it! It works; don't touch it!"
Is it possible to get the filename of a file descriptor (Linux) in C?
That's something different, working for a already-opened file. In older linuxes, /proc/self/fd/* will only give you a device/inode pair. In newer linuxes, you can read it for the actual path you originally opened. I don't think any linux gives you the fully canonalized path, as readlink -f does.
Consider these files:
/u -> /a
/a/b -> c
/a/c -> /x
opening /u/b will end up opening /x, but multiple symbolic links at multiple points along the path have to be resolved to find that location, and from C you have to write your own code for that.
Not as much as you might think. It's quite difficult to do (it requires a different design of parser, AIUI) but once you've done the parse, you're just working with a normal function call tree just as you effectively would be with normal operators (which might then be inlined for efficiency reasons).
Yeah, you're speaking exclusively from the computer's perspective. I think it'd be hard for a human to parse if each project in the language can have a different set of operators.
@maciejasjmj That's why the example file has them all commented out. You actually have to pick one from the six or seven they've confirmed won't send individuals sternly worded letters, in which case you're assuming responsibility. But, barring the chaos of the nuclear apocalypse, all of those options work as soon as they're uncommented.
I'm feeling happy with this, and it isn't something I wrote by myself, but we've just got an “accurate” power measurement instrumentation system written at work. It's pretty neat, and generates a nice report at the end of the simulation describing how many Joules of energy were used at each stage of the processing. Right now, we're still in the process of validating it (because we were initially checking with a trivial example simulation so that tests would be very quick) but it's looking good. It'll replace our previous system for doing this, which was a board with an Arduino bolted on the side to do power measurement, which would be fine except that it doesn't sample nearly often enough to catch meaningful detail (also there's only one such board and it appears to have some minor hardware faults).
I wrote the part that actually measures the power usage of the CPUs, taking into account all the tricky bits like possible systematic sampling errors and running at a high enough frequency to be actually able to detect the detailed behaviour of our simulation engine. Which sounds trivial, and sort of is, but tends to cause problems if you don't plug in code to ensure that you do it right.
We're planning to totally brag about this capability in our future papers.
@gwowen also, I should've mentioned that you can click next to the voting buttons on a post and click the "View raw" option; that'll show the markdown that the poster used. If you see anything in a post that you're not sure how they did it, you can use it to find out.
To be fair, most Dwarf Fortress embarks start with Urist McMiner, Urist McCarpenter, Urist McWoodCutter, Urist McMason, Urist McJeweler, Urist McFisher, and Urist McClothesMaker.
That's seven dwarves, although generally you don't get Urist McDonald until much later in the game unless you're unlucky and the king dies and one of your starting seven was their son or daughter or something.
When compiling programs that use the BGL, be sure to compile with optimization.
Why would it be important to enable optimization when compiling programs that use the library? How the heck are you supposed to debug code that uses it? I can understand turning on opt for speed, but the way it's written makes me think they need it for correctness, which is totally crazy.
I guess it's not for correctness, as it is for practical usability. When every character of source code translates into 200 lines of code with 20 nested function calls, you either enable inlining and monomorphization, or end up with hello world that takes 20 seconds to execute and leaves behind 200MB object files
I bet it's a matter of time before someone points out your first conditional and branch is redundant given the second conditional and its branch.
Hush you! I was just trying to keep the code simple while still providing an example of where there was only one conditional statement in the parentheses, which is a case in which I am okay with there being no spaces within or around the parentheses.
And that, kids, is why distinguishing nullable references from non-nullable ones in the type system is a good thing.
I don't see how that would actually affect this. If I understand the code correctly it's attempting to retrieve the member from a service of some kind. Which means that you would have to always have a nullable reference returned from that method, since you could be attempting to retrieve an object that isn't there. The only reason I assume the code says that it should never happen is that the author of the code either assumed that nothing would remove the member between calls, or was assuming some sort of transactional guarantee that is no longer true.
Which is why the error should be a custom exception type, with a description of what's actually wrong. Everything is wrong with the branch of logic that throws this exception.
@aliceif That's up there with the errors you can get in Java when you start really messing around with classloaders; things like (paraphrased) “can't call method; expected class a.b.c.Foo but found class a.b.c.Foo”. The first time you see those things, you totally go but the key is that classes in the JVM aren't just distinguished by name, despite what the errors say…
In my first example, the beetle is even created externally. It is requested.
In my second example, the beetle is explicitly created by the parent.
In neither case should the beetle be injected.
In your case, you should probably inject a factory.
public class Beetle
private SingletonService _service;
public Beetle(SingletonService service)
_service = service;
public class BeetleFactory
private SingletonService _service;
public BeetleFactory(SingletonService service)
_service = service;
public Beetle MakeBeetle()
return new Beetle(_service);
public class CreatorClass
private BeetleFactory _factory;
public CreatorClass(BeetleFactory factory)
_factory = factory;
public void DoStuff()
var beetle = _factory.GetBeetle();
// at composition root
var mainObject = IoC.Resolve<CreatorClass>();
Which makes me wonder: I should really check to see if it still fucks the Task Manager reporting of the current clock speed. Last time I enabled it on my laptop and it claimed I magically got almost triple the GHz...
Why does the idea of parsing an error message to fix it sound familiar... oh, I did that once...
Database-sourced errors in general are nasty to deal with. Entity Framework, for example, just tosses you a SqlException and it's up to you to unwrap all the inner exceptions and cross-reference the magic error numbers to find out what exactly the problem is - whether you've violated a PK, a check constraint, or just had the DB crap itself in a myriad of possible vendor-specific ways.
@dkf That's the thing where my brain went "looks OK-ish to me, but not egregious enough to scream ". That's as far as I got though, been ages since I learned German and I wasn't particularly good even then...