I'm playing with the new template variables feature from C++14 in order to get used to it (maybe is soon to do this 'cause it seems that some compilers didn't implement it completely).
Now I'm wondering where lies each instance of a template variable. In the tests I did so far they seem to be initialized before any static data so I'm wondering if they're placed in the data segment of the program. Let's see what I've tryed so far, I have a class which prints information on construction and destruction:
struct squealer
{
squealer(std::string a_name) : m_name(a_name) { std::cout << this << ' ' << m_name << ' ' << __PRETTY_FUNCTION__ << '\n'; }
~squealer() { std::cout << this << ' ' << m_name << ' ' << __PRETTY_FUNCTION__ << '\n'; }
void f() {}
const std::string m_name;
};
And a program which instances some squealers in local storage, static storage and as template variables, this is the program:
// static storage squealer
squealer s("\"static\"");
// template variable squealer
template <int i> squealer test(std::string(i, 'A'));
// function using a template variable squealer
void f() { test<1>.f(); }
int main(int argc, char **argv)
{
// local storage squealer
squealer ss("local");
// using another template variable squealers
test<2>.f();
switch (argc)
{
case 1: test<3>.f(); break;
case 2: test<4>.f(); break;
case 3: test<5>.f(); break;
case 4: test<6>.f(); break;
}
return 0;
}
Here is the program and this is the output:
A squealer::squealer(std::string)
AA squealer::squealer(std::string)
AAA squealer::squealer(std::string)
AAAA squealer::squealer(std::string)
AAAAA squealer::squealer(std::string)
AAAAAA squealer::squealer(std::string)
"static" squealer::squealer(std::string)
local squealer::squealer(std::string)
local squealer::~squealer()
"static" squealer::~squealer()
AAAAAA squealer::~squealer()
AAAAA squealer::~squealer()
AAAA squealer::~squealer()
AAA squealer::~squealer()
AA squealer::~squealer()
A squealer::~squealer()
As we can see, all the template variables squealer instances are created before the one named "static" and at the end (as expected) the one named local is created, the destruction order is the opposite (as expected too), so: the order of creation/initialization of template variables instances is the same of its appearance on the code regardless of the locality of this appearance and regardless of they're used or not (the f() function is never called).
So the first question is, are this template variables placed on the data segment? I don't know how to test or check it.
The second question is, are all of this template variables squealer instances thread safe? I've readed on n3376 §6.7 the following sentence (emphasis mine):
An implementation is permitted to perform early initialization of other block-scope variables with static or thread storage duration under the same conditions that an implementation is permitted to statically initialize a variable with static or thread storage duration in namespace scope (3.6.2). Otherwise such a variable is initialized the first time control passes through its declaration; such a variable is considered initialized upon the completion of its initialization. If the initialization exits by throwing an exception, the initialization is not complete, so it will be tried again the next time control enters the declaration. If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.
From C++11 if all of the template variable squealer instances are in static storage they should be thread safe, isn't it?
Thanks.
The section of the standard you quote describes block-scope variables with static storage duration, e.g:
int foo() {
static int bar = 42;
return bar;
}
of which your program has none. All of your variables with static storage duration are declared at namespace scope, so you need to be looking at [basic.start.init] (3.6.2). Specifically paragraph two which states:
Variables with static storage duration (3.7.1) or thread storage duration (3.7.2) shall be zero-initialized (8.5) before any other initialization takes place.
...
Dynamic initialization of a non-local variable with static storage duration is unordered if the variable is an implicitly or explicitly instantiated specialization, and otherwise is ordered [ Note: an explicitly specialized
static data member or variable template specialization has ordered initialization. —end note ] Variables with ordered initialization defined within a single translation unit shall be initialized in the order of their
definitions in the translation unit. If a program starts a thread (30.3), the subsequent initialization of a variable is unsequenced with respect to the initialization of a variable defined in a different translation unit. Otherwise, the initialization of a variable is indeterminately sequenced with respect to the initialization of a variable defined in a different translation unit. If a program starts a thread, the subsequent unordered initialization of a variable is unsequenced with respect to every other dynamic initialization. Otherwise,
the unordered initialization of a variable is indeterminately sequenced with respect to every other dynamic initialization.
In the question's program, all the squealer instances with static storage duration must be dynamically initialized since squealer has a member std::string that cannot be constant-initialized. ::s has ordered initialization, and all of the instances of test have unordered initialization since each is an "implicitly or explicitly instantiated specialization" of the template test. The test instances are guaranteed to be initialized before entering main, but otherwise all bets are off: they may be initialized in any order, possibly before and/or after initialization of ::s and more importantly std::cout. Those initializations are notably not thread-safe: "If a program starts a thread, the subsequent unordered initialization of a variable is unsequenced with respect to every other dynamic initialization."
Variable template specializations are static variables as stated by [temp.inst]/12:
Implicitly instantiated class, function, and variable template specializations are placed in the namespace where the template is defined.
Therefore, usual static initialization rules apply, which means that all specializations are initialized before main() executes.
Related
In the C++11 specification, basic.start.term 1 states:
If the completion of the constructor or dynamic initialization of an object with static storage
duration is sequenced before that of another, the completion of the destructor of the second is sequenced
before the initiation of the destructor of the first. [ Note: This definition permits concurrent destruction.
—end note ]
In C++03, my destructors were ordered. The order may not be specified, but they were ordered. This was very useful for static objects that had to register themselves. There was no concept of multithreading in the spec, so the spec had no concept of unordered destructors. The compilers that implemented multithreading that I know of did destruction in a single-threaded environment.
a.cpp:
struct A
{
A()
: mRegistration(0)
{ }
~A()
{
if (mRegistration)
tryUnregisterObject(mRegistration);
}
void registerNow()
{
mRegistration = registerObject(this);
}
};
A myA;
b.cpp:
class Registrar
{
public:
Registrar()
{
isAlive = true;
}
~Registrar()
{
isAlive = false;
}
...
};
bool isAlive = false; // constant initialization
static Registrar& registrar()
{
static Registrar instance;
return instance;
}
int registerObject(void* obj)
{
registar().register(obj);
}
void tryUnregisterObject(void* obj)
{
if (isAlive) {
registrar().unregister(obj);
} else {
// do nothing. registrar was destroyed
}
}
In this example, I can't guarantee the order of destruction for myA and Registrar because they're in different compilation units. However, I can at least detect what order they occurred in and act accordingly.
In C++11, this approach creates a data race around the isAlive variable. This can be solved during construction because I can create a synchronization object like a mutex to protect it when I first need it. However, in the destruction case, I may have to check isAlive after my mutex has been destroyed!
Is there a way to get around this in C++11? I feel like I need a synchronization primitive to solve the problem, but everything I've tried leads to the primitive getting destroyed before its done protecting what I need to protect. If I were to use the Windows or PThreads threading primitives, I could simply elect to not call the destructor and let the OS clean up after me. However, C++ objects clean themselves up.
[basic.start.init]/2 If a program starts a thread (30.3), the subsequent initialization of a variable is unsequenced with respect to the initialization of a variable defined in a different translation unit. Otherwise, the initialization of a variable is indeterminately sequenced with respect to the initialization of a variable defined in a different translation unit. If a program starts a thread, the subsequent unordered initialization of a variable is unsequenced with respect to every other dynamic initialization. Otherwise, the unordered initialization of a variable is indeterminately sequenced with respect to every other dynamic initialization.
(Emphasis mine.) Therefore, as long as you don't start threads in any of your static objects' constructors, you have the same guarantee as in earlier versions of the standard.
I've been struggling with a destructor call order which I cannot really understand.
Say we have the following definitions:
#include <memory>
#include <iostream>
class DummyClass {
std::string name;
public:
DummyClass(std::string name) : name(name) { std::cout << "DummyClass(" << name << ")" << std::endl; }
~DummyClass() { std::cout << "~DummyClass(" << name << ")" << std::endl; }
};
class TestClass {
private:
static DummyClass dummy;
static DummyClass& objects() {
static DummyClass dummy("inner");
return dummy;
}
public:
TestClass() {
std::cout << "TestClass" << std::endl;
std::cout << "TestClass Objects is: " << &objects() << std::endl;
}
virtual ~TestClass() {
std::cout << "~TestClass Objects is: " << &objects() << std::endl;
std::cout << "~TestClass" << std::endl;
}
};
DummyClass TestClass::dummy("outer");
Now, If I instantiate the TestClass as follows:
TestClass *mTest = nullptr;
int main() {
mTest = new TestClass(); delete mTest;
return 0;
}
The output obtained is the one I would expect:
DummyClass(outer)
TestClass
DummyClass(inner)
TestClass Objects is: 0x....
~TestClass Objects is: 0x....
~TestClass
~DummyClass(inner)
~DummyClass(outer)
But, now, if I use a shared_ptr for mTest, like:
std::shared_ptr<TestClass> mTest;
int main() {
mTest = std::make_shared<TestClass>();
return 0;
}
the output produced is:
DummyClass(outer)
TestClass
DummyClass(inner)
TestClass Objects is: 0x....
~DummyClass(inner)
~TestClass Objects is: 0x....
~TestClass
~DummyClass(outer)
Can someone explain why is the DummyClass inner object being destroyed before the end of the TestClass object destructor, in this particular case?
I found consistent behavior for gcc 5.2.0 using -std=gnu++11 and clang 3.8.0 with -std=c++11 but could not find any particular documentation citing this example.
Edit: To clarify: all of the code above was written in the same translation unit (*.cpp file) in the presented order. It is a simplification of a usage case where I have a header only class definition which must hold a static list of this pointers to derived class objects. These pointers are added via ctor and removed when the dtor is reached. The problem is triggered when destroying the last object. The list is kept inside a static method and accessed through it to achieve the header only goal.
The rules for all objects with static storage duration (namespace members, static class members, and static objects in function definitions) are:
If the entire initialization can be considered a constant expression, that initialization happens before anything else. (Doesn't apply to anything in your examples.) Otherwise,
Namespace members and static class members are guaranteed to begin initialization at some point before any function in the same translation unit is called. (In most implementations, if we ignore dynamic library loading, all of these happen before main begins. In your examples, since main is in the same TU, we know they happen before main.)
Namespace members and static class members defined in the same TU begin their initializations in the order of their definitions.
For namespace members and static class members defined in different TUs, there is no guarantee on order of initialization!
Static objects defined inside a function begin their initialization the first time program control reaches the definition (if ever).
When main returns or std::exit is called, all objects with static storage duration are destroyed in order opposite to when each completed its initialization.
So in your second example:
Initialization of TestClass::dummy begins. First a temporary std::string is created, and then DummyClass::DummyClass(std::string) is called.
The DummyClass constructor does a std::string copy, then outputs "DummyClass(outer)\n". The temporary std::string is destroyed. Initialization of TestClass::dummy is complete.
Initialization of ::mTest begins. This calls std::shared_ptr<TestClass>::shared_ptr().
The shared_ptr constructor sets up the smart pointer to be null. Initialization of ::mTest is complete.
main begins.
The std::make_shared call ends up creating a TestClass object, calling TestClass::TestClass(). This constructor first prints "TestClass\n", then calls TestClass::objects().
Inside TestClass::objects(), initialization of local object dummy begins. Again a temporary std::string is created, and DummyClass::DummyClass(std::string) is called.
The DummyClass constructor does a std::string copy, then outputs "DummyClass(inner)\n". The temporary std::string is destroyed. Initialization of objects' dummy is complete.
TestClass::TestClass() continues, printing "TestClass Objects is: 0x...\n". Initialization of the dynamic TestClass object is complete.
Back in main, the make_shared function returns a temporary std::shared_ptr<TestClass>. A move assignment moves from the returned temporary to ::mTest, then the temporary is destroyed. Note that although the TestClass object is associated with ::mTest, it has dynamic storage duration, not static storage duration, so the above rules do not apply to it.
main returns. C++ begins destroying objects with static storage duration.
The last static object to finish initialization was the dummy local of TestClass::objects() at step 8 above, so it is destroyed first. Its destructor body outputs "~DummyClass(inner)\n".
The next object to finish initializing was ::mTest in step 4 above, so its destruction begins next. The ~shared_ptr destructor ends up destroying the owned dynamic TestClass object.
The TestClass::~TestClass() destructor body first calls TestClass::objects().
In TestClass::objects(), we encounter the definition of an already destroyed function-local static, which is Undefined Behavior! Apparently though, your implementation does nothing but return a reference to the storage that formerly contained dummy, and it's probably a good thing you didn't do anything with it other than take the address.
TestClass::~TestClass() continues, outputting "~TestClass Objects is: 0x...\n" and then "~TestClass\n".
The ~shared_ptr destructor for ::mTest deallocates associated memory and completes.
Finally, the first static object to finish initialization was TestClass::dummy, in step 2 above, so it is destroyed last. The DummyClass::~DummyClass destructor body outputs "~DummyClass\n". The program is finished.
So the big difference between your two examples is the fact that the TestClass destruction gets delayed until the shared_ptr is destroyed - it doesn't really matter when in the scheme of things the TestClass was created. Since the shared_ptr was created before the "inner" DummyClass in the second example, its destruction happens after the "inner" object is gone, causing that Undefined Behavior.
If this is a simplification of an actual issue you ran into and need to fix, you might try adding something like
class TestClass {
// ...
public:
class ForceInit {
ForceInit() { TestClass::objects(); }
};
// ...
};
// ...
TestClass::ForceInit force_init_before_mTest;
std::shared_ptr<TestClass> mTest;
It's not related to shared_ptr but to the order of destruction of global variables in modules (cc files). The spec states that the order is undefined so you can not assume that static inner object will be destroyed after or before another global object. If you need to have a consistent order of destruction I advise that you take care of it explicitly.
In this passage on program exit from cppreference.com
If the completion of the constructor or dynamic initialization for thread-local or static object A was sequenced-before thread-local or static object B, the completion of the destruction of B is sequenced-before the start of the destruction of A
what is the meaning of "sequenced-before"?
In particular, for this program
struct Object {
Object() {
}
~Object() {
}
};
Object a;
void f() {
static Object b;
}
int main() {
f();
}
is it safe to assume that a.~Object() is called after b.~Object() because a.Object() is called before b.Object()?
what is the meaning of "sequenced-before"?
Objects are initialized at run time by the run time environment in a sequence. If initialization of one object comes before initialization of a second object, then the construction of the first object is "sequenced-before" construction of the second object.
is it safe to assume that a.~Object() is called after b.~Object() because a.Object() is called before b.Object()?
If you can assume that a.Object() is called before b.Object(), then you can assume that a.~Object() is called after b.~Object(). However, that is not always the case. In your posted code that is true. But it is possible, in a more complex application, that f() is called before a is initialized.
class A { public: int x[100]; };
Declaring A a will not initialize the object (to be seen by garbage values in the field x).
The following will trigger initialization: A a{} or auto a = A() or auto a = A{}.
Should any particular one of the three be preferred?
Next, let us make it a member of another class:
class B { public: A a; };
The default constructor of B appears to take care of initialization of a.
However, if using a custom constructor, I have to take care of it.
The following two options work:
class B { public: A a; B() : a() { } };
or:
class B { public: A a{}; B() { } };
Should any particular one of the two be preferred?
Initialization
class A { public: int x[100]; };
Declaring A a will not initialize the object (to be seen by garbage
values in the field x).
Correct A a is defined without an initializer and does not fulfill any of the requirements for default initialization.
1) The following will trigger initialization:
A a{};
Yes;
a{} performs list initialization which
becomes value initialization if {} is empty, or could be aggregate initialization if A is an aggregate.
Works even if the default constructor is deleted. e.g. A() = delete; (If 'A' is still considered an aggregate)
Will warn of narrowing conversion.
2) The following will trigger initialization:
auto a = A();
Yes;
This is copy initialization where a prvalue temporary is constructed with direct initialization () which
uses value initialization if the () is empty.
No hope of aggregate initialization.
The prvalue temporary is then used to direct-initialize the object.
Copy elision may be, and normally is employed, to optimize out the copy and construct A in place.
Side effects of skipping copy/move constructors are allowed.
Move constructor may not be deleted. e.g A(A&&) = delete;
If copy constructor is deleted then move constructor must be present. e.g. A(const A&) = delete; A(A&&) = default;
Will not warn of narrowing conversion.
3) The following will trigger initialization:
auto a = A{}
Yes;
This is copy initialization where a prvalue temporary is constructed with list initialization {} which
uses value initialization if {} is empty, or could be aggregate initialization if A is an aggregate.
The prvalue temporary is then used to direct-initialize the object.
Copy elision may be, and normally is employed, to optimize out the copy and construct A in place.
Side effects of skipping copy/move constructors are allowed.
Move constructor may not be deleted. e.g A(A&&) = delete;
If copy constructor is deleted then move constructor must be present. e.g. A(const A&) = delete; A(A&&) = default;
Will warn of narrowing conversion.
Works even if the default constructor is deleted. e.g. A() = delete; (If 'A' is still considered an aggregate)
Should any particular one of the three be preferred?
Clearly you should prefer A a{}.
Member Initialization
Next, let us make it a member of another class:
class B { public: A a; };
The default constructor of B appears to take care of initialization
of a.
No this is not correct.
the implicitly-defined default constructor of 'B' will call the default constructor of A, but will not initialize the members. No direct or list initialization will be triggered. Statement B b; for this example will call the default constructor, but leaves indeterminate values of A's array.
1) However, if using a custom constructor, I have to take care of it. The
following two options work:
class B { public: A a; B() : a() { } };
This will work;
: a() is a constructor initializer and a() is a member initializer as part of the member initializer list.
Uses direct initialization () or, if () is empty, value initialization.
No hope of using aggregate initialization.
Will not warn of narrowing conversion.
2) or:
class B { public: A a{}; B() { } };
This will work;
a now has a non-static data member initializer, which may require a constructor to initialize it if you are using aggregate initialization and the compiler is not fully C++14 compliant.
The member initializer uses list initialization {} which
may become either value initialization if {} is empty or aggregate initialization if A is an aggregate.
If a is the only member then the default constructor does not have to be defined and the default constructor will be implicitly defined.
Clearly you should prefer the second option.
Personally, I prefer using braces everywhere, with some exceptions for auto and cases where a constructor could mistake it for std::initializer_list:
class B { public: A a{}; };
A std::vector constructor will behave differently for std::vector<int> v1(5,10) and std::vector<int> v1{5,10}. with (5,10) you get 5 elements with the value 10 in each one, but with {5,10} you get two elements containing 5 and 10 respectively because std::initializer_list is strongly preferred if you use braces. This is explained very nicely in item 7 of Effective Modern C++ by Scott Meyers.
Specifically for member initializer lists, two formats may be considered:
Direct initialization a() which becomes value initialization if the () is empty.
List initialization a{} which also becomes value initialization if {} is empty.
In member initializer lists, fortunately, there is no risk of the most vexing parse. Outside of the initializer list, as a statement on its own, A a() would have declared a function vs. A a{} which would have been clear. Also, list initialization has the benefit of preventing narrowing conversions.
So, in summary the answer to this question is that it depends on what you want to be sure of and that will determine the form you select. For empty initializers the rules are more forgiving.
This part of the question provides background information and can be ignored
I am working on a template library which heavily relies on the use of the curiously recurring template pattern. The idea behind the class structure is that the user can either
1). Use predefined classes with standard methods. These classes are very simple leafs of the base class that only provide constructors/destructor, declare the variable members and declare the base class(es) as friend(s). All methods that operate on the variable members of the derived classes are defined in the base class(es).
2). Use the base classes to create his/her own extensions. This method also allows users to introduce their own methods that operate on the same variable members.
Only a single level inheritance is enforced by design.
My question is, primarily, about the clause 2. In the current implementation the user has to define all constructors implicitly (i.e. describe full process of memory allocation for dynamic variable members of the class, etc).
Question
The example below demonstrates an investigation into a possibility to use the CRTP to provide the definition of the allocation of the memory of the heap variables of the derived classes in the base class constructors.
Part of the base class
template<class TLeafType, class MyClass> class sysBaseDiscreteTrajectoryPoint {
...
//one of the base constructors
sysBaseDiscreteTrajectoryPoint(const MyClass& MyClassInstance) {
std::cout << "Base additional constructor called" << std::endl;
std::cout << asLeaf().Point << std::endl;
asLeaf().Point=new MyClass(MyClassInstance);
std::cout << asLeaf().Point << std::endl;
}
TLeafType& asLeaf(void) {
return static_cast<TLeafType&>(*this);
}
...
};
The derived class:
template<class MyClass>
class sysDiscreteTrajectoryPoint: public sysBaseDiscreteTrajectoryPoint<sysDiscreteTrajectoryPoint<MyClass>, MyClass> {
...
friend class sysBaseDiscreteTrajectoryPoint<sysDiscreteTrajectoryPoint<MyClass>, MyClass>;
private:
MyClass* Point;
public:
sysDiscreteTrajectoryPoint(const MyClass& MyClassInstance): sysBaseDiscreteTrajectoryPoint<sysDiscreteTrajectoryPoint<MyClass>, MyClass>(MyClassInstance){
std::cout << "Derived additional constructor called " << std::endl;
std::cout << Point << std::endl;
std::cout << *Point << std::endl;
}
...
}
main:
int a(5);
sysDiscreteTrajectoryPoint<int> A(a);
The code produces the following output:
Base additional constructor called
0x847ff4
0x8737008
Derived additional constructor called
0x8737008
5
Derived destructor called
Base destructor called
The output suggests that the concept may be feasible. However, I have two questions.
1). I would like to ensure that I understand all processes that happen during the execution of the code. In particular, I am interested in the efficiency of the process, as I may need to instantiate a substantial amount of objects from the classes presented above and I would like to understand what happens with Point (are there any hidden redefinitions?)
2). The question is related to the use of the library boost for the definition of smart pointers for the members of the derived class. When I tried replacing the raw pointer with boost::shared_ptr, I received a segmentation fault error when trying to allocate memory for the member of the derived class through the base class. The important sections of the code are shown below.
Part of the base class:
template<class TLeafType, class MyClass> class sysBaseDiscreteTrajectoryPoint {
...
//one of the base constructors
sysBaseDiscreteTrajectoryPoint(const MyClass& MyClassInstance) {
std::cout << "Base additional constructor called" << std::endl;
std::cout << asLeaf().Point << std::endl;
asLeaf().Point.reset(new MyClass(MyClassInstance));
std::cout << asLeaf().Point << std::endl;
}
TLeafType& asLeaf(void) {
return static_cast<TLeafType&>(*this);
}
...
};
Part of the derived class:
template<class MyClass>
class sysDiscreteTrajectoryPoint: public sysBaseDiscreteTrajectoryPoint<sysDiscreteTrajectoryPoint<MyClass>, MyClass> {
...
friend class sysBaseDiscreteTrajectoryPoint<sysDiscreteTrajectoryPoint<MyClass>, MyClass>;
private:
boost::shared_ptr<MyClass> Point;
public:
sysDiscreteTrajectoryPoint(const MyClass& MyClassInstance): sysBaseDiscreteTrajectoryPoint<sysDiscreteTrajectoryPoint<MyClass>, MyClass>(MyClassInstance){
std::cout << "Derived additional constructor called " << std::endl;
std::cout << Point << std::endl;
std::cout << *Point << std::endl;
}
...
}
main:
int a(5);
sysDiscreteTrajectoryPoint<int> A(a);
The code produces the following output:
Base additional constructor called
0x28d324
Segmentation fault
I have also tried scoped_ptr. However, it failed at run time but with a different error:
Base additional constructor called
*** glibc detected *** ./TestSystem: free(): invalid pointer: 0x00d3fff4 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6b961)[0xc4e961]
...
I assume that it is related to the specifics of the operation of boost smart pointers. Does anyone know how to resolve this issue?
The address of the shared_ptr is known at compile time for the reasons given in the above answers, but the shared_ptr itself is still uninitialised because the derived-class constructor has not yet been called, and thus has not had a chance to implicitly call its instance members' constructors, including the default constructor for shared_ptr. Therefore, when you call reset() to assign the shared_ptr, it first tries to release (and possibly delete) the object at whatever spurious address it contains (to avoid leaking an existing referent) before assigning and referencing the new object. That first step, I believe, is what causes the segfault.
If the shared_ptr constructor ran first, it would null its contained raw pointer, preventing the subsequent reset() call from trying to release an object at the spurious address.
Using asLeaf() to access the derived class from the base-class constructor is inherently unsafe for non-POD types because construction is incomplete (the derived class's members are not yet constructed). This is, incidentally, why virtual method calls from a base constructor will never call overrides from more-derived classes - the language explicitly prevents overrides from being called until construction of the whole object is complete because in most cases the state of the whole object is not yet defined.
There may be better solutions for you, but one approach that would work would be to remove that initialization code from the base class's constructor and put it in an init() function that is called explicitly at every instantiation of the derived class. init() can still live in the base class, but it's safer because everything will have been initialized by the time it runs.
Side note: avoid putting small objects in shared_ptr without good reason. You might have a legitimate need for it in this case, but in general I prefer direct aggregation of members to single-owner pointers and single-owner pointers to shared pointers wherever possible because the overhead escalates. Single-owner pointers involve heap allocations, and shared pointers also add to this the cost of counting/tracking owners so that the object can be deleted when unreachable.
How is it possible that you can access Point member belonging to the derived class from base constructor? When the base constructor is being invoked, the derived class part does not exist. Perhaps it works just "by accident".
But it certainly fails with shared_ptr, because you attempt to assign it before it has a chance to get initialized.