Initialization of static non-const and general purpose class members

[Rick C. Hodgin]

Why can't I do this (what is the reasoning behind the decision to
prohibit this from occurring at compile-time)?

class xyz
{
public:
xyz();
~xyz();

private:
static char abc[] = "abc text";
}

I don't understand why that would not be allowed. In my thinking,
it would resolve to a public variable that's observable only
through/to a class, so that its token name is in scope only there,
and there is only one instance of that value per class, one which
is populated at startup.

In my thinking it could even be aliased to global memory so that
the compiler treats it as though you had done this (giving it a
unique internal name so there are no name collisions, but the
principle would still be the same):

static char abc[] = "abc text";

class xyz
{
public:
xyz();
~xyz();
}

Thank you,
Rick C. Hodgin

[Alf P. Steinbach]

On 13-Mar-17 4:59 PM, Rick C. Hodgin wrote:
> Why can't I do this (what is the reasoning behind the decision to
> prohibit this from occurring at compile-time)?
>
> class xyz
> {
> public:
> xyz();
> ~xyz();
>
> private:
> static char abc[] = "abc text";

> };

(Missing semicolon added – please do post real code.)

It's for the same reason that you can't do

class Oh { auto x = 3.14; };

… even though you can do

auto x = 3.14;

… in namespace scope or local scope in a function.

As far as I know that reason is that variable declarations, data member
declarations and formal function argument declarations have /evolved/,
somewhat haphazardly and independently.

> I don't understand why that would not be allowed. In my thinking,
> it would resolve to a public variable that's observable only
> through/to a class, so that its token name is in scope only there,
> and there is only one instance of that value per class, one which
> is populated at startup.

There's much that C++ could automate for you, but doesn't.

Still, what you /can/ do is quite simple, once you know about it:


#include <iostream>
using namespace std;

struct xyz
{
static constexpr auto& abc = "abc text";
};

auto main()
-> int
{
cout << xyz::abc << endl;
}



Cheers & hth.,

- Alf

[David Brown]

On 13/03/17 16:59, Rick C. Hodgin wrote:
> Why can't I do this (what is the reasoning behind the decision to
> prohibit this from occurring at compile-time)?
>
> class xyz
> {
> public:
> xyz();
> ~xyz();
>
> private:
> static char abc[] = "abc text";
> }

It is allowed if you have:

static constexpr const char abc[] = "abc text";

For non-integral members, you have to have a "constexpr const" to be
able to initialise them inside the class definition, rather than outside
it. I don't know why that is the case.

[Öö Tiib]

On Monday, 13 March 2017 23:23:51 UTC+2, David Brown wrote:
>
> It is allowed if you have:
>
> static constexpr const char abc[] = "abc text";
>
> For non-integral members, you have to have a "constexpr const" to be
> able to initialise them inside the class definition, rather than outside
> it. I don't know why that is the case.

Is here any difference with just plain 'constexpr' (without 'const')?

I know that with pointers there is really difference so in following 'const'
matters:

static constexpr char const* abc = "abc text";

I always try to write const right of type (or *) since IMHO that makes
more clear that 'const' above is about 'char' but 'constexpr' is
about 'abc'.
However I don't think that this applies to array so isn't const about
constexpr array just redundant?