Ttdfjt

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

#include <string>

class Klass 
public:
 Klass()
 : ptr_str&str
 , str
 
private:
 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.

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

No.

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:

[basic.life] 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.

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 contrieved case).