Hopefully not the typical "I want to program" thread...

[bonheur]

Thank you for your advice, but I preffer to learn something else given the amount of time that has elapsed since the last time I coded in Basic. Python looks very interesting so I'll be delving into that for a while. I'm sure Python has to have some shortcomings or downsides compared to other languages, but I haven't come across any issues yet.

 

[Merad]

I'm a fan of C++ (there is no such language as "C/C++"), but...

Memory leaks are programmer error, not language error. C/C++ don't just randomly leak out memory. In fact most programs WITH garbage collectors often have more problems with memory than C/C++ ever run into.

The entire problem with C and C++ is that they make it difficult to properly manage memory. C++ is better than C, IMO (at least you can use RAII), but adds plenty of its own twists. Learning how to manually manage memory is great, and it'd be nice if all programmers had that knowledge, but C++ simply is not a good first language.

Undefined behavior.. Umm, EVERY language has SOME undefined behavior. The fact is, you're code has to look REALLY crappy before you hit the corner case of undefined behavior with C/C++. You'll almost never run into that case, and if you do, throwing in a few parentheses will almost always fix the problem.

Um, define "really crappy code"?

Foo* f;
f->bar();

Doesn't look crappy to me. Totally undefined.

int* array = new int[10];
...
delete array;

Doesn't look crappy to me. Totally undefined.

You could go on, and on...

 

[Cogman]

I'm a fan of C++ (there is no such language as "C/C++"), but...



The entire problem with C and C++ is that they make it difficult to properly manage memory. C++ is better than C, IMO (at least you can use RAII), but adds plenty of its own twists. Learning how to manually manage memory is great, and it'd be nice if all programmers had that knowledge, but C++ simply is not a good first language.

Being difficult to manage may be a language fault. But memory leaks themselves are not a language fault.

Um, define "really crappy code"?

Foo* f;
f->bar();

Doesn't look crappy to me. Totally undefined.

Using uninitialized variables is crappy code.

int* array = new int[10];
...
delete array;

Doesn't look crappy to me. Totally undefined.

You could go on, and on...

True, I hadn't thought of this.

 

[Merad]

Using uninitialized variables is crappy code.

Then change the example to

void baz(Foo* f)
{
  f->bar();
}

...

baz(0);

Or any one of numerous other variations. I imagine you'll say that not checking for a null parameter or just using a reference is crappy coding, and I don't really disagree. The point is, someone who's learning doesn't know all of this, and C++ has so many "gotchas" it practically hands them a gun and begs them to shoot themselves in the foot.

 

[Cogman]

Then change the example to

void baz(Foo* f)
{
  f->bar();
}

...

baz(0);

Or any one of numerous other variations. I imagine you'll say that not checking for a null parameter or just using a reference is crappy coding, and I don't really disagree. The point is, someone who's learning doesn't know all of this, and C++ has so many "gotchas" it practically hands them a gun and begs them to shoot themselves in the foot.

There is no disputing that C and C++ have some dangerous gotchas. After all, they give everyone enough rope to hang themselves with. However, for someone looking at scientific data, they are nice quick languages that work well. They are more complex than other languages, but its faults are really not THAT big of an issue. Programmers like to make a mountains out of a mole hills when it comes to them. A new programmer will run into the issue, learn about it, and then say "Oh, well, I won't do THAT again."

My point was more "guys, C and C++ aren't THAT bad". These old dinosaurs still work pretty well while not having a terrible syntax. What I said initially "handling large amounts of data" is true, no language really compares to these guys in terms of speed and memory foot print (until you break out the assembly).

 

[Pia]

int foo(int bar) {
  return -bar; // may trigger undefined behavior; do you see why?
}

I know the problem exists, but there is no way I'm going to spot it from the middle of nontrivial code. This is an issue with the language, not the coder.

 

[Markbnj]

My point was more "guys, C and C++ aren't THAT bad". These old dinosaurs still work pretty well while not having a terrible syntax. What I said initially "handling large amounts of data" is true, no language really compares to these guys in terms of speed and memory foot print (until you break out the assembly).

It's not a matter of bad vs. good, which is why language wars are always amusing (I'm not implying you guys are engaged in one here). There are way too many variables to make a judgement like that... so I agree with you. C and C++ are not bad.

C and C++ are simply more granular than the ideal language that the industry requires at this time. When those languages were at the height of their popularity the world was a lot different. Ten or fifteen years later we have many more programmers, many more computers, many more devices that run on software, many more critical systems. Someone mentioned above that languages/frameworks with managed memory often run into more problems than C or C++ programs. Languages don't run into memory problems, programs written by programmers do. The memory management in the .NET CLR might have all sorts of problems, I don't know, but it retains the advantage of being a standard facility, written and maintained in one place, that can be updated and deployed to all platforms running the framework. We don't need thousands of programmers deciding how to do memory management. Those days are gone forever in all but a few specific computing disciplines, and those will follow eventually.

 

[Cogman]

int foo(int bar) {
  return -bar; // may trigger undefined behavior; do you see why?
}

I know the problem exists, but there is no way I'm going to spot it from the middle of nontrivial code. This is an issue with the language, not the coder.

? I'm not seeing the undefined behavior here. If you are referring to issues with 2's compliment and integer size, that is not undefined. Integer overflow is very well defined in the language. Just because you don't expect it, doesn't mean it is undefined.

Many other languages (Java, C#, fortran, Cobol, Perl, Pretty much everything except for python and ruby) have this very issue.

 

[Pia]

? I'm not seeing the undefined behavior here. If you are referring to issues with 2's compliment and integer size, that is not undefined. Integer overflow is very well defined in the language. Just because you don't expect it, doesn't mean it is undefined.

Many other languages (Java, C#, fortran, Cobol, Perl, Pretty much everything except for python and ruby) have this very issue.

Nope!

In C and C++ (Fortran too...) accidental integer overflow does not merely result in "something else than the programmer expected". It results in undefined behavior. So the compiler could do anything it wants when the above code is called with INT_MIN.

This leads into real-world bugs when a (normal, standards-conforming) C or C++ compiler does some optimization and throws away undefined statements. Even if binary with expected results happens to be generated, switching to a newer compiler version that is better at optimization may result in silently broken binary.

Overflow behavior in Java is defined. C# lets you choose whether overflow is checked and defined, or not checked (I'm not totally sure if C# overflow is defined in this case, but I suspect it is).

Lisp, Haskell etc. do not have this problem of course.

 

[Merad]

? I'm not seeing the undefined behavior here. If you are referring to issues with 2's compliment and integer size, that is not undefined.

Pretty sure integer overflow actually is officially undefined since it is possible for C and C++ to run on platforms that don't use 2's compliment.