Apr
4
comment Why is “Select * from table” considered bad practice
@AdrianoVaroliPiazza: What he meant was that performance (via being explicit about columns) is a better reason to avoid * than the inability to access by column. He was NOT suggesting that * is a good thing.
Apr
3
comment Why is “Select * from table” considered bad practice
@jwenting: I think gbjbannb misunderstood you as saying that performance matters more than correctness, and then you affirmed this misunderstanding. What you originally said was performance is more correct than convenience, not correctness, which I think is far less disagreeable.
Mar
26
comment How to data model more than one 'last name'?
@FedericoPoloni: Anyone looking up a patient by the last name probably knows the patient's last name.
Mar
11
comment How can you decompose a constructor?
Named Parameter idiom
Feb
19
comment Is rethrowing an exception leaking an abstraction?
Exceptions should be about causes not about who throws them. If your code can have a file_not_found, then it should throw a file_not_found_exception. Exceptions should not be library specific.
Dec
5
revised Is there a known algorithm for scheduling tournament matchups?
added 273 characters in body
Aug
5
comment Undefined behaviour in Java
@SarvexJatasra: The why is simple, by not specifying certain behaviors, compilers can make optimizations that assume those behaviors never happen, causing faster programs, for whatever the target architecture may be. That's also why they refuse to fix it, removing the undefined behavior would force our programs to go slower on some processors.
Feb
25
awarded  Caucus
Oct
30
comment Simplifying C++11 optimal parameter passing when a copy is needed
Since you're using @ to represent perfect forwarding anyway, I'm pretty sure the std::forward<T> is redunant. (Especially since there's no T declared.)
Oct
30
comment Simplifying C++11 optimal parameter passing when a copy is needed
let us continue this discussion in chat
Oct
30
revised Simplifying C++11 optimal parameter passing when a copy is needed
added 39 characters in body
Oct
30
comment Simplifying C++11 optimal parameter passing when a copy is needed
@Mr.C64: I take it back, std::string is NOT constructable from an int. Sorry. I was thinking of vector<anything>. vector<anything> is constructable from an int, but not assignable from an int.
Oct
30
comment Simplifying C++11 optimal parameter passing when a copy is needed
Setters don't have initializers. If you changed that to std::is_assignable and {m_name = std::forward<T>(Name);}, then it'd still be wrong, since you defined string@ as perfect forwarding of something constructable to a std::string, not assignable. As I said in the answer, int to std::string is the counterexample here.
Oct
30
awarded  Commentator
Oct
30
comment Simplifying C++11 optimal parameter passing when a copy is needed
@Mr.C64: Yes, it can be suboptimal in some situations sometimes. Seriously, do it anyway. When the optimizer doesn't optimize it properly (which is rare), it is suboptimal by three pointer copies. Also, it's better code, which is far more important than a few measely pointer copies. Simpler Code = fewer mistakes = faster code.
Oct
30
revised Simplifying C++11 optimal parameter passing when a copy is needed
added 111 characters in body
Oct
30
awarded  Editor
Oct
30
revised Simplifying C++11 optimal parameter passing when a copy is needed
added 292 characters in body
Oct
30
comment Simplifying C++11 optimal parameter passing when a copy is needed
Also happens all the time if you don't know in advance what the type of the data member is. Like a container. Or an algorithm.
Oct
30
answered Simplifying C++11 optimal parameter passing when a copy is needed