4 ms·

No, see, that's the thing. It's annoying when you want to--and I apologize because it's been several years since I had to deal with this nonsense--copy elements

No, see, that's the thing. It's annoying when you want to--and I apologize because it's been several years since I had to deal with this nonsense--copy elements between logically compatible containers but ones whose types are differing in layers of constness. Or if you to, say, move a reference all the way down into a pointer (or vice versa) to interop with C or other legacy code. Or any of several other things, including some truly odd possibilities using operator and function overloading. It's just really gross as implemented.

CountSessine 11y ago
copy elements between logically compatible containers but ones whose types are differing in layers of constness. Or if you to, say, move a reference all the way down into a pointer (or vice versa) to interop with C or other legacy code. Or any of several other things, including some truly odd possibilities using operator and function overloading. And this is 'const''s fault? Others have asked - can you provide an example? Because what you're describing sounds like it's going to be a hot mess, const or no const. I don't really think that const can make bad data representation any worse than it already is.
cmma 11y ago
It sounds like you wanted to do something like this: std::vector<char*> vec1(...); std::vector<char const*> vec2(...); std::copy(vec1.begin(), vec1.end(), vec2.begin()); // works (1) std::copy(vec2.begin(), vec2.end(), vec1.begin()); // fails (2) If this compiled, the second example would invoke undefined behavior and crash if you attempted to write to an element that pointed to read-only memory (e.g., a string literal). Container element types are almost never declared const unless their values are truly immutable (in this case the pointer is mutable, but the underlying memory is not, which is kind of strange).
- cLeEOGPw 11y ago
  I think he just meant that: void foo(std::vector<char const* > &vec2) { ... } ... std::vector<char*> vec1(...); foo(vec1); // fails The idea is that you should be allowed to pass non-const vector to const function who accepts same vector (const or not const) with const variables. Because the function foo is like saying "give me vector, I will not modify it's elements", and with current C++ standard this is not allowed.
  - cmma 11y ago
    In that case, the question should be, why am I attempting to convert one concrete type to another concrete type? If you're writing a program, you should use the same type, std::vector<char* >, everywhere. If you're writing a library, the API should avoid including container details in function parameters, and const and non-const T should be allowed. template<typename Container> void foo1(Container const& c); template<typename Iterator> void foo2(Iterator first); template<typename Iterator> void foo3(Iterator first, Iterator last); template<typename Iterator> void foo4(Iterator first, std::size_t num); template<typename T> void foo5(std::vector<T> const& vec); void foo6(char const* const* first, std::size_t num); foo6 is a pretty good alternative here, imo: std::vector<char*> vec(...); foo6(&vec.front(), vec.size()); It would be cool if the compiler could figure templated type conversion out, but the crux of the issue is, as I understand it, that T<A> and T<A const> are not necessarily implemented the same way. Also note that std::vector<std::string const> won't compile -- it wouldn't be copy-assignable -- so these issues mostly seem to arise specifically when dealing with C strings and/or C compatibility. And reinterpret_cast is amazingly helpful for porting from C.
  - to3m 11y ago
    Even if you ignore the way that the types of template instantiations are (for good or for ill) unrelated, these two types are not compatible. Say this particular conversion were permitted. You have your function. (String literals are const char * .) void blah(vector<const char * > &xs) { xs.push_back("blah"); } And you have the code calling it: vector<char * > xs; blah(xs); And that would not be valid. The rationale for the conversion rules for pointers to pointers is based on a similar sort of problem. (In fact I think it's exactly the same problem, at any level, but that only just occurred to me, so perhaps not.) (This isn't to say there aren't other similar sorts of conversion that would be safe, and that the language perhaps should support, just that this isn't one of the valid ones.)
Gibbon1 11y ago
You are arguing with the Java People(tm), you cannot win this. Also: http://yosefk.com/c++fqa/const.html http://yosefk.com/c++fqa/const.html
golergka 11y ago
But that's exactly what is const is created for — preventing you from doing that. Why would you want to break the safeguards somebody has deliberately put in place?

CountSessine 11y ago

copy elements between logically compatible containers but ones whose types are differing in layers of constness. Or if you to, say, move a reference all the way down into a pointer (or vice versa) to interop with C or other legacy code. Or any of several other things, including some truly odd possibilities using operator and function overloading. And this is 'const''s fault? Others have asked - can you provide an example? Because what you're describing sounds like it's going to be a hot mess, const or no const. I don't really think that const can make bad data representation any worse than it already is.

cmma 11y ago

It sounds like you wanted to do something like this: std::vector<char*> vec1(...); std::vector<char const*> vec2(...); std::copy(vec1.begin(), vec1.end(), vec2.begin()); // works (1) std::copy(vec2.begin(), vec2.end(), vec1.begin()); // fails (2) If this compiled, the second example would invoke undefined behavior and crash if you attempted to write to an element that pointed to read-only memory (e.g., a string literal). Container element types are almost never declared const unless their values are truly immutable (in this case the pointer is mutable, but the underlying memory is not, which is kind of strange).

cLeEOGPw 11y ago
I think he just meant that: void foo(std::vector<char const* > &vec2) { ... } ... std::vector<char*> vec1(...); foo(vec1); // fails The idea is that you should be allowed to pass non-const vector to const function who accepts same vector (const or not const) with const variables. Because the function foo is like saying "give me vector, I will not modify it's elements", and with current C++ standard this is not allowed.
- cmma 11y ago
  In that case, the question should be, why am I attempting to convert one concrete type to another concrete type? If you're writing a program, you should use the same type, std::vector<char* >, everywhere. If you're writing a library, the API should avoid including container details in function parameters, and const and non-const T should be allowed. template<typename Container> void foo1(Container const& c); template<typename Iterator> void foo2(Iterator first); template<typename Iterator> void foo3(Iterator first, Iterator last); template<typename Iterator> void foo4(Iterator first, std::size_t num); template<typename T> void foo5(std::vector<T> const& vec); void foo6(char const* const* first, std::size_t num); foo6 is a pretty good alternative here, imo: std::vector<char*> vec(...); foo6(&vec.front(), vec.size()); It would be cool if the compiler could figure templated type conversion out, but the crux of the issue is, as I understand it, that T<A> and T<A const> are not necessarily implemented the same way. Also note that std::vector<std::string const> won't compile -- it wouldn't be copy-assignable -- so these issues mostly seem to arise specifically when dealing with C strings and/or C compatibility. And reinterpret_cast is amazingly helpful for porting from C.
- to3m 11y ago
  Even if you ignore the way that the types of template instantiations are (for good or for ill) unrelated, these two types are not compatible. Say this particular conversion were permitted. You have your function. (String literals are const char * .) void blah(vector<const char * > &xs) { xs.push_back("blah"); } And you have the code calling it: vector<char * > xs; blah(xs); And that would not be valid. The rationale for the conversion rules for pointers to pointers is based on a similar sort of problem. (In fact I think it's exactly the same problem, at any level, but that only just occurred to me, so perhaps not.) (This isn't to say there aren't other similar sorts of conversion that would be safe, and that the language perhaps should support, just that this isn't one of the valid ones.)

Gibbon1 11y ago

You are arguing with the Java People(tm), you cannot win this. Also: http://yosefk.com/c++fqa/const.html http://yosefk.com/c++fqa/const.html

golergka 11y ago

But that's exactly what is const is created for — preventing you from doing that. Why would you want to break the safeguards somebody has deliberately put in place?