average c++ dev
-
Even with qualitative measurements they can do stupid things.
For work I have to write code in C# and Microsoft found that null reference exceptions were a common issue. They actually calculated how much these issues cost the industry (some big number) and put a lot of effort into changing the language so there's a lot of warnings when something is null.
But the end result is people just set things to an empty value instead of leaving it as null to avoid the warnings. And sure great, you don't have null reference exceptions because a value that defaulted to null didn't get set. But now you have issues where a value is an empty string when it should have been set.
The exception message would tell you exactly where in the code there's a mistake, and you'll immediately know there's a problem and it's more likely to be discovered by unit tests or QA. Something that's an value that's supposed to be set may not be noticed for a while and is difficult to track down.
So their research indicated a costly issue (which is ultimately a dev making a mistake) and they fixed it by creating an even more costly issue.
There's always going to be things where it's the responsibility of the developer to deal with, and there's no fix for it at the language level. Trying to fix it with language changes can just make things worse.
For this example, I feel that it is actually fairly ergonomic in languages that have an
Optiontype (like Rust), which can either beSomevalue or no value (None), and don't normally havenullas a concept. It normalizes explicitly dealing with the None instead of havingnullor hidden empty strings and such. -
I don't know which is worse. Using C++ like lazy C, or using C++ like it was designed to be used.
An acquaintance of mine once wrote a finite element method solver entirely in C++ templates.
-
I suppose it's a matter of experience and practise. The more you wotk with it the better you get. As usual with all things one can learn.
The question becomes, then, if I spend 5 years learning and mastering C++ versus rust, which one is going to help me produce a better product in the end?
-
For this example, I feel that it is actually fairly ergonomic in languages that have an
Optiontype (like Rust), which can either beSomevalue or no value (None), and don't normally havenullas a concept. It normalizes explicitly dealing with the None instead of havingnullor hidden empty strings and such.I just prefer an exception be thrown if I forget to set something so it's likely to happen as soon as I test it and will be easy to find where I missed something.
I don't think a language is going to prevent someone from making a human error when writing code, but it should make it easy to diagnose and fix it when it happens. If you call it null, "", empty, None, undefined or anything else, it doesn't change the fact that sometimes the person writing the code just forgot something.
Abstracting away from the problem just makes it more fuzzy on where I just forgot a line of code somewhere. Throwing an exception means I know immediately that I missed something, and also the part of the code where I made the mistake. Trying to eliminate the exception doesn't actually solve the problem, it just hides the problem and makes it more difficult to track down when someone eventually notices something wasn't populated.
Sometimes you want the program to fail, and fail fast (while testing) and in a very obvious way. Trying to make the language more "reliable" instead of having the reliability of the software be the responsibility of the developer can mean the software always "works", but it doesn't actually do what it's supposed to do.
Is the software really working if it never throws an exception but doesn't actually do what it's supposed to do?
-
Yeah and those are the ones currently identified (btw that issue isn't completely fixed) because rust never was nor advertised itself as sound. Meaning, you gotta be careful when writing Rust code too. Not as much as C++, but it's not a magical shield against memory problems like people have been shilling it as.
I guess what you mean is that Rust doesn't advertise the compiler as being bug-free?
The massive difference here is that C++ has no soundness guarantees even when the compiler is working as intended, whereas Rust actually does in fact give soundness guarantees in the absence of compiler bugs.
-
I just prefer an exception be thrown if I forget to set something so it's likely to happen as soon as I test it and will be easy to find where I missed something.
I don't think a language is going to prevent someone from making a human error when writing code, but it should make it easy to diagnose and fix it when it happens. If you call it null, "", empty, None, undefined or anything else, it doesn't change the fact that sometimes the person writing the code just forgot something.
Abstracting away from the problem just makes it more fuzzy on where I just forgot a line of code somewhere. Throwing an exception means I know immediately that I missed something, and also the part of the code where I made the mistake. Trying to eliminate the exception doesn't actually solve the problem, it just hides the problem and makes it more difficult to track down when someone eventually notices something wasn't populated.
Sometimes you want the program to fail, and fail fast (while testing) and in a very obvious way. Trying to make the language more "reliable" instead of having the reliability of the software be the responsibility of the developer can mean the software always "works", but it doesn't actually do what it's supposed to do.
Is the software really working if it never throws an exception but doesn't actually do what it's supposed to do?
It is fair to have a preference for exceptions. It sounds like there may be a misunderstanding on how
Optionworks.Have you used languages that didn't have
nulland hadOptioninstead? If we look at Rust, you can't forget not to check it: it is impossible to get theSomeof anOptionwithout dealing with theNone. You can't forget this. You can mess up in a lot of other ways, but you explicitly have to decide how to handle that potentialNonecase.If you want it to fail fast and obvious, there are ways to do this. For example you, you can use the
unwrap()method to get the containedSomevalue or panic if it isNone,expect()to do the same but with a custom panic message, the?operator to get the containedSomevalue or return the function withNone, etc. Tangentially, these also work forResult, which can beOkorErr.It is pretty common to use these methods in places where you always want to fail somewhere that you don't expect should have a
Noneor where you don't want your code to deal with the consequences of something unexpected. You have decided this and live with the consequences, instead of it implicitly happening/you forgetting to deal with it. -
But it will let you do it if you really want to.
Now, I've seen this a couple of times in this post. The idea that the compiler will let you do anything is so bizarre to me. It's not a matter of being allowed by the software to do anything. The software will do what you goddamn tell it to do, or it gets replaced.
WE'RE the humans, we're not asking some silicon diodes for permission. What the actual fuck?!? We created the fucking thing to do our bidding, and now we're all oh pwueez mr computer sir, may I have another ADC EAX, R13? FUCK THAT! Either the computer performs like the tool it is, or it goes the way of broken hammers and lawnmowers!
I understand the idea. But many people have hugely mistaken beliefs about what the C[++] languages are and how they work. When you write ADC EAX, R13 in assembly, that's it. But C is not a "portable assembler"! It has its own complicated logic. You might think that by writing ++i, you are writing just some INC [i] ot whatnot. You are not. To make a silly example, writing
int i=INT_MAX; ++i;you are not telling the compiler to produce INT_MIN. You are just telling it complete nonsense. And it would be better if the compiler "prevented" you from doing it, forcing you to explain yourself better. -
#pragma push
Context?
-
I understand the idea. But many people have hugely mistaken beliefs about what the C[++] languages are and how they work. When you write ADC EAX, R13 in assembly, that's it. But C is not a "portable assembler"! It has its own complicated logic. You might think that by writing ++i, you are writing just some INC [i] ot whatnot. You are not. To make a silly example, writing
int i=INT_MAX; ++i;you are not telling the compiler to produce INT_MIN. You are just telling it complete nonsense. And it would be better if the compiler "prevented" you from doing it, forcing you to explain yourself better.I get what you're saying. I guess what I'm yelling at the clouds about is the common discourse more than anything else.
If a screw has a slotted head, and your screwdriver is a torx, few people would say that the screwdriver won't allow them to do something.
Computers are just tools, and we're the ones who created them. We shouldn't be submissive, we should acknowledge that we have taken the wrong approach at solving something and do it a different way. Just like I would bitch about never having the correct screwdriver handy, and then go look for the right one.
-
Context?
You use it to "pack" bitfields, bytes etc together in structs/classes (wo functions), otherwise the computer usually align every variable on a 32bit boundary for speed.
-
You use it to "pack" bitfields, bytes etc together in structs/classes (wo functions), otherwise the computer usually align every variable on a 32bit boundary for speed.
You don't need that pragma to pack bitfields.
-
You don't need that pragma to pack bitfields.
wrote on last edited by [email protected]With say a 3bit int, then a 2bit int and various char, int etc and so on you did have to use the pragma with gcc & visual around 2012 at least
-
"C++ compilers also warn you..."
Ok, quick question here for people who work in C++ with other people (not personal projects). How many warnings does the code produce when it's compiled?
I've written a little bit of C++ decades ago, and since then I've worked alongside devs who worked on C++ projects. I've never seen a codebase that didn't produce hundreds if not thousands of lines of warnings when compiling.
A production code should never have any warning left. This is a simple rule that will save a lot of headaches.
-
"washing your hands isn't a guarantee that the patient isn't going to get an infection, they could get infected some other way too".
Every single doctor should know this yes.
It seems people are adding a sentence I didn't say "rust can be unsafe and thus we shouldn't try" on top of the one I did say "programmers should be aware that rust doesn't automatically mean safe".
wrote on last edited by [email protected]You didn't say "programmers should be aware that rust doesn’t automatically mean safe". You said:
People just think that applying arbitrary rules somehow makes software magically more secure...
You then went on to mention
unsafe, conflating "security" and "safety"; Rust's guarantees are around safety, not security, so it sounds like you really mean "more safe" here. But Rust does make software more safe than C++: it prohibits memory safety issues that are permitted by C++.You then acknowledged:
I understand that rust forces things to be more secure
...which seems to be the opposite of your original statement that Rust doesn't make software "more secure". But in the same comment:
It’s not not like there’s some guarantee that rust is automatically safe...
...well, no, there IS a guarantee that Rust is "automatically" (memory) safe, and to violate that safety, your program must either explicitly opt out of that "automatic" guarantee (using
unsafe) or exploit (intentionally or not) a compiler bug....and C++ is automatically unsafe.
This is also true! "Safety" is a property of proofs: it means that a specific undesirable thing cannot happen. The C++ compiler doesn't provide safety properties[1]. The opposite of "safety" is "liveness", meaning that some desirable thing does happen, and C++ does arguably provide certain liveness properties, in particular RAII, which guarantees that destructors will be called when leaving a call-stack frame.
[1] This is probably over-broad, but I can't think of any safety properties C++ the language does provide. You can enforce your own safety properties in library code, and the standard library provides some; for instance, mutexes have safety guarantees.
-
A production code should never have any warning left. This is a simple rule that will save a lot of headaches.
Neither should your development code, except for the part where you're working on.
-
I don't think that casting a range of bits as some other arbitrary type "is a bug nobody sees coming".
C++ compilers also warn you that this is likely an issue and will fail to compile if configured to do so. But it will let you do it if you really want to.
That's why I love C++
Aand what is wrong with that?
-
But it will let you do it if you really want to.
Now, I've seen this a couple of times in this post. The idea that the compiler will let you do anything is so bizarre to me. It's not a matter of being allowed by the software to do anything. The software will do what you goddamn tell it to do, or it gets replaced.
WE'RE the humans, we're not asking some silicon diodes for permission. What the actual fuck?!? We created the fucking thing to do our bidding, and now we're all oh pwueez mr computer sir, may I have another ADC EAX, R13? FUCK THAT! Either the computer performs like the tool it is, or it goes the way of broken hammers and lawnmowers!
Yup, I am with you on this one
-
I don't think that casting a range of bits as some other arbitrary type "is a bug nobody sees coming".
C++ compilers also warn you that this is likely an issue and will fail to compile if configured to do so. But it will let you do it if you really want to.
That's why I love C++
Did you know 100% of C programmers were sex offenders?
-
But it will let you do it if you really want to.
Now, I've seen this a couple of times in this post. The idea that the compiler will let you do anything is so bizarre to me. It's not a matter of being allowed by the software to do anything. The software will do what you goddamn tell it to do, or it gets replaced.
WE'RE the humans, we're not asking some silicon diodes for permission. What the actual fuck?!? We created the fucking thing to do our bidding, and now we're all oh pwueez mr computer sir, may I have another ADC EAX, R13? FUCK THAT! Either the computer performs like the tool it is, or it goes the way of broken hammers and lawnmowers!
wrote on last edited by [email protected]Yeah, but there's some things computers are genuinely better at than humans, which is why we code in the first place. I totally agree that you shouldn't ever be completely controlled by your machine, but strong nudging saves a lot of trouble.
-
"C++ compilers also warn you..."
Ok, quick question here for people who work in C++ with other people (not personal projects). How many warnings does the code produce when it's compiled?
I've written a little bit of C++ decades ago, and since then I've worked alongside devs who worked on C++ projects. I've never seen a codebase that didn't produce hundreds if not thousands of lines of warnings when compiling.
My team uses the -Werror flag, so our code won't compile if there are any warnings at all.
