|
retep998
|
|
Reply #31 Posted on: April 07, 2010, 10:40:52 am |
|
|
Location: Where else? Joined: Jan 2010
Posts: 248
|
@retep Incorrect. Your behavior is unspecified. Are you sure it is the first element(0)? Why not the second? The fact it is UNDEFINED. It may indeed give the result you think. But you can NEVER be sure. C doesn't specify it. One compiler may give the result you predict. Different compilers or different optimization flags may give different results.
y++ returns the current value of y and then increments it for the next statement. ++y increments y and then returns the new value for the current statement. If a compiler behaves differently, then it needs to be fixed. Just because YOU don't know this rule, doesn't mean a compiler doesn't. http://www.cplusplus.com/doc/tutorial/operators/go down to the Increase and decrease (++, --) section
|
|
« Last Edit: April 07, 2010, 10:43:28 am by retep998 »
|
Logged
|
|
|
|
|
retep998
|
|
Reply #33 Posted on: April 07, 2010, 11:38:51 am |
|
|
Location: Where else? Joined: Jan 2010
Posts: 248
|
The problem is not increment. The problem is using an incremented variable again in the same statement. Knowing if it is incremented or not is undefined. It's not a specific compiler that sucks. It's the C STANDARD that sucks.
When you have a suffix increment it increments the variable AFTER that statement is finished. so even if I did x[y++] = y; it should still behave the same because the increment only applies after the statement. If i did x[++y] = y; or x[y] = ++y; then the code will first increment y, and then go on to executing the statement. If you can compile this code 2 different ways and provide 2 exes which behave differently, but with the same code, then I'll believe you.
|
|
|
Logged
|
|
|
|
|
score_under
|
|
Reply #35 Posted on: April 07, 2010, 01:58:18 pm |
|
|
Joined: Aug 2008
Posts: 308
|
int x[5]; for (int i = 0; i < 5; ++i) x[i] = 0;
int i = 1; x[i] = i++; printf("0=%d;1=%d;2=%d\n", x[0], x[1], x[2]); getc(stdin);
Causes a -Wall warning: "operation on 'i' may be undefined"
In theory yes, but in practice it's always executed the same. On a lower warning level, you can get the warning "warning: no newline at end of file" - doesn't mean that your code is going to break on some random compiler. Also, who the hell codes like that anyway? You want C undefined behavior? This, for instance:
int x[3]; int y = 0; x[y] = y++;
Different compilers may give different results. In fact, the same compiler may give different results for that same code.
Right, let's see: x[y]=y++; That means "set x[y] to y, then increase y". y is zero at the time this command is executed. Let's see what we get from different compilers. int main() { int x[3]; int y = 0; x[y] = y++; printf("%u,%u,%u\n",x[0],x[1],x[2]); }
GCC: 0,4199264,2359160 BCC: 0,256,1 MSVC++: 0,3435973836,3435973836
|
|
« Last Edit: April 07, 2010, 02:33:23 pm by score_under »
|
Logged
|
|
|
|
luiscubal
|
|
Reply #36 Posted on: April 07, 2010, 02:32:32 pm |
|
|
Joined: Jun 2009
Posts: 452
|
Anyone before learning that it is undefined behavior. That buffer overflows, segmentation faults and stack overflows are undefined behavior, I can understand, but is the performance benefit of leaving this undefined really that much?
Either way, undefined is undefined. This would be a perfectly legitimate-looking code. So this blows up your whole "predictable" point: C++ is either as predictable as, or less predictable than, Java and C#.
Here are our points so far: - C/C++ is faster than, Java/C#, although computers now are much faster than computers when C was invented and either way JIT means Java/C# speed isn't really that bad. - C/C++ has basically no API(stdio, iostream, match, etc. are hardly enough). Java/C# have big, useful, unified APIs. Somehow, you think this is an advantage for C/C++. I think it's an advantage for Java/C#.(we're not in the runtime size issue yet here) - C/C++ has no built-in garbage collector, although bad-quality garbage collectors, so programmers are forced to deal with complex memory leaks/segmentation faults situations. Java/C# have mandatory first-class garbage collectors. You claim C++ is better because (supposedly) this is faster and gives you more freedom. I think the freedom claim is bogus since people don't want to deal with language stupidities when they are solving real problems, so the only thing here is the perceived speed advantage. This difference is negligible. Also, garbage collectors(particularly of JITed languages) know what they are dealing with(hardware) so they can optimize for specific caches and avoid memory fragmentation(which native malloc/free are bad at), so the GC is not really the bottleneck of these languages' speed.
When an application is slow, it is more likely an algorithm problem(such as using O(n^3) when a log(n) solution exists) than a language problem. It is important to note that we are talking in a game-related forum, where speed(frames per second) is particularly important, which is a possible excuse for your excessive obsession with speed. Aside from games, very few problems suffer from garbage collection/speed issues. Usually, development costs and Moore's law are enough to justify using Java/C#(and, once again, Java/C# aren't as slow as you might think).
The "consumes more memory" issue is very similar to the speed issue.
Anyway, going on:
- C/C++ have a (relatively) small runtime(libraries, etc.), while Java/C# have big runtimes. In terms of available hard disk space, this issue is irrelevant, in terms of internet bandswidth, I understand your problem. Either way, many computers come with Java/.NET so, in the end, the size of the runtime(in terms of what the end-user has to download) is about 0. Also, C++ executables can get really big with things like templates, and those can't come with the computer(C++ ABIs is hell, while C/Java/C# ABIs are relatively easy to manage. By the way, "ABI" means "Application binary interface", for those who don't know: it's kind of like APIs, but for compiled applications).
Things I hope to have proven as false: - "Java/C# are interpreted so they can't be faster than C/C++": Even if Java/C# are indeed as slow as you claim it to be, Java/C# are NOT typically interpreted. They are JIT compiled. In fact, there are AOT compilers for C#(this is how Mono allows C# applications to run on the iPhone, where compilation and interpretation are forbidden by Apple). This happens regardless of *.class and *.dll files. - "C is more predictable than Java": Java has less undefined behavior situations than C, and both are clearly defined in their own specifications, so Java is either as predictable or more predictable than C. So "predictable" in NOT the word you want. Perhaps you say you like being able to do stupid things and that C doesn't attempt to stop it. I don't see how this is an advantage, but indeed C allows that. This is not being "predictable". - "C/C++ is the best possible language for all possible situations": This is incorrect. C is a language that's best used in some cases, and particularly bad in others. If you're writing a kernel, a driver or you're on a microcontroller with 8KB of memory, then C or Assembly are probably the only reasonable choice. If you're developing some Math simulations, which don't need to go super-fast but indeed need to be drafted fast - then C is a horrible choice. Depending on the kind of simulation, functional languages or languages like Python are far better. If you want to do web design, where multiple layers of security and fast development cycles are more important than saving a few clock cycles, then PHP, Java and/or C# are the best choices(and, in this field, C# is really competitive relatively to competition). Once Josh admitted the possibility of using V8, he implicitly admitted he couldn't use C for everything(V8 is in C, but it executes JavaScript). For desktop applications where you have a fast-moving competition and need to provide features rather than being for hours trying to find out that annoying memory leak that's taking 100MB of memory(which is far more than what a GC consumes and, yes, it happens in C because people aren't perfect), then Java/C# might indeed be better than C.
|
|
|
Logged
|
|
|
|
|
luiscubal
|
|
Reply #38 Posted on: April 07, 2010, 03:00:38 pm |
|
|
Joined: Jun 2009
Posts: 452
|
I did program in ASM, and I just f***ing said C is too low-level, and you want me to code in Assembly? If that's the point, then you should be doomed to code for eternity in Lisp, without ever being able to go back to C.
And apparently, 90MB GCC API aren't very good. So it appears Java and .NET make better use of its space. Also, we're talking about convenience here. It's not about being just sloppy. A sloppy programmer can be a bad C# programmer as well(although arguably less dangerous?), but programming a field that responds badly to throwing more people at a problem, so managing human resources efficiently is critical. And having programmers(even brilliant programmers) spend 10x more time to do the same is NEVER efficient human resource management. Not except in the few relatively rare situations I mentioned above.
Different languages have different advantages. I *AM* able to code efficiently in Assembly and in C. I can code in multiple paradigms(the only one that's relatively hard for me to use is functional paradigm like what Haskell and Scheme use, but I am still able to code in Scheme!). Different problems are better handled differently. I can choose the language that fits the problem better. And, in fact, I have picked C++ in the past, I currently use it, and I will probably continue to pick it in the future when the problem I am faced with are best solved in C. However, I have used, I am using, and I will use in the future other languages(including Java and C#) when the problem is best solved in them. I am a C programmer and I am able to code it efficiently without memory leaks, but that isn't the only thing that matters. Because, like it or not, C isn't perfect.
In contrast, you are so blinded by C that you are unable to see that there is anything useful beyond it. You use C in problems that are best solved in C, and I agree with you there, but you also try to put C in problems that would be better solved in C#, PHP or Lua. I think that's not being a good programmer. A good programmer uses the right tool for the right job. You use a sledgehammer for everything - fixing tables, opening doors, traveling to other places, everything - and indeed sledgehammers can, with some creativity(somehow) do all that, but the right tools for the right job is still the best choice.
|
|
« Last Edit: April 07, 2010, 03:11:26 pm by luiscubal »
|
Logged
|
|
|
|
|
|
score_under
|
|
Reply #41 Posted on: April 07, 2010, 04:31:12 pm |
|
|
Joined: Aug 2008
Posts: 308
|
Actually, power kept going out and I couldn't be bothered to write another overly-complicated response. Not arguments: I did program in ASM, and I just f***ing said C is too low-level, and you want me to code in Assembly? If that's the point, then you should be doomed to code for eternity in Lisp, without ever being able to go back to C. Different languages have different advantages. I *AM* able to code efficiently in Assembly and in C. I can code in multiple paradigms(the only one that's relatively hard for me to use is functional paradigm like what Haskell and Scheme use, but I am still able to code in Scheme!). Not arguments and flawed anyway: In contrast, you are so blinded by C that you are unable to see that there is anything useful beyond it. You use C in problems that are best solved in C, and I agree with you there, but you also try to put C in problems that would be better solved in C#, PHP or Lua. I think that's not being a good programmer. A good programmer uses the right tool for the right job. You use a sledgehammer for everything - fixing tables, opening doors, traveling to other places, everything - and indeed sledgehammers can, with some creativity(somehow) do all that, but the right tools for the right job is still the best choice. Supporting C doesn't mean I use it for everything. Flawed: And apparently, 90MB GCC API aren't very good. So it appears Java and .NET make better use of its space. Now, assuming you're using C++ with GTK, what can Java do that C++ can't? Also, we're talking about convenience here. It's not about being just sloppy. A sloppy programmer can be a bad C# programmer as well(although arguably less dangerous?) Yet you never took this into account in most of your arguments against C++. I am a C programmer and I am able to code it efficiently without memory leaks, but that isn't the only thing that matters. Because, like it or not, C isn't perfect. It's perfect enough that I haven't found any genuine flaw with it yet. Actual arguments: but programming a field that responds badly to throwing more people at a problem, so managing human resources efficiently is critical. And having programmers(even brilliant programmers) spend 10x more time to do the same is NEVER efficient human resource management. Not except in the few relatively rare situations I mentioned above. Etc.: Different problems are better handled differently. I can choose the language that fits the problem better. And, in fact, I have picked C++ in the past, I currently use it, and I will probably continue to pick it in the future when the problem I am faced with are best solved in C. However, I have used, I am using, and I will use in the future other languages(including Java and C#) when the problem is best solved in them. Example of when Java is better than C++?
|
|
« Last Edit: April 07, 2010, 04:49:08 pm by score_under »
|
Logged
|
|
|
|
luiscubal
|
|
Reply #42 Posted on: April 07, 2010, 04:42:49 pm |
|
|
Joined: Jun 2009
Posts: 452
|
Now, assuming you're using C++ with GTK, what can Java do that C++ can't? This whole thing has never been about possibility. Possibility is not enough. Both languages are turing complete. But Java is so much simpler and easier to use(less problems to worry about, and less things to keep track of, such as allocated variables), so when both languages fit, why spend 10x more time in C? If C is so perfect, explain why the Vala project exists. Vala is essentially syntactic sugar for C. It turns code of a Java-like language(Vala) into C. I'm perfectly fine with languages like that. It's obviously possible to do everything Vala does in C, but Vala is still nicer to use(I'm supposing Vala is as easy to use as Java and C#, but I haven't actually used it so I can't be sure). Supporting C doesn't mean I use it for everything. Care to enlighten us with other things you use(aside from ASM, that is) and for which problems you use it? Are you forced to use those other languages or do you do it on free will? If you use other languages on free will, then maybe that'll help you understand why people pick other languages(but I'll have to wait for your reply to know if this is the case). It's perfect enough that I haven't found any genuine flaw with it yet. What about: but programming a field that responds badly to throwing more people at a problem, so managing human resources efficiently is critical. And having programmers(even brilliant programmers) spend 10x more time to do the same is NEVER efficient human resource management. Not except in the few relatively rare situations I mentioned above. If you have to keep track of your variables to prevent memory leaks, and if you have to waste time picking libraries for something as basic as strings, then you might indeed take 10x more time in your C project than you would in Java/C#. I think this is one of the reasons Java and .NET exist and became so popular(aside from marketing of course). Example of when Java is better than C#? The existence of standard GUI libraries(Swing is more "standard" than WinForms). But... huh... are you sure this is what you meant? Don't you mean "Example of when Java is better than C"? If that's the case, see above.
|
|
« Last Edit: April 07, 2010, 04:55:48 pm by luiscubal »
|
Logged
|
|
|
|
|
Micah
|
|
Reply #44 Posted on: April 07, 2010, 07:06:46 pm |
|
|
Joined: May 2008
Posts: 128
|
score_under's arguments for C and assembly: It's Turing-equivalent. That means it's the best fit for all problems. And real programmers use it. It's perfect enough that I haven't found any genuine flaw with it yet. Are you serious?
|
|
|
Logged
|
|
|
|
|