It is always applied to what comes right before it. However, when there is nothing before, it applies to what comes right after it. In other words, const Type& is the same as Type const& . Then, you are doing stuff on the pointee but this time it's the pointer, not the pointee, that is const , so everything is fine.
Encountering const after * means the const qualifier is applied to a pointer declaration; encountering it prior to the * means the qualifier is applied to the data pointed to. Because the semantic meaning does not change if the const qualifier appears before or after the type specifiers, it is accepted either way.
Concerning objects (especially strings), call by reference is faster than call-by-value because the function call does not need to create a copy of the original object. Using const, one can also ensure that the reference is not abused.
Pass Using Const Reference in C++ Now, we can use the const reference when we do not want any memory waste and do not change the variable's value. The above code will throw a compile error as num = num +10 is passed as a const reference.
There is no semantic difference between const T&
and T const&
; the language treats them as the same type. (The same thing applies to const T*
and T const*
.)
Regarding which you should prefer stylistically, however, I'll dissent from a lot of the other answers and prefer const T&
(and const T*
):
const T&
is the style used in Stroustrup's The C++ Programming Language book.const T&
is the style used in the C++ standard itself.const T*
is the style used in K&R's The C Programming Language book.const T*
is the style used in the C standard.const T&
/const T*
have way more inertia than T const&
/T const*
. const T&
/const T*
empirically seem way more common to me than T const&
/T const*
in all of the C++ and C code that I've seen. I think following common practices is more readable than dogmatically adhering to right-to-left parsing rules.T const*
, it seems easier to misplace the *
as T* const
(especially if people aren't as accustomed to it). In contrast, const* T
is not legal syntax.Regarding the whole right-to-left parsing argument that people seem to love to use: as I mentioned in a comment to another answer, const T&
reads fine right-to-left too. It's a reference to a T constant. "T" and "constant" each can work as an adjective or a noun. (Additionally, reading T const*
right-to-left can be ambiguous since it could be incorrectly interpreted as "pointer constant to T" instead of as "pointer to constant T".)
No difference as const is read right-to-left with respect to the &, so both represent a reference to an immutable Fred instance.
Fred& const
would mean the reference itself is immutable, which is redundant; when dealing with const pointers both Fred const*
and Fred* const
are valid but different.
It's a matter of style, but I prefer using const
as a suffix since it can be applied consistently including const member functions.
Though they are one and the same, to retain consistency with the RIGHT-LEFT rule about parsing C and C++ declarations, it is better to write Fred const &arg
Also refer this for developing more understanding about declarations, qualifiers and declarators.
Both work, and here is the explanation from the man who wrote it.
To quote him:
Why? When I invented "const" (initially named "readonly" and had a corresponding "writeonly"), I allowed it to go before or after the type because I could do so without ambiguity.
No difference, both are syntactically and semantically same.
No difference http://c-faq.com/ansi/constptrconst.html
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With