Arsthbt

What happens when a metallic dragon and a chromatic dragon mate?

What's the difference between repeating elections every few years and repeating a referendum after a few years?

Check if two datetimes are between two others

Re-submission of rejected manuscript without informing co-authors

Can produce flame be used to grapple, or as an unarmed strike, in the right circumstances?

Are white and non-white police officers equally likely to kill black suspects?

What does 'script /dev/null' do?

Deciding between multiple birth names and dates?

Information to fellow intern about hiring?

Shall I use personal or official e-mail account when registering to external websites for work purpose?

Email Account under attack (really) - anything I can do?

COUNT(id) or MAX(id) - which is faster?

Domain expired, GoDaddy holds it and is asking more money

Why airport relocation isn't done gradually?

Is this food a bread or a loaf?

Eliminate empty elements from a list with a specific pattern

What to wear for invited talk in Canada

What do you call something that goes against the spirit of the law, but is legal when interpreting the law to the letter?

Mapping arrows in commutative diagrams

Why did the Germans forbid the possession of pet pigeons in Rostov-on-Don in 1941?

Is a car considered movable or immovable property?

Prime joint compound before latex paint?

Can a planet have a different gravitational pull depending on its location in orbit around its sun?

Is there a familial term for apples and pears?

Is there a way to make member function NOT callable from constructor?

What are the differences between a pointer variable and a reference variable in C++?Can I call a constructor from another constructor (do constructor chaining) in C++?Throwing exceptions from constructorsHow do I call ::std::make_shared on a class with only protected or private constructors?Calling a base member in constructor in multiple inheritance in C++Equality-compare std::weak_ptrClass inheritance: Constructor and member functions of class not recognized by compilerHow does shared_ptr<T> detect that T derives from enable_shared_from_this<T>?enable_shared_from_this derived class methods are undefined referenceDefault move constructor with mutex member

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;

12

2

I have member function (method) which uses

std::enable_shared_from_this::weak_from_this() 

In short: weak_from_this returns weak_ptr to this. One caveat is it can't be used from constructor.
If somebody would use my function from constructor of inherited class, weak_from_this inside it would return expired weak_ptr. I guard against that with assertion checking that it's not expired, but it's a run-time check.

Is there a way to check against it at compile time?

c++ c++17 shared-ptr weak-ptr

share|improve this question

edited 8 hours ago

armitus

524114

asked 8 hours ago

KorriKorri

34128

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Note there is a difference in scope between a child class constructor body and the parent class constructor: the latter has been executed completely before you even start initializing the child class's members (if any), let alone enter the child class constructor body.
  
  – rubenvb
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Nice question. One way would be to make a dummy class with pure virtual function weak_from_this and inherit yours from it. This will make it a hard compile error.
  
  – SergeyA
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @SergeyA Why didn't you post that as an answer? All other people here seem to conclude that it's not possible so either your comment is wrong and misleading or they are wrong and you should show how it can be achieved.
  
  – Bakuriu
  1 hour ago
  

  
  
  
  

add a comment | 

12

2

I have member function (method) which uses

std::enable_shared_from_this::weak_from_this() 

In short: weak_from_this returns weak_ptr to this. One caveat is it can't be used from constructor.
If somebody would use my function from constructor of inherited class, weak_from_this inside it would return expired weak_ptr. I guard against that with assertion checking that it's not expired, but it's a run-time check.

Is there a way to check against it at compile time?

c++ c++17 shared-ptr weak-ptr

share|improve this question

edited 8 hours ago

armitus

524114

asked 8 hours ago

KorriKorri

34128

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Note there is a difference in scope between a child class constructor body and the parent class constructor: the latter has been executed completely before you even start initializing the child class's members (if any), let alone enter the child class constructor body.
  
  – rubenvb
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Nice question. One way would be to make a dummy class with pure virtual function weak_from_this and inherit yours from it. This will make it a hard compile error.
  
  – SergeyA
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @SergeyA Why didn't you post that as an answer? All other people here seem to conclude that it's not possible so either your comment is wrong and misleading or they are wrong and you should show how it can be achieved.
  
  – Bakuriu
  1 hour ago
  

  
  
  
  

add a comment | 

I have member function (method) which uses

std::enable_shared_from_this::weak_from_this() 

In short: weak_from_this returns weak_ptr to this. One caveat is it can't be used from constructor.
If somebody would use my function from constructor of inherited class, weak_from_this inside it would return expired weak_ptr. I guard against that with assertion checking that it's not expired, but it's a run-time check.

Is there a way to check against it at compile time?

c++ c++17 shared-ptr weak-ptr

share|improve this question

edited 8 hours ago

armitus

524114

asked 8 hours ago

KorriKorri

34128

std::enable_shared_from_this::weak_from_this() 

share|improve this question

edited 8 hours ago

armitus

524114

asked 8 hours ago

KorriKorri

34128

share|improve this question

edited 8 hours ago

armitus

524114

asked 8 hours ago

KorriKorri

34128

edited 8 hours ago

armitus

524114

edited 8 hours ago

armitus

524114

asked 8 hours ago

KorriKorri

34128

asked 8 hours ago

KorriKorri

34128

3 Answers
3

active

oldest

votes

10

I am afraid the answer is "no, it's not possible to protect against this at compile-time." It's always difficult to prove a negative, but consider this: if it was possible to protect a function this way, it would probably have been done for weak_from_this and shared_from_this in the standard library itself.

share|improve this answer

answered 8 hours ago

AngewAngew

135k11260354

add a comment | 

4

No there is no way. Consider:

void call_me(struct widget*);

struct widget : std::enable_shared_from_this<widget> 
 widget() 
 call_me(this);
 

 void display() 
 shared_from_this();
 
;

// later:

void call_me(widget* w) 
 w->display(); // crash

The thing is there is a reason you want to check for not calling shared_from_this in the constructor. Think about that reason. It's not that shared_from_this cannot be called, it's because it's return value has no way of being assigned yet. It is also not because it will never be assigned. It's because it will be assigned later in the execution of the code. Order of operation is a runtime property of your program. You cannot assert at compile time for order of operation, which is done at runtime.

share|improve this answer

answered 7 hours ago

Guillaume RacicotGuillaume Racicot

16.3k53872

add a comment | 

4

Not as such, but - if performance is not an issue, you could add a flag which indicates construction is complete, and use that to fail at run-time with such calls:

class A 

 // ... whatever ...

 A() 
 // do construction work
 constructed = true;
 

 foo() 
 if (not constructed) 
 throw std::logic_error("Cannot call foo() during construction"); 
 
 // the rest of foo
 

 bool constructed false ;

You could also make these checks only apply when compiling in DEBUG mode (e.g. with conditional compilation using the preprocessor - #ifndef NDEBUG) so that at run time you won't get the performance penalty. Mind the noexcepts though.

An alternative to throwing could be assert()'ing.

share|improve this answer

answered 6 hours ago

einpoklumeinpoklum

37k28132263

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Since apparently there isn't compile-time solution which doesn't make code less readable, I decided to go with assert(!wptr.expired()). I think it's a little bit more fitting than exception, because there is no way to recover from this situation.
  
  – Korri
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Korri remember that asserts are usually compiled out in release builds, so nothing will happen. An exception however is not, so it would still terminate the program (if not caught and swallowed) in a release build. You could do both; first assert then throw, or just throw.
  
  – Jesper Juhl
  4 hours ago
  
  

  
  
  
  

add a comment | 

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55576192%2fis-there-a-way-to-make-member-function-not-callable-from-constructor%23new-answer', 'question_page');

);

Post as a guest

Name

Email

Required, but never shown

10

I am afraid the answer is "no, it's not possible to protect against this at compile-time." It's always difficult to prove a negative, but consider this: if it was possible to protect a function this way, it would probably have been done for weak_from_this and shared_from_this in the standard library itself.

share|improve this answer

answered 8 hours ago

AngewAngew

135k11260354

add a comment | 

10

I am afraid the answer is "no, it's not possible to protect against this at compile-time." It's always difficult to prove a negative, but consider this: if it was possible to protect a function this way, it would probably have been done for weak_from_this and shared_from_this in the standard library itself.

share|improve this answer

answered 8 hours ago

AngewAngew

135k11260354

add a comment | 

I am afraid the answer is "no, it's not possible to protect against this at compile-time." It's always difficult to prove a negative, but consider this: if it was possible to protect a function this way, it would probably have been done for weak_from_this and shared_from_this in the standard library itself.

share|improve this answer

answered 8 hours ago

AngewAngew

135k11260354

share|improve this answer

answered 8 hours ago

AngewAngew

135k11260354

answered 8 hours ago

AngewAngew

135k11260354

answered 8 hours ago

AngewAngew

135k11260354

4

No there is no way. Consider:

void call_me(struct widget*);

struct widget : std::enable_shared_from_this<widget> 
 widget() 
 call_me(this);
 

 void display() 
 shared_from_this();
 
;

// later:

void call_me(widget* w) 
 w->display(); // crash

The thing is there is a reason you want to check for not calling shared_from_this in the constructor. Think about that reason. It's not that shared_from_this cannot be called, it's because it's return value has no way of being assigned yet. It is also not because it will never be assigned. It's because it will be assigned later in the execution of the code. Order of operation is a runtime property of your program. You cannot assert at compile time for order of operation, which is done at runtime.

share|improve this answer

answered 7 hours ago

Guillaume RacicotGuillaume Racicot

16.3k53872

add a comment | 

4

No there is no way. Consider:

void call_me(struct widget*);

struct widget : std::enable_shared_from_this<widget> 
 widget() 
 call_me(this);
 

 void display() 
 shared_from_this();
 
;

// later:

void call_me(widget* w) 
 w->display(); // crash

The thing is there is a reason you want to check for not calling shared_from_this in the constructor. Think about that reason. It's not that shared_from_this cannot be called, it's because it's return value has no way of being assigned yet. It is also not because it will never be assigned. It's because it will be assigned later in the execution of the code. Order of operation is a runtime property of your program. You cannot assert at compile time for order of operation, which is done at runtime.

share|improve this answer

answered 7 hours ago

Guillaume RacicotGuillaume Racicot

16.3k53872

add a comment | 

No there is no way. Consider:

void call_me(struct widget*);

struct widget : std::enable_shared_from_this<widget> 
 widget() 
 call_me(this);
 

 void display() 
 shared_from_this();
 
;

// later:

void call_me(widget* w) 
 w->display(); // crash

The thing is there is a reason you want to check for not calling shared_from_this in the constructor. Think about that reason. It's not that shared_from_this cannot be called, it's because it's return value has no way of being assigned yet. It is also not because it will never be assigned. It's because it will be assigned later in the execution of the code. Order of operation is a runtime property of your program. You cannot assert at compile time for order of operation, which is done at runtime.

share|improve this answer

answered 7 hours ago

Guillaume RacicotGuillaume Racicot

16.3k53872

void call_me(struct widget*);

struct widget : std::enable_shared_from_this<widget> 
 widget() 
 call_me(this);
 

 void display() 
 shared_from_this();
 
;

// later:

void call_me(widget* w) 
 w->display(); // crash

share|improve this answer

answered 7 hours ago

Guillaume RacicotGuillaume Racicot

16.3k53872

answered 7 hours ago

Guillaume RacicotGuillaume Racicot

16.3k53872

answered 7 hours ago

Guillaume RacicotGuillaume Racicot

16.3k53872

4

Not as such, but - if performance is not an issue, you could add a flag which indicates construction is complete, and use that to fail at run-time with such calls:

class A 

 // ... whatever ...

 A() 
 // do construction work
 constructed = true;
 

 foo() 
 if (not constructed) 
 throw std::logic_error("Cannot call foo() during construction"); 
 
 // the rest of foo
 

 bool constructed false ;

You could also make these checks only apply when compiling in DEBUG mode (e.g. with conditional compilation using the preprocessor - #ifndef NDEBUG) so that at run time you won't get the performance penalty. Mind the noexcepts though.

An alternative to throwing could be assert()'ing.

share|improve this answer

answered 6 hours ago

einpoklumeinpoklum

37k28132263

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Since apparently there isn't compile-time solution which doesn't make code less readable, I decided to go with assert(!wptr.expired()). I think it's a little bit more fitting than exception, because there is no way to recover from this situation.
  
  – Korri
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Korri remember that asserts are usually compiled out in release builds, so nothing will happen. An exception however is not, so it would still terminate the program (if not caught and swallowed) in a release build. You could do both; first assert then throw, or just throw.
  
  – Jesper Juhl
  4 hours ago
  
  

  
  
  
  

add a comment | 

4

Not as such, but - if performance is not an issue, you could add a flag which indicates construction is complete, and use that to fail at run-time with such calls:

class A 

 // ... whatever ...

 A() 
 // do construction work
 constructed = true;
 

 foo() 
 if (not constructed) 
 throw std::logic_error("Cannot call foo() during construction"); 
 
 // the rest of foo
 

 bool constructed false ;

You could also make these checks only apply when compiling in DEBUG mode (e.g. with conditional compilation using the preprocessor - #ifndef NDEBUG) so that at run time you won't get the performance penalty. Mind the noexcepts though.

An alternative to throwing could be assert()'ing.

share|improve this answer

answered 6 hours ago

einpoklumeinpoklum

37k28132263

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Since apparently there isn't compile-time solution which doesn't make code less readable, I decided to go with assert(!wptr.expired()). I think it's a little bit more fitting than exception, because there is no way to recover from this situation.
  
  – Korri
  5 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Korri remember that asserts are usually compiled out in release builds, so nothing will happen. An exception however is not, so it would still terminate the program (if not caught and swallowed) in a release build. You could do both; first assert then throw, or just throw.
  
  – Jesper Juhl
  4 hours ago
  
  

  
  
  
  

add a comment | 

Not as such, but - if performance is not an issue, you could add a flag which indicates construction is complete, and use that to fail at run-time with such calls:

class A 

 // ... whatever ...

 A() 
 // do construction work
 constructed = true;
 

 foo() 
 if (not constructed) 
 throw std::logic_error("Cannot call foo() during construction"); 
 
 // the rest of foo
 

 bool constructed false ;

You could also make these checks only apply when compiling in DEBUG mode (e.g. with conditional compilation using the preprocessor - #ifndef NDEBUG) so that at run time you won't get the performance penalty. Mind the noexcepts though.

An alternative to throwing could be assert()'ing.

share|improve this answer

answered 6 hours ago

einpoklumeinpoklum

37k28132263

class A 

 // ... whatever ...

 A() 
 // do construction work
 constructed = true;
 

 foo() 
 if (not constructed) 
 throw std::logic_error("Cannot call foo() during construction"); 
 
 // the rest of foo
 

 bool constructed false ;

share|improve this answer

answered 6 hours ago

einpoklumeinpoklum

37k28132263

answered 6 hours ago

einpoklumeinpoklum

37k28132263

answered 6 hours ago

einpoklumeinpoklum

37k28132263