5 ms·

Unnecessary is a question of taste, right? foo(void) seems less likely to cause confusion to anyone who hasn't got that C vs C++ distinction uppermost in their

• hermitdev 7y ago
  I largely agree with what you say, but can you elaborate on what you mean by "macho coding" styles? I'm guessing youre referring to when one deigns venture into template metaprogramming. TMP is an area with 2 decades of experience, I can basically only do it with a copy of the standard and/or relevant reference material handy. Although I'd consider my C++ knowledge in the 95th percentile or so, I probably know less than 20% of the std lib well. I've read most of the +1200 pages of the C++11 spec, but ive not kept up to date since, sadly, because its no longer my daily language.
  • harry8 7y ago
    What I mean is anything that is showing off, has a lack of humility and implicitly disparages others in a way that is totally unneeded while producing lower-quality, less-maintainable, less robust code. Being clever for the sake of appearing clever. That kind of thing. if(condition) I_am_tough_so_I_do_not_brace(); The un-braced block is a classic "macho" pose in code. leaving out a '{' and a '}', two characters, has no benefit in any way, shape or form. It is decrying "I will never make a mistake with this loose razor blade if you do maintaining it is because you suck" There is literally no reason to do it ever, under any circumstances. Yet I have, and we do. We can change. Now watch the arguments presented when you bring un-braced blocks up. They're insanely ridiculous. (vertical space, need static analysis, etc.) If you were betting your retirement savings on no bug in the line of code now or in the future, you'd be very nervous about it sure. And then you would brace it. Unbraced blocks are a minor thing that mostly don't matter. I wouldn't fight too hard over it. It's just that it's so very, very clear that one way is bugs for zero benefit while the other isn't. Meh. So here's Bjarne being "Uber-Macho" to the delight of the conference crowd. Note the quote: "I think I understand what you're saying and I think you happen to be wrong." (crowd whoops in glee). https://youtu.be/OB-bdWKwXsU?t=4141 https://youtu.be/OB-bdWKwXsU?t=4141 This is a pretty ugly way of saying "I disagree and this is why..." But the crowd loves it. That attitude gets into our code. "Macho coding" is the best descriptive name I can manage. Maybe there's a better one? (Note I agree with the content of Bjarne says, I just think he's being an asshole about it, why do that? https://www.urbandictionary.com/define.php?term=Waltersobchakeit https://www.urbandictionary.com/define.php?term=Waltersobcha... )
• zvrba 7y ago
  > Other than following the style of the project you're working on is there any reason to use a reference ever over say a const pointer? One reason is to use overloaded operators. With pointers, adding two matrices which are arguments to a function would look like `( <star>a ) + ( <star>b )` (using asterisk makes the text italic); with references it's just `a+b`. Another, stylistic, reason for which I use references is as a hint for two things: 1) the parameter is NOT optional (whenever you see a pointer parameter you wonder whether it can be null), and 2) that no ownership is transferred. For these reasons, unless I actually need a pointer (e.g. optional parameter), I use references: less syntactic clutter at both call-site and use-site. With a decent IDE, it's easy to see how the parameter is passed. > And member functions defaulting to const That wouldn't fly and in many scenarios it wouldn't make sense because whether an operation is "const" is unclear. Like, you have a class representing a socket, and methods like read, write and close. None of the methods change the in-memory contents of the class (so, yes they're technically const), yet their behavior changes depending on the sequence in which they're called, e.g., calling close before write instead of the other way around (so no, they're not really const).
  • harry8 7y ago
    const by default: I think I explained badly or you read too much into it or both. This is pure syntactic sugar I'm talking about. Instead of marking const member functions const, you mark functions which aren't const "mutable." Literally no change to the semantics of the language, just which one is assumed if you leave it blank. Right now it's mutable by default if you do nothing, it could just as easily have been const, you need to be able to tell the compiler which one you mean with a keyword whichever one is chosen to be represented by no token. If "everything should be const unless it has to be mutable" is a reasonable position to take - which many seem to, then it should be the default, right? Too late for that now. (<star>a) + (<star>b) yeah it's reasonable use. I can't say I care much. Obviously need references for the return value of an operator overload too if you're having operator overloading. It's reasonable. Doesn't thrill me, people have different taste on it which is reasonable too.. IMHO if the answer is "IDE" that's a workaround to a language issue and it may not be a big language issue either but it exists. C++ and Java both have some of that. Is the function taking the arg by mutable reference because Dave forgot? Or was did he have constication hell and a deadline so applied prune juice liberally? Or is it an output? Documentation in the header, popped up by your ide/text editor? sure, but that's also a workaround for something that would be nice if it were clear just by looking.
• kllrnohj 7y ago
  > Other than following the style of the project you're working on is there any reason to use a reference ever over say a const pointer? Yes, definitely. It codifies nullability. const pointers should _typically_ be const references instead, see https://google.github.io/styleguide/cppguide.html#Reference_Arguments https://google.github.io/styleguide/cppguide.html#Reference_... > Maybe in another world everything would be const by default and have to be marked mutable then references might go away I'd definitely +1 a references are const by default, but that would not make references go away at all. You'd still have references (non-null) and pointers (null) just for the reason of non-null vs. null. This is a very useful distinction. So much so Kotlin built an entire language around it. > The syntax then makes it clear you're not dealing with a pass-by-value copy. Which is not a useful behavior difference. If it's const why do you care if it's pass-by-value or pass-by-reference? It doesn't change behavior and it doesn't even tell you anything about the performance of the call (there are plenty of pass-by-pointer calls that are slow and plenty of pass-by-value that are not - it depends on the size of the argument, and what the function is doing)
  • harry8 7y ago
    when you read a function call foo(bar, baz, bajinga); Which of those are pass by value, by reference or by const reference? I say it would be useful to know that by inspection from just reading that line of code. You don't have to agree. And you care about by value vs by reference because copy constructors exist and you need to reason about performance or if you don't need to why are you using c++ anyway? You mostly care whether it's by value or by reference because what is passed could be altered with the latter unless it's marked const. But which is it? Stop! Stop what you're reading right now and go and look at the foo() signature. 9 times in 10 you won't be surprised, the arguments should not be altered by the function call but you might want to check that, then get back to whatever you were actually trying to understand with a break in the flow of your understanding and the prospect of some context fading slightly from your short term memory. But yeah some people are so smart that there is literally nothing in coding readability they need and sneer at those of us who take a different approach. Such people never make mistakes. Twas ever thus, well before C++.
    • 7y ago