5 ms·

> 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 ov

by 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
  mutable already exists and means something different from non-const. class foo { void b1(); void b2() const; void b3() mutable; } b1, b2, and b3 are all distinct.
  - harry8 7y ago
    Distinct indeed, they've got different names. If they're all called b1() then what? But you're hung up on "mutable" as a keyword. What is the semantics of b1(). The language could make them const semantics instead and so also provide a different keyword for 'non-const' maybe 'nonconst' would do if it really clashes with 'mutable' (I don't care if it is, I'm not proposing this to the committee as it's insane to be incompatible with existing code). When it was all just a twinkle in Bjarne's eye, he could have gone that way. Should have, say I.
- zvrba 7y ago
  > If "everything should be const unless it has to be mutable" is a reasonable position to take For a language like C++ I don't think that's a reasonable position. "Good" class design is about a class encapsulating some behavior and providing methods to access that behavior. Any "interesting" behavior is based on mutable state, whereas const methods are useful only as observers of the state. So "const" as default would make the code more cluttered... Heck, Java and C# don't even have const (though recent version of C# have added kind-of struct constness...) > sure, but that's also a workaround for something that would be nice if it were clear just by looking. In any sufficiently large program, nothing is clear just by looking. Such "local artifacts@ (like, explicit address-of operator) are irrelevant, the fewer the better. Writing `unique_lock<mutex> lk(&my_mutex)` would not add the tiniest bit of clarity compared to what you write now `unique_lock<mutex> lk(my_mutex)` > Is the function taking the arg by mutable reference because Dave forgot? That's easy to check: change it to const and see whether the method still compiles. > Documentation in the header, popped up by your ide/text editor? In the end, you always have to go to the function's definition and inspect it, and possibly follow the call chain further to find out what's really happening (i.e., the top-level call site is no longer relevant), and that's where IDEs shine. And no amount of syntax changes is going to save you from a const reference being aliased by a non-const one.
earenndil 7y ago
That's no different to a class having a pointer to memory outside the class, which is modified by the const member function.

by zvrba 7y ago

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
mutable already exists and means something different from non-const. class foo { void b1(); void b2() const; void b3() mutable; } b1, b2, and b3 are all distinct.
- harry8 7y ago
  Distinct indeed, they've got different names. If they're all called b1() then what? But you're hung up on "mutable" as a keyword. What is the semantics of b1(). The language could make them const semantics instead and so also provide a different keyword for 'non-const' maybe 'nonconst' would do if it really clashes with 'mutable' (I don't care if it is, I'm not proposing this to the committee as it's insane to be incompatible with existing code). When it was all just a twinkle in Bjarne's eye, he could have gone that way. Should have, say I.
zvrba 7y ago
> If "everything should be const unless it has to be mutable" is a reasonable position to take For a language like C++ I don't think that's a reasonable position. "Good" class design is about a class encapsulating some behavior and providing methods to access that behavior. Any "interesting" behavior is based on mutable state, whereas const methods are useful only as observers of the state. So "const" as default would make the code more cluttered... Heck, Java and C# don't even have const (though recent version of C# have added kind-of struct constness...) > sure, but that's also a workaround for something that would be nice if it were clear just by looking. In any sufficiently large program, nothing is clear just by looking. Such "local artifacts@ (like, explicit address-of operator) are irrelevant, the fewer the better. Writing `unique_lock<mutex> lk(&my_mutex)` would not add the tiniest bit of clarity compared to what you write now `unique_lock<mutex> lk(my_mutex)` > Is the function taking the arg by mutable reference because Dave forgot? That's easy to check: change it to const and see whether the method still compiles. > Documentation in the header, popped up by your ide/text editor? In the end, you always have to go to the function's definition and inspect it, and possibly follow the call chain further to find out what's really happening (i.e., the top-level call site is no longer relevant), and that's where IDEs shine. And no amount of syntax changes is going to save you from a const reference being aliased by a non-const one.

earenndil 7y ago

That's no different to a class having a pointer to memory outside the class, which is modified by the const member function.