-
Notifications
You must be signed in to change notification settings - Fork 5.5k
reference member #1809
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Related/Duplicate: #1707 |
We have this in C.12 so perhaps a PR to propose updates to that? |
I’m curious why this is desirable? Aren’t reference members (passed as constructor parameters) a perfectly valid way to do dependency injection in C++? |
(I'm ignoring the note - which is not a guideline; see #1707 about that one) While references as members can make a class somewhat unwieldy - non-assignable, non-movable - I can't say I understand why @BjarneStroustrup believes such members should be banned. I'm not even convinced they should be discouraged. When one wants a reference-type member, the three main options seem to be:
The appeal of a reference relative to the other two, is that it hides - when used - its referential nature: You use it as you would a value-type. It is often convenient or appealing to me as a class designer that my users don't have to say Personally, I would avoid references in a class I design as part of, say, the public API of a library. But for something internal which doesn't have to be super robust and has limited scope - I wouldn't strongly oppose their use. |
From my perspective, a guideline should discourage the use of reference members, as it makes lifetime management harder and may lead to dangling reference; |
@GuillaumeDua : Well, discourage is not as drastic than "almost always wrong"... But let me push back a little...
|
|
I think we need a rule banning reference members. All we have is a note: (Note that using a reference member is almost always wrong.)
The text was updated successfully, but these errors were encountered: