W dniu 2012-07-04 20:50, slawek pisze:
> Jeszcze raz - wywołanie konstruktora i run() są jedno-po-drugim, nigdy
> nie będzie potrzeby rozdzielenia. UWAGA: podkreślam - niekoniecznie C++.
> Także C#, Java, cokolwiek co lubicie.

Podobna dyskusja:

http://stackoverflow.com/questions/3905784/what-not-
to-do-in-a-constructor

artur

do góry

Użytkownik "Paweł Kierski" napisał w wiadomości grup
dyskusyjnych:jt3ab8$gr8$...@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/step1
.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%2B_Q
t4_w_systemie_Gnu/Linux/Helo_World_w_QT4)

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.

GTK/GTK+ - mają run(), tyle że nazywa się on gtk_main() i nie jest metodą,
lecz funkcją. Ale sens jest taki sam - oddzielne poproszenie o to "by się
działo".

FLTK - patrzę i co widzę - jest return Fl:run()
(http://www.linux.rk.edu.pl/w/p/wprowadzenie-do-fltk
/)

wxWidgets - oj, oszukują - dali makro IMPLEMENT_APP(myApp) - ale jeżeli mnie
pamięć nie zawodzi, to run chyba (?) nie było.

do góry

Dnia Thu, 05 Jul 2012 08:29:34 +0200, slawek napisal:

> Użytkownik "Michoo" napisał w wiadomości grup
> dyskusyjnych:jt2mjk$hud$...@m...internetia.pl...
>
>>Foo().run();
>
> Ok, też można. Nie zrozumiałeś jednak pytania. Bo to co proponujesz to
> dalej używanie metody run/execute/command/...
>
> A chodziło o taką "filozofię", w której samo istnienie obiektu uruchamia
> jego działanie.
>
> Czyli nie ma potrzeby "mieć obiekt i potem kazać mu coś zrobić" - tylko
> "obiekt robi coś, bo po prostu istnieje".

Zdarzyło mi się tworzyć takie obiekty w celu drobnych inicjalizacji,
gdzie prawa dostępu public/protected/private w C++ pozwalało mieć
taką klasę jako friend, która jednocześnie służyła jako implementacja
drobnego interfejsu.
Były tak małe, że pisanie osobnej run() kolidowało z zasadą najmniejszego
wysiłku ;).

Zazwyczaj jednak albo Foo().do() albo to samo w statycznej metodzie.

Edek

do góry

Użytkownik "Artur M. Piwko" napisał w wiadomości grup
dyskusyjnych:slrnjvadpo.8la.milusi.pysiaczek@buziacz
ek.pl...

>Pytanie dlaczego nie jeśli po wykonaniu nie będzie potrzebny:
>int Foo_run() {...}

Odpowiedź oczywista: bo w trakcie działania ma tworzyć inne obiekty, mające
referencje do pól, a w szczególności do jego this.

(Ewentualnie "tu jest Java" cytując za "300".)

do góry

W dniu środa, 4 lipca 2012 20:50:53 UTC+2 użytkownik slawek napisał:

> I tu jest pytanie, a nawet dwa:
>
> 1. Czy nie wystarczyłoby zrobić copy-paste tego co ma run() w środku do
> konstruktora i wy...ć [ref1] zbędne już run() ?

Jeśli konstruktor i run() zawsze idą w parze i nie są rozdzielone innymi operacjami
(spekulacja: można mieć listę takich obiektów? można je zapisać i odczytać? itd.), to
można. Ale dlaczego się na tym zatrzymywać? Jeżeli zaraz po run() obiekt i tak jest
niszczony, to całość można zebrać w jedną funkcję runFoo().

Paweł podał argument, że być może ta funkcja jest skomplikowana i korzysta z usług
innych klas, które odwołują się do pól Foo - ale to niewiele zmienia, bo skoro tym
innym klasom trzeba podać referencje do tych wykorzystywanych pól, to równie dobrze
można im podać referencje do odpowiednich zmiennych lokalnych stworzonych w run().

Podejrzewam tu po prostu nadmiar nieuzasadnionej "obiektowości".

> 2. Czy metodę run() można wywoływać w konstruktorze

Można.

> Jeszcze raz - wywołanie konstruktora i run() są jedno-po-drugim, nigdy nie
> będzie potrzeby rozdzielenia.

W takim razie nie ma potrzeby ich rozdzielać.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Thu, 5 Jul 2012 01:21:52 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> o mona zebra w jedn funkcj runFoo().

Nie mona - bo funkcja nie ma pól. Obiekty tworzone wewntrz foo
musz mie dostp do pól klasy foo i mog by w rónych wtkach.
Uycie zmiennych globalnych jako namiastki wykluczone.

do góry

On Thu, 5 Jul 2012 01:21:52 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> Podejrzewam tu po prostu nadmiar nieuzasadnionej "obiektowoci".

Wszystko mona zrobi w Fortranie

do góry

Dnia 05-07-2012 o 09:20:31 slawek <h...@s...pl> napisał(a):

[...]
> W Qt jest (vide np.
> http://pl.wikibooks.org/wiki/Programowanie_C%2B%2B_Q
t4_w_systemie_Gnu/Linux/Helo_World_w_QT4)
>
> QApplication app(argc,argv);
> return app.exec();
[...]

ależ to jest przykład tego co mówiłem: tworzysz app, potem dodajesz
labele, buttony, etc. i dopiero po tym ,,skonfigurowaniu" robisz
app.exec(); to nawet mocniejszy przykład, bo z założenia jakieś elementy
dodajesz, a nie w wyjątkowych sytuacjach

--
Jordan Szubert

do góry

On Thursday, July 5, 2012 9:21:52 AM UTC+1, Maciej Sobczak wrote:
> W dniu środa, 4 lipca 2012 20:50:53 UTC+2 użytkownik slawek napisał:
>
> > I tu jest pytanie, a nawet dwa:
> >
> > 1. Czy nie wystarczyłoby zrobić copy-paste tego co ma run() w środku do
> > konstruktora i wy...ć [ref1] zbędne już run() ?
>
> Jeśli konstruktor i run() zawsze idą w parze i nie są rozdzielone innymi operacjami
(spekulacja: można mieć listę takich obiektów? można je zapisać i odczytać? itd.), to
można. Ale dlaczego się na tym zatrzymywać? Jeżeli zaraz po run() obiekt i tak jest
niszczony, to całość można zebrać w jedną funkcję runFoo().
>
> Paweł podał argument, że być może ta funkcja jest skomplikowana i korzysta z usług
innych klas, które odwołują się do pól Foo - ale to niewiele zmienia, bo skoro tym
innym klasom trzeba podać referencje do tych wykorzystywanych pól, to równie dobrze
można im podać referencje do odpowiednich zmiennych lokalnych stworzonych w run().

>
> Podejrzewam tu po prostu nadmiar nieuzasadnionej "obiektowości".

Moze byc tez chec rozdzielenia trzech faz funkcji run():

1. przygotuj zmienne lokalne (np. rozpakuj dane wejsciowe, ustaw odpowiednie opcje)
2. wykonaj potrzebna operacje
3. posprzataj po sobie

Faza 1. to konstruktor klasy Foo, faza 2. to Foo.run() a faza 3. to destruktor Foo.

Alternatywa jest albo duza funkcja run(), albo przekazywanie mnostwa zmiennych
pomiedzy funkcja prepareRun() a run().

RW

do góry

Użytkownik "slawek" <h...@s...pl> napisał:

> 2. Czy metodę run() można wywoływać w konstruktorze (i dlaczego nie?)

Z reguly tak.

> (i dlaczego nie?)

Gdyz (rowniez z reguly) "wpakowujac" kod run() w konstruktor tracisz wtedy
polimorfizm run().

Duzo zalezy od jezyka, ale niektore z nich nie lubia wyjatkow (a wiec "wlasnosc"
akcji/metod)
rzucanych z konstruktora.

Osobiscie staram sie trzymac sie zasady, ze w konstrulktorzae(ach) winno byc jedynie
_to co niezbedne_ to utworzenia obiektu, a ew akcje sa jako osobne metody
(ew wolane w konstruktorze, ale mozliwie minimalizujac do oczywistych/narzucajacych
sie
przypadkow taki wolania).

AK

do góry