I’m glad my company speaks a different language than English, and can’t use all the word soup completely. That said, my company is also wondering why my timesheets never add up to the entire day because always in meetings, scrum, or “can we jump on video chat for a sec because it’s easier to explain vocally than in writing”… And that “sec” turns into a 30 minute tutorial I have to give.
If you like turtles and programming, you might enjoy hearing about LOGO.
Back in the day, that was the first programming language I was taught. Years and years before I’d learn C or ASM.
You’d give instructions to a “turtle”, moving it about the screen, drawing as it did so. It was a magical experience for 9yo me.
Thank you! I had been picking my memory for this for so long. We too were taught LOGO in school in the early 2000s. I had forgotten the name, I found kturtle after searching about but couldn’t recall what the original program was called.
I was taught it around 1988, most likely on a Thomson MO5 ? Or maybe it was a TO9. It was a while ago :,) I just remember the fascination watching the little pixels color themselves and experimenting with the instructions to see what we could come up with.
Word! The whole snafu with co_routines has been quite the laughable show. It would have been trivially sortable if C++ did something like what PHP did, using a symbol to absolutely disambiguate what is a variable and what is not. That way eg.: await is a keyword, $await is a variable (perhaps a functor).
To make it even better, $ is already unused in C++!
Correct. Backwards compatibility is both its biggest asset and its bigger problem.
In syntax alone, you can check what Herb Sutter is doing with cppfront. Specifically, the wiki page on the postfix operators is quite enlightening. It shows some interesting examples of how by making everything a postfix operator you drop the need of -> and the duality of pre/post increment and decrement operators.
C++ is just as “safe” as Rust if you use modern language features (std::unique_ptr, for instance). I would argue that anyone who says Rust provides better memory safety than C++ most likely is not familiar with modern C++ and still sees the language as “C with classes.”
As someone whose first language was C, I plan to never use C++ for anything more than programming an Arduino precisely because of the multitude of pointer types. A pointer should just be a pointer. Having five hundred different flavors of pointers is confusing as fuck.
That was my first take as well, coming back to C++ in recent years after a long hiatus. But once I really got into it I realized that those pointer types still exist (conceptually) in C, but they’re undeclared and mostly unmanaged by the compiler. The little bit of automagic management that does happen is hidden from the programmer.
I feel like most of the complex overhead in modern C++ is actually just explaining in extra detail about what you think is happening. Where a C compiler would make your code work in any way possible, which may or may not be what you intended, a C++ compiler will kick out errors and let you know where you got it wrong. I think it may be a bit like JavaScript vs TypeScript: the issues were always there, we just introduced mechanisms to point them out.
You’re also mostly free to use those C-style pointers in C++. It’s just generally considered bad practice.
Smart pointers model ownership. Instead of (maybe) a comment telling you if you have to free/delete a returned pointer this information is encoded into the type itself. But that’s not all, this special type even handles the whole deleting part once it goes away.
Since they model ownership you should only use them when ownership should be expressed. Namely something that returns a pointer to a newly allocated thing should be a std::unique_ptr because the Callie has ownership of that memory. If they want to share it (multiple ownership of the object) there’s a cheap conversion to std::shared_ptr.
How about a function that takes in an object cause it wants to look at it? Well that doesn’t have anything to do with ownership so make it a raw pointer, or better yet a reference to avoid nullability.
What about when you’ve got a member function that wants to return a pointer to some memory the object owns? You guessed it baby raw pointer (or again reference if it’ll never be null).
Of course there’s no point in trying to rationalize this 'cos these people use meetings to try justify their usefulness to the company (HR does the same with random activities), so you end up drawing red lines with invisible ink…
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.