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





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







14















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

























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






  • 2





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






  • 1





    @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
    6 hours ago


















14















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

























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






  • 2





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






  • 1





    @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
    6 hours ago














14












14








14


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
















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




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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 12 hours ago









armitus

524114




524114










asked 12 hours ago









KorriKorri

35128




35128













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






  • 2





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






  • 1





    @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
    6 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
    12 hours ago






  • 2





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






  • 1





    @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
    6 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
12 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
12 hours ago




2




2





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




1




1





@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
6 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
6 hours ago












3 Answers
3






active

oldest

votes


















13














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































    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































      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
























      • 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
        9 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
        8 hours 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









      13














      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




























        13














        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


























          13












          13








          13







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









          AngewAngew

          135k11261354




          135k11261354

























              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




























                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


























                  4












                  4








                  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













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









                  Guillaume RacicotGuillaume Racicot

                  16.3k53872




                  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
























                      • 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
                        9 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
                        8 hours ago


















                      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
























                      • 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
                        9 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
                        8 hours ago
















                      4












                      4








                      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













                      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 10 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
                        9 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
                        8 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
                        9 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
                        8 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
                      9 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
                      9 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
                      8 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
                      8 hours 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

                      Ponta tanko

                      Image
                      Usona ponta tanko M60A1 Ponta tanko estas, simile kiel kirasita savveturilo, inter specialaj kirasitaj transportiloj. Kiel pontaj tankoj eblas konsideri ĉiujn memmovigaj rimedoj ebligantaj superi obstaklojn ĝis larĝeco 24 metroj rekte en spaco de bataloperacoj. Ties ĉefa tasko estas ebligi al la propraj taĉmentoj daŭrigi en rapida antaŭenirado sen senbezona reteniĝo. El tio pli-malpli rezultas taktikaj-teknikaj postuloj, kiujn ili devas plenumi. Precipe temas pri kapablo operacii komune kun unue-sinsekvaj taĉmentoj kaj transpontigi obstaklojn dum kelke da minutoj. This page is only for reference, If you need detailed information, please check here
                      Read more

                      Tantalo (mitologio)

                      Image
                      Ĉi tiu artikolo temas pri mitologio. Por aliaj signifoj vidu la paĝon Tantalo (apartigilo) . Tantalo , laŭ Gioacchino Assereto. Laŭ la helena mitologio, Tantalo (el la greka Τάνταλος , ŝancelanta aŭ tre malfeliĉa ) estis filo de Zeŭso kaj la oceanidino Pluto, laŭ la plej divastigata versio. Li estis reĝo de Frigio [1] aŭ de la monto Sipilo, en Lidio (Malgrandazio) [2] kaj post sia morto li suferis eternan torturadon ĉe la Tartaro, la plej profunda parto de Hadeso, rezervita por la plej perversaj homoj. Tamen, kelkaj rakontoj asertas ke li estis reĝo de Argo aŭ de Korinto [3] , aŭ ke li migris norden el la monto Sipilo por akiri la tronon de Paflagonio, el kie Ilo forpelis lin pro tio, ke Tantalo forkaptis kaj seksperfortis lian fraton Ganimedon [4] , kaj tiel ofendis la diojn. Verŝajne li ankaŭ regis urbon en okcidenta Anatolio, kiun oni nomis Tantalis [5] pro li, aŭ Sipilo , pro la monto sur kies flanko ankoraŭ staras ĝiaj ruinaĵoj [6] . Laŭ la geografiisto Strabo,...
                      Read more

                      Erzsébet Schaár

                      Image
                      Erzsébet Schaár Memportreto de Erzsébet Schaár en Pécs Personaj informoj Naskiĝo 27-an de julio 1908 ( 1908-07-27 ) en Budafok Morto 29-an de aŭgusto 1975 ( 1975-08-29 ) (67-jara) en Budapeŝto Ŝtataneco Hungario Profesio skulptisto Familianoj Edz(in)o Tibor Vilt v   •   d   •   r Erzsébet Schaár [erĵEbet ŝAr], laŭ hungarlingve kutima sinsekvo Schaár Erzsébet estis hungara skulptisto. Ŝia edzo estis Tibor Vilt. Déryné Széppataki Róza en Miskolc fare de Erzsébet Schaár Erzsébet Schaár [1] naskiĝis la 27-an de julio 1908 en Budafok, ŝi mortis la 29-an de aŭgusto 1975 en Budapeŝto. Enhavo 1 Biografio 2 Elektitaj solaj ekspozicioj 3 Elektitaj kolektivaj ekspozicioj 4 Elektitaj skulptaĵoj 5 Elektitaj disĉiploj 6 Fontoj 7 Referencoj Biografio | Erzsébet Schaár studis en Industriarta Lernejo, poste en Reĝa Belarta Altlernejo (1924-1926). Ŝia ĉefinstruisto estis Zsig...
                      Read more