Calculator should use constexpr when defining static const strings about calculator HOT 10 CLOSED

static constexpr char s[] = "Hello";

from calculator.

This is your friendly Microsoft Issue Bot. I created this issue automatically as requested by a team member.

from calculator.

What exactly do you mean by strings? const char* s ="Helllo"; is a compiletime constant. std::string on the other hand can't be made constexpr anyway.

from calculator.

Ideally, we move to this as standard for our string constants.

constexpr auto s = L"Hello";

from calculator.

Nothing against it but is there any difference between that and const auto s = L"Hello" ?

Just curious.

from calculator.

Nothing against it but is there any difference between that and const auto s = L"Hello" ?

Just curious.

L"Hello"
L Marks that the string will be always widechar.

from calculator.

Thanks, but my question was not about L"" vs "", but constexpr auto s = L"Hello" vs const auto s = L"Hello".

from calculator.

Thanks, but my question was not about L"" vs "", but constexpr auto s = L"Hello" vs const auto s = L"Hello".

I believe the only difference is that the constexpr version is available for use with other constexpr expressions during compilation, whereas the const form is not created until static are initialized at runtime.

from calculator.

Im pretty confident that the the "normal" const version will not cause initialization at run-time. But you are probably right about use in constexpr expressions - I haven't tried top use "nornal" global const variables in quite some time now. That's why I was asking.

from calculator.

I think you're right, see the doc on constant initialization.

In practice, constant initialization is performed at compile time, and pre-calculated object representations are stored as part of the program image (e.g. in the .data section). If a variable is both const and constant-initialized, its object representation may be stored in a read-only section of the program image (e.g. the .rodata section)

So is this issue even needed or should we close it? Right now I would say this is low priority and falls into the bucket of general codebase improvement/best-practices.

from calculator.