Python vs. C++: The Freedom to Crash Your Own Computer
Description
A two-panel meme comparing Python and C++. The top panel, labeled "Python," shows a character from the Halo video game series in blue armor saying, "Wait. That's illegal," reacting to the header text "When I code some stupid shit that will obviously break my computer:". The bottom panel, labeled "C++," shows a determined and crazed-looking close-up of a Teenage Mutant Ninja Turtle with the caption "COWABUNGA IT IS," enthusiastically embracing the same dangerous coding practice. The joke contrasts Python's safety features and abstractions, which prevent many types of catastrophic errors, with C++'s low-level capabilities. In C++, developers have direct memory access and fewer safety nets, giving them the "freedom" to write code that can easily cause segmentation faults, memory leaks, or crash the entire system. The meme resonates with experienced engineers who understand the trade-offs between high-level safety and low-level power
Comments
29Comment deleted
Python will throw an exception if you try to shoot yourself in the foot. C++ will let you shoot yourself in the foot, and it'll even let you do it with a multithreaded, template-metaprogrammed, laser-guided shotgun
Python gently raises an exception; C++ disables RTTI, cranks -Ofast, slides a raw pointer under the stack canary and whispers, “Postmortem’s on Friday, cowabunga.”
After 20 years in the industry, I've learned that C++ doesn't prevent you from shooting yourself in the foot - it just gives you a fully automatic weapon with unlimited ammo and asks if you'd like to aim at both feet simultaneously for better performance
Python: 'You can't just dereference a null pointer!' C++: 'Haha, segfault go brrr.' The eternal dichotomy between a language that holds your hand and one that hands you a loaded gun with the safety off - both will get the job done, but only one lets you shoot yourself in the foot with style. Python developers write code that crashes gracefully with a stack trace; C++ developers write code that crashes so hard it takes the OS with it, then spend three days in Valgrind wondering why their perfectly valid pointer arithmetic summoned a demon from /dev/null
In Python the runtime says “that’s illegal”; in C++ the compiler nods, inlines your bad idea, and lets UB make it faster - until -O3 in prod turns it into a heisenbug
Python gives a traceback; C++ gives a clean build, a 3am segfault, and occasionally a CVE with your initials
Python's your mom vetoing the bad idea; C++ hands you root and whispers 'YOLO' into the kernel panic
That's funny and all but can you give me an example of such program? Comment deleted
any virus lol Comment deleted
it will not break your PC. It can only harm data on your PC Comment deleted
Oh thank you душнила) I think in terms of simple users) If you can't use your PC its obviously broken for a reason Comment deleted
no it is not Comment deleted
We aren't talking about hardware breaking here. Comment deleted
No need to be so harsh :D Although he's technically right I support your position, that "Break my computer" means to stop OS from running normally Comment deleted
Block coolers Make PC work on 100% Profit Comment deleted
apple be like Comment deleted
Compiler bomb Comment deleted
WTF!? Comment deleted
--fstack-model=medium 😎 Comment deleted
int main() { int* a = new int(0); delete a; sleep(10000); a = 1; while (true) { a++; } } Comment deleted
First, why do you even allocate an array, if you delete it and then overwrite the provided address on the next lines? Second, all you do is increment a value infinitely, and, as you don't ever dereference it, the fact that it's a pointer doesn't matter. Moreover, since integer overflow cannot overflow any memory, all this program does is runs forever without a hope of breaking anything in any way, and it can be trivially stopped by any means available to the user. It's a bad example, overall Comment deleted
new int is not array, it is request to allocate free memory from anywhere on ram delete returns it back to os which can give that to other processes. But I didn't make the pointer a null pointer so I would probably accessed to memory which does not belong me Comment deleted
And continue accessing it again and again infinite Comment deleted
You seem to misundersand c(++) pointer mechanics and and dynamic memory. First, as referencing an array and a pointer are literally the same operation (a[i] and *(a + i) do exactly the same thing and are even compiled in the same way. Of course, that's only true if a isn't of a custom type with an overloaded operator[], but that's not the case. And no, i shouldn't be multiplied by the type's size, that is done automatically with pointer addition), so when I called a an array, I meant the same as a pointer. Second, the new operator with a literal type does the same as calloc, and that is, allocates a new chunk of heap memory of your process and returns a pointer to it (except, when calloc would return nullptr, new would throw an exception, but that's besides the point). The heap occupies a definite and limited chunk of space, so you definitely won't get an address of a random place in memory. Third, when you do a = 1, you don't change the value at which the pointer points, but change the address itself. (What you probably wanted to do was *a = 1). And the same goes for a++ - it only increases the address without touching the memory it refers to. And finally, every modern os switches the cpu into protected mode, which, among other features, introduces virtual addresses for user-space programs, as well as memory segmentation and access rights, so even if you were to actually write at random addresses, the most you'll be able to achieve is tamper with the memory of your process, and if you try to write to or read from unmapped or protected pages, you'll get a segmentation fault. In particular, all addresses below 0x4000 or something like that are always invalid in user mode, and the regions where your code resides are protected from writing by default, so your attempts to write anywhere among them would just crash your own program. To map a chunk of another processes' memory to your address space, there exists a syscall (at least in Windows, but most certainly in other OS'es as well). There are no means to map an arbitrary chunk of ram on any modern OS that aims to provide at least any security. I've worked with C and assembler quite a lot, and so I know them and the low-level computer architecture quite well, so trust me - crashing the system would be a lot harder than that. Comment deleted
In DOS, however, the approach of completely overwriting the memory with garbage would have worked, since DOS, being a 16-bit OS, didn't utilize protected mode (because it didn't exist at the time) and thus allowed for any kind of tampering with the system's internals, including referencing video memory directly or using BIOS syscalls Comment deleted
Yes, thanks, I recently started cpp (it is obvious I think), I'm actually js dev. Pointers and refs are tricky themes for me, in js there was no need do make any pointers and fix memory leaks. Comment deleted
Good luck with your studies then Comment deleted
And even if you attempted to write something at those addresses in the loop, it would've just segfaulted on the first iteration. It isn't trivial to crash the system with the cpu in user mode, you'd need to employ some syscalls at the very least Comment deleted
Would this actually run? I have never tried this yet Comment deleted