On Jul 5, 9:20 am, "slawek" <h...@s...pl> wrote:
> Użytkownik "Paweł Kierski"  napisał w wiadomości grup
> dyskusyjnych:jt3ab8$g...@i...gazeta.pl...
>
> >Pytanie, dlaczego nie Foo::run(), czyli metoda statyczna, czyli zwykła
> >funkcja? Domyślam się, że z powodu dużego skomplikowania funkcji,
>
> To nie tego rodzaju problem. Jeszcze raz, bo mogło nie być oczywiste -
> pytanie jest bowiem nie o to "jak załatać konkretną dziurę" - i przez to
> nieco teoretyczne.
> Poniżej masz przykłady używania metody run() lub podobnej. Pytanie było: czy
> naprawdę musi być run() - czy nie wystarczyłoby, aby konstruktor robił całą
> robotę?
>
> W Borlandowskim OWL jest (vide np.http://www.tenermerx.com/owlhow/items/tutorial/st
ep1.html)
>
>    TApplication app;  // odpalany jest konstruktor
>    return app.run();   //  odpalana metoda run
>
> W Qt jest (vide np.http://pl.wikibooks.org/wiki/Programowanie_C%2B%2
B_Qt4_w_systemie_Gnu...)
>
>    QApplication app(argc,argv);
>    return app.exec();
>
> Natomiast w MFC niesposób znaleźć "execute" czy "run" - dzieje się samo, bez
> popychania. Być może run() siedzi gdzieś przyczajone globalnie.

MFC po prostu dolinkowuje ci entry point do execa który wywołuje Run()
na zarejestrowanym obiekcie CWinApp.
W przypadku statycznych (w tym globalnych) obiektów umieszczanie
działania w konstruktorze jest o tyle ryzykowne, że dla nietrywialnie
konstruowanych typów kolejność inicjalizacji pomiędzy jednostkami
translacji nie jest wyspecyfikowana.

Pewną dość oczywistą wadą 'uruchomienia przez konstruktor' jest brak
możliwości sensownego dziedziczenia po takiej klasie. W C++ dodatkowo
w takich przypadkach występuje problem z wywoływaniem funkcji
wirtualnych z konstruktora.