Anaphase

[luiscubal]

Java is written in C, but so is GCC. I could write a C compiler in Java too, and that wouldn't necessarily make C run slower than Java.
Java is nowadays typically compiled.

As for buffer overflows, consider this code in C.

Code: [Select]

char x[100];
char inTrustMode = isInTrustMode();
//...
gets(x);
//...
if (inTrustMode) {
 //Do trusted(unsafe) operation
}

In this example, what happens if you input a 100th character. This is a typical C security vulnerability. I believe GCC even outputs a warning for using gets. Maybe it's just gets that's badly designed, but the fact is even strcpy has an associated security vulnerability.
Now, C++ might have improved the situation for strings, but the remaining types of arrays are still unsafe.
In Java, this is a Out of bounds exception and that's the end of it. So, you get a nasty exception(that can be caught) instead of having malware installed in your computer.

Last time I tried, I could use try/catch in C++ without the double underscore prefix. It still can't catch out of bounds.

they probably just had written it better in Java than in C

Then you're saying the application code matters more than the language. And, in that case, I'd rather be solving problems(and coding better) than being stuck with C.

GTK, Qt, and wxwidgets are in that category.  So are WinAPI and XLib.

Of all your examples, only wxWidgets(and possibly Qt) are worth discussing. XLib was a particularly miserable example.
However, I'll grant that Swing is less than optimal, and C# GUI is not-so-brilliant if you need cross-platform.
However, Java+Swing coding is simpler than C+wxWidgets. With the time I get left, I can actually figure out where/why my code is being slow and optimize the parts that matter, instead of trying to reinvent the wheel or recompile some C++ library, so the end user gets an application that's safer, faster and - most important of all - is actually released!

Regarding IDE writing, Java code is more predictable than C++ code.
For instance, consider the following pseudo-code(translate it to Java and C++ in your mind):

Code: [Select]

class Foo{
 Content goes here
}

what is that? A Java IDE would correctly assume it is a class. A C++ IDE *could* try to assume it is a class. However, the C++ IDE first needs to be sure(in order to be accurate) that this particular piece of code does not appear:

Code: [Select]

#define class enum
Which, guess what, is valid C++.
Also, the above code could be in a header file of its own, so I could have:

Code: [Select]

#define class enum
#include "Foo_definition.h"
So when editing Foo_definition, there'd be absolutely no reference to the class definition as enum.

The C++ IDEs can, therefore:
 - Incorrectly assume that all classes are classes. I believe most IDEs do this.
 - Check for #defines in the same file. As I showed earlier, this is not always correct behavior.
 - Infer usage based on previous compilations. This does not work on the first time and works badly when headers are used in multiple contexts.
 - Implement some fancy system that's not intuitive(hence nobody will use your IDE), takes 3 years to theorize, 5 years to understand and another 4 years to implement, and takes O(n^n) time to run, making even IE6's JScript look fast.

Besides, Pinta, Tomboy and F-Spot aren't very good, nor are they fast.

I provided examples, which was what I was asked to do.

Some citations:
http://en.wikipedia.org/wiki/Buffer_overflow :

Programming languages commonly associated with buffer overflows include C and C++, which provide no built-in protection against accessing or overwriting data in any part of memory and do not automatically check that data written to an array (the built-in buffer type) is within the boundaries of that array.

The Java and .NET bytecode environments also require bounds checking on all arrays. Nearly every interpreted language will protect against buffer overflows, signalling a well-defined error condition.

http://golang.org/doc/go_faq.html
Go features fast compilation (as opposed to C) as a language feature. So it obviously isn't just for me that it matters.

[Rusky]

C/++ doesn't have out of bounds exceptions because it doesn't check. In Java/C#, there is no way not to check, so arrays will always be slower. In C/++, you can use vectors, which are closer to Java/C# arrays. Not to re-open this discussion, but none of these language have the best solution here. You either get runtime checking or no checking.

[retep998]

C/++ doesn't have out of bounds exceptions because it doesn't check. In Java/C#, there is no way not to check, so arrays will always be slower. In C/++, you can use vectors, which are closer to Java/C# arrays. Not to re-open this discussion, but none of these language have the best solution here. You either get runtime checking or no checking.

Exactly.
So it's a choice
sacrifice safety for speed
or speed for safety
I prefer speed, since I take the time to ensure my code works well, and if i want to segfault my computer, I WANT TO BE ABLE TO DO IT WITHOUT ANY RUNTIME CHECKS STOPPING ME!!!

[Rusky]

No, you misunderstand. In C, C++, Java or C# you get either runtime checking or no checking. There is a third choice- compile-time checking. I'm not saying you shouldn't have a choice; you should, you need it for things like drivers and kernels. However, C/++ is just as braindead as Java/C# in this regard.

[retep998]

Well, it looks like we're split into 3 groups here.

1. The c++ group. They want to have fully compiled exe's with no runtime checks wasting time.
2. The java group which hates the freedom of c++, and wants runtime checks to keep everything safe and slow. (just like the tortoise, slow and steady wins the race...)
3. The whateverruskyissupportingidontknowwhattocallit, where everything is checked at compile time, and whatever benefits rusky claims it has. I'm not very well educated on this area.

[serprex]

Rusky is into solving the halting problem

[Rusky]

@retep: No, not really. Nobody hates the freedom or speed of C++, so I suggest you stop being a moron and blindly following everyone else. It's really more of the C++ group which wants fully compiled exes with no runtime checks because they heard that's the fastest and they only care about speed, and the smart group which actually thinks about what they say.

C++ is only one way of going about things. It does some things badly and some things well. Neither is perfect, and despite popular opinion here, the same is true of Java- it is not completely worthless. There are also other ways to do things that neither C++ nor Java use, which also have their own advantages and disadvantages.

[Micah]

Rusky is into solving the halting problem

Proving all indices to be in-bounds at compile-time is perfectly possible.

Retep, I would suggest that you shut up, go away and stop worshipping every stupid little thing that Josh says, and go actually learn how to program.

[Josh @ Dreamland]

"Proving all indexes to be in-bounds at compile-time is perfectly possible."
Given a large number of conditions are met, sure.

"C++ is the best PERIOD"
Don't put words in my mouth. C++ is the best for me.

[Micah]

Given a large number of conditions are met, sure.

I'm not sure what you mean. Please elaborate.

Also, C++ is the best for you because you're a Blub programmer.

[luiscubal]

Well, I believe Josh meant this:

Code: [Select]

int x = get random number between 1 and 10;
int[] y = new int[x];
y[5] = 3; //Is this OK?


[Micah]

That code would be proven to have the possibility of out-of-bounds indices.

This code would not have that possibility:

Code: [Select]

x = get random number between 1 and 10
y = array[x]
if x >= 5
  y[5] = 3
else
  do something else

[Rusky]

@Josh: You can't know it's the best for you because you haven't tried the alternatives. All you can reasonably claim is that it's the best for you out of what you've used, which doesn't include any of the stuff we're talking about.

The reasoning behind dependent typing is that the compiler finds possible bugs. Luiscubal's example has a possible bug, so the compiler would find it and either error until you fixed it like miky's example, or insert it's own check. The compiler could always behave one way or behave one of those ways depending on a compiler switch or something in the code.

[luiscubal]

Assuming your arrays are 0-started, but I get your point.
Although possible, that's notably hard.
There are two possible choices for that:
 - Have a really REALLY strong type system.
 - Have an amazingly efficient type inference system.

Neither are possible with C nor Java.
So instead of "C is perfect" or "C and Java are the best choice in different cases", we got to "both C++ and Java suck".

That requires a specific paradigm of programming languages that, for some reason, never really became mainstream.
That particular paradigm is really annoying to program in(since very often it is terribly hard to find out the code possibilities, and we end up with annoying errors), but also really bug-safe. Once again, we have something that's more adequate in some cases than others.

[Rusky]

... not really? You could add dependent typing to C. That particular example would require no extra code, just a better compiler. The only extra code required in general would be type annotations. However, these annotations would actually be useful, rather than just mindless "int" or "float." You would, for example, tell the compiler that random can generate numbers between 1 and 10 (or its arguments, or whatever it does return numbers between). Depending on the implementation, even that wouldn't always be required.