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

Why was the "bread communication" in the arena of Catching Fire left out in the movie?

How to deal with fear of taking dependencies

What does 'script /dev/null' do?

Landlord wants to switch my lease to a "Land contract" to "get back at the city"

Crop image to path created in TikZ?

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

Are cabin dividers used to "hide" the flex of the airplane?

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

What is GPS' 19 year rollover and does it present a cybersecurity issue?

Doomsday-clock for my fantasy planet

Need help identifying/translating a plaque in Tangier, Morocco

Mapping arrows in commutative diagrams

Some basic questions on halt and move in Turing machines

Could a US political party gain complete control over the government by removing checks & balances?

Can I legally use front facing blue light in the UK?

Is Fable (1996) connected in any way to the Fable franchise from Lionhead Studios?

Why is the design of haulage companies so “special”?

Weird behaviour when using querySelector

Is this food a bread or a loaf?

Are objects structures and/or vice versa?

My colleague's body is amazing

How to create a consistant feel for character names in a fantasy setting?

aging parents with no investments

OA final episode explanation



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;








9















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?










share|improve this question
























  • 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
    5 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
    5 hours ago

















9















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?










share|improve this question
























  • 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
    5 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
    5 hours ago













9












9








9


1






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?










share|improve this question
















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















share|improve this question













share|improve this question




share|improve this question








edited 5 hours ago









armitus

509114




509114










asked 5 hours ago









KorriKorri

32627




32627












  • 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
    5 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
    5 hours ago

















  • 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
    5 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
    5 hours ago
















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
5 hours ago





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
5 hours ago




1




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
5 hours ago





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
5 hours ago












3 Answers
3






active

oldest

votes


















5














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






























    2














    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






























      2














      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























      • 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
        2 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
        1 hour ago












      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


















      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















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      5














      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



























        5














        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

























          5












          5








          5







          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













          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












          share|improve this answer



          share|improve this answer










          answered 5 hours ago









          AngewAngew

          134k11260353




          134k11260353























              2














              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



























                2














                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

























                  2












                  2








                  2







                  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













                  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












                  share|improve this answer



                  share|improve this answer










                  answered 4 hours ago









                  Guillaume RacicotGuillaume Racicot

                  16.3k53872




                  16.3k53872





















                      2














                      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























                      • 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
                        2 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
                        1 hour ago
















                      2














                      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























                      • 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
                        2 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
                        1 hour ago














                      2












                      2








                      2







                      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













                      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












                      share|improve this answer



                      share|improve this answer










                      answered 3 hours ago









                      einpoklumeinpoklum

                      37k28132263




                      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
                        2 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
                        1 hour ago


















                      • 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
                        2 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
                        1 hour ago

















                      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
                      2 hours ago





                      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
                      2 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
                      1 hour 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
                      1 hour ago


















                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid …


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      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















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Which organization defines CJK Unified Ideographs? The Next CEO of Stack OverflowCharacters which have several different shapesHow useful are the kanji in reading Chinese?Can Chinese readers scan large amounts of text faster/more accurately than their alphabet-using counterparts?丼: why is “well” also “bowl of food”?What Does Unicode 8.0 Mean For Chinese?How are blanks indicated for placeholders in Chinese (like ???)Is there a dictionary of standard character variants?How to display CJK Extension F?How is it decided as to which character is used on the tech terminology?How does 子 come to mean 'midnight'?

                      Shenzhen Football Club Índice Elenco atual | Títulos | Referências Ligações externas | Menu de navegaçãoGooglenotíciaslivrosacadêmicoeditar«"Elenco"»Site oficialexpandindo-oeee

                      When We Were Young (canção de Adele) Índice Antecedentes e lançamento | Faixas e formatos | Performances e covers | Desempenho nas tabelas musicais | Créditos | Histórico de lançamento | Referências Menu de navegação«Best albums of 2015»«Adele - When We Were Young (Radio Date: 22-01-2016)»«When We Were Young - Single by Adele»«Adele: Inside Her Private Life and Triumphant Return»«adele interview: world exclusive first interview in three years»«Tobias Jesso Jr: since Adele tweeted his song, he's even bigger than his dad»«Adele interviews Tobias Jesso Jr: 'I think that a couple of the ideas we had could be rap songs'»«Adele on Her Return: 'I Was So Frightened That No One Cared'»«Tobias Jesso Jr. on working with Adele: 'I was as nervous as shit'»«How Ariel Rechtshaid Pushed Adele To Her Limit»«Adele Previews 'When We Were Young' on '60 Minutes' Teaser, Tops Trending 140»«Adele Performs New '25' Ballad, "When We Were Young" Live: Watch»«Which '25' Song Should Be Adele's Next Single?»«Adele's 'When We Were Young' Confirmed As Second Single From '25'»«Adele's new single artwork for 'When We Were Young' is perfectly adorable»«Adele at the BBC review: honest, funny and spectacular – Celebrity News News»«'Saturday Night Live': Adele Sings 'Hello' and 'When We Were Young'»«'Adele: Live in New York City' NBC Special – Set List Revealed!»«Adele Closes Out the 2016 Brit Awards With 'When We Were Young'»«What Is The Adele Live Tour Set List? There's No Way She'd Leave Out These 8 Songs»«See Demi Lovato's Soaring Cover of Adele's 'When We Were Young'»«'The Voice': 5 Best Moments From Week 1 Blind Auditions»«Adele – When We Were Young (Media Control Charts)»«Adele – When We Were Young (Entertainment Monitoring Africa)»«Adele – When We Were Young (ARIA Charts)»«Adele – When We Were Young (Ö3 Austria Top 40)»«Adele – When We Were Young (Ultratop 50)»«Adele – When We Were Young (Ultratop 40)»«Adele – When We Were Young (Canadian Hot 100)»«Adele – When We Were Young (Tracklisten)»«Adele – When We Were Young (The Official Charts Company)»«Adele – Hello (IFPI Slovenská Republika)»«Adele – When We Were Young (Productores de Música de España)»«Adele – When We Were Young (Billboard Hot 100)»«Adele – When We Were Young (Pop Songs)»«Adele – When We Were Young (Adult Pop Songs)»«Adele – When We Were Young (Hot Adult Contemporary Charts)»«Adele – When We Were Young (Hot Dance Club Songs)»«Adele – When We Were Young (Rock Airplay)»«Adele – When We Were Young (IFPI Finlândia)»«Adele – When We Were Young (Syndicat National de l'Éditon Phonographique)»«Adele – When We Were Young (Magyar Hanglemezkiadók Szövetsége)»«Adele – When We Were Young (Irish Recorded Music Association)»«Adele – When We Were Young (Mexico Airplay)»«Adele – When We Were Young (VG-lista)»«Adele – When We Were Young (NZ Top 40 Singles)»«Adele – When We Were Young (MegaCharts)»«Adele – When We Were Young (Związek Producentów Audio Video)»«Adele – When We Were Young (Portugal Digital Songs)»«Adele – When We Were Young (UK Indie Singles Chart)»«Adele – When We Were Young (UK Singles Chart)»«Adele – When We Were Young (Sverigetopplistan)»«Adele – When We Were Young (Schweizer Hitparade)»«Adele – When We Were Young (Portugal Digital Songs)»«Music Canada – Gold/Platinum – When We Were Young»«NZ Top 40 Singles Chart»«Certified Awards»e