|
Boost : |
Subject: Re: [boost] [type_traits][function_types] Discard param const qualification, bug or feature?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-09-29 21:18:43
On 9/30/2013 10:44 AM, Quoth Sergey Zhuravlev:
> Signature type int(int, const std::string) can be used as parameter for
> some compiletime algorithm. For example, algorithm that generate new
> signature type with optimal transfer arguments int (int, const
> std::string&) or generate signature with all argument references int (int&,
> const std::string&)
> Can't use type_traits, function_types at that cases, because const be
> omitted. This will lead to compiletime error, if function with first
> signature call function with second signature and use arguments from
> function with first signature for this call.
This was discussed recently; there is no difference between the
following two signatures:
int func(int a, std::string b);
int func(int a, const std::string b);
Both describe a function that accepts two parameters and returns an int
value; the first parameter being an int passed by value and the second
parameter being a std::string passed by value. "const" does nothing to
any outside code -- its only effect is to artificially restrict the
allowed behaviour inside the implementation of the function. In neither
case can the implementation affect the original string object passed by
the caller (unless the string's copy constructor is broken), so
constness cannot be part of the interface.
ie. it's perfectly valid to declare a function as the first in a header
file and then implement it as the second in a cpp file.
When the string is passed by reference, the presence or absence of
"const" does make a difference, and it should be (and is) preserved.
This *is* an interface detail as it indicates to the caller whether the
object can be modified or not by the implementation.
Can you describe (with code) what your actual problem is and why this is
giving you trouble?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk