Decision Making

Hi, I have been admitted into University this year. In my university there is a compulsory course in C which is going on and It has just began. But Actually I am in love of C++ that I am studying from a book on my own. Classes on C in are at initial level so I have continued my study on C++.But after a few days things are gonna change I believe.
Sould I skip my learning in C++ and just give attention to C to improve my grade?(It is a semestar(5 month) course) and start C++ after. Or I should keep learning both same time? Syntax in C is a bit complicated though.
N.B=I am learning C++ from C++ primer(lippman) and the book recommended by my course teacher for C is C the complete reference by herbert schildt.

No one can tell you how much or what you are able to learn - except yourself.

In saying

Quote:

---

...to improve my grade?

---

it appears you are asking whether you should do what you like or do what you are paying for - again only you can answer this.

Personally I would focus on that which has a better chance of benefit down the road (grades). Pull out the board game LIFE and spin the wheel, let me know what spot you land on.

I recommend learning both C and C++, but the advice you'll get from most members (including myself) on the C++ forum here is to learn C++ first. chances are, if you learn C++, you'll understand C readily. there are certainly more hoops to jump through and more code that has to be written to do seemingly simple things, but one of the main advantages of C is that, out of all the C-like languages, C itself allows (forces?) the programmer to have finer grained control over everything. the drawback to this is that you have to do everything explicitly, rather than rely on language features to do some things automatically, like you would in C++.

Alright.. I will continue to learn both... thanks for the advice!! By the way, do you think the books are OK??

C++ primer is considered a good book for beginners, although I've never looked at it, and I know nothing about the C book. generally, I would say a "reference" book is a bad choice as a class textbook for beginners.

Be extremely wary of the C course you're enrolled in. Here's an interesting review of the book you're supposed to use:
C: The Complete Nonsense

Herbert Schildt is notable for writing books that very readable (so publishers like them, and they sell well) but describe C in profoundly incorrect and misleading ways.


People I trust have been quite positive about "C++ Primer" by Lippman, Lajoie, and Moo, but can't say I used it in earnest myself. Best to get a latest edition if possible. And be careful, as there are some books with similar names, by different authors, that are reportedly dreadful.

Not forgetting
bullschildt

Quote:

---

Originally Posted by Salem

Not forgetting
bullschildt

---

Wasn't aware of this and reading about it I have to admit that I am a just shocked...

It's a slang term in a slang dictionary, though. So some words probably aren't even fads.

Thanks for this information guys. I will be careful from now onwards. So, Which book do you recommend for C?

I have also the book , "The C" by dennis ritchie. Is this book helpful?

If you are learning C: The C Programming Language (2nd edition) by Brian Kernighan and Dennis Ritchie is a good book, but it is dated. It was dated when I read it. Do not treat it as your last book is my advice. https://cboard.cprogramming.com/showthread.php?t=74079

If you are learning C++: No.

If you are learning C and C++: A C book, of course, doesn't teach C++. If you are learning object oriented programming for the first time, if you are learning your first language, then I would not recommend learning C and C++ in tandem. This is largely because you are also learning how to program, and C and C++ code have different paradigms for software development. You would be learning object oriented stuff in C++ but you wouldn't be able to apply that in C. These kinds of headaches are avoidable. If you have a language under your belt, you can do whatever you want and I don't really care.

Actually,for this year my target is to compete in ACM-ICPC.. Which doesnt require Object oriented programming i guess. So learning C and C++ basics will be helpful because in some problems It is easier to solve in C than C++ and vice versa. There is also the matter of time limit.. so I think I should learn both shouldnt I?

Quote:

---

So learning C and C++ basics will be helpful because in some problems It is easier to solve in C than C++ and vice versa.

---

In general this is not true. C and C++ are Turing complete, which means that they can solve any problem that a computer can solve. If you are worried about your skills for the contest, the more problems you can solve in 1 language is more important than half-understanding 2 languages, especially since you will be judged on your professionalism, essentially.

Quote:

---

Originally Posted by Tamim Ad Dari

So learning C and C++ basics will be helpful because in some problems It is easier to solve in C than C++ and vice versa.

---

I think I agree with that.

Some problems feel like they would be most naturally solved in C++ over C. I don't necessarily mean the ones that cry out for full OO -- but sometimes you really want objects with functions and state -- and that's less natural in C. On the other hand, I wouldn't use C++ for a problem I could solve in C.

Still, given that, I think learning C and C++ at the same time isn't a great idea. I think C++ without OO, templates, STL, etc... is going to be confusingly similar-yet-different to C. My advice would be to focus on your university C course first, since that's what you're meant to be doing at the moment.

Quote:

---

Originally Posted by Elkvis

the advice you'll get from most members (including myself) on the C++ forum here is to learn C++ first. chances are, if you learn C++, you'll understand C readily

---

Really? I would have thought it'd be easier to go the other way - learn C first. Because you can do everything in C++ that you can do in C, and more. Whereas going the other way I'd expect you to be often confounded by not being able to do something. I suppose C is a lot simpler so maybe it is a good way around to do it.

I sort of learned C-like-C++ (it was C++, but I was just learning the C bits of it) first, then C properly, then improved my C++ knowledge somewhat (it's not great). It wasn't a good way to learn -- so OP, if you do decide to learn both, try to keep them separate in your head.

Quote:

---

Originally Posted by Elkvis

I recommend learning both C and C++, but the advice you'll get from most members (including myself) on the C++ forum here is to learn C++ first.

---

I agree with you that it is a good idea to - eventually - learn both C and C++. But in terms of the advice from "most members" I must be in a minority - I don't advocate any order in which they should be learned.

The general advice I give is to pick one, and learn that. If you know enough to know you will need to use one or the other, pick that one. If courses available to you only teach one of them, pick that. If you clearly have the option of learning one or the other, and no real reason to prefer one, flip a coin.

Whichever way you learn C and C++, there will be an unlearning and relearning (of practices that are considered good in one of them, but not the other) element of transitioning from one to the other.


It is possible to learn C and C++ together. That is not really a good option for beginners to programming though - it would be difficult without a decent level of experience with other programming languages (or, for those with a theoretical bent) an understanding of computer science.

Quote:

---

Originally Posted by smokeyangel

...On the other hand, I wouldn't use C++ for a problem I could solve in C.

---

That's just silly.
If you can use C++ instead of C, then you should do it (I am purposefully ignoring factors such as cost, availability, etc that can an effect on what language to choose here to make this simple).
C++ is, at the very least, a stronger C. If the problem does not naturally lend itself to an OOP solution, C++ still have way more features that help you solve your problem than C.
Choosing C over C++ simply because you can is just silly.

To be fair, your preferences are equally silly. You're reading too much into that statement.

Quote:

---

Originally Posted by Elysia

That's just silly.
If you can use C++ instead of C, then you should do it (I am purposefully ignoring factors such as cost, availability, etc that can an effect on what language to choose here to make this simple).
C++ is, at the very least, a stronger C. If the problem does not naturally lend itself to an OOP solution, C++ still have way more features that help you solve your problem than C.
Choosing C over C++ simply because you can is just silly.

---

If you say so :) I know C a lot better (there's less to know...) so I'm less likely to make some horrible inefficiency bungle or other mistake.

I'll use C++ when appropriate - I just don't think it's appropriate all the time. If I were to write a little program that took some input and printed output, I'd use cstdio rather than iostream. It's those kinds of cases where I don't have anything to gain by using C++.

Well, I mean, clearly if you know a language better than something other, you would want to use the one you are more familiar with. That's natural.
But that was not my point. If you know C and C++, both roughly equally well, then it would be silly to use C when you can use C++.
The fact that you seem to prefer to use C over C++ for simple tasks seems to imply that you simply are not familiar enough with C++ yet. But it's a personal preference, so don't sweat it. So long as it is a hobby, using whatever language you are most familiar with is fine.

Thanks for contributing essentially nothing.

Quote:

---

But that was not my point. If you know C and C++, both roughly equally well, then it would be silly to use C when you can use C++.

---

He doesn't, he admits this in his own posts.

Quote:

---

The fact that you seem to prefer to use C over C++ for simple tasks seems to imply that you simply are not familiar enough with C++ yet. But it's a personal preference, so don't sweat it. So long as it is a hobby, using whatever language you are most familiar with is fine.

---

He also says that he works, so programming is more than a hobby.

She :)

Yep, I'm a software engineer. Of all things, I work on a C/C++ compiler. It's written in C++ -- parts of it are very C++y, full of templates and polymorphism, but quite a lot of it is C-like. I'm competent in C++, not afraid of it, I just prefer C.

It's a personal preference. And as I said, I will use C++ if it seems appropriate.

I'm not sure exactly what I'm supposed to be missing out on. What's so much better about C++ when the task does not need any of the extra features of C++? Most people I know share the same preference for C -- but the ones who prefer C++ don't seem to be noticably more productive.

[edit] -- just to repeat what whiteflags already repeated for me: I do not know C++ as well as I know C. For C, I know exactly what the executable will look like - I know what happens for e,.g. a function call, library init, stack use, heap use.
C++ I don't have the same depth of knowledge about. There's a lot to know -- it's so much more complicated than C. I know how virtual functions are handled by the compiler and runtime, but I've no idea about things like exception unwind tables etc etc. The standard library appears to be a goliath, and I don't know anything about that either.

I'm not saying that I won't code in a language until I know exactly how it's compiled -- I'm just saying I prefer C and that my C++ knowledge is not equal to my C knowledge.

In contests , It is better to use C I think. Cause some functions in C like printf,scanf works faster than cout and cin. So using C++ there is a chance to get the time limit exceeded.

Quote:

---

Originally Posted by Tamim Ad Dari

In contests , It is better to use C I think. Cause some functions in C like printf,scanf works faster than cout and cin. So using C++ there is a chance to get the time limit exceeded.

---

That has got to be the weakest argument I've ever heard for preferring any programming language over another.

You're comparing the speed of two snails. I/O is a performance bottleneck, regardless of programming language, and regardless of how library capabilities are implemented.

Quote:

---

Originally Posted by whiteflags

Thanks for contributing essentially nothing.

He doesn't, he admits this in his own posts.

He also says that he works, so programming is more than a hobby.

---

Thanks for your pointless contribution.

Quote:

---

Originally Posted by smokeyangel

I'm not sure exactly what I'm supposed to be missing out on. What's so much better about C++ when the task does not need any of the extra features of C++? Most people I know share the same preference for C -- but the ones who prefer C++ don't seem to be noticably more productive.

---

Better type safety, templates, objects that can store state, lambdas, the ability to write more generic code (ie, auto, decltype). A massive library of pre-written code with common containers and algorithms. Compile-time computation. Etc. Etc. Etc.
And don't tell me that there is no program that will not benefit from any of these features. I find that extremely hard to believe. Most will benefit from at least one.

Also, you really don't need to be aware of exactly what happens in the executable when you write your code. That's the whole point of portability and genericness - write once, deploy anywhere. If you must know what something does, then you have violated this rule. Yes, I know there are sometimes you must know certain things. In embedded systems, for example, it is almost critical to know what memory ends up where (for example, embedded memory or sdram). But that's just one little detail. The rest you can mostly ignore.

Quote:

---

Originally Posted by smokeyangel

It's a personal preference. And as I said, I will use C++ if it seems appropriate.

---

A lot of people say "I prefer X over Y, but will use Y if it seems appropriate." It's amazing how often their preference then seems to influence what they consider appropriate.

Quote:

---

Originally Posted by smokeyangel

I'm not sure exactly what I'm supposed to be missing out on.

---

If you don't know what you're missing out on, then you will make decisions on the premise that you are missing out on nothing. That is human nature.

Quote:

---

Originally Posted by smokeyangel

What's so much better about C++ when the task does not need any of the extra features of C++? Most people I know share the same preference for C -- but the ones who prefer C++ don't seem to be noticably more productive.

---

I wouldn't actually read anything into that observation. Those who prefer C++ will probably make the same observation about those who prefer C.

The value of the extra features of C++ depends on the task at hand. There are some things that a C++ programmer can achieve significantly faster than a C programmer. There are other things that a C programmer can achieve significantly faster than a C++ programmer.

I would certainly not ask someone who openly prefers C and who questions the value of C++ to assess the productivity of a C++ developer. Similarly, I would not ask someone who openly prefers C++ and who questions the value of C to assess the productivity of a C developer. Both assessments will exhibit cognitive bias. They will each, for example, tend to pick measures or metrics that suit their preference.

Quote:

---

Originally Posted by smokeyangel

There's a lot to know -- it's so much more complicated than C.

---

Sure, but once you get a handle on those complications, a lot can be done quite quickly in C++.

There are plenty of examples where making use of the C++ standard library allows writing a few lines to do what takes orders of magnitude more code than in C. That catch is that the knowledge and thought (i.e. intellectual effort) to write the C++ code and the C code can be equivalent, depending on experience of the developers. An advantage of C++, in this scenario, is that a few lines of code are easier to get right than a lot of lines while an advantage of C is that the developer will probably have more understanding of the implementation details. Either of those advantages, however, can be disadvantages, depending on the task at hand.

Quote:

---

Originally Posted by smokeyangel

I know how virtual functions are handled by the compiler and runtime,

---

Your words imply there is only one approach to handling virtual functions, which is wrong. That suggests you know one strategy for handling of virtual functions by the compiler and runtime (presumably, the virtual function table, which is often used). There are other strategies, each with different trade-offs.

Quote:

---

Originally Posted by smokeyangel

The standard library appears to be a goliath, and I don't know anything about that either.

---

That's ironic. One of the reasons for advocacy of some other languages is their "comprehensive" library - which usually refers to a library considerably larger than the C++ library.

In any event, the C library is not exactly small. It is true that the C++ library is larger. And that there are plenty of things that can be achieved with the C++ library that require a significant body of code to implement in C.

Quote:

---

Originally Posted by smokeyangel

I'm not saying that I won't code in a language until I know exactly how it's compiled.

---

No, but you are suggesting that you will lean toward a language if you (think you) know exactly how it is compiled.

In some ways, expecting to have an exhaustive model of how a language is compiled is at odds with the philosophy of C++ - where the point is to focus on what you seek to achieve, rather than in how to build it from the ground up.

Given the complexity of some modern C compilers, the fact that a lot of C compilers are actually C++ compilers, and the fact that C and C++ compilers both do significant code transformation and optimisation it is a fair bet that you have one mental model of how C compilation works, but that model is quite different from reality.

Quote:

---

Originally Posted by Elysia

Better type safety, templates, objects that can store state, lambdas, the ability to write more generic code (ie, auto, decltype). A massive library of pre-written code with common containers and algorithms. Compile-time computation. Etc. Etc. Etc.

---

"Objects that store state" is very useful and something I use quite often. I also use containers when I need to.

I think very hard before I use templates. If I find myself copy/pasting a function and changing just one thing in each.... I'll use templates.
For more interesting and complicated situations where you'd have multiple template parameters, I'd stop and think. In my experience, complicated template stuff is surprisingly easy to write and shockingly difficult for anyone else to read.
Just because you can parameterise your code to hell and back doesn't mean you should!

I honestly don't find myself in need of the swishy features of C++ very often. I'm familiar enough with some bits of C++ to know when I should be using them - but other parts... I'll obviously make a limited judgement based on limited knowledge.
So that's not saying "I prefer C" - that's "I don't know C++ very well" again.

If there's no need to use any of the snazz, then I think a C++ programmer and a C programmer would write pretty similar programs. I imagine we'd differ on new/delete vs malloc/free, iostream vs stdio, and possibly char* vs string.

I don't care about malloc at all, I'd happily use new instead.

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.

I've definitely seen char* and stdio used in C++ programs before. Is this a Bad Thing? Why?

Quote:

---

Originally Posted by grumpy

The value of the extra features of C++ depends on the task at hand. There are some things that a C++ programmer can achieve significantly faster than a C programmer. There are other things that a C programmer can achieve significantly faster than a C++ programmer.

I would certainly not ask someone who openly prefers C and who questions the value of C++ to assess the productivity of a C++ developer. Similarly, I would not ask someone who openly prefers C++ and who questions the value of C to assess the productivity of a C developer. Both assessments will exhibit cognitive bias. They will each, for example, tend to pick measures or metrics that suit their preference.

---

That's fair.

After I replied, I realised I did recently write something in C that would have been better in C++ (needed persistent state and needed to prepend something to a string -- both easier in C++). And I've just remembered I had to call realloc a couple of times. Yes, I should have written that in C++.

Quote:

---

Originally Posted by grumpy

Your words imply there is only one approach to handling virtual functions, which is wrong. That suggests you know one strategy for handling of virtual functions by the compiler and runtime (presumably, the virtual function table, which is often used). There are other strategies, each with different trade-offs.

---

Quite right. I should have said that I knew how it worked on one specific compiler. Although I thought vtable structure was part of the generic C++ ABI?

Quote:

---

Originally Posted by grumpy

That's ironic. One of the reasons for advocacy of some other languages is their "comprehensive" library - which usually refers to a library considerably larger than the C++ library.

In any event, the C library is not exactly small. It is true that the C++ library is larger. And that there are plenty of things that can be achieved with the C++ library that require a significant body of code to implement in C.

---

So, I have a rough idea of some of the sorts of things supported in the libraries. If I needed to use some sort of resizable container I'd know that a number are available. I wouldn't be able to name the right one for the job without looking them up.
There are doubtless tons of things in there that I've never even heard of.

Quote:

---

Originally Posted by grumpy

No, but you are suggesting that you will lean toward a language if you (think you) know exactly how it is compiled.

---

Quote:

---

Originally Posted by Elysia

Also, you really don't need to be aware of exactly what happens in the executable when you write your code.

---

I've had to think about this a bit and about what I was trying to say before, and have changed my mind :)

I think it would have been more accurate for me to say "know exactly how it behaves at runtime" and then soften that to "know roughly how it might behave at runtime".

To explain: When I think about it further, it wasn't working on a compiler that made me understand C better - it was spending a lot of time looking at machine code when I first started working on embedded stuff. Suddenly a lot of 'fluffy' C concepts made sense, So it's not really anything to do with knowing how the compiler does its business.

Now - these days I work on code compiled for x86 (Linux and Windows) so I expect much of the mental model I have of C is invalid. That doesn't bother me though -- I have *a* mental model of how it works, which helps. Less so now, but when I was unfamiliar with C it helped a lot.

It's my natural instinct to try to break something down into its most basic form and figure it out from there. I think that's fairly common and I don't think it's wrong. However, I don't think staring at disassembly of C++ objects all day would improve my C++ expertise - especially given that my main blind spot is the library support.

I still think that understanding how things are implemented is a good thing. An interesting thing. But probably not a necessary thing, and may have no tangible benefit. For example, I used printf for years without knowing how it handled all those arguments. I didn't gain any additional printf powers by looking into it, but I'm pleased to know (for one toolchain/architecture).

So, I think my revised stance on C++ is that there's a lot of it that is still "magic" to me (e.g. iostream), and I'll be happier once i know a bit more about them,

Quote:

---

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.

---

I squirm when I hear you say you prefer char* over std::string and you are working on a compiler. A compiler! For two extremely popular platforms!
Do you understand what you are doing? I don't think so. Your limited experience with higher level languages is causing you to make bad decisions and those decisions are going to reflect on whomever is using your software.
You should really, really, really start learning C++, C#, Java, whatever. Any higher-level language than C will do. Get familiar with them, and start using them as replacements for C as much as possible to break your habits on using C stuff instead of higher-level stuff.
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.
You have a very dangerous mindset for a software engineer. 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.

Quote:

---

Originally Posted by smokeyangel

I honestly don't find myself in need of the swishy features of C++ very often. I'm familiar enough with some bits of C++ to know when I should be using them - but other parts... I'll obviously make a limited judgement based on limited knowledge.
So that's not saying "I prefer C" - that's "I don't know C++ very well" again.

---

Quote:

---

Originally Posted by smokeyangel

If there's no need to use any of the snazz, then I think a C++ programmer and a C programmer would write pretty similar programs. I imagine we'd differ on new/delete vs malloc/free, iostream vs stdio, and possibly char* vs string.

---

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.

Quote:

---

Originally Posted by smokeyangel

I've definitely seen char* and stdio used in C++ programs before. Is this a Bad Thing? Why?

---

Depends on the context. Sometimes they are necessary, but more than often it is used by "C+" programmers who are somewhat stuck between C and C++. Unless you absolutely need them, don't use them. They are mostly unsafe and complex, whereas C++'s features are typically (everything is not always better, so typically it is) safer and easier.

Quote:

---

Originally Posted by smokeyangel

I think very hard before I use templates. If I find myself copy/pasting a function and changing just one thing in each.... I'll use templates.
For more interesting and complicated situations where you'd have multiple template parameters, I'd stop and think. In my experience, complicated template stuff is surprisingly easy to write and shockingly difficult for anyone else to read.
Just because you can parameterise your code to hell and back doesn't mean you should!

---

No, it doesn't. It's always a trade-off, but unless you are familiar enough with a language, you can't make those decisions very well.

Quote:

---

Originally Posted by smokeyangel

I still think that understanding how things are implemented is a good thing. An interesting thing. But probably not a necessary thing, and may have no tangible benefit. For example, I used printf for years without knowing how it handled all those arguments. I didn't gain any additional printf powers by looking into it, but I'm pleased to know (for one toolchain/architecture).

---

It may also be a bad thing, because the assumption you make on one platform might not hold on another platform and you are unknowingly doing a bad thing™ by drawing on experience on how a specific platform works.

Quote:

---

Originally Posted by smokeyangel

In my experience, complicated template stuff is surprisingly easy to write and shockingly difficult for anyone else to read.

---

I won't argue with that. It can also be quite difficult to get right.

Quote:

---

Originally Posted by smokeyangel

Just because you can parameterise your code to hell and back doesn't mean you should!

---

Yep. I tend not to parameterise things unless I have a number of specific use cases that are supported by doing so. In other words, when the need for parameterisation has been demonstrated by being useful more than once (and preferably much more than once).

Quote:

---

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.

---

It's just a way of thinking. There are quite a few people who find printf/scanf format strings counter-intuitive too.

Yes, printf() is allowed in C++. Type safety, however, does help with eliminating quite a few common errors.

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.

Quote:

---

Originally Posted by smokeyangel

I've definitely seen char* and stdio used in C++ programs before. Is this a Bad Thing? Why?

---

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 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.

Quote:

---

Originally Posted by smokeyangel

Quite right. I should have said that I knew how it worked on one specific compiler. Although I thought vtable structure was part of the generic C++ ABI?

---

As a side effect, yeah. However, the name "generic C++ ABI" is misleading. It is a separate specification from any C++ standard, and therefore not required of all compilers.

Quote:

---

Originally Posted by smokeyangel

So, I have a rough idea of some of the sorts of things supported in the libraries. If I needed to use some sort of resizable container I'd know that a number are available. I wouldn't be able to name the right one for the job without looking them up.

---

There are quite a few corners of the C library that require access to a good reference as well. That is true of any large library.

Quote:

---

Originally Posted by smokeyangel

Now - these days I work on code compiled for x86 (Linux and Windows) so I expect much of the mental model I have of C is invalid. That doesn't bother me though -- I have *a* mental model of how it works, which helps. Less so now, but when I was unfamiliar with C it helped a lot.

---

Everyone has to have a mental model of something if they are going to use it reliably.

The difference is that the preferred style of mental model to use C++, or its standard library, is a mapping from code construct to detectable effect. Whereas a common mental model encouraged for using C is a mapping of code constructs to lower level instructions.

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.

Quote:

---

Originally Posted by smokeyangel

It's my natural instinct to try to break something down into its most basic form and figure it out from there. I think that's fairly common and I don't think it's wrong.

---

I don't think it's wrong either. It is one way of approaching problems. Like any approach to problems, it has strengths and weaknesses, depending on how your mind works, your comfort zones, experience levels, the size of problems you're working on, and things like that.

Quote:

---

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.

Quote:

---

Originally Posted by Elysia

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

---

Mhmm.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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 :)

Quote:

---

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.

Quote:

---

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.

Quote:

---

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...

Quote:

---

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?

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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(), ...);

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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

Quote:

---

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.

Quote:

---

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?

Quote:

---

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.

Quote:

---

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?

Quote:

---

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."

Quote:

---

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?

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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?

Quote:

---

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

---

I beg to differ.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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#.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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:

Quote:

---

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.....

Quote:

---

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.

Quote:

---

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,

Quote:

---

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™.

Quote:

---

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...

Quote:

---

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#.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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++.

Quote:

---

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.

Quote:

---

...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.

Quote:

---

Originally Posted by Elysia

Unfortunately not so in embedded systems where every KByte counts.

---

I disagree. I can't speak about VC++, but G++ gives the option to exclude all built-in declarations/implementations, via the -fno-builtin command line option, and there are other options to strip it down even further, so that the only code that gets built is the code you write. in fact, the GCC family goes so far as to give the ability to create a flat, plain binary file, of the type you'd burn into a ROM chip. I'm sure VC++ and Intel's C++ compiler offer similar options, but I have no experience in trying to do that with those two compilers.

Just adding iostream adds a lot of kbytes, you know? Which might be too expensive.
But actually, I did not know of this option. This will certainly come in handy, so thanks for that.

Quote:

---

Originally Posted by Elysia

Just adding iostream adds a lot of kbytes, you know? Which might be too expensive.
But actually, I did not know of this option. This will certainly come in handy, so thanks for that.

---

I get your point, but the same could be said of including the C standard library in an embedded system. in my experience, it's much more common to implement your own iostream/stdio library that contains no more than the minimum functionality required for a given embedded system. including the whole standard library, whether it's C or C++, is probably the wrong thing to do for embedded programming.

Still, the C I/O library, though big, takes up far less space than the C++ I/O library in my experience.

It is important to note though that much of the C standard (excepting the language grammar basically), including the libraries and main() and other things, only apply to hosted environments. Since embedded programming is frequently not on a hosted environment rolling your own I/O functions may be mandatory.

Of course, good hardware has something to the effect of a library, usually.