This question already has answers here:
When should you use constexpr capability in C++11?
(15 answers)
Closed 9 years ago.
I have a class which contains three static constants,
static const int NUM_POINTS = 2000;
static const float LAKE_THRESHOLD = 0.3;
static const int NUM_LLOYD_ITERATIONS = 2;
In the header file. I realize that now in C++11 I have to use a constexpr but I can't figure out how to use them. Can anyone explain constexpr in a simple way?
constexpr can be used to mark an expression as compile-time constant. It extends to functions as well, so an arbitrarily deep call chain can be compile-time constant. This permits the compiler to substitute the constant value, rather than evaluating it unnecessarily at runtime.
See: http://en.cppreference.com/w/cpp/language/constexpr
Related
This question already has answers here:
Literal initialization for const references
(3 answers)
Closed 2 years ago.
My understanding is that a const T& is internally implemented via a const T *const. If so, how is the below code valid (since we cannot take the address of 7)?
const int& i = 7;
Or does the compiler does some trick here? If so, what?
You cannot take the address of a literal like 7 but you can take the address of a temporary object whose value is 7.
Think of that line to be equivalent to
const int unnamed_temprary_variable = 7;
const int& i = unnamed_temprary_variable;
Or does the compiler does some trick here? If so, what?
The compiler does something analogous to the two lines I mentioned but it is not a trick. It is required by the language.
Searching for "extending the lifetime of temporaries" in SO resulted in a long list.
This question already has answers here:
How can this code be constexpr? (std::chrono)
(2 answers)
Closed 4 years ago.
As std::optional can change its state at runtime (i.e. an object is attached to it), how is it possible for the has_value() method and the bool operator to be constexpr, therefore evaluated at compile time?
constexpr does not mean it is always evaluated at compile time; it means that if you give a constant value (known at compile time), THEN the result will be const as well.
the constructor is constexpr
template < class U = value_type >
constexpr optional( U&& value );
thus you may fill an optional so that the compiler already knows at compile time the value is set.
std::optional<int> opt(3); // <- optional is valid
see
https://en.cppreference.com/w/cpp/utility/optional/optional
This question already has answers here:
When should you use constexpr capability in C++11?
(15 answers)
Closed 6 years ago.
So I understand that the use of constexpr in C++ is for defined expressions that are be evaluated at compile time, and more obviously to declare a variable or function as a constant expression. My confusion comes from understanding any benefits of using it for simple functions that will not change.
Suppose you have a function to simply square a value...
int square(int x) {
return x * x;
}
Typically that will never change, or be overridden, however, I've seen people say that it would be better practice to instead define it as...
constexpr int square(int x) {
return x * x;
}
To me, this seems like such a trivial change. Can anyone enlighten me on serious advantages of declaring such simple expressions as constexpr?
The advantage of that change is that whenever x is known at compile time, result of square could be used to initialize constexpr variables or as a template argument.
This question already has answers here:
Why are preprocessor macros evil and what are the alternatives?
(8 answers)
Is constexpr really needed?
(6 answers)
Closed 7 years ago.
You definetely know that macros are somewhat evil. With the relatively new keyword constexpr we can do a few good stuff we couldn't with const. E.g:
constexpr int GetVal()
{
return 40;
}
int arr[GetVal()];
And yeah...there are also many other usages for constexpr, like in constructors..etc.
Now the question is, is there any benefit of using it over #define macros?
edit
I know what can and what cannot be done with constexpr over macros which is what most of that question and its answers are all about. Here I'm explicitly asking what are the benefits of using constexpr over #define when BOTH can be used.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
When I add a static const char[] to my class as public field, the compiler gives me error, but with static const int it's fine. Why, and how can I fix it?
class example
{
public:
static const int num2 = 5;// fine
static const char num[] = "test";// problem
};
C++ language does not support in-class initializers for static members of non-integral and non-enum types. Members of integer and enum types are given special treatment. You can give them initializer right in the class definition. All other types have to be defined outside.
This is done that way because in large percentage of cases constant integral values are used as compile-time constants, as rvalues in the program. They do not require space in the actual storage (i.e. require no physical definition). And at the same time the compiler can benefit greatly from knowing the value of integral constants in each translation unit (e.g. optimizations, embedding integer operands directly into machine instructions etc.) This does not apply (or applies to a much lesser degree) to non-integral types.
You have to define your static member outside of the class and provide an initializer there.
class example
{
public:
static const int num2 = 5;
static const char num[];
};
const char example::num[] = "test";
Just keep in mind that to obey ODR, the member definition has to be placed into one and only one implementation file. Don't try placing it into a header file.