const-correctness

Const method that modifies *this without const_cast

╄→尐↘猪︶ㄣ 提交于 2019-11-27 04:26:03
问题 The following pattern has arisen in a program I'm writing. I hope it's not too contrived, but it manages to mutate a Foo object in the const method Foo::Questionable() const , without use of any const_cast or similar. Basically, Foo stores a reference to FooOwner and vice versa, and in Questionable() , Foo manages to modify itself in a const method by calling mutate_foo() on its owner. Questions follow the code. #include "stdafx.h" #include <iostream> using namespace std; class FooOwner;

What is the reason behind cbegin/cend?

僤鯓⒐⒋嵵緔 提交于 2019-11-27 02:32:50
I wonder why cbegin and cend were introduced in C++11? What are cases when calling these methods makes a difference from const overloads of begin and end ? Nicol Bolas It's quite simple. Say I have a vector: std::vector<int> vec; I fill it with some data. Then I want to get some iterators to it. Maybe pass them around. Maybe to std::for_each : std::for_each(vec.begin(), vec.end(), SomeFunctor()); In C++03, SomeFunctor was free to be able to modify the parameter it gets. Sure, SomeFunctor could take its parameter by value or by const& , but there's no way to ensure that it does. Not without

Why am I getting an error converting a ‘float**’ to ‘const float**’?

让人想犯罪 __ 提交于 2019-11-27 01:41:32
I have a function that receives float** as an argument, and I tried to change it to take const float** . The compiler ( g++ ) didn't like it and issued : invalid conversion from ‘float**’ to ‘const float**’ this makes no sense to me, I know (and verified) that I can pass char* to a function that takes const char* , so why not with const float** ? Sean See Why am I getting an error converting a Foo** → const Foo**? Because converting Foo** → const Foo** would be invalid and dangerous ... The reason the conversion from Foo** → const Foo** is dangerous is that it would let you silently and

Can a heap-allocated object be const in C++?

a 夏天 提交于 2019-11-27 01:20:37
问题 In C++ a stack-allocated object can be declared const : const Class object; after that trying to call a non-const method on such object is undefined behaviour: const_cast<Class*>( &object )->NonConstMethod(); //UB Can a heap-allocated object be const with the same consequences? I mean is it possible that the following: const Class* object = new Class(); const_cast<Class*>( object )->NonConstMethod(); // can this be UB? is also undefined behaviour? 回答1: Yes. It's legal to construct and destroy

Const correctness for value parameters

我与影子孤独终老i 提交于 2019-11-26 22:32:18
I know there are few question about const correctness where it is stated that the declaration of a function and its definition do not need to agree for value parameters. This is because the constness of a value parameter only matters inside the function. This is fine: // header int func(int i); // cpp int func(const int i) { return i; } Is doing this really a best practice? Because I've never seen anyone do it. I've seen this quotation (not sure of the source) in other places this has been discussed: "In fact, to the compiler, the function signature is the same whether you include this const

Logical const in D

南笙酒味 提交于 2019-11-26 21:47:22
问题 D has two types of constness: immutable variables are ones that were declared immutable, and always will be immutable, while const variables are simply read only versions of an object. Logical const is when a function is marked as const , but allows write access to one or more member variables. The typical use of this is for lazy evaluation, e.g. (in C++) struct Matrix { double determinant() const { if ( m_dirty ) { m_determinant = /* expensive calculation */; m_dirty = false; } return m

What are the use cases for having a function return by const value for non-builtin type?

风格不统一 提交于 2019-11-26 20:06:15
Recently I have read that it makes sense when returning by value from a function to qualify the return type const for non-builtin types, e.g.: const Result operation() { //..do something.. return Result(..); } I am struggling to understand the benefits of this, once the object has been returned surely it's the callers choice to decide if the returned object should be const? Basically, there's a slight language problem here. std::string func() { return "hai"; } func().push_back('c'); // Perfectly valid, yet non-sensical Returning const rvalues is an attempt to prevent such behaviour. However,

“const correctness” in C#

大兔子大兔子 提交于 2019-11-26 19:48:16
The point of const-correctness is to be able to provide a view of an instance that can't be altered or deleted by the user. The compiler supports this by pointing out when you break constness from within a const function, or try to use a non-const function of a const object. So without copying the const approach, is there a methodology I can use in C# that has the same ends? I'm aware of immutability, but that doesn't really carry over to container objects to name but one example. Trap I've come across this issue a lot of times too and ended up using interfaces. I think it's important to drop

Can const-correctness improve performance?

[亡魂溺海] 提交于 2019-11-26 17:30:37
问题 I have read numerous times that enforcing const-correctness in your C or C++ code is not only a good practice with regards to maintainability, but also it may allow your compiler to perform optimizations. However, I have read the complete opposite, too — that it does not affect performance at all. Therefore, do you have examples where const correctness may aid your compiler with improving your program's performance? 回答1: const correctness can't improve performance because const_cast and

Modifying a const through a non-const pointer

 ̄綄美尐妖づ 提交于 2019-11-26 15:33:24
I'm a bit confused what happened in the following code: const int e = 2; int* w = ( int* ) &e; // (1) cast to remove const-ness *w = 5; // (2) cout &lt&lt *w &lt&lt endl; // (3) outputs 5 cout &lt&lt e &lt&lt endl; // (4) outputs 2 cout &lt&lt "w = " &lt&lt w &lt&lt endl; // (5) w points to the address of e cout &lt&lt "&e = " &lt&lt &e &lt&lt endl; In (1), w points to the address of e. In (2), that value was changed to 5. However, when the values of *w and e were displayed, their values are different. But if you print value of w pointer and &e, they have the same value/address. How come e