206 karma · joined January 15, 2011
So, sorry, but this isn't exclusive to large companies.
I don't think this really does much for customers except make it harder to fully enjoy the game. "Sign into our network for a free exclusive item/map!" - no thanks.
Maybe he's talking about restrictions about releasing free content on Xbox Live (you're supposed to charge for pretty much anything)?
One time we wrote a quite complicated graph-based algorithm (as in, lots of bug potential, but it turned out bug free) and the other two times we fixed bugs that hounded us for weeks in just one session.
I definitely feel like it works best in those situations when both people can complement each other somehow. If it's just a junior/senior person it will probably not be very useful for the senior person (note I mean a true junior here with little programming experience, not just some non-senior engineers).
Would've been nice to see that news a few weeks ago, then today's acquisition wouldn't have been so out of the blue.
Closed source = no good for privacy.
that way it will fail extremely rarely and be even harder to detect!
Then again, hard drives return minimum sized blocks of data anyway, which is sized in kilobytes. So I'm guessing the "skipping" is a performance benefit only as so far as user space goes.
One would really have to grep a long string to be able to skip more than a block/page!
2) You can't actually use an xbox controller with a computer (and hence with firefox) anyway without a USB cable. You could use a 360 controller, but not the first Xbox.
It would've been nice to drill down why mmap makes a difference in particular, why not use something like lseek to skip characters?
It's too easy for the web developers to just point the memory leak blame to the browser and none of the users will be the wiser.
If some day in the future there's an extremely easy way to figure out which sites are using how much memory (each tab in a process?) then we could start seeing some push back for JS leaks to be fixed.
Then again this is dealing with system-wide performance. Application-specific performance should be significantly less of a problem to fix.
I think the jobs that are simply "here is this function, make it 10x faster" would be pretty rare, since usually people don't know what part of the code is going slow. A lot of the times they'll guess "X, Y, Z is making it slow" but without a real performance analysis patching stuff all over the place just doesn't pan out.
volatile int b = 23;
if (a + b < b) overflow;
Tada. That's how you get around the GCC optimization issue in practice. I suppose though this doesn't suite as a proper answer since overflowing as a result of adding two signed integers results in undefined behavior..The solution is to cast the integers to unsigned and then do the overflow check. The following two standard sections should demonstrate the standards-compliance of the code below.
> ANSI C99 6.2.5 Types #9
> A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.
> ANSI C99 6.3.1.3 Signed and unsigned integers #2
> Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.
---------
// shift the MSB to the LSB
#define signof(x) (!!((x) & INT_MIN))
int x, y;
// bits stay the same thanks to 6.3.1.3
unsigned int a = (unsigned int) x;
unsigned int b = (unsigned int) y;
unsigned int sign_a = signof(a);
unsigned int sign_b = signof(b);
// a+b should have the same sign as a and b, otherwise an overflow/underflow has occurred
// note that a+b is well defined for unsigned ints according to 6.2.5 #9
if (sign_a == sign_b && signof(a+b) != sign_a) overflow;
The code for checking overflow on unsigned ints is trivial: unsigned int a, b;
if (a + b < a) overflow;Well, good for him I guess? But how is that news?
The advantage of C++ is knowing exactly what happens when, and being able to tightly control the memory footprint. If that's not the requirement, I see no reason to spend extra effort on the language's verbosity.
That being said, the only feature D seems to really have that C++ doesn't (besides gc) is compile time reflection aka traits (granted, it's possible to derive some of those like boost traits, but for others like virtual function detection it's impossible without compiler support).