Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Hi P

C++ and C

Recommended Posts

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.

Link to post
Share on other sites
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. 

 


Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to post
Share on other sites
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.


"Anger, which, far sweeter than trickling drops of honey, rises in the bosom of a man like smoke."

Link to post
Share on other sites
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.


Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to post
Share on other sites
Posted · Original PosterOP
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 :o

 

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?

Link to post
Share on other sites
49 minutes ago, Hi P said:

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

 

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

Link to post
Share on other sites

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.

 

Link to post
Share on other sites
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.

 

Link to post
Share on other sites
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.  


15" MBP TB

Serenity: Intel 4960x | ASUS X79-E WS | ASUS DCUII 770 | Corsair 750D || Blade Server: Intel 3570k | GD65 | Corsair C70 | 13TB

What Drive Should You Get?

Have a question? Please, don't hesitate to ask me over PM or on Twitter @Bladeof_Grass

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×