41–47 of 47 posts
"auto a = ConjureMagic();" "SetMagic(a);" The problem here is actually is an old one of failing to separate a getter from a command. It looks like ConjureMagic is causing side effects and modifying the state of whatever class it belongs to. This is also the reason one can't answer the question "what the heck is a?". If the "ConjureMagic" is only a getter and does not modify class state, it may probably need a better…
Having Getters for each member variable always seems fine and reasonable. It's when you have getters that do "magic" that I feel a little.. unsure. Like if it's taking a member and returning it in a different unit that seems kosher... But there is a fuzzy line where at some point the Getter is doing too much work to genuinely be a getter. It gives a false impression for the internal structure of the program. But conv…
Earlier quoted context omitted.
I would be very surprised if someone can meaningfully review C++ templates without an IDE. Really not reviewing a program inside an IDE is a poor idea in general.
Some of us still use emacs and vim.
I'd be more than annoyed if I saw someone name a function "xxInteger()" because it returns an integer. I don't actually think the first example was that bad, modulo some context. Sometimes even knowing the type for this kind of thing isn't super important to understand what the code is doing; ala opaque types.
Apple publishes some very good guidelines for Objective-C and Swift, the latter here: https://swift.org/documentation/api-design-guidelines/
Generally, I'd name this method according to the role of the result, and not it's type. While "xxInteger()" isn't good, "numberOfXX()" returning an integer type does improve readability and would still be understandable assigned into an auto.
Remember, you're not writing code for you, you're writing code for future you. Or worse, for the next guy who comes into the codebase. They should be able to derive your intent without having to figure out what each method signature is, and reading all the API docs due to lack of code readability.
Earlier quoted context omitted.
Would you mind giving some examples? I don't find STL to be crap at all.
std::unordered_map ::iterator it = hashmap.begin(); vs auto it = hashmap.begin(); I find auto useful for cutting down some of the verbosity of templates STL containers, but I can see how over use can lead to code requiring much more referencing if maintaining code that rarely defines types.
No doubt auto is extremely useful in a case like the one you mentioned. In fact, even more so in here:
for (std::unordered_map*>::const_iterator it = a.begin(); ...)
Earlier quoted context omitted.
std::unordered_map ::iterator it = hashmap.begin(); vs auto it = hashmap.begin(); I find auto useful for cutting down some of the verbosity of templates STL containers, but I can see how over use can lead to code requiring much more referencing if maintaining code that rarely defines types.
Oh no, I agree with that. I was specifically talking about fenesiistvan's point about his STL wrapper. I was wondering what his use cases were. No doubt auto is extremely useful in a case like the one you mentioned. In fact, even more so in here: for (std::unordered_map *>::const_iterator it = a.begin(); ...)
So my hashmap handling looks like this:
MHashMap userlist = new MHashMap>();
HUser *user = userlist->First();
while(user) { user->DoSomething(); user = userlist->Next(); }
A lot of times, the type is unimportant but when it is, this kind of usage can bloat a simple task into 5 to 15 minutes of hunting through headers or grepping.
It's strange to think of an IDE feature so impacting a language feature. The stack is not supposed to affect in that direction but this is one case where it really does.