-
11. Data: 2012-06-25 22:43:24
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: "AK" <n...@n...com>
Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
> operacje na stosie przy rekurencji itp.
Edziu
Mam 55+ lat i ok 35lat siedze w programowaniu i dalibóg
(no fakt... trzeba by wziac poprawke na niewatpliwy Alzheimer;)
nie pamietam kiedy ostatnio napisalem funkcje rekurencyjna.
No dobra : jakies narzedziowki typu walk_dir byly ale to _naprawde_
skonczona liczba zaglebien :)
Tak wiec "nie stulaj" o wydajnosci itp/ tylko programuj normalnie
ciagle pamietajac o fundamentalnej zasadzie:
"nie ma nic gorszego od pzedwczesnej optymalizacji".
AK
-
12. Data: 2012-06-25 22:51:42
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: Bronek Kozicki <b...@s...net>
On 25/06/2012 20:41, Edek Pienkowski wrote:
> Dnia Mon, 25 Jun 2012 20:30:49 +0100, Bronek Kozicki napisal:
>
>> On 25/06/2012 19:38, Edek Pienkowski wrote:
>>> Powiedzmy, że mam metodę która ma ze 30 zmiennych i, co oczywiste w tym
>>> przypadku, jest za duża. Chcę ją podzielić.
>>>
>>> Problem polega na tym, że cokolwiek bym nie chciał wydzielić z tej
>>> metody zmienia te zmienne lokalne. Jeżeli zmieniałoby jedną, nie ma
>>> problemu:
>>> x1 = doSth(a,b,c,d,e);
>>
>> elementarne - zrób klasę i zamień zmienne lokalne na prywatne pola
>> klasy, a częsci funkcji na funkcje klasy. Potem upraszczaj.
>
> Powiedz od razu, że mam pisać klasy zamiast metod
niekoniecznie. Zależy od tego czy w ten sposób program robi się bardziej
zrozumiały, czy nie.
> - jest takich metod
> dobre kilka. I nie bardzo wiem, co miałbym upraszczać i dlaczego miałbym
no właśnie, dlaczego napisałeś "chcę ją podzielić" ? Mogę zgadywać że
przyczyna jest ta sama co zawsze - kod jest zbyt skomplikowany i w
związku z tym trudno jest go poprawiać. Ale, to mojej zgadywanie.
Prawdziwą przyczynę zapewne znasz sam.
B.
-
13. Data: 2012-06-25 22:59:11
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: Michoo <m...@v...pl>
On 25.06.2012 22:08, AK wrote:
> Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
>
>> Ja to mało wydajny jestem, ale już od dawna marudzą, że tool startuje
>> aż w 2 minuty, i to pomimo tego, że wcześniej startował w 6. Ciężkie
>> życie...
>
> No to sobie wbij do glowy, ze wlasnie to wychwalene "reczne" malloc jest
> _najbardziej kosztowna funkcja w C/C++_.
Jakie, kurcze, "ręczne" malloc? Jeżeli w c++ oprzesz sobie cały
interface na shared_ptr<T> to masz dokładnie to co robi java/C#, tylko z
deterministycznym zwalnianiem zasobów. Jak trzymasz się wzorca pimpl to
masz kod używający new tylko w konstruktorze a delete wcale. Spieprzyć
kod można w dowolnym języku.
P.S.
Przypominam, że miałeś udowodnić jak to kolejność ewaluacji operatorów w
C/C++ jest dowolna.
--
Pozdrawiam
Michoo
-
14. Data: 2012-06-25 23:09:46
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: Edek Pienkowski <e...@g...com>
Dnia Mon, 25 Jun 2012 21:51:42 +0100, Bronek Kozicki napisal:
> On 25/06/2012 20:41, Edek Pienkowski wrote:
>> Dnia Mon, 25 Jun 2012 20:30:49 +0100, Bronek Kozicki napisal:
>>
>>> On 25/06/2012 19:38, Edek Pienkowski wrote:
>>>> Powiedzmy, że mam metodę która ma ze 30 zmiennych i, co oczywiste w
>>>> tym przypadku, jest za duża. Chcę ją podzielić.
>>>>
>>>> Problem polega na tym, że cokolwiek bym nie chciał wydzielić z tej
>>>> metody zmienia te zmienne lokalne. Jeżeli zmieniałoby jedną, nie ma
>>>> problemu:
>>>> x1 = doSth(a,b,c,d,e);
>>>
>>> elementarne - zrób klasę i zamień zmienne lokalne na prywatne pola
>>> klasy, a częsci funkcji na funkcje klasy. Potem upraszczaj.
>>
>> Powiedz od razu, że mam pisać klasy zamiast metod
>
> niekoniecznie. Zależy od tego czy w ten sposób program robi się bardziej
> zrozumiały, czy nie.
Czy w ogóle jest zrozumiały to sprawdzę jutro, przewiduję drobne
problemy. Łatwiej mi się czyta kod mieszczący się na dwóch ekranach
niż rozsiany pomiędzy kilka metod w osobnej klasie. Kiedyś było może
i odwrotnie, ale dzisiaj muszę, ehh, "ogarnąć", nawet wizualnie
jeżeli widzę to jest łatwiej. Chyba lubię kształty.
>
>> - jest takich metod dobre kilka. I nie bardzo wiem, co miałbym
>> upraszczać i dlaczego miałbym
>
> no właśnie, dlaczego napisałeś "chcę ją podzielić" ? Mogę zgadywać że
> przyczyna jest ta sama co zawsze - kod jest zbyt skomplikowany i w
> związku z tym trudno jest go poprawiać. Ale, to mojej zgadywanie.
> Prawdziwą przyczynę zapewne znasz sam.
Trochę z natury skomplikowane, takie jest. Jeżeli coś uproszczę,
to będzie to w rodzaju pośredniej struktury danych, której przygotowanie
jest prostsze i użycie jest prostsze i złożoność daje się zakceptować.
To mi nie przeszkadza, po prostu nie mogę z Javie zrobić tego samego co
bym zrobił w C++. Taka obserwacja:
w C++ nie muszę używać wszystkiego, ale mogę; w Javie dla mojego własnego
bezpieczeństwa nie mogę mieć zwykłego goto, które dodatkowo po coś
jest zarezerwowane jako słowo kluczowe.
Edek
-
15. Data: 2012-06-25 23:22:12
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: A.L. <l...@a...com>
On Mon, 25 Jun 2012 18:38:13 +0000 (UTC), Edek Pienkowski
<e...@g...com> wrote:
>Powiedzmy, że mam metodę która ma ze 30 zmiennych i, co oczywiste
>w tym przypadku, jest za duża. Chcę ją podzielić.
Jezeli tak ci wyszlo, to twoj projekt jest do d... Wyrzuc go i zacznij
od poczatku.
Dawnymi czasy, IBM rozdawal nowo przyjetym pracownikom taka tabliczke
na biurko z napisem THINK! Juz nie rozdaje, a tabliczka jako taka
warta jest duze pieniedze. Oryginalna, oczywiscie,
Ale haslo na tej tabliczce obowiazuje i dzis, czy sie ma tabliczke
czy nie
Moze zacznij myslenie od zastanawiania sie nad nastepujacym cytatem
As Joshua Bloch states in Effective Java, 2nd Edition: The builder
pattern is a good choice when designing classes whose constructors or
static factories would have more than a handful of parameters.
oraz nad tym czt twoja metoda powinna byc metoda czy klasa. I czy w
ogole stosujesz programwoanie obiektowe? Moze powinienes programowac w
Cobolu?
A.L.
-
16. Data: 2012-06-25 23:37:00
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: "AK" <n...@n...com>
Użytkownik "Michoo" <m...@v...pl> napisał:
> Jakie, kurcze, "ręczne" malloc? Jeżeli w c++ oprzesz sobie cały interface na
shared_ptr<T> to masz
> dokładnie to co robi java/C#, tylko z deterministycznym zwalnianiem zasobów. Jak
trzymasz się
> wzorca pimpl to masz kod używający new tylko w konstruktorze a delete wcale.
Misiu
Nie ucz ojca dzieci robic (dlaczego kurcze Wam mlodym _ciagle_ sie od lat
wydaje, ze pozjadaliscie wszytskie rozumy/umiejetnosci w stosunku
do nas "matuzalemow;) ?).
Sam tak robie od lat.
I nie shared_pt tylko: shared_ptr, scoped_ptr i grin_ptr itp
Tylko powiedz mi Musiu dlaczego w C++ musze sie tyle nameczyc
(no i jeszcze ten PIMPL niezbedny) jesli w Javie mam to ad hoc
i bez udziwnien/komplikacji/ograniczen PIMPLa (dziedziczenie) itp ?
No po co ? Przeciez wtedy pisze niby w C++, ale _tak naprawde w Javie_ :)
Zwlaszcza, ze shared_ptr jest "atomowy" rowniez w sensie wielowatkowosci,
a wiec naprawde _cholernie_ kosztowny w stosunku do jednowatkowosci.
Tyle, ze ja sobie "mutexowania" w shared_ptr wylaczyc nie moge
nawet gdybym w dokumentacji duzymi bukwami napisal, ze
program/modul jest jednowatkowy.
Przecie smart_ptr to szablon, a wiec macro a wiec kompilator g.. wie o
kontekscie uzycia (nie umie zoptymalizowac).
W Javie/.NET refs sa _wewnetrzym wbudowanym podstawowym mechanizmem_
obslugi obiektow, wiec Java/.NET sobie moze to o wiele lepiej (i czymi to)
zoptymalizowac
PS: i nieprawda jest, ze mam wtedy "deterministyczne" zwalnianie zasobow.
Mamy tak/podobnie jak w Javie/C# (smieciarka), czyli wolnienie gdy ref_count
zjedzie do 0. (No ale o cykle to juz musze niestety zadbac/pilnowac sam:).
> Spieprzyć kod można w dowolnym języku.
Czasem sam jezyk (C++) "pieprzy"" kod.
> P.S.
> Przypominam, że miałeś udowodnić jak to kolejność ewaluacji operatorów w C/C++ jest
dowolna.
a nie chce mi sie teraz:) Moze jutro ?
I badz precyzyjny: pisalem ze "kolejnosc evaluacji operatorow" _o tym samym
priotrytecie_
jest dowolna.
Nawiasy w tym przypadku sa opuszczane juz na etapie (umownego) parsingu.
AK
-
17. Data: 2012-06-25 23:40:30
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: Wojciech Muła <w...@g...com>
W dniu poniedziałek, 25 czerwca 2012 22:59:11 UTC+2 użytkownik Michoo napisał:
> > No to sobie wbij do glowy, ze wlasnie to wychwalene "reczne" malloc jest
> > _najbardziej kosztowna funkcja w C/C++_.
> Jakie, kurcze, "ręczne" malloc? Jeżeli w c++ oprzesz sobie cały
> interface na shared_ptr<T> to masz dokładnie to co robi java/C#, tylko z
> deterministycznym zwalnianiem zasobów.
Chyba AK chodziło o sam kod, który jest w uniwersalnym alokatorze.
To zwykle dość skomplikowana maszyneria.
> Jak trzymasz się wzorca pimpl
Pimpl to taki sam "wzorzec" jak trzymanie stanu programu
w zmiennych globalnych. :)
w.
-
18. Data: 2012-06-25 23:40:45
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: Edek Pienkowski <e...@g...com>
Dnia Mon, 25 Jun 2012 16:22:12 -0500, A.L. napisal:
> On Mon, 25 Jun 2012 18:38:13 +0000 (UTC), Edek Pienkowski
> <e...@g...com> wrote:
>
>>Powiedzmy, że mam metodę która ma ze 30 zmiennych i, co oczywiste w tym
>>przypadku, jest za duża. Chcę ją podzielić.
>
> Jezeli tak ci wyszlo, to twoj projekt jest do d... Wyrzuc go i zacznij
> od poczatku.
Czasami coś wyrzucam, może nie tak drastycznie żeby od razu wszystko,
ale zdarza się.
>
> Dawnymi czasy, IBM rozdawal nowo przyjetym pracownikom taka tabliczke na
> biurko z napisem THINK! Juz nie rozdaje, a tabliczka jako taka warta
> jest duze pieniedze. Oryginalna, oczywiscie,
Podobno noszenie ich na czole niewiele daje tak na codzień.
>
> Ale haslo na tej tabliczce obowiazuje i dzis, czy sie ma tabliczke czy
> nie
>
> Moze zacznij myslenie od zastanawiania sie nad nastepujacym cytatem
>
> As Joshua Bloch states in Effective Java, 2nd Edition: The builder
> pattern is a good choice when designing classes whose constructors or
> static factories would have more than a handful of parameters.
>
> oraz nad tym czt twoja metoda powinna byc metoda czy klasa. I czy w
> ogole stosujesz programwoanie obiektowe? Moze powinienes programowac w
> Cobolu?
Nie ponieważ nie znam COBOL-a. Tak przypuszczałem: "chcesz goto" ->
"projekt do bani"
Edek
-
19. Data: 2012-06-25 23:45:39
Temat: Re: Nie mieszczę się w tym garniturku część 2: Java i parametry in/out
Od: Edek Pienkowski <e...@g...com>
Dnia Mon, 25 Jun 2012 14:40:30 -0700, Wojciech Muła napisal:
> W dniu poniedziałek, 25 czerwca 2012 22:59:11 UTC+2 użytkownik Michoo
> napisał:
>> > No to sobie wbij do glowy, ze wlasnie to wychwalene "reczne" malloc
>> > jest _najbardziej kosztowna funkcja w C/C++_.
>> Jakie, kurcze, "ręczne" malloc? Jeżeli w c++ oprzesz sobie cały
>> interface na shared_ptr<T> to masz dokładnie to co robi java/C#, tylko
>> z deterministycznym zwalnianiem zasobów.
>
> Chyba AK chodziło o sam kod, który jest w uniwersalnym alokatorze. To
> zwykle dość skomplikowana maszyneria.
Skomplikowana to pojęcie relatywne. Alokatory są o tyle niewdzięczne,
że trudno uzyskać coś lepszego od defaulta.
Edek
-
20. Data: 2012-06-25 23:46:11
Temat: Re: Nie mieszcz? si? w tym garniturku cz?oeae 2: Java i parametry in/out
Od: "AK" <n...@n...com>
Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
> Tak przypuszczałem: "chcesz goto" -> "projekt do bani"
Pogodz te dwie rzeczy i wywolaj tak:
obj.metodka(par1, par2, par3, par8, goto nowy_projekt9, goto nowy_projekt10, .. ,
goto
nowy_projekt30)
AK