The Big Programming Thread - Page 68

On July 11 2011 16:23 waxypants wrote:
Your main problem is that the "(N rem 2)" should be the digit added to the left of "Acc". You are adding it to the right. Also, once you figure out how to do that (it's a bit trickier adding the new digit to the left than adding it to the right), I believe your base cases will also need to be fixed up.

10 * (n rem 2) + acc

d2b :: Int -> Int
d2b = d2bh 0 1
d2bh acc _ 0 = acc
d2bh acc k n = d2bh ((n `mod` 2) * k + acc) (k * 10) (n `div` 2)

(n rem 2) * k + acc

On July 11 2011 18:32 uzyszkodnik wrote:
@up

http://php.net/manual/en/features.file-upload.multiple.php ?

On July 11 2011 21:22 tofucake wrote:

I know enough languages to do what I need to do, and I've never had a good enough reason to pick up Python. The fact that tabbing is actually part of the code is one of the reasons I haven't learned it "just because".

On July 11 2011 21:22 obesechicken13 wrote:

I read that.
It's not dynamic.
I still need help and that was a very rude answer.

On July 11 2011 19:34 uzyszkodnik wrote:Not really, the syntax of C++ and C# is similar and telling that c# does teh magic and c++ doesnt is false - it all depends on what libraries you use in c++ ( yep you can even have garbage collector in c++ ) . The main difference is speed of execution, nothing else.

On July 11 2011 20:35 heishe wrote:
Also, in real-world applications, even just decent C/C++ code will produce much, much faster applications.

plus C/C++ compilers (and linkers for link-state optimization) are just miles ahead of C#/Java compilers/interpreters in terms of code optimization (For example, the compilation step in javac doesn't optimize the code at all) so it's much easier to make performance costly mistakes in C#/Java than in C++.

So in the gaming market, where AAA titles have to be optimized to the last bit in order to show awesome graphics on relatively weak hardware (360/PS3, etc.) people are of course going to use C++ (indie devs still use C# with XNA on the 360 though, since the C++ SDK for 360 is only available for lots of money and AAA developers).

On July 11 2011 21:33 delHospital wrote:
Once you get used to it, you'll be like "ughh, I can't look at these disgusting brackets".

On July 11 2011 21:59 uzyszkodnik wrote:



Well have you tried just accesing the array?

On July 11 2011 22:11 EvanED wrote:

That just isn't true. (I'm one of those C#/Java lobbyists. :-)) We're talking a factor of 2, maybe 3 total. For most real-wold applications, that just won't matter.

Somewhat true, but on the flip side, when you're JITing, you have lots of opportunites to do things that a C++ compiler flat out cannot. Have tight loop with a virtual method call? If you have a JIT you can inline it, because you can look at the dynamic type and pick the right function. A static compiler can't.

On July 11 2011 22:59 japro wrote:

I always like this part of the language discussion where everyone agrees on the facts but weights them differently :D.

And then, quite some polymorphism that is required in managed languages can be replaced by "static polymorphism" via templates in C++ which allows even more aggressive inlining .

This type of listing individual advantages/disadvantages especially when it comes to optimization doesn't really take you anywhere.

On July 11 2011 23:27 EvanED wrote:

Heh. See, I'd save "much, much" faster for comparisons against, say, Python.

Discussing programming languages without the context of an actual application just doesn't make sense. It's like discussing whether airplanes or cars are the better means of transportation without specifying where you want to go. You obviously cant drive overseas while flying to the supermarket would be equally stupid.

On July 11 2011 23:58 heishe wrote:


Yes, I have to add though that I was talking in the context of games, since I believed delHospital was the guy with a learning disability who wanted to get into the gaming industry - which I know see is wrong (I was thinking of RedJustice). Sorry for that.

For general applications, like your average business-suit GUI application, I think the large majority of developers actually use C# or Java since they have superior frameworks to C++ (in terms of usability) in that regard.

On July 11 2011 23:48 japro wrote:
There is no reason why it shouldn't be possible to build a java/C# compiler that optimizes as agressively as a C++ compiler...

void foo() {
    int x = 5;
    print(x);
    double y = 4.0;
    print(y);
}

On July 12 2011 00:31 EvanED wrote:

Well, that's not quite true, unfortunately.
...

On July 12 2011 00:31 EvanED wrote:

Well, that's not quite true, unfortunately.

C++ compilers have the luxury of (1) being able to take as much time for optimization as they want (to a loose approximation) , (2) being less constrained about how what they output behaves, and (3) being less constrained by requirements of the language semantics.

For instance, take the following code:

void foo() {
    int x = 5;
    print(x);
    double y = 4.0;
    print(y);
}

(and ignore for the moment the fact that the complier can do constant propagation).

A C++ compiler can very easily reuse the same memory space for x and y. I'm not 100% positive, but I think this optimization is unavailable to the Java or C# AOT compilers (the ones that go to bytecode) because the variables have different types, and if the compiler did try to reuse memory the resulting class file wouldn't pass the bytecode verifier. Thus as far as the AOT complier has to say about it, the Java version takes more memory for that function. That's where (2) comes in -- a C program that never invokes undefined behavior won't be able to distinguish whether the compiler has shared memory between x and y, but a Java program will (because it will always say "no"). (If you drop the bytecode verifier, IMO you lose most of the point of using a managed language in the first place.)

Well, what about the JIT? The JIT certainly could certainly make that change. But that's where (1) comes into play. The JIT can't exactly perform super heavy-weight dataflow analyses -- because whatever it does is coming out of the runtime of the program. In this particular case it actually probably would be able to share those spots, but there are plenty of optimizations that are too slow to run at runtime.

Finally, what about (3)? Turns out that all the "undefined behavior" in C++ can lead to optimization opportunities not available to Java/C#. Of course, the most obvious one of these is buffer checks. Dataflow analysis can certainly establish that some buffer checks are not needed. (Though you have to keep in mind constraints (1) and (2) -- the AOT compiler can't omit them (in fact they aren't even explicit, so there's not even a way to omit them even if javac wanted to) and the JIT has to do its analysis at runtime.) But there are still lots of times when it can't, and those checks are going to make your Java/C# program slower.

There are more subtle ones as well. For instance, Java's semantics guarantees that integers are represented as 32-bit two's complement, and that, for example, INT_MAX+1 will overflow around to INT_MIN. So for instance, the check if (x+1 > x) is functionally equivalent to if (x == INT_MAX). C++ makes no such guarantee. Compilers can and do optimize that condition to true (and then of course optimize away the if statement entirely).

Chris Lattner of the LLVM project has posted a wonderful series of blog posts about this topic, and the benefits and drawbacks of these types of optimizations. This post by John Rehger is also quite good.