Screenshots?

Screenshots?

Here you go

@LennyMcLennington What do you want changed?

@LennyMcLennington if I make it an enum, I would need it to have a function that returns a string constant based on the value, do you have a preferred way of implementing that or just hardcode everything in that said function?

@LennyMcLennington if I make it an enum, I would need it to have a function that returns a string constant based on the value, do you have a preferred way of implementing that or just hardcode everything in that said function?

just use a QMap<LoaderType, QString>

@Sneedplex That's a very bad idea for a couple of reasons:

1. The data is mutable
2. It adds CPU strain because of hashing
3. It uses more memory than needed

I was going to make an enum of values, where I can then have a function where you pass in the value and returns a char const *.

1. const exists for a reason
2. if your CPU can't handle a single enum hash then it might be over for you
3. oh no a whole 100 bytes

@Sneedplex @AutumnalModding This is how software turns to shit, people like you. No wonder modern software takes years to open for example, you just don't give a shit at all. It would be much faster to just return a fucking address and doing a simple comparison on the enum value. Or make a static constant array, and use the enum value as an index. You just add complexity.

It's 100 bytes of memory and a picosecond of computation time. If you're that concerned about micro-optimizations then you wouldn't be using Qt, create your own shitty CLI launcher in x86 assembly.

@crueter @xslendix @Sneedplex Instead of whining or speculating I have prepared some example code for you:

switch https://godbolt.org/z/z1bTW5v98
array https://godbolt.org/z/oMdreervn
map https://godbolt.org/z/qedP1h74v
unordered_map https://godbolt.org/z/TYn3hYd8Y

Honestly, I don't care which approach you take or if you take a completely different approach, I just want it to not have arbitrary strings floating around in random parts of the code.

I've arranged them in order of my personal preference of how I would probably do it from a balance of code readability/maintainability and performance. But I really don't care because they all solve my nitpick.

Also please try not to use Qt containers when a standard one suffices, except when the Qt container provides some additional functionality that you require over the standard one. Qt already has excellent support for the standard containers, I don't want any new code written to use Qt specific containers unless it's actually a hard requirement.

Also I just had the thought that since we're on C++17 now we could also use std::optional instead of throwing ig.

these old PRs are so irritating because none of them build properly thanks to the QList<>::iterator change that I cba to fix every time

these old PRs are so irritating because none of them build properly thanks to the QList<>::iterator change that I cba to fix every time

@Sneedplex can't you just rebase it and then force push?

these old PRs are so irritating because none of them build properly thanks to the QList<>::iterator change that I cba to fix every time

@Sneedplex can't you just rebase it?

Yeah but I don't want to push when I've rebased the entirety of develop onto the branch and it's annoying to go back.

@xslendix i need to push a quick fix turn on maintainer edits again.

Yeah but I don't want to push when I've rebased the entirety of develop onto the branch and it's annoying to go back.

@Sneedplex if you want to rebase the PR onto develop and force push that's fine.