Decision Making

Originally Posted by Elysia

C stuff is dangerous. C will cause more bugs, harder-to-read code (yeah, good luck reading all that reallocation and stuff with arrays and dynamic buffers), and are prone to many more security issues than higher-level code.

Do you have any evidence that C code has more bugs? Or security issues for that matter?

As for reallocation and dynamic buffers.... I would use a C++ resizable type if I needed a resizable type.

Originally Posted by Elysia

[You have a very dangerous mindset for a software engineer.

Mhmm.

Originally Posted by Elysia

Your goal is to create flexible, easy to read, bugfree and secure code. C was not made to fulfil those goals on modern platforms. C is much more suited for platforms where resources are scarce and behemoth languages cannot work.

Isn't the Linux kernel written in C?

Along with a few other things:
C (programming language) - Wikipedia, the free encyclopedia

So I don't buy that as a reason at all.

Wiki does add:
"C has also been widely used to implement end-user applications, but much of that development has shifted to newer languages."

It seems reasonable that people would move to newer languages if they provide more features -- as C++ does over C. That's fine, but it doesn't imply anything about the suitability of C.

Originally Posted by Elysia

I beg to differ. There is always place for the "snazz". std::string by itself even is a huge difference. Stop trying to convince yourself that you may not certain features. Start trying to convince yourself if these features can make a difference. std::string makes a huge difference in terms of bugs, security and bugs.

Again, it sounds like you've actually observed a huge difference. Where?

I agree that std::string removes causes of common bugs with char* strings. I agree that having the memory allocation taken care of by the class is useful,

I'll try using this next time I need to do something with a string. I'm not hot on the idea of having to create a StringStream every time I want to do an
sprintf-like-thing.
C stdio (especially scanf) takes a bit of getting used to and can be pretty annoying. I expect this'll have its own raft of slightly odd seeming behaviour to get used to. Guess that 's a good reason to get familiar with it.

Originally Posted by grumpy

Two of the most common classes of error in C are pointer molestation and mismatched format specifiers. With C strings, one of the common classes of error involves misplacing the zero sentinel (terminator). Things have improved somewhat with modern compilers (eg diagnosing printf() calls at compile time), but these types of programming errors are a common cause of bugs. And of exploitable security holes.

I suppose it's easily done. I've done it a few times (especially forgetting to put Null at the end of strings), but have always realised when the output wasn't what I expected.

Originally Posted by grumpy

I would suggest mixing manipulation of C-strings with manipulation of C++-strings, and mixing stdio and stream I/O on the same stream, are often "bad things". Because they tend to introduce bugs that are hard to track down.

Ha, I could see myself copying the c_str out of a string and manipulating it. I think at that point it's time to ask yourself some serious questions about why you're missing the point so badly

Originally Posted by grumpy

In practice, it is also possible to program in C with a mental model concerned with mapping code construct to detectable effect. In fact, quite a bit the C standard specifies things in that manner. However, it is much harder - as you have observed - to build a mental model for mapping a lot of C++ code constructs to lower level instructions. This is described using "higher level of abstraction" and terms like that. Higher levels of abstraction are powerful, as they can support large scale development (eg complex systems, or algorithms built up using more machine instructions and low level coding constructs than a mere mortal can wrap their mind around). The weakness of higher levels of abstraction is that it takes more effort to learn, and quite a few people have trouble grasping the concepts.

Yes, exactly. You put that a lot better than I did

I'm not great with high level abstractions -- depends how abstract they are. The library function descriptions don't seem too bad -- not so abstract that my brain rejects them as incomplete. Probably helps that I've seen use of Lists and Vectors and stuff in real code many times.

Originally Posted by smokeyangel

Do you have any evidence that C code has more bugs? Or security issues for that matter?

Do you really need a scientific report to tell you that?
More complicated code leads to more bugs. It's human nature. We aren't perfect.
As for security issues... yeah, how many buffer overrun issues have you seen in software (especially big ones such as Internet Explorer and Windows)? That should be proof enough.
Also, do you know why banks do not use C in their applications? Especially ones that handle money?

Oh, and btw, there was once a time when I saw an innocent looking piece of code. At first glance, I really couldn't find many problems with it.
But you know what? Applying static analysis on that piece of code turned up a lot of problems that I couldn't find.
This just goes to show that we make mistakes, and we are not perfect.

Isn't the Linux kernel written in C?

Along with a few other things:
C (programming language) - Wikipedia, the free encyclopedia

So I don't buy that as a reason at all.

Wiki does add:
"C has also been widely used to implement end-user applications, but much of that development has shifted to newer languages."

It seems reasonable that people would move to newer languages if they provide more features -- as C++ does over C. That's fine, but it doesn't imply anything about the suitability of C.

The Linux kernel was written before C++ even existed. Sure they could switch to another language, but that would require rewriting all the code in the kernel. Yeah... not happening.
Add that to the fact that Linus Torvalds, the "owner" of the kernel, is dead set against C++ because he has some personal vendetta against the language.
Then there are people who just learn C in college and that this language is the way to go. Then there is the fact that most OS API (such as Linux) are C APIs.
Then there are people who thinks C is cool, awesome and can do everything, therefore it must be best. Some colleges teach C out of ignorance just to throw in some programming course.
And because C is so popular, there are tons of tutorials, courses and tools for C. That causes more people to jump on the bandwagon.
It's an evil cycle. The reasons why C is still in use on desktop is endless.
But you know, Microsoft purposefully did not include C as a language for their new Metro API. I wonder why...

Again, it sounds like you've actually observed a huge difference. Where?

I agree that std::string removes causes of common bugs with char* strings. I agree that having the memory allocation taken care of by the class is useful,

I don't use char* so that I don't have to bother with buffers and checking for buffer overruns.
But, you know, instead of trying to probe us for information, why not just try it?
Experience is the best guide, you know?

I'll try using this next time I need to do something with a string. I'm not hot on the idea of having to create a StringStream every time I want to do an
sprintf-like-thing.
C stdio (especially scanf) takes a bit of getting used to and can be pretty annoying. I expect this'll have its own raft of slightly odd seeming behaviour to get used to. Guess that 's a good reason to get familiar with it.

Deal with it!
Every language has its quirks. You know that. You should know that. Nothing is perfect, but it is better than nothing.
Everyone complains about stuff in the beginning because X is done differently in language Y. But that's just life. But the more you use, the more you get used it, the easier it becomes.
But you could even make your own formatting function if it irks you so much. Encapsulate it. Hide it.
And if that irks you so much, then take a look at Boost.Format.

I'm not great with high level abstractions -- depends how abstract they are. The library function descriptions don't seem too bad -- not so abstract that my brain rejects them as incomplete. Probably helps that I've seen use of Lists and Vectors and stuff in real code many times.

You know, all this stuff about not understanding something often is a result of not having worked with it enough.
The more you practice, the easier it becomes. But if you just take your time to implement and work with some stuff and experiment with it in different ways, it will come to you. When you stumble into problems that some of this stuff that you don't really get really helps, then that is where you really start to understand it, and come to accept it more.
I know, I've been there. So have we all.

Originally Posted by smokeyangel

I do prefer printf though. I don't see why I should be forbidden from using it, it's allowed in C++ isn't it? I know it's not typesafe, but I'll live. I like writing output as a string with format specifiers. The cout way of doing it is harder to visually relate to the output you'll see.
char* and string.... I'm perfectly happy with char* -- I don't feel the need for a class. If I were to use string, I think I'd have to jump on the stream bandwagon as well, since that seems to provide the functionality you'd ususally use sprintf() for.

There is actually a big list of where char* lacks when used for a string

1) Performance. Sometimes you need to check every single character when going through a loop to see if it ends with /0. Maybe in very primitive systems where registers where limited you might prefer to save the char pointer rather the pointer and the length, but I doubt that is the case today. This is also bad for a language that performance is part of its main advantages
2) Safety as indicated. Both causing bugs and security holes.
3) To avoid safety bugs you can use some safer functions like strncpy() that pass the length. So you know check the length and for /0, decreasing further performance
4) Not having a distinct type. You can use char* for a null terminated string or a simple char array. For user defined functions that a accept char* as an arguments it might not be clear which one is intended. If you have from a single user "readFileBinary(char* bug, int len)" and "readFileText(char* bug, int len)" it might not be clear if the second function will append automatically \0.
5) You can define a struct for a string in C quite quite easily, there is no technical reason preventing you or something lacking in the language itself. It is just not in the standard library. Prior to C++11 there wasn't either a std::array in C++. C++ has a bigger standard library progressing much faster compared to C. There is also no harm using sprintf with a std::string using ".c_str()" to pass the char*. The same for any function that doesn't modify the std::string. In C# you can more naturally print strings in both ways and this could have been done with C++ streams. But regardless, C++ allows you to use all C libraries. The other way is not necessarily true.

Originally Posted by C_ntua

...There is also no harm using sprintf with a std::string using ".c_str()" to pass the char*...

Just to be clear: this does not imply you can use std::string as a buffer for sprintf, only as a possible argument for a string (ie const char*).
Bad: std::string s; sprintf(s.c_str(), ...);
OK: std::string s; sprintf(..., s.c_str(), ...);

Originally Posted by Elysia

Do you really need a scientific report to tell you that?
More complicated code leads to more bugs. It's human nature. We aren't perfect.

True, if C code was actually more complicated than C++.
It's not though. Obviously there are simple and complicated C and C++ programs. You can't make a general statement about one being more complicated than the other.

Originally Posted by Elysia

As for security issues... yeah, how many buffer overrun issues have you seen in software (especially big ones such as Internet Explorer and Windows)? That should be proof enough.
Also, do you know why banks do not use C in their applications? Especially ones that handle money?

And yet safety critical systems, like in aeroplanes and cars do use C.

Originally Posted by Elysia

Oh, and btw, there was once a time when I saw an innocent looking piece of code. At first glance, I really couldn't find many problems with it.
But you know what? Applying static analysis on that piece of code turned up a lot of problems that I couldn't find.
This just goes to show that we make mistakes, and we are not perfect.

Of course, but that's true of any language, not just C.

Originally Posted by Elysia

The Linux kernel was written before C++ even existed. Sure they could switch to another language, but that would require rewriting all the code in the kernel. Yeah... not happening.
Add that to the fact that Linus Torvalds, the "owner" of the kernel, is dead set against C++ because he has some personal vendetta against the language.

I know. I pointed out to contradict your statement that C isn't right for modern systems.

The thing is, I'm not trying to engage in a C vs C++ debate. I don't think C++ is a bad language, or personally dislike it.

But you keep trying to say that C is an intrinsically bad language..... by making stuff up. "It's more complicated so it has more bugs" is clearly nonsense. You said that C is not able to deliver flexible, easy to read, bugfree and secure code on modern systems. The Linux kernel isn't bugfree or easy to read, but I wouldn't say it's a bad piece of engineering concocted by dangerous minds, would you?

You obviously dislike C, and there are valid reasons why C++ might be preferred in some situations, but you gain nothing by making random unsubstantiated statements of personal opinion dressed up as facts.

Originally Posted by Elysia

Then there are people who just learn C in college and that this language is the way to go. Then there is the fact that most OS API (such as Linux) are C APIs.
Then there are people who thinks C is cool, awesome and can do everything, therefore it must be best. Some colleges teach C out of ignorance just to throw in some programming course.
And because C is so popular, there are tons of tutorials, courses and tools for C. That causes more people to jump on the bandwagon.
It's an evil cycle. The reasons why C is still in use on desktop is endless.

I guess that's one of the reasons why C++ has to be almost completely backward compatible with C, to be able to access OS APIs
I don't think C's continuing populatity is evil. C got a spec update in C11, so clearly the powers-that-be don't think it's a dead language either.

Originally Posted by Elysia

But you know, Microsoft purposefully did not include C as a language for their new Metro API. I wonder why...

The answer seems obvious: because C doesn't support everything they need in their library.
Neither does C++, hence C++/CX.
I'm amazed that there are any C GUI libraries at all. I had a look at one a while ago to see how convoluted it had to be - it wasn't actually that bad. Still, C++ is definitely a better fit.
I don't think that it's because C is bad or unsafe yadda yadda -- just lacking essential features. Which are not essential for all programs. the whole concept seems to r

Obviously because the features C++ has (templates, OO, etc) are needed, and then some, hence why it's C++/CX

Originally Posted by Elysia

You know, all this stuff about not understanding something often is a result of not having worked with it enough.

I didn't say that I didn't understand.

Gaining experience with a language is the best way to learn, definitely. I'll carry on using C++ when it's the right thing to do.

Originally Posted by C_ntua

There is actually a big list of where char* lacks when used for a string

Thanks, that's useful.

Can't disagree with your point about performance
About safety: so long as you're aware of the issues and use safe functions like strncpy and fgets many of the risks can be mitigated. You could still lose the Null terminator through coding error, but then you could screw up a C++ string object through coding error too.

Lack of distinct type is a good one. I hadn't thought about this before. I mean, generally you can't tell if int* is a pointer to a single in or an array of ints. You always need some context - comments, argument names. char* is worse than that though, as it does get some special treatment:

Code:

   char *str =  "hello there";
   char str2[] = "hi there";'

If you pass these both around as char*s you have no way of knowing that one is writable and the other is not.

My mention of sprintf was more wanting to use sprintf to create a string and store it in a string object. Purely because I like printf format strings. That's mostly fear of the unknown though: once I read up on streams and stringstream I can see the advantages of using it. I know I can initialise/set string objects with a char* which I could have sprintf'd already -- but I'm trying to get into the spirit of doing things the C++ way.

I didn't even know there was a std::array. I just looked it up -- handy. Although .... if you use overloaded [n] to access an out of bounds element, the behaviour is undefined? It only does bounds checking for at(n). I suppose for someone coming from C that's not so bad, as you always need to guarantee that the array access is in bounds in C, obviously. So use [] when you've guaranteed it's within bounds, and at() when you think it is but can't guarantee it?

Originally Posted by Elysia

Do you really need a scientific report to tell you that?
More complicated code leads to more bugs. It's human nature. We aren't perfect.

Yea. Data always helps. I do not want programming to become a field where emotions and platitudes rule the day. From the point of view of the person you are trying to persuade, (more on that later) you are not providing sufficient evidence to back up your claims.

As for security issues... yeah, how many buffer overrun issues have you seen in software (especially big ones such as Internet Explorer and Windows)? That should be proof enough.

My contention with this statement is that the more C++ is used, the more these errors will come from C++ code as well. I can't appreciate the difference.

I mean, I will grant you that people do not have to do things the C way, when you have helpful classes but if you expect such code not to produce run time errors, then I think you'll end up hoist by your own petard. How many C++ people know about STL debug mode?

Also, do you know why banks do not use C in their applications? Especially ones that handle money?

Funny story. I'm studying Java right now. In the book I am reading they recommend to use BigDecimal for money. Of course, I had a hard time believing that a serious financial application does this because scaling integers is easy and correct. So that led to some googling, and I found a page with a most interesting fact: "A standard long value can store the current value of the Unites States national debt (as cents, not dollars) 6477 times without any overflow."

Oh, and btw, there was once a time when I saw an innocent looking piece of code. At first glance, I really couldn't find many problems with it.
But you know what? Applying static analysis on that piece of code turned up a lot of problems that I couldn't find.
This just goes to show that we make mistakes, and we are not perfect.

And how is that a negative mark on C? My memory is hazy on this book but in Deep C Secrets, there was a statement that separation of the C compiler from lint, a static analysis tool, was the worst thing to happen in C's history.

And there is no free lint for C++. C++ sucks then, right?

Then there are people who just learn C in college and that this language is the way to go. Then there is the fact that most OS API (such as Linux) are C APIs.
Then there are people who thinks C is cool, awesome and can do everything, therefore it must be best. Some colleges teach C out of ignorance just to throw in some programming course.

I cannot appreciate this argument since formal education has warped you into a C++ version of this.

And because C is so popular, there are tons of tutorials, courses and tools for C. That causes more people to jump on the bandwagon.

C is popular so it is bad? That is the kind of argument I expect for mainstream music, Mr. hipster.

It's an evil cycle. The reasons why C is still in use on desktop is endless.

One wonders why you have so much effort to spend slaying the C dragon.

But you know, Microsoft purposefully did not include C as a language for their new Metro API. I wonder why...

Did they now? I'm having trouble confirming your statement.

On one hand, Metro is nothing like what you say it is. Wikipedia leads me to believe that it is a design language that makes programs look like windows phone apps. That certainly doesn't seem very relevant.

But further digging helped me find a slide from a build conference from over a year ago. C is on it:
Microsoft to developers: Metro is your future | ZDNet It appears you mean the WinRT API.

Which is C++ with proprietary extentions:
Windows Runtime - Wikipedia, the free encyclopedia

So I will concede that you are at least factually correct. But if I may, do you have an intelligent answer to your own question? Why does WinRT exclude C? It would seem that C can use WinRT.




And I promised a comment on something earlier. To me, it sounds like you are asking a fisherman to throw away his rod, and that this whole debate is mean-spirited in origin.

First, let me just put this:
C, C++, C#, Java, and whatever other language you want to list. They all have their places. No language is better than the other.
But you will run into problems if you the wrong tool for the job. In this case, C is the wrong tool for PC platforms, in most cases. Unless you need a reason to do so, such as the Linux kernel which is mostly C for compatibility and has an evil head that disregard anything that is C++.
My aim is not to say C++ is better than C. My aim is to make you understand that C is not the right tool for the PC platform! C++, C# and Java are all better alternatives, but not alternative is necessarily better than the other.

Originally Posted by smokeyangel

True, if C code was actually more complicated than C++.
It's not though. Obviously there are simple and complicated C and C++ programs. You can't make a general statement about one being more complicated than the other.

Yes, I can. Simple enough proof:

Code:

char buf[500];
strcpy(buf, "Hello World");
strcat(buf, "! Bye World!");

vs

Code:

std::string s;
s = "Hello World";
s += "! Bye World!";

Is this more complicated? Absolutely! Because you have the danger of a buffer overflow there.
Or how about your typical 2D array (dunno if I will get this right the first time):

Code:

int * p = malloc(50 * sizeof(int*));
for (int i = 0; i < 50; i++)
	p[i] = malloc(50 * sizeof(int));

// Use

for (int i = 0; i < 50)
	free(p[i]);
free(p);

vs

Code:

std::vector<std::vector<int>> v(50, std::vector<int>(50));

Which one is safer?
Though, this probably won't convince you, will it?

And yet safety critical systems, like in aeroplanes and cars do use C.

I beg to differ.

Of course, but that's true of any language, not just C.

It is. I did not say it wasn't. It just goes to show we make mistakes. And with lots of code, we make many mistakes. And with many mistakes comes many bugs.

I know. I pointed out to contradict your statement that C isn't right for modern systems.

The thing is, I'm not trying to engage in a C vs C++ debate. I don't think C++ is a bad language, or personally dislike it.

But you keep trying to say that C is an intrinsically bad language..... by making stuff up. "It's more complicated so it has more bugs" is clearly nonsense. You said that C is not able to deliver flexible, easy to read, bugfree and secure code on modern systems. The Linux kernel isn't bugfree or easy to read, but I wouldn't say it's a bad piece of engineering concocted by dangerous minds, would you?

You obviously dislike C, and there are valid reasons why C++ might be preferred in some situations, but you gain nothing by making random unsubstantiated statements of personal opinion dressed up as facts.

I do not make stuff up, and that is not a contradiction.
But that's probably pointless to argue.

I didn't even know there was a std::array. I just looked it up -- handy. Although .... if you use overloaded [n] to access an out of bounds element, the behaviour is undefined? It only does bounds checking for at(n). I suppose for someone coming from C that's not so bad, as you always need to guarantee that the array access is in bounds in C, obviously. So use [] when you've guaranteed it's within bounds, and at() when you think it is but can't guarantee it?

Depends. If you are looking at speed, you may choose [] (preferably when checking that it is bounds; but in time critical applications, there may not be time to do that, so you may just have to hope it runs right and does not crash and burn). If you want to write a safe program that should show an error for the user instead of crashing or behaving weird, you would probably choose the at function.

Originally Posted by whiteflags

I cannot appreciate this argument since formal education has warped you into a C++ version of this.

Depends on your point. I have no classes in C, or just some random bits and pieces.
I have had one class on C++, and it sucked.
I have had one class in Java and I can't say it makes me like Java anymore.
I have had 0 classes in C#.

On one hand, Metro is nothing like what you say it is. Wikipedia leads me to believe that it is a design language that makes programs look like windows phone apps. That certainly doesn't seem very relevant.

But further digging helped me find a slide from a build conference from over a year ago. C is on it:
Microsoft to developers: Metro is your future | ZDNet It appears you mean the WinRT API.

Which is C++ with proprietary extentions:
Windows Runtime - Wikipedia, the free encyclopedia

So I will concede that you are at least factually correct. But if I may, do you have an intelligent answer to your own question? Why does WinRT exclude C? It would seem that C can use WinRT.

You bring the bull out by the horns. I don't know enough of this whole mess that is Metro or WinRT, so I am going to concede here.

I am still trying to find a good source that explains the dangers of C.

Originally Posted by whiteflags

On one hand, Metro is nothing like what you say it is. Wikipedia leads me to believe that it is a design language that makes programs look like windows phone apps. That certainly doesn't seem very relevant.

When Surface was announced, I'm pretty sure "Metro" referred to the new UI in general. Or at least, journalists used it like that (possibly incorrectly). Microsoft ran into trademark trouble (according to wikipedia....) so I guess they are using it in a more focused way now.

Originally Posted by whiteflags

But further digging helped me find a slide from a build conference from over a year ago. C is on it:
Microsoft to developers: Metro is your future | ZDNet It appears you mean the WinRT API.

Interesting!!
I went digging but couldn't find anything official saying C is supported.

he unofficial word is that WinRT is based on COM. You can use COM in C, so should be able to use WInRT too. I've no idea if that's correct or not.

Question on stackoverflow:
visual studio - Using WinRT from C? - Stack Overflow

COM in plain C:
COM in plain C - CodeProject


I do know that Microsoft have publicly stated that they're never going to fully support C99, and only support C11 in ways that it's a subset of C++.

Apparently they say "Use C++"
Microsoft to C99 Developers: Use ISO C++

Funny, one of the comments on there says:

Originally Posted by article

C is still alive, very heavily used throughout everything — from frameworks to applications. Things that do not need anything C++ has to offer, but would greatly benefit from C99′s features that classic C90 does not provide.

Sounds familiar somehow.....

Originally Posted by whiteflags

To me, it sounds like you are asking a fisherman to throw away his rod

Haha - that's a new one on me. I've no idea what it means. Obviously I don't want to part with my rod - but am I right or wrong to cling to it?

I'd like to think that I'll change my opinion on something if it turns out to be wrong. I just haven't been convinced in this case.

Originally Posted by whiteflags

and that this whole debate is mean-spirited in origin.

There were some interesting points in some posts. Got me thinking about why I prefer C, and having a look at the C++ stuff I never use (iosteam, string...).

I think that's all I'm going to get out of this. I don't think Elysia and I will manage to convince each other of anything. Yeah, I don't really have anything else to say. I'm gonna go back to helping the spread of evil.

Mmm, I also found these links to be interesting:
When to use C over C++, and C++ over C? - Programmers
Is the C programming language still used? - Programmers
Gmane Loom

They don't walk so much about security, but they are interesting nonetheless.


As for the whole security issue, it is common knowledge in software engineering that more lines of code = more bugs. That is all there is to it, and it is very simple argument for reducing the number of lines of code by choosing an appropriate programming language for the task at hand.

Go on, one more post.

The string examples are equally complicated. They both call 2 functions. In C, you have to knwith more complicated syntax. You don't get anything for ow what those functions are. In C++, you have to know that those operators have been overloaded to do .... that.

The vector example - yes, this is more complex in C so potentially more error prone.

That's not enough to say "C code is more complicated than C++". Consider a program that actually has some complexity to it and isn't trivally implemented by C++. The C version would probably contain more code to define and set up some data types and operations on them. The C++ version would probably be shorter, built out of more complicated building blocks interating in much more complex ways. One of the links you linked to said "C is easier to learn". That's it, in a nutshell. You can't ignore the complexity of the language when considering how buggy code is likely to be.
C++ has plenty of undefined behaviour that a person could stumble into.

If our hypothetical C programmer is too careless to consider buffer overrun, then our hypothetical C++ programmer can't be an expert either.



About safety critical.... I beg you to read more than the first line of it,

Originally Posted by risk

Although C and C++ were not specifically designed for this type of application, they are widely used for embedded and safety-critical software for several reasons.

I don't have time cover everything, but some more interesting stuff can be found here: Stroustrup: FAQ
Especially Stroustrup: FAQ and Stroustrup: FAQ and Stroustrup: FAQ.
Remember that this is the creator of C++ and a very wise man™.

Originally Posted by smokeyangel

The string examples are equally complicated. They both call 2 functions. In C, you have to knwith more complicated syntax. You don't get anything for ow what those functions are. In C++, you have to know that those operators have been overloaded to do .... that.

Yes, they might as well be equally complex in this case, but are they equally safe? I wonder...

Originally Posted by smokeyangel

If our hypothetical C programmer is too careless to consider buffer overrun, then our hypothetical C++ programmer can't be an expert either.

The point is that there are many less (hence, it is much harder) opportunities to get buffer overruns in C++ than it is in C, and even harder in languages like Java and C#.

Originally Posted by smokeyangel

That's not enough to say "C code is more complicated than C++". Consider a program that actually has some complexity to it and isn't trivally implemented by C++. The C version would probably contain more code to define and set up some data types and operations on them. The C++ version would probably be shorter, built out of more complicated building blocks interating in much more complex ways. One of the links you linked to said "C is easier to learn". That's it, in a nutshell. You can't ignore the complexity of the language when considering how buggy code is likely to be.
C++ has plenty of undefined behaviour that a person could stumble into.

While complexity of the program is indeed a factor, consider how much more complex it would be in C. How much more code duplication there would be.

And a question for you: how would you use a linked list in C? In C++, I would use std::list. In C# and Java, there are equivalents.
Are you going to write one yourself? Consider all the bugs and security issues!
Are you going to use an external library? How do you know you can trust that library then? How do you know it isn't riddles with bugs and security issues? There are idiots in the industry, unlike us experts, and they make these bad decisions which affect the code quality in projects.

And a question for you: how would you use a linked list in C? In C++, I would use std::list. In C# and Java, there are equivalents.
Are you going to write one yourself? Consider all the bugs and security issues!
Are you going to use an external library? How do you know you can trust that library then? How do you know it isn't riddles with bugs and security issues? There are idiots in the industry, unlike us experts, and they make these bad decisions which affect the code quality in projects.

This is FUD. You like to use the word security as a magic wand.

Point of order: unless you can describe specific security issues, then don't talk about it. What I'm looking for is a security bug that can be squarely placed on C and not idiot programmers who might make a mistake.

Code deserves to be peer reviewed regardless of origin. I won't be convinced that way.

Originally Posted by whiteflags

This is FUD. You like to use the word security as a magic wand.

Is that so? I find a very big issue in security critical systems.

Originally Posted by whiteflags

Code deserves to be peer reviewed regardless of origin. I won't be convinced that way.

Who says otherwise? Code reviews increase code quality, but they are not enough to find many bugs and security issues. Don't have a source on that, but generally that is how it has been from what I've heard. I can also attest a little to that myself from my own experience.

as a language, C is no less secure than C++. both can be used to write equally secure code. the standard library of the two languages is another story. C's standard library does very little to encourage safe code, whereas C++'s standard library is written with exactly that (among other things) in mind.

the simple fact is that C's library functions expect the programmer to know exactly how big a given buffer is at any given time, and any failure to keep track of that instantly becomes a security risk. the C++ standard library - the STL - encapsulates string, array, list, and other container functionality into classes, which handle buffer sizes implicitly. add to this the fact that in C++ it's possible for an array to truly be a first-class object, instead of always decaying into a pointer. it's certainly possible to have a bug in the C++ standard library that causes something to become insecure, but those occurrences seem to be much less common than simple lazy coding by a well-intentioned C coder.

I see absolutely no reason to use C for a new project, when C++ is safer by design, and is (almost) fully backward compatible with C. C++ does not penalize the programmer for features that he/she does not use. the idea of C++ being a bloated language that saddles the programmer with a lot of extra overhead is complete nonsense. also, any difference in intrinsic performance of the language is purely a result of programming prowess by the programmer. C is not inherently "faster" than C++. it may have been at one time, but modern compilers produce very high quality machine code, regardless of whether it is C or C++.

Originally Posted by Elkvis

as a language, C is no less secure than C++. both can be used to write equally secure code.

Just going to add that C++ have features that help programmers keep track of things, such as size without needing to do so explicitly (for example, template arguments).
There are also the matter of type safety where C tends to use void pointers, which requires the programmer to correctly convey the type to the compiler at a later stage. C++'s template system helps the compiler remember the type so that a mistake is made later down the road.
Using only C++ features, I could a more safe malloc than with C simply by utilizing the template system. Writing a memory allocator is still not easy, of course.

...the idea of C++ being a bloated language that saddles the programmer with a lot of extra overhead is complete nonsense.

For PC platforms, yep. Unfortunately not so in embedded systems where every KByte counts.