C++ and C

[Mira Yurizaki]

10 minutes ago, reniat said:

Can you go into more detail as to why they would have been better off in C? I feel this is less C vs C++ and more about whether you like OOP.

In the end does it really matter? What works for me will not necessarily work for you and vice versa. If you want to OOP everything, that's fine. If I don't want to, that's fine. Because in the end all that matters is who has software that works. If mine works and yours doesn't, then there is no more discussion to be had here.

[reniat]

6 minutes ago, Mira Yurizaki said:

In the end does it really matter?

I would agree that in the end it doesn't, I'm just trying to steer the thread, which is targeted at someone who knows neither C nor C++, away from any kind of "C++/C is definitely better so stay away from C/C++"

 

tl;dr i'm just trying to get people to bring more than just personal opinion when making blanket statements like:

27 minutes ago, bloodthirster said:

there are some code bases which C++ makes sense but in the vast majority of them C would have been the better choice. 

 

[bloodthirster]

1 hour ago, reniat said:

Can you go into more detail as to why they would have been better off in C? I feel this is less C vs C++ and more about whether you like OOP.

 

While I'm not a fan of pure OOP because it makes no sense in the work I do, some of the concepts definitely are useful though.  It's much better to have a simple implementation (which you can reuse) of what you need in C than use C++ with all the mess/"features" it brings in.  Because if you have a feature in a language, people will abuse and misuse it and create garbage with it. There's nothing "wrong" with C++, it just encourages horrible coding habbits and allows programmers to be lazy when they shouldn't.  If used properly, C and C++ aren't that far off.  C just forces people to see the crap code they're writing more easily and C++ doesn't bring that much to the table to make it worth using (especially since C can do most of the useful stuff C++ can do[abet with a ittle work]).

 

Ultimately, C++ has a lot more negatives than positives when compared to C when the vast majority of people use it.

[reniat]

24 minutes ago, bloodthirster said:

Ultimately, C++ has a lot more negatives than positives when compared to C when the vast majority of people use it.

I think we're just going to have to agree to disagree on this, and that's fine. IMO C code can also be pretty trash when written by people who are using it improperly, so to me it feels like you are comparing C++ written by subpar developers with C written by competent developers. To be fair, I am probably also comparing C++ written by competent developers to C written by subpar developers. It's likely just a matter of familiarity and bias between the two.

[Hi P]

21 hours ago, bloodthirster said:

There's nothing "wrong" with C++, it just encourages horrible coding habbits and allows programmers to be lazy when they shouldn't. C just forces people to see the crap code they're writing more easily.

 

Ultimately, C++ has a lot more negatives than positives when compared to C when the vast majority of people use it.

So that's why someone suggested learning C before C++ in another thread

 

If C++ encourages bad habbits, does it mean it's even worse with higher languages?

 

I don't know if it's related, but since I'm just a beginner I took Python as my first language, I finished the official guide along almost two books so far, and I still don't know what I'm doing most of the time, it's hard to describe, will this feeling be away once I learn a lower level language?

[Franck]

49 minutes ago, Hi P said:

So that's why someone suggested learning C before C++ in another thread

 

If C++ encourages bad habbits, does it mean it's even worse with higher languages?

What they mean is that C++ abstract more than C obviously and in a newcomer hands it tends to create more bad habits. But on the other hand i have seen much worse code in C from newcomer as it's more complex to write. C++ can encourage bad habits (compared to C) but C can create worst logic code. Again in both case we are talking of from a newcomer stand point not experienced people.

 

I get my hands on C and C++ weekly / biweekly and from what i see from clients if i assume their coders are similar in experiences and the result of C or C++ are 90% clean in both cases. Usually they have been patched here and there and often it's a case of "do it now no time to waste to make it done right" and that happen all the time in the real world. I don't remember getting recently a "worse" case as what is being discussed. Usually when it happen it's a very small project like something that rename files or with very few steps which barely take an hour or two to reimplement for their new systems. Something simple made by a new dev they had that didn't know much the language. I have never seen yet a 1-2 million line codebase done by a newcomer so far..... keep finger cross i guess .

[JacobFW]

As far as I can recall from my own experience, the only thing I can think of in C that doesn't work the same as in C++ are boolean casting (although it's been a few years since I've done this, so it might have been a glitch at the time).

int i = 1024;
if(i)
	cout << "True";
else
	cout << "False";

In C you would have "True" printed out, but in C++ you would have "False";

 

Reason for this as I understand it is that in C there is no official boolean type, so i is true if it's nonzero, and false if it's zero.

C++ does have a boolean type (which I believe is just a wrapped byte), so it will first cast the integer to a byte, meaning it grabs the 8 least significant bits (which for 1024 are all 0's), then compares that to 0, which will of course be false in this case.

 

I encountered that several years ago.  Real pain to figure out what the hell was happening.  To be fair though, it is bad form.  Even if it does work in C, you should really just make it

if(i != 0)
   ...

Just for the sake of clarity.

 

Also, I know some compilers treat C code differently.  I don't remember which compiler it was, but several years ago I attached a .c file to one of my projects, and it started giving me all kinds of errors and warning messages.  Renamed it to .cpp and it compiled just fine.  Turns out the for C code, it wouldn't let me declare variables half way through a function.  I was suppose to declare them all at the very start of the code.

 

 

To my knowledge the primary reason why people will prefer C over C++ is the umambiguity.  I love C++, but many of the features that make it easier for programmers to write code also lead to a lot of unknowns in terms of which codepaths the compiler is choosing (one of the reasons why it's so important to thoroughly test your code before release).  Going back to the boolean example I mentioned above, booleans can also be cast to integers.  So you can have instances where due to casting rules, you can have int -> boolean -> int, when you didn't want there to be any casting at all.  And again, unless you're thoroughly testing, or if you have your compiler spit out it's assembly output and you check it, you might never know.

 

Now in many cases that might not be a big deal.  If a bug like that manages to make it through you just release a patch and everyone goes on their way.  But if that occurs in an OS, or in a medical device of some kind, where reliability is King, you're in for a bad time.

 

[Unimportant]

3 hours ago, JacobFW said:

As far as I can recall from my own experience, the only thing I can think of in C that doesn't work the same as in C++ are boolean casting (although it's been a few years since I've done this, so it might have been a glitch at the time).

int i = 1024;
if(i)
	cout << "True";
else
	cout << "False";

In C you would have "True" printed out, but in C++ you would have "False"; 

 

Reason for this as I understand it is that in C there is no official boolean type, so i is true if it's nonzero, and false if it's zero.

C++ does have a boolean type (which I believe is just a wrapped byte), so it will first cast the integer to a byte, meaning it grabs the 8 least significant bits (which for 1024 are all 0's), then compares that to 0, which will of course be false in this case.

No, it works just the same and will always print "True". Nonzero values evaluate as true, zero as false.

 

3 hours ago, JacobFW said:

I encountered that several years ago.  Real pain to figure out what the hell was happening.  To be fair though, it is bad form.  Even if it does work in C, you should really just make it

if(i != 0)
   ...

Just for the sake of clarity.

Why would it be bad form? It's used all over the place by C and C++ programmers, what is unclear about it ?

3 hours ago, JacobFW said:

Also, I know some compilers treat C code differently.  I don't remember which compiler it was, but several years ago I attached a .c file to one of my projects, and it started giving me all kinds of errors and warning messages.  Renamed it to .cpp and it compiled just fine.  Turns out the for C code, it wouldn't let me declare variables half way through a function.  I was suppose to declare them all at the very start of the code.

 

It is allowed since C99.

3 hours ago, JacobFW said:

To my knowledge the primary reason why people will prefer C over C++ is the umambiguity.  I love C++, but many of the features that make it easier for programmers to write code also lead to a lot of unknowns in terms of which codepaths the compiler is choosing (one of the reasons why it's so important to thoroughly test your code before release).  Going back to the boolean example I mentioned above, booleans can also be cast to integers.  So you can have instances where due to casting rules, you can have int -> boolean -> int, when you didn't want there to be any casting at all.  And again, unless you're thoroughly testing, or if you have your compiler spit out it's assembly output and you check it, you might never know.

 

Now in many cases that might not be a big deal.  If a bug like that manages to make it through you just release a patch and everyone goes on their way.  But if that occurs in an OS, or in a medical device of some kind, where reliability is King, you're in for a bad time.

 

Could you give an example of such a int -> boolean -> int because this sounds like gibberish to me and would require some pretty poor code to even invoke.

 

We tend to prefer C++ in environments where reliability is king due to the very powerful static tools it has, such as templates and constexpr.

When properly used these can provide a safety layer at compile time! What is more reliable then your faulty code failing to compile ? For example:

const auto speedOne = GetSpeedSensorOne();	//European made sensor returns a Speed<Speed::Unit::kmh>
const auto speedTwo = GetSpeedSensorTwo();	//American made sensor returns a Speed<Speed::Unit::mph>
const auto totalSpeed = speedOne + speedTwo;	//Speed<Speed::Unit::kmh> and Speed<Speed::Unit::mph> are...
//...diffirent types , compile error ! When uncaught, mistakes like this make Mars climate orbiters crash!
//...or, a craftier implementation would convert between the two units automatically.

 

[Blade of Grass]

On 3/13/2019 at 10:28 PM, Sebivor said:

not only do people tell you not to cast `malloc` in C++, they tell you to flat-out avoid `malloc` in C++. I wonder why?

Safety. Void * don't auto cast to other pointer types because this would violate the type safety of the system. 

Overall, you should never use malloc in C++ because you open yourself up to a wealth of UB. What happens when you delete an uninitialized object that was malloc'd? How do you guarantee that the dtor is no throw when it's operating on garbage? You can't, and that is the very issue reason why it's not allowed.