I'm just a noob when it comes to low level languages, having only been in C# and python. But I took a course on C++ and encountered something that didn't seem right. And I asked and got the "that's undefined behavior". And that didn't quite sit tight with me. We don't know what will happen? It'll probably crash? Or worse? How can one not know how a programming language will perform? I felt it was wrong.

Now, it's quite some time since that happened, and I understand why it's undefined. But I still do not think it should be allowed by default. C and C++ both are "free to do as you want" languages, but I don't think a language should let you do something that's undefined especially if you aren't aware you're doing it. Everyone makes mistakes, even stupid ones. If we can make a place where undefined behavior simply won't happen, why not go there? If you need some special tricks, you can always drop the guard where you need it. I guess I'm just reiterating the article here though. But that's the point for me, if something can enforce "defined behavior" by default then I'd want that.

[–] Sylvartas@lemmy.world 2 points 10 months ago (2 children)

We don't know what will happen? It'll probably crash? Or worse? How can one not know how a programming language will perform? I felt it was wrong.

If you really want to know you can. Basically in most cases it depends on the compiler. Sometimes the hardware. The point is that you should not expect any specific behavior because the standard doesn't specify one

[–] BatmanAoD@programming.dev 6 points 10 months ago

The standard differentiates between "unspecified" behavior, which is as you describe, and "undefined" behavior, which may be completely nondeterministic at runtime.

[–] BehindTheBarrier@programming.dev 1 points 10 months ago* (last edited 10 months ago)

And that's is the part that irks me a little. How should I expect anything when I don't expect the undefined behavior to begin with?

Say I manage to accidentally do something undefined, I do some math incorrectly on some index, and try to read out of bounds on an array that didn't implement bound guards. Now already it's my fault for several reasons, but in a complex project what the array is, and the details of the array may be "vague", especially if it's not something you did yourself in the project. So as a scenario, it's not completely out there. (some other dev knew the index was "always" right, and did premature optimization and used unguarded arrays instead) Still completely avoidable, but it can happen.

But if only an edge case actually leads to an out of bound read, the problem will probably never happen where the issue is. An experienced dev might never step into this mess, but sometimes this happens when other people change up what others did. I've had similar problems at my workplace, just not with undefined behavior as a result. At the end of the day, you sitting there with hard to know issues that have hard to know consequences.

This doesn't require a special programming language to solve, it just requires a guarded array first and foremost, tests and good reviews might see the bug as well before production. Which in C++ we were taught about from the beginning. If performance actual was a problem, then I guess we'd maybe still end up with this bug in the example. But my point is something along the lines of, all the good practice comes down to the choices of the individual developer. And the choices of one, also affects the next one.

If we could instead place those choices a step up in the chain however. Have the language enforce safety, unless you specifically say you need the be unsafe. So in my example, other the code would be safe already or someone threw and unsafe block to do their "fast" read of the array. In one case, I'll make a crash due to a bad read, the other I'll have to really evaluate why this is unsafe to begin with and apply extra caution. That extra caution goes away when everything is unsafe. Kinda like a small PR will have 15 comments, a huge PR will have less. You won't dedicate your all for every line of code, but if a line is tagged "unsafe" you sure as hell will.

Nothing is a magic solution to everything, and unsafe array reads are just a simple example of fucky behavior. I'm not sure if it still stands, but even something like this was/is undefined in C++

a[i] = i++;

That is to me something you quickly can forget about. And it happens because of compiler optimization that happens even if it breaks the code, because normally the index in the array should be a different variable. Again, here is something that should have obviously stopped me. If the compiler still follows through (I'm sure there warnings for it) then it's just letting me do an error no one should be allowed to. There is no reason this should ever compile.

If we cna do that for everything at the language level, it's a win in my book.

[–] bluGill@kbin.social 1 points 10 months ago (1 children)

Easy to say, but in the real world those are things you don't do so who cares? You mostly hear about it from people who use other languages and want to pick on C

[–] sugar_in_your_tea@sh.itjust.works 1 points 10 months ago

I think there's a much higher chance of running into UB on C++ vs C due to the complexity of the language. That's why I don't touch C++ and only use C if a higher level language isn't available. I can understand the C language in its entirety, whereas that's really not feasible with C++, especially at the edges.

So I think it's absolutely fair criticism of C++, but a little tired for C.