average c++ dev
-
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++
Don't be average
-
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++
I actually do like that C/C++ let you do this stuff.
Sometimes it's nice to acknowledge that I'm writing software for a computer and it's all just bytes. Sometimes I don't really want to wrestle with the ivory tower of abstract type theory mixed with vague compiler errors, I just want to allocate a block of memory and apply a minimal set rules on top.
-
C++ is kinky that way. You can consent to all manner of depraved programming patterns. Great for use in personal life, but maybe not appropriate for the office.
But does it have cargo-mommy
-
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++
What do you mean I'm not supposed to add 0x5f3759df to a float casted as a long, bitshifted right by 1?
-
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++
My issue is C++ will "let me do it", and by that I mean "you didn't cast here (which is UB), so I will optimize out a null check later, and then segfault in a random location"
-
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++
Thank you for including the text as text.
-
What do you mean I'm not supposed to add 0x5f3759df to a float casted as a long, bitshifted right by 1?
-
What do you mean I'm not supposed to add 0x5f3759df to a float casted as a long, bitshifted right by 1?
//what the fuck? -
I actually do like that C/C++ let you do this stuff.
Sometimes it's nice to acknowledge that I'm writing software for a computer and it's all just bytes. Sometimes I don't really want to wrestle with the ivory tower of abstract type theory mixed with vague compiler errors, I just want to allocate a block of memory and apply a minimal set rules on top.
People just think that applying arbitrary rules somehow makes software magically more secure, like with rust, as if the compiler won't just "let you" do the exact same fucking thing if you type the
unsafekeyword -
People just think that applying arbitrary rules somehow makes software magically more secure, like with rust, as if the compiler won't just "let you" do the exact same fucking thing if you type the
unsafekeywordI don't know rust, but for example in Swift the type system can make things way more difficult.
Before they added macros if you wanted to write ORM code on a SQL database it was brutal, and if you need to go into raw buffers it's generally easier to just write C/objc code and a bridging header. The type system can make it harder to reason about performance too because you lose some visibility in what actually gets compiled.
The Swift type system has improved, but I've spent a lot of time fighting with it. I just try to avoid generics and type erasure now.
I've had similar experiences with Java and Scala.
That's what I mean about it being nice to drop out of setting up some type hierarchy and interfaces and just working with a raw buffers or function pointers.
-
People just think that applying arbitrary rules somehow makes software magically more secure, like with rust, as if the compiler won't just "let you" do the exact same fucking thing if you type the
unsafekeywordYou don't even need
unsafe, you can just take user input and execute it in a shell and rust will let you do it. Totally insecure! -
C lets you shoot yourself in the foot.
C++ lets you reuse the bullet.
C is dangerous like your uncle who drinks and smokes. Y’wanna make a weedwhacker-powered skateboard? Bitchin’! Nail that fucker on there good, she’ll be right. Get a bunch of C folks together and they’ll avoid all the stupid easy ways to kill somebody, in service to building something properly dangerous. They’ll raise the stakes from “accident” to “disaster.” Whether or not it works, it’s gonna blow people away.
C++ is dangerous like a quiet librarian who knows exactly which forbidden tomes you’re looking for. He and his… associates… will gladly share all the dark magic you know how to ask about. They’ll assure you that the power cosmic would never, without sufficient warning, pull someone inside-out. They don’t question why a loving god would allow the powers you crave. They will show you which runes to carve, and then, they will hand you the knife.
-
People just think that applying arbitrary rules somehow makes software magically more secure, like with rust, as if the compiler won't just "let you" do the exact same fucking thing if you type the
unsafekeywordIt's neither arbitrary nor magic; it's math. And
unsafedoesn't disable the type system, it just lets you dereference raw pointers. -
//what the fuck? -
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++
There are no medals waiting for you by writing overly clever code. Trust me, I’ve tried. There’s no pride. Only pain.
-
You don't even need
unsafe, you can just take user input and execute it in a shell and rust will let you do it. Totally insecure!Rust isn't memory safe because you can invoke another program that isn't memory safe?
-
There are no medals waiting for you by writing overly clever code. Trust me, I’ve tried. There’s no pride. Only pain.
It really depends on your field. I'm doing my master's thesis in HPC, and there, clever programming is really worth it.
-
People just think that applying arbitrary rules somehow makes software magically more secure, like with rust, as if the compiler won't just "let you" do the exact same fucking thing if you type the
unsafekeywordwrote on last edited by [email protected]I want you to stop what you're doing, pause and read your comment again slowly.
What you're arguing is analogous to: "People just think that strapping a cloth to them in the car will make driving more secure. As if someone can't just not use the seatbelt and still die in a car crash from that."It's not arbitarious rules, it's math and computer science. Wth are you some kind of science denier? Have they reached the computer science realm, like "Big O is out to get you?"
These rules do make Rust safer than c++ not in term of business logic but in terms of memory handling. I've been doing c++ for a looooooong time and once in a while there are times where we lose days if not weeks tracking down a race condition or memory bug where we could have been tracking down business logic bugs, improving code quality and coverage, adding features, etc
-
I want you to stop what you're doing, pause and read your comment again slowly.
What you're arguing is analogous to: "People just think that strapping a cloth to them in the car will make driving more secure. As if someone can't just not use the seatbelt and still die in a car crash from that."It's not arbitarious rules, it's math and computer science. Wth are you some kind of science denier? Have they reached the computer science realm, like "Big O is out to get you?"
These rules do make Rust safer than c++ not in term of business logic but in terms of memory handling. I've been doing c++ for a looooooong time and once in a while there are times where we lose days if not weeks tracking down a race condition or memory bug where we could have been tracking down business logic bugs, improving code quality and coverage, adding features, etc
That's not what I meant. I understand that rust forces things to be more secure. It's not not like there's some guarantee that rust is automatically safe, and C++ is automatically unsafe.
-
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++
wrote on last edited by [email protected]I used to love C++ until I learned Rust. Now I think it is obnoxious, because even if you write modern C++, without raw pointers, casting and the like, you will be constantly questioning whether you do stuff right. The spec is just way too complicated at this point and it can only get worse, unless they choose to break backwards compatibility and throw out the pre C++11 bullshit
