Incase it doesn't show up:
They are still using Reddit, so one has to wonder if they have not abandoned sanity and intellect a long time ago.
this post was submitted on 02 Sep 2024
886 points (99.0% liked)
Programmer Humor
32874 readers
599 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
Unfortunately, those of us that make games in Unreal Engine are stuck writing a lot of C++, unless we want to do everything in BPs (no thanks, they're fine, but it's not coding, and it's difficult to maintain and refactor for complicated projects, they're good for taking C++ components and building bigger components out of the base C++ functionality though).
With that said, UE's support for C++ is decent. Which is, that as long as you tag all your fields, properties, methods, classes, etc. with some UnrealEngine attribute filter (like UCLASS or UPROPERTY), Unreal will handle the memory management of those constructs for you. Which is nice.
Unfortunately it has some other limitations to the C++ language that you can't work around, like disallowing pure abstracts because every C++ derivative class based on any UE construct (Actor, Character, Pawn, etc.) has to be instantiatable in the editor. So no pure abstracts and such.
In general, I'd give it a 6/10.
It's still mostly C++, but some of the things suck less.
Jokes aside, I struggle more with abominations like JavaScript and even Python.
Python has its quirks, but it’s much much cleaner than js or c++, not fair to drag it down with them imo
The terse indexing and index manipulation gets a bit Perl-ish and write-only to me. But other than that I agree.
I think the thing with C++ is they have tried to maintain backward compatibility from Day 1. You can take a C++ program from the 80s (or heck, even a straight up C program), and there's a good chance it will compile as-is, which is rather astonishing considering modern C++ feels like a different language.
But I think this is what leads to a lot of the complexity as it stands? By contrast, I started Python in the Python 2 era, and when they switched to 3, I was like "Wow, did they just break hello world?" It's a different philosophy and has its trade-offs. By reinventing itself, it can get rid of the legacy cruft that never worked well or required hacky workarounds, but old code will not simply run under the new interpreter. You have to hope your migration tools are up to the task.
even a straight up C program
There were breaking changes between C and C++ (and some divergent evolution since the initial split) as well as breaking changes between different releases of C++ itself. I am not saying these never happened, but the powers that be controlling the standard have worked hard to minimize these for better or worse.
If I took one of my earliest ANSI C programs from the 80s and ran it through a C++23 compiler, I would probably need to remove a bunch of register statements and maybe check if an assumption of 16-bit int is going to land me in some trouble, but otherwise, I think it would build as long as it's not linking in any 3rd party libraries.
Yeah JavaScript is a bit weird, semicolons being optional and compulsory at the same time: I remember trying to build an electron example ~5yrs ago and it didn't work unless I put in the semicolons which the developers omitted.
Python is just glorified shell scripting. Libraries like numpy are cool but I don't like the indentation crap, I'm getting used to it because University likes it.
load more comments
(4 replies)
Do you have a minute for our lord and savoir TypeScript?
As long as it can distinguish between int and uint - yesss!
TypeScript is still built on JavaScript, all numbers are IEEE-754 doubles 🙃
Edit: Actually I lied, there are BigInts which are arbitrarily precise integers but I don't think there's a way to make them unsigned. There also might be a byte-array object that stores uint8 values but I'm not completely sure if I'm remembering that correctly.
load more comments
(1 replies)
Disclaimer: I actually like C++ the language, I'm reasonably comfortable with it and enjoy it as an upgrade from C. I don't use much OOP stuff as I'm writing a game using the flecs ECS. So things like abstract classes are mostly absent from my codebase.
What has been driving me up the wall the last month has been build systems and dependencies: don't get me wrong; meson is great but the problem is not everyone uses meson. All I want to do is add some library built with cmake as a dependency without needing to rewrite the build system or install it on my OS. Apparently that is too much to ask!
I'm seriously considering dropping everything and jumping to Rust because of Cargo. Yes I've tried setting up conan but not having much fun since the packages are all third party and out of date anyways
Rust's cargo is great, I'd say it would be best to make the switch sooner rather than later once your code base is established. The build system and tooling alone is a great reason to switch
What sucks is I've been working on this hobby project for nearly 4 years now. It started in C#, moved to C, now C++. It's at the stage where a lot of basic functionality has been implemented, with the largest component, the Vulkan based renderer being maybe 1/4 implemented. The core game stuff is ECS based and flecs has a rust binding so migrating that will be easy. Renderer will just become even further from completion. I'm worried that there will be new problems that are maybe more inhibiting, but this is meant to be a fun project and build systems aren't fun. It's a difficult balance and I'm not the only person involved, the other person isn't as convinced by cargo as they haven't spent days working on the build system
load more comments
(8 replies)
So things like abstract classes are mostly absent from my codebase.
I believe the consensus nowadays is that abstract classes should be avoided like the plague even in languages like Java and C#.
I have not heard this consensus. Definitely inheritance where the base class holds data or multiple inheritance, but I thought abstract was still ok. Why is it bad?
In 99% of the cases, inheritance can easily be replaced with composition and/or interfaces. Abstract classes tend to cause hard dependencies that are tough to work with.
I’m not sure why you would use abstract classes without data. Just use interfaces.
Say List is an interface.
You have implementations like ArrayList and LinkedList.
Many of those method implementations will differ. But some will be identical. The identical ones go in the abstract base class, so you can share method implementation inheritance without duplicating code.
That’s why.
If the lists have shared components then that can be solved with composition. It’s semantically the same as using abstract classes, but with the difference that this code dependency doesn’t need to be exposed to the outside. This makes the dependency more loosely coupled.
In my example, how is the code dependency exposed to the outside? The caller only knows about the List interface in my example.
In your example, the declaration of ArrayList look like:
public class ArrayList extends AbstractList implements List {
}
The dependence on AbstractList is public. Any public method in AbstractList is also accessible from the outside. It opens up for tricky dependencies that can be difficult to unravel.
Compare it with my solution:
public class ArrayList implements List {
private AbstractList = new AbstractList();
}
Nothing about the internals of ArrayList is exposed. You’re free to change the internals however you want. There’s no chance any outside code will depend on this implementation detail.
load more comments
(1 replies)
How do you implement an interface in C++ without an abstract class?
I know at least three ways, one of them involves variadic macros.
You don't even need to look that far, take any sufficiently aged library, like OpenGL.
load more comments
(2 replies)
Ask Bjarne to add interfaces enough many times until he gives in.
On a more serious note, I’m not exactly sure what the best C++ practice is. I guess you just have to live with abstract classes if you really want interfaces.
An abstract class with no member variables serves the same purpose in C++.
The only problem is to ensure the entire team agrees to only use it like an interface and nothing else. But I guess that’s the only proper way to do it in C++, for now.
load more comments
(2 replies)
The way I was taught was that you usually start off with only an interface and then implementing classes, and then once you have multiple similar implementations it could then make sense to move the common logic into an abstract class that doesn't get exposed outside of the package
I usually break it out using composition if that’s ever needed. Either by wrapping around all the implementations, or as a separate component that is injected into each implementation.
load more comments
(6 replies)
load more comments
(6 replies)
Instructions unclear, attempted to learn JS