const-cast

Automatic type deduction with const_cast is not working

由 喜欢而已 提交于 2019-12-10 21:47:12
问题 In my work the use of const_cast is under some circumstances unavoidable. Now I have to const_cast some pretty complicated types and actually I don't want to write all this type clutter in the const_cast<Clutter> expressions, especially if Clutter is very long. My first idea was to write const_cast<>(myType) , but my compiler cannot deduce the non-const type of myType . So I thought about helping my compiler and I deviced the following approach, which compiles. #include <stdlib.h> #include

static_cast and reference to pointers

由 余生长醉 提交于 2019-12-10 18:05:23
问题 Can anyone tell me why this doesn't compile: struct A { }; struct B : public A { }; int main() { B b; A* a = &b; B* &b1 = static_cast<B*&>(a); return 0; } Now, if you replace the static cast with: B* b1 = static_cast<B*>(a); then it does compile. Edit: It is obvious that the compiler treats A* and B* as independent types, otherwise this would work. The question is more about why is that desirable? 回答1: B is derived from A , but B* isn't derived from A* . A pointer to a B is not a pointer to

const_cast and UB

由 試著忘記壹切 提交于 2019-12-10 14:32:41
问题 $5.2.11/7 - "[Note: Depending on the type of the object, a write operation through the pointer, lvalue or pointer to data member resulting from a const_cast that casts away a const-qualifier68) may produce undefined behavior (7.1.5.1). ]" The wordings of this section (C++03) are surprising to me. What is suprising are two things. a) Firstly, the use of 'may'. Why is it 'may'? Other places in the Standard are very definitive about the undefined behavior b) Why is that the casting away the

Const casting empty base class

由 我的未来我决定 提交于 2019-12-10 13:36:41
问题 Is it undefined behavior to const_cast away an empty base class and call a non const method on it? For example class EmptyBase { public: void bar() { ... } }; class Something : public EmptyBase { public: void foo() const { const_cast<EmptyBase&>(static_cast<const EmptyBase&>(*this)).bar(); } }; I haven't been able to find relevant information in the standards (C++14 and C++17) that answers this.. 回答1: It's not UB in and of itself. You get undefined behavior when you cast away constness and

Using const_cast to add const-ness - bad idea?

由 回眸只為那壹抹淺笑 提交于 2019-12-07 17:22:03
问题 as we all know the usage of const_cast to remove the const-ness of a pointer should be avoided. But how is it about the other way around? For my use case I have a function that copies data (bytes) from a non-const source buffer. I thought a good design decision would be to declare the parameter according to that source buffer fully const. void copyfunction(const char* const data) { ... } For a function call like below this would lead to a pointer-type error 'const char* const <-> char*'. void

Using const_cast to add const-ness - bad idea?

由 只愿长相守 提交于 2019-12-06 02:05:06
as we all know the usage of const_cast to remove the const-ness of a pointer should be avoided. But how is it about the other way around? For my use case I have a function that copies data (bytes) from a non-const source buffer. I thought a good design decision would be to declare the parameter according to that source buffer fully const. void copyfunction(const char* const data) { ... } For a function call like below this would lead to a pointer-type error 'const char* const <-> char*'. void main() { char sourcebuffer[] = {0x00}; copyfunction(sourcebuffer); } Sure, now I could simply declare

Filling a std::array at compile time and possible undefined behaviour with const_cast

由 只谈情不闲聊 提交于 2019-12-06 00:47:45
问题 It is known that std::array::operator[] since C++14 is constexpr , see declaration below: constexpr const_reference operator[]( size_type pos ) const; However, it is also const qualified. This causes implications if you want to use the subscript operator of a std::array in order to assign values to your array at compile time. For example consider the following user literal: template<typename T, int N> struct FooLiteral { std::array<T, N> arr; constexpr FooLiteral() : arr {} { for(int i(0); i

Is this const_cast undefined behavior?

由 ￣綄美尐妖づ 提交于 2019-12-05 21:47:57
问题 I was wondering whether the following is undefined behavior // Case 1: int *p = 0; int const *q = *const_cast<int const* const*>(&p); // Case 2: (I think this is the same) int *p = 0; int const *const *pp = &p; int const *q = *pp; Is this undefined behavior by reading a int* as if it were a int const* ? I think it is undefined behavior, but I previously thought that only adding const in general is safe, so I'm unsure. 回答1: Qualification-wise, it's fine. With each expression split into a

Need clarifications in C-style, reinterpret, and const casts

由 丶灬走出姿态 提交于 2019-12-05 08:47:08
Am I right in assuming that C-style casts (which are discouraged) are nothing but reinterpret_casts? Using the latter is visually striking and easy to search when looking for nasty casts, and hence it's recommended over C-style casts? If casting away const using const_cast and writing to a originally const object is undefined, what is the purpose of const_cast? Note: I know that Bjarne rightly condemns casting operations that they are unsafe and even goes to the extent of stating "An ugly operation should have an ugly syntactic form." and hence the verbosity of casting operators in C++. So I

Compiler switch to disable const_cast semantics in c-style casts?

由 房东的猫 提交于 2019-12-05 08:29:48
Recently I stumbled over code such as this: void foo(const Bar* b) { ... takes_nonconst_param_fn((Bar*)b); ... Obviously, the developer didn't know what he was doing, but if the compiler hadn't silently accepted the c-style-cast and at least required a proper const_cast , he may have though twice before committing this. So this got me thinking, do any modern compilers have a switch to prevent const_cast semantics for c-style-casts? It's simply not practical to prevent all occurrences of c-style-casts and it's a necessary evil to allow their static_ and reinterpret_ semantics (if only for some
订阅 const-cast