By Ayxan

2019-05-10 13:43:57 8 Comments

Can I initialize a pointer to a data member before initializing the member? In other words, is this valid C++?

#include <string>

class Klass {
        : ptr_str{&str}
        , str{}
    std::string *ptr_str;
    std::string str;

this question is similar to mine, but the order is correct there, and the answer says

I'd advise against coding like this in case someone changes the order of the members in your class.

Which seems to mean reversing the order would be illegal but I couldn't be sure.


@Damon 2019-05-10 17:12:38

Funny question.

It is legitimate and will "work", though barely. There is a little "but" related to types which makes the whole thing a bit awkward with a bad taste (but not illegitimate), and which might make it illegal some border cases involving inheritance.

You can, of course, take the address of any object whether it's initialized or not, as long as it exists in the scope and has a name which you can prepend operator& to. Dereferencing the pointer is a different thing, but that wasn't the question.

Now, the subtle problem is that the standard defines the result of operator& for non-static struct members as "“pointer to member of class C of type T” and is a prvalue designating C::m".

Which basically means that ptr_str{&str} will take the address of str, but the type is not pointer-to, but pointer-to-member-of. It is then implicitly and silently cast to pointer-to.

In other words, although you do not need to explicitly write &this->str, that's nevertheless what its type is -- it's what it is and what it means [1].

Is this valid, and is it safe to use it within the initializer list? Well yes, just... barely. It's safe to use it as long as it's not being used to access uninitialized members or virtual functions, directly or indirectly. Which, as it happens, is the case here (it might not be the case in a different, arguably contrived case).

[1] Funnily, paragraph 4 starts with a clause that says that no member pointer is formed when you put stuff in parentheses. That's remarkable because most people would probably do that just to be 100% sure they got operator precedence right. But if I read correctly, then &this->foo and &(this->foo) are not in any way the same!

@Ben Voigt 2019-05-10 17:50:39

No, & with an unqualified name never creates a pointer-to-member. If you wanted a pointer-to-member, you would have to write &Klass::str. Similarly, &this->foo and &(this->foo) are the same, both create ordinary pointers because these are member-access expressions, not qualified names.

@Ben Voigt 2019-05-10 17:52:39

The Standard rule you link to starts out with "If the operand is a qualified-id" Which is why it does not apply here.

@Sneftel 2019-05-10 17:54:42

Moreover, there are no implicit conversions from a pointer-to-member type to a pointer type (what object would it bind to?).

@eerorika 2019-05-10 13:55:25

Does a member have to be initialized to take its address?


Can I initialize a pointer to a data member before initializing the member? In other words, is this valid C++?

Yes. Yes.

There is no restriction that operand of unary & need to be initialised. There is an example in the standard in specification of unary & operator:

int a;
int* p1 = &a;

Here, the value of a is uninitialized and it is OK to point to it.

What that example doesn't demonstrate is pointing to an object before its lifetime has begun, which is what happens in your example. Using a pointer to an object before and after its lifetime is explicitly allowed if the storage is occupied. Standard draft says:

[] Before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that represents the address of the storage location where the object will be or was located may be used but only in limited ways ...

The rule goes on to list how the usage is restricted. You can get by with common sense. In short, you can treat it as you could treat a void*, except violating these restrictions is UB rather than ill-formed. Similar rule exists for references.

There are also restrictions on computing the address of non-static members specifically. Standard draft says:

[class.cdtor] ... To form a pointer to (or access the value of) a direct non-static member of an object obj, the construction of obj shall have started and its destruction shall not have completed, otherwise the computation of the pointer value (or accessing the member value) results in undefined behavior.

In the constructor of Klass, the construction of Klass has started and destruction hasn't completed, so the above rule is satisfied.

P.S. Your class is copyable, but the copy will have a pointer to the member of another instance. Consider whether that makes sense for your class. If not, you will need to implement custom copy and move constructors and assignment operators. A self-reference like this is a rare case where you may need custom definitions for those, but not a custom destructor, so it is an exception to the rule of five (or three).

P.P.S If your intention is to point to one of the members, and no object other than a member, then you might want to use a pointer to member instead of pointer to object.

@Daniel Langr 2019-05-10 13:58:02

It would be nice to quote relevant parts of the Standard. These might be relevant: and

@eerorika 2019-05-10 14:05:29

@DanielLangr Thanks for looking those up.

@Brian 2019-05-10 14:57:28

There's a subtle difference between your example and the OP's example. In your example, the lifetime of the variable a has begun, but it was not initialized. In the OP's example, the address of a member is taken before its lifetime. Given that your quotations of the standard already adequately address the OP's question, I think the example should be deleted.

@eerorika 2019-05-10 15:10:26

@Brian OP's specifically asks about initialization. The quoted rule doesn't explicitly address initialization (no rule addresses it; there simply isn't a rule related to initialization to my knowledge). Sure, lack of lifetime implies lack of initialization, but I prefer to be explicit. In my opinion, the example demonstrating lack of initialization is useful even if it is technically made redundant by the lifetime rule.

Related Questions

Sponsored Content

6 Answered Questions

[SOLVED] How to directly initialize a HashMap (in a literal way)?

30 Answered Questions

[SOLVED] Initialization of an ArrayList in one line

24 Answered Questions

11 Answered Questions

[SOLVED] Static constant string (class member)

21 Answered Questions

[SOLVED] How to initialize all members of an array to the same value?

17 Answered Questions

[SOLVED] How to initialize private static members in C++?

15 Answered Questions

[SOLVED] Efficiency of Java "Double Brace Initialization"?

11 Answered Questions

[SOLVED] What does the explicit keyword mean?

7 Answered Questions

Sponsored Content