🚀 go-pugleaf

Użytkownik <lrem@lrem.maxnet> napisał:

> pl.comp.objects
> Description: Obiektowa technologia tworzenia oprogramowania i C++.
> Więc chyba c++ jednak ma coś wspólnego.

Nie. Po prostu tworca opisu mial pierdolca ;)

>> Idz na odpowiednia grupe.
>
> Chodzi Ci o pl.comp.lang.c?

Dokladnie.

AK 

Użytkownik "Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> napisał:

>> 1. brak smieciarki
>
> W samym języku tak. Znam dwie smieciarki dla C++ i jedną
> dla C czasami uznawaną jako możliwą do włączenia do C++.

Zna Pan jakas _standardowa_ i jakas _pewna_ ?
Taka np thread-safe ?
Ale nie tak "thread-safe' jak _standardowa biblioteka_ std::. ;)

>> 2. chory niskopoziomowy przydzial pamieci na stosie
>> 3. chory niskoposiomowy przydzial pamieci w heap
>
> W kontekście 1. te punkty są bezzasadne, a w szczególności słowo "chore".
> Jeżeli używa Pan śmieciarek, to słowo "chore" jest moim zdaniem nie na
> miejscu, ale to jest kwestia gustu z którym nie ma zwyczaju dyskutować.

Gustu ?
Chyba Pan zartuje.
To kwestia kompletnej nieuzytecznosci takich
przydzialow w programowaniu _realnym_,
ze o glownym zrodle bledogenosci nie wspomne.
Te punkty sa zasadne bo oprocz przydzialu dynamicznego
istnieje tez przydzial jak ja to nazywam 'scopowy' i tam
smieciarka nie ma nic do gadania.
Tenze przydzial to w C++ wielka parodia.
W Simuli jest wzorcowy.

>> 4. sp.. referencje wlasnie za brak siegniecia do dobrych
>>     i juz istniejacyh lata wzorcow w sensie wspolistnienia
>>     swiata "wartosciowego' ze swiatem "referencyjnym"
>
> Tak tu przyznaję rację, chociaż są pewne sytuacje, kiedy to ma
> znaczenie np. bezpieczne napełnianie kontenerów.

Nie rowumiem ?
Co niby jest takiego w skopanych referencjach C++
(ktore defacto sa prymitywnymi wskaznikami, majacymi 0
 wspolnego ze smart, gc itp) ktore je czyni ponad te z Simuli
w przypadku kontenerow ?

> Introspekcja?

Co to jest ?

Z innych tematow:

Zna Pan moze w C++ jakis _standardowy_ mechanizm
programowania procesow/zadan wspolbieznych ?
Moze chociaz jakies prymitywne korutyny ?

Jak Pan chce uzyskac w C++ to co jest w Simuli czy w Adzie ?
Te jezyki maja ponad i prawie pol wieku a Pan mi chce wmowic
ze jezyk ktory nie ma ustandaryzowanego _zadnego mechanizmu
wspolbieznosci_ (a jeden z jego Guru wyraznie dowodzi ze w
C++ nie da sie uzyskac pewnosci w programach wspolbieznych)
ma byc kurde nowoczesny i mainstream ?

> Rozumiem, że Simula będąc językiem kompilowalnym stoi
> w kontekście dynamizmu po tej samej stronie co C++.

Chyba Pan zartuje !.
Algol czy Simula ze swoim call by name do prymitywizmu
wartosciowego C++ ?

> A tak w ogóle to czemu Pan porównuje C++ do Simuli?

Bo sie C++ uwaza np na pl.comp.lang.c za sukcesora i "poprawiacza"
Simuli a to wielkie g.. prawda.

To najwyzej jakis bekart inzynierii oprogramowania ktoremu sie
najwyrazniej matki pomylily (a raczej ojcowie - assembler).

AK

Witam

Adam Karpierz wrote:

> Użytkownik "Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com>
> napisał:
> 
>>> 1. brak smieciarki
>>
>> W samym języku tak. Znam dwie smieciarki dla C++ i jedną
>> dla C czasami uznawaną jako możliwą do włączenia do C++.
> 
> Zna Pan jakas _standardowa_ i jakas _pewna_ ?

Standardowej to nie ma, bo jak Pan zauważył GC nie jest zawarte jako
standard w C++.

Są m.in. takie jak Śmieciuch [1] i SGCL [2].

> Taka np thread-safe ?
> Ale nie tak "thread-safe' jak _standardowa biblioteka_ std::. ;)

A tak a'propo to w jakim języku wszystko jest thread-safe i jeszcze do tego
wydajne? 

>>> 2. chory niskopoziomowy przydzial pamieci na stosie
>>> 3. chory niskoposiomowy przydzial pamieci w heap
>>
>> W kontekście 1. te punkty są bezzasadne, a w szczególności słowo "chore".
>> Jeżeli używa Pan śmieciarek, to słowo "chore" jest moim zdaniem nie na
>> miejscu, ale to jest kwestia gustu z którym nie ma zwyczaju dyskutować.
> 
> Gustu ?
> Chyba Pan zartuje.
> To kwestia kompletnej nieuzytecznosci takich
> przydzialow w programowaniu _realnym_,
> ze o glownym zrodle bledogenosci nie wspomne.

Rozumiem, czy jednak jedynymi błędami w programach są przydzielanie i
zwalnianie pamięci? IMHO nie. Już nie wspomnę o błędach logicznych.
Pomijam też sprawę błędów polegających na literówkach, które są trudno
identyfikowalne w językach dynamicznych jak Perl. Program działa, ale jakoś
dziwnie źle.

>>> 4. sp.. referencje wlasnie za brak siegniecia do dobrych
>>>     i juz istniejacyh lata wzorcow w sensie wspolistnienia
>>>     swiata "wartosciowego' ze swiatem "referencyjnym"
>>
>> Tak tu przyznaję rację, chociaż są pewne sytuacje, kiedy to ma
>> znaczenie np. bezpieczne napełnianie kontenerów.
> 
> Nie rowumiem ?
> Co niby jest takiego w skopanych referencjach C++
> (ktore defacto sa prymitywnymi wskaznikami, majacymi 0
>  wspolnego ze smart, gc itp) ktore je czyni ponad te z Simuli
> w przypadku kontenerow ?

A czy ja powiedziałem, że czyni je ponad te z Simuli! W ogóle niech mi Pan
nie imputuje, że cokolwiek powiedziałem złego na Simulę. Generalnie uważam,
że powstałe dawno temu języki, poprzez to, że myślano o nich nie tylko na
metry kodu, ale na papierze były lepiej przemyślane niż dzisiejsze - patrz
PHP.

>> Introspekcja?
> 
> Co to jest ?

Sobistość obiektu? :-) Samoświadomość obiektu?
 
> Z innych tematow:
> 
> Zna Pan moze w C++ jakis _standardowy_ mechanizm
> programowania procesow/zadan wspolbieznych ?

Nie ma standardowego, bo inaczej to się robi na DSP, a inaczej na Cray, a
jeszcze inaczej na klastrze opartym o Mosix. Więc standardowość byłaby za
pewne nie wskazana. Coś i tak gdzieś by nie działało, albo goście z Craya
byliby nie zadowoleni z narzuconego minimalizmu, który wymusza DSP. 

Pytałem ostatnio o platformy docelowe Ady i okazało się, że jest jakiś DSP,
który pozwala na użycie Ady. Jednak nie był on możliwy dla mnie do
rozważenia z powodu pewnych innych parametrów, które nie odpowiadały.

> Jak Pan chce uzyskac w C++ to co jest w Simuli czy w Adzie ?

Tu ma Pan rację. Te języki natywnie wspierają takie sprawy. Jednak nie widzę
tylu docelowych platform co dla C++, aby można było wskazać, że jedno
standardowe podejście jest słuszne.

Np. moje ostatnie doświadczenie jest takie, że czasem lepsze od wątków są
procesy. A dokładniej program, który jest równoległy w sensie działania
różnych (swoich) procesów.

I tego nie oferują wszystkie języki jako standard, czy to obliguje mnie do
pejoratywnej ich oceny? Chyba nie. Więc akurat istnienia takiego
wyposażenia jako standardu nie wymagam, tak jak wątków nie wymagam. 

Wolę mieć pulę dostępnych rozwiązań i wybrać sobie jedno (np. [3][4][5][6
[7][8]), niż mieć w standardzie i patrzeć na nie jak na prawdę objawioną. 

To samo dotyczy biblioteki STL. Jak mi nie odpowiada to jej nie używam, bo
są jej różne implementacje. Szczególnie ciekawa i użyteczna jest
http://stxxl.sourceforge.net/.

> Te jezyki maja ponad i prawie pol wieku a Pan mi chce wmowic
> ze jezyk ktory nie ma ustandaryzowanego _zadnego mechanizmu
> wspolbieznosci_ (a jeden z jego Guru wyraznie dowodzi ze w
> C++ nie da sie uzyskac pewnosci w programach wspolbieznych)
> ma byc kurde nowoczesny i mainstream ?

A czy one są w mainstream i czy są nowoczesne?
 
>> Rozumiem, że Simula będąc językiem kompilowalnym stoi
>> w kontekście dynamizmu po tej samej stronie co C++.
> 
> Chyba Pan zartuje !.
> Algol czy Simula ze swoim call by name do prymitywizmu
> wartosciowego C++ ?

Jakoś nie widzę przykładów dodawania do obiektów metod czy pól w locie tak
jak to jest możliwe w Pythonie. Ale może znowu żartuje.
 
>> A tak w ogóle to czemu Pan porównuje C++ do Simuli?
> 
> Bo sie C++ uwaza np na pl.comp.lang.c za sukcesora i "poprawiacza"
> Simuli a to wielkie g.. prawda.

No może się tak uważa - ja tak nie twierdzę. Tak samo jak nie twierdzę, że
Java jest lepszym Smalltalkiem.

> To najwyzej jakis bekart inzynierii oprogramowania ktoremu sie
> najwyrazniej matki pomylily (a raczej ojcowie - assembler).

I Pan mi usiłuje powiedzieć, że nie posługuje się Pan pejoratywnymi
określeniami względem C++? Niech Pan zacznie być dorosły!

Pozdrawiam.

[1] http://smieciuch.sourceforge.net/
[2] http://sourceforge.net/projects/sgcl
[3] http://www.boost.org/doc/html/threads.html 
[4] http://zthread.sourceforge.net/documentation.html
[5] http://www.dinkumware.com/manuals/?manual=compleat&page=index_thr.html
[6] http://www.llnl.gov/computing/tutorials/pthreads/
[7] http://msdn2.microsoft.com/en-us/library/975t8ks0(VS.80).aspx
[8] http://msdn2.microsoft.com/en-us/library/ms693421.aspx

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

On Tue, 10 Apr 2007 16:59:57 +0200, Seweryn Habdank-Wojewódzki
<habdank@n0-5p4m-gmail.com> wrote:
 
>> 
>> Zna Pan moze w C++ jakis _standardowy_ mechanizm
>> programowania procesow/zadan wspolbieznych ?
>
>Nie ma standardowego, bo inaczej to się robi na DSP, a inaczej na Cray, a
>jeszcze inaczej na klastrze opartym o Mosix. Więc standardowość byłaby za
>pewne nie wskazana. Coś i tak gdzieś by nie działało, albo goście z Craya
>byliby nie zadowoleni z narzuconego minimalizmu, który wymusza DSP. 
>

Hym... A Java na przyklad, nie mowiac o Adzie i Smalltalku?... na
poziomie jezyka sposob programowania procesow wspolbieznych jest
ustandaryzowany; kazda implementacja dba o to zeby bylo w porzadku na
poziomie sprzetu.

>Pytałem ostatnio o platformy docelowe Ady i okazało się, że jest jakiś DSP,
>który pozwala na użycie Ady. Jednak nie był on możliwy dla mnie do
>rozważenia z powodu pewnych innych parametrów, które nie odpowiadały.

Cena kompliatora, jak rozumiem...

Z C++ jest jak z Napoleonem i armatami: Brak GC (prosze nie puszczac
kawalkow z "dostawkami"), manualna gospodarka pamiecia oraz  "naked
pointers". Zajatwia to-to C++ odmownie w roznych aplikacjach, na
przyklad moich. Co nie wyklucza ze dla kogos kto generuje 20 obiektow
jak program "wstaje" i usuwa je tydzien pozniej gdy program zakancza
dzialalnosc C++ moze sie nadac.

A.L.

Witam

A.L. wrote:

> Hym... A Java na przyklad, nie mowiac o Adzie i Smalltalku?... na
> poziomie jezyka sposob programowania procesow wspolbieznych jest
> ustandaryzowany; kazda implementacja dba o to zeby bylo w porzadku na
> poziomie sprzetu.

Nie rozumiem wypowiedzi. Czy zna Pan Smalltalka na DSP? A gdzie Java określa
pracę między procesową?

Teraz Proszę o pokazanie mi języka, który łączy ficzery wszystkich języków
to zacznę go używać. Każdy ma wady i zalety. Ja nie próbuję nikogo zmuszać
do migracji na C++. Jak Pan uważa, że Java jest dobra dla Pana, dlaczego
ona musi być dobra dla mnie?

>>Pytałem ostatnio o platformy docelowe Ady i okazało się, że jest jakiś
>>DSP, który pozwala na użycie Ady. Jednak nie był on możliwy dla mnie do
>>rozważenia z powodu pewnych innych parametrów, które nie odpowiadały.
> 
> Cena kompliatora, jak rozumiem...

Nie. Techniczne własności danego DSP. Czy myśli Pan, że na rynku jest jeden
jedyny DSP do kupienia, a reszta jest kwestią tego czy mnie stać na
kompilator Ady czy nie? Są takie które *nie* oferują kompilatora Ady i
koniec, a są dobre technicznie, a ficzery Ady nie rekompensują innych
strat.
 
> Co nie wyklucza ze dla kogos kto generuje 20 obiektow
> jak program "wstaje" i usuwa je tydzien pozniej gdy program zakancza
> dzialalnosc C++ moze sie nadac.

To jest Pańska ocena programów w C++. Moje programy zazwyczaj pracują na
dużej ilości obiektów. W zależności od aplikacji 10k obiektów na sekundę do
1M obiektów na 10 sekund. Czasem nawet nie potrafię policzyć ile jest
obiektów, kiedy są dynamicznie tworzone w kontekście różnych decyzji, a np.
startuję z pierwotnej kolekcji 200k obiektów, a potem jadą procedury data
miningu, klasteryzacji, klasyfikacji, uczenia predyktorów etc. Obiekty są
tworzone oceniane i kasowane jak nie wnoszą nic nowego.

Rozumiem, że na tej grup[ie mają Panowie jakąś wyłączność na pisanie dużych
projektów i ktoś z zewnątrz nie może takich projektów pisać? Jeśli tak to w
ogóle o czym mowa.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

On Tue, 10 Apr 2007 17:47:45 +0200, Seweryn Habdank-Wojewódzki
<habdank@n0-5p4m-gmail.com> wrote:

>Witam
>
>A.L. wrote:
>
>> Hym... A Java na przyklad, nie mowiac o Adzie i Smalltalku?... na
>> poziomie jezyka sposob programowania procesow wspolbieznych jest
>> ustandaryzowany; kazda implementacja dba o to zeby bylo w porzadku na
>> poziomie sprzetu.
>
>Nie rozumiem wypowiedzi. Czy zna Pan Smalltalka na DSP? A gdzie Java określa
>pracę między procesową?
>

Mowilismy o standardach a nie implementacjach. Jak rowneiz
prawdopodobnie mamy inna definicje  "programowanai procesow
wspolbieznych".

>Teraz Proszę o pokazanie mi języka, który łączy ficzery wszystkich języków
>to zacznę go używać. Każdy ma wady i zalety. Ja nie próbuję nikogo zmuszać
>do migracji na C++. Jak Pan uważa, że Java jest dobra dla Pana, dlaczego
>ona musi być dobra dla mnie?
>

Nie uwazam aby cokolwiek bylo dobra dla Pana. Mowie tylko ze C++ to
pomylka ewolucji.

>>>Pytałem ostatnio o platformy docelowe Ady i okazało się, że jest jakiś
>>>DSP, który pozwala na użycie Ady. Jednak nie był on możliwy dla mnie do
>>>rozważenia z powodu pewnych innych parametrów, które nie odpowiadały.
>> 
>> Cena kompliatora, jak rozumiem...
>
>Nie. Techniczne własności danego DSP. Czy myśli Pan, że na rynku jest jeden
>jedyny DSP do kupienia, a reszta jest kwestią tego czy mnie stać na
>kompilator Ady czy nie? Są takie które *nie* oferują kompilatora Ady i
>koniec, a są dobre technicznie, a ficzery Ady nie rekompensują innych
>strat.

Jakich strat?... Tak na marginesie, kompilatory Ady na egzotyczne
platformy sa jednak dosyc kosztowne.

> 
>> Co nie wyklucza ze dla kogos kto generuje 20 obiektow
>> jak program "wstaje" i usuwa je tydzien pozniej gdy program zakancza
>> dzialalnosc C++ moze sie nadac.
>
>To jest Pańska ocena programów w C++. Moje programy zazwyczaj pracują na
>dużej ilości obiektów. W zależności od aplikacji 10k obiektów na sekundę do
>1M obiektów na 10 sekund. Czasem nawet nie potrafię policzyć ile jest
>obiektów, kiedy są dynamicznie tworzone w kontekście różnych decyzji, a np.
>startuję z pierwotnej kolekcji 200k obiektów, a potem jadą procedury data
>miningu, klasteryzacji, klasyfikacji, uczenia predyktorów etc. Obiekty są
>tworzone oceniane i kasowane jak nie wnoszą nic nowego.
>

Salute you! Ja nie mam tyle czasu, piniedzy i cierpliwosci.

>Rozumiem, że na tej grup[ie mają Panowie jakąś wyłączność na pisanie dużych
>projektów i ktoś z zewnątrz nie może takich projektów pisać? Jeśli tak to w
>ogóle o czym mowa.
>

Alez moze Pan pisac, moze... ja tylko wyrazam zdiwienie ze robi Pan to
w C++.

A.L.

Witam

A.L. wrote:

> Salute you! Ja nie mam tyle czasu, piniedzy i cierpliwosci.

Dziękuję :-).
 
>>Rozumiem, że na tej grup[ie mają Panowie jakąś wyłączność na pisanie
>>dużych projektów i ktoś z zewnątrz nie może takich projektów pisać? Jeśli
>>tak to w ogóle o czym mowa.
>>
> 
> Alez moze Pan pisac, moze... ja tylko wyrazam zdiwienie ze robi Pan to
> w C++.

C++. Czasem Python. Czasem inne dedykowane i już raczej nie działające na
DSP.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

"Wojciech Muła" <wojciech_mula@poczta.null.onet.pl.invalid> wrote:

> Użycie "del" nie powoduje zwolnienia pamięci.

Uscislajac.
Ono nawet nie powoduje zniszczenia obiektu.

AK

Witam

Wojciech Muła wrote:

> Seweryn Habdank-Wojewódzki wrote:
>> Ciekawy np. jest "del" w Pythonie, czy Python mając del jest
>> strukturalnym asemblerem?
> 
> Użycie "del" nie powoduje zwolnienia pamięci.

Hmm... Rozumiem, że del nie jest odpowiednikiem delete z C++, czy też free z C.
Ale moja analiza korelacyjna wykazuje, że istnieje związek del 
ze zwalnianiem pamięci.

Proszę zbadać następujący program:

<code filename=test_mem.py>

#!/usr/bin/env python

import sys

raw_input('Press any key.')

data = []

for x in range(0,100000):
    data.append(x)

raw_input('Press any key.')

del data[:len(data)/2]

raw_input('Press any key.')

sys.exit()

</code>

przy pomocy np.

pmap `ps ak comm o pid,args | grep "./test_mem.py" | grep -v grep | cut -f1 -d" "`

del nie zwalnia całej pamięci. del robi wiele ciekawszych rzeczy też, np. 
może kasować pola w klasie i metody i wiele innych równie interesujących spraw.

Ale del daje zielone światło do GC, że ten może coś sprzątać.

A tak na marginesie to nie odpowiedziałeś na moje pytanie, tylko na jakieś 
zadane zadane przez samego siebie - rozumiem, że nie całkiem zrozumiałeś 
to o co pytałem :-).

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

Seweryn Habdank-Wojewódzki wrote:
> Ale del daje zielone światło do GC, że ten może coś sprzątać.

No właśnie, a czy GC sprzątnie i kiedy, "nie nasza rzecz wiedzieć".
Swoją drogą piszę sporo w pythonie i nie przypominam sobie, żebym
używał "del" do innych celów niż usuwanie elementów ze słowników/list.

> A tak na marginesie to nie odpowiedziałeś na moje pytanie, tylko na jakieś 
> zadane zadane przez samego siebie - rozumiem, że nie całkiem zrozumiałeś 
> to o co pytałem :-).

Przecież na tym polega flejmowanie. ;)  Nie, Python nie jest
"strukturalnym asemblerem".

w.

Witam

Wojciech Muła wrote:

> No właśnie, a czy GC sprzątnie i kiedy, "nie nasza rzecz wiedzieć".
> Swoją drogą piszę sporo w pythonie i nie przypominam sobie, żebym
> używał "del" do innych celów niż usuwanie elementów ze słowników/list.

Hmm... a klasy, które mają __del__(self)? np. otwierające jakiś sokecik, czy
połączenie do DB? Czy trzeba pisać __del__(), czy trzeba używać del obiekt?
Rozumiem że to jest NTG i OT, ale poproszę o jakiegoś linka, z
przykładzikami kiedy należy, a kiedy nie trzeba pisać del i __del__(self).
 
>> A tak na marginesie to nie odpowiedziałeś na moje pytanie, tylko na
>> jakieś zadane zadane przez samego siebie - rozumiem, że nie całkiem
>> zrozumiałeś to o co pytałem :-).
> 
> Przecież na tym polega flejmowanie. ;)

:-)

> Nie, Python nie jest "strukturalnym asemblerem".

To dobrze, bo w takim razie nie jestem zdany tylko na moc i nie moc
strukturalnych asemblerów - używam niestrukturalnego nieasemblera o
skróconej nazwie Python :-D.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

"Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> wrote:

>> Użycie "del" nie powoduje zwolnienia pamięci.
>
> Hmm... Rozumiem, że del nie jest odpowiednikiem
> delete z C++, czy też free z C.

I nigdy nie byl.

> Ale moja analiza korelacyjna wykazuje, że istnieje związek del
> ze zwalnianiem pamięci.

Zaden
Pana analiza jest dorabianiem teorii.
Del w Pythonie robi tylko i wylacznei 2 rzeczy
1. wywoluje (jesli istnieje) metode __del__
2. likwiduje metke do obiektu
   To likwdidowanie metki skutkuje oczywiscie
    zmniejszeniem licznika odwolan do obiektu
    co jest naturalna koleja rzeczy.

Dla kontenerow jest podobnie
Del likwiduje zakres "metek"
(czyli scope) i tyle.
Zadnego zwalniania pamieci
obiektow tu nie ma.


> del nie zwalnia całej pamięci.

del nei zwalnia zadnej pamieci.
No chyba ze robocza na referencje w kontenerze
ale to jest nic nie znaczacy szczegol implementacyjny.
Wcale zreszta niepewny.

> del robi wiele ciekawszych rzeczy też, np.
> może kasować pola w klasie i metody i wiele innych
> równie interesujących spraw.

Nie.
del nic nie kasuje
Del tylko usuwa nazwe/metke ze slownika klasy.
To samo tyczy metod

> Ale del daje zielone światło do GC, że ten może coś sprzątać.

Nie. GC nie wie nawet o del.
Ono patrzy tylko czy obiekt jest uzywany.
Samo del nie daje jej zielonego swiatla.
Zielone swiatlo daje dopiero fakt ze juz nikt
nie uzywa obiektu a to sie moze stac zupelnie
bez uzycia del

AK

Seweryn Habdank-Wojewódzki wrote:
> Hmm... a klasy, które mają __del__(self)? np. otwierające jakiś sokecik, czy
> połączenie do DB? Czy trzeba pisać __del__(), czy trzeba używać del obiekt?

Z tym są kłopoty, poczytaj: 
http://docs.python.org/ref/customization.html#l2h-178
Moim zdaniem to całe __del__ jest spieprzone.

> Rozumiem że to jest NTG i OT, ale poproszę o jakiegoś linka, z
> przykładzikami kiedy należy, a kiedy nie trzeba pisać del i __del__(self).

Najlepiej zamykać takie zasoby wprost.  W pythonie 2.5 wprowadzono
'with', co nieco upraszcza życie: http://www.python.org/dev/peps/pep-0343/

w.

Witam

Adam Karpierz wrote:

>> Ale moja analiza korelacyjna wykazuje, że istnieje związek del
>> ze zwalnianiem pamięci.
> 
> Zaden

No Panie A.K. potestuj Pan program.

> Pana analiza jest dorabianiem teorii.
> Del w Pythonie robi tylko i wylacznei 2 rzeczy
> 1. wywoluje (jesli istnieje) metode __del__

Tak.

> 2. likwiduje metke do obiektu
>    To likwdidowanie metki skutkuje oczywiscie
>     zmniejszeniem licznika odwolan do obiektu
>     co jest naturalna koleja rzeczy.

Tak? Ale heca z pieca! A jak licznik jest 0 i gc uzna, że jest mało ramu to
co robi? 

Całe szczęście że implementacja GC w pythonie nie czeka nie wiadomo do
kiedy, aby kasować obiekty których liczniki mają 0 odwołań. Programiści
jednak uznali, że czekać chwilę można, ale nie w nieskończoność, bo
zwalnianie większej ilości pofragmentowanego ramu na raz też trwa.

> Zadnego zwalniania pamieci
> obiektow tu nie ma.

To też napisałem, ale Panu wściekłość tak zalewa oczy, że Pan tego nie
widzi. 

>> del robi wiele ciekawszych rzeczy też, np.
>> może kasować pola w klasie i metody i wiele innych
>> równie interesujących spraw.
> 
> Nie.
> del nic nie kasuje

Zwał jak zwał. Kasuje czy usuwa - co jest lepsze.

> Del tylko usuwa nazwe/metke ze slownika klasy.

Oczywiście.

> To samo tyczy metod

Także.

>> Ale del daje zielone światło do GC, że ten może coś sprzątać.
> 
> Nie. GC nie wie nawet o del.

No tak, bo po drodze jest licznik odwołań. I GC nie czyta del, tylko licznik
odwołań.

> Ono patrzy tylko czy obiekt jest uzywany.
> Samo del nie daje jej zielonego swiatla.

Oczywiście. Do momentu, aż licznik odwołań nie spada do 0, co może być
spowodowane poprzez del i nie tylko.

> Zielone swiatlo daje dopiero fakt ze juz nikt
> nie uzywa obiektu a to sie moze stac zupelnie
> bez uzycia del

Oczywiście. Czy ja napisałem inaczej?

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

"Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> wrote:

> Hmm... a klasy, które mają __del__(self)? np. otwierające jakiś sokecik, 
> czy
> połączenie do DB? Czy trzeba pisać __del__(), czy trzeba używać del 
> obiekt?
> Rozumiem że to jest NTG i OT, ale poproszę o jakiegoś linka, z
> przykładzikami kiedy należy, a kiedy nie trzeba pisać del i __del__(self).

Panie Kolego, pisdzac w Pythonie wypadalo by sie wreszcie
dowiedziec czym sie rozni w skutkach:

obiekt.__del__()
od
del obiekt

Rozni sie bardzo.
To mozna bardzo latwo sprawdzic ekperymentalnie.

> używam niestrukturalnego nieasemblera o  skróconej nazwie
> Python :-D.

Pan go uzywa nie znajac.
Nie wrozy to dobrze :(

PS: Czy wie Pan ze w Pythonie kazdy obiekt nie ma
        w ogole nazwy ? Kazdy to NN :(

AK

"Wojciech Muła" <wojciech_mula@poczta.null.onet.pl.invalid> wrote:

> Z tym są kłopoty, poczytaj: 
> http://docs.python.org/ref/customization.html#l2h-178
> Moim zdaniem to całe __del__ jest spieprzone.

Nie zgodze sie.

__del__() to zwykla metoda.
Jest po prostu wywolywana wtedy gdy
obiekt juz nie jest uzywany przez nikogo i przestaje istniec (smieciarka).
Oczywiscie nozna ja sobie wywolywac wczesniej co niczego
nie zmienia. I tak bedzie wywolana w ww/w sytuacji jeszcze
raz (juz ostatni :)

del obiekt
natomiast po prostu (i tylko ) likwiduje nazwe (metke) obiektu
w danej przestrzeni nazw i tym samym zmniejsza
liczbe odwolan do obiektu.
Tylko tyle.

AK

"Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> wrote :

> No Panie A.K. potestuj Pan program.

Panie Wojewodzki, nie wszytsko co plywa ryba sie nazywa.

>> Pana analiza jest dorabianiem teorii.
>> Del w Pythonie robi tylko i wylacznei 2 rzeczy
>> 1. wywoluje (jesli istnieje) metode __del__
>
> Tak.

No i widzi Pan ?
Oczywistej nieprawdy Pan nie zauwazyl
Wlasnei ze _nie_ :).

W ogole nie dotyka __del__()
To tylko zbieznoisc nazw.

AK 

Witam

Adam Karpierz wrote:

> Panie Kolego, pisdzac w Pythonie wypadalo by sie wreszcie
> dowiedziec czym sie rozni w skutkach:
> 
> obiekt.__del__()
> od
> del obiekt

Panie A.K. czyżby myślał Pan że nie czytałem o del i __del__? To proszę
kuknąć na [1]. I powiedzieć mi czy działanie tych funkcji jest ortogonalne?

A tak na marginesie to jaki jest zatem preferowany styl uznawany przez ogół
do oznaczania finalizatorów klas/obiektów np. jak napisałem wcześniej
zamykanie połączenia z bazą danych, czy gniazda?
 
>> używam niestrukturalnego nieasemblera o  skróconej nazwie
>> Python :-D.
> 
> Pan go uzywa nie znajac.

A Pan robi to samo z C++. Więc jesteśmy po jednakich pieniądzach.

> Nie wrozy to dobrze :(

Dla Pana? Czy dla mnie?

Pozdrawiam.

[1] http://docs.python.org/ref/customization.html#l2h-177

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

Adam Karpierz wrote:
>> Z tym s? k^(3)opoty, poczytaj: 
>> http://docs.python.org/ref/customization.html#l2h-178
>> Moim zdaniem to ca^(3)e __del__ jest spieprzone.
> 
> Nie zgodze sie.
> 
> __del__() to zwykla metoda.
> Jest po prostu wywolywana wtedy gdy
> obiekt juz nie jest uzywany przez nikogo i przestaje istniec (smieciarka).
> Oczywiscie nozna ja sobie wywolywac wczesniej co niczego
> nie zmienia. I tak bedzie wywolana w ww/w sytuacji jeszcze
> raz (juz ostatni :)

Problem z tym, ze gdy __del__ jest wolane "niewiadomo-kiedy".
Nacialem się na to przy programowaniu w Tkinterze -- obiekt
reprezentowal "cos" na canvas i umysliłem sobie, zeby zwalanial
tkinterowe obiekty w __del__ wlasnie.  Zwalnial, a jakze, tylko
na samym koncu dzialania programu, ale ze wczesniej polaczenie
z tcl-em bylo zamykane, to oczywiscie wywalilo mnosto bledow.

Wydaje mi sie bardziej logiczne, gdyby uzycie "del" powodowalo
za pierwszym razem wolanie __del__ (od razu!) i zmniejszenie
licznika referencji, a kazde kolejne "dele" tylko zmniejszalyby
licznik.

w.

Witam

Adam Karpierz wrote:

> "Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> wrote :
> 
>> No Panie A.K. potestuj Pan program.
> 
> Panie Wojewodzki, nie wszytsko co plywa ryba sie nazywa.
> 
>>> Pana analiza jest dorabianiem teorii.
>>> Del w Pythonie robi tylko i wylacznei 2 rzeczy
>>> 1. wywoluje (jesli istnieje) metode __del__
>>
>> Tak.
> 
> No i widzi Pan ?
> Oczywistej nieprawdy Pan nie zauwazyl
> Wlasnei ze _nie_ :).

W manualu stoi:

del x" doesn't directly call x.__del__()

Co można rozumieć że nie woła, ale użycie słowa directly wskazuje na to że
nie woła bezpośrednio (wprost). Jednak można to rozumieć, że woła nie
wprost. Tak czy inaczej praca z del powoduje prędzej czy później odpalenie
__del__()

#!/usr/bin/env python

import sys

class A:
    def __init__(self):
        print "init"

    def __del__(self):
        print "del"

a = A()
del a

raw_input ("Press any key.")

sys.exit()

a wynik

init
del
Press any key.

Zatem __del__() odpalono przed raw_input.
 
> W ogole nie dotyka __del__()
> To tylko zbieznoisc nazw.

Rozumiem, zatem co służy do odpalania __del__()? Albo dalej co służy do
zwalniania zasobów w szczególności różnych od ramu lub pliku. A może panuje
wolność jeden sobie nazwie "endzik", drugi "finalizik",
trzeci "a_idz_baco_do_domu". Może - tego jeszcze nie zbadałem.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

"Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> wrote:

> Panie A.K. czyżby myślał Pan że nie czytałem o del i __del__? To proszę
> kuknąć na [1]. I powiedzieć mi czy działanie tych funkcji jest 
> ortogonalne?

Panie kochany.
Jest w pelni ortogonalne.
Dla scislosci
del obiekt nie jest zadna funkcja (w sensie jezyka)
to statement i tak nalezy go rozumiec.

> A tak na marginesie to jaki jest zatem preferowany styl uznawany przez 
> ogół
> do oznaczania finalizatorów klas/obiektów np. jak napisałem wcześniej
> zamykanie połączenia z bazą danych, czy gniazda?

__del__()

> A Pan robi to samo z C++. Więc jesteśmy po jednakich pieniądzach.

Mysle ze znam C++.
Panu sie moze wydaje ze znajomiosc jezyka polega
na scislym poznaniu jego wszystkich jego zakamarkow ?.

AK

"Wojciech Muła" <wojciech_mula@poczta.null.onet.pl.invalid> wrote:

> Problem z tym, ze gdy __del__ jest wolane "niewiadomo-kiedy".

To prawda.

> Nacialem się na to przy programowaniu w Tkinterze -- obiekt
> reprezentowal "cos" na canvas i umysliłem sobie, zeby zwalanial
> tkinterowe obiekty w __del__ wlasnie.  Zwalnial, a jakze, tylko
> na samym koncu dzialania programu, ale ze wczesniej polaczenie
> z tcl-em bylo zamykane, to oczywiscie wywalilo mnosto bledow.

No niestety .
Tkinter to jednak "osobne" polaczenie
dwoch jezykow i Tcl nie jest w stanie sie dowiedziec
ze sa jeszcze jakies widgety uzywane :(

> Wydaje mi sie bardziej logiczne, gdyby uzycie "del" powodowalo
> za pierwszym razem wolanie __del__ (od razu!) i zmniejszenie
> licznika referencji, a kazde kolejne "dele" tylko zmniejszalyby
> licznik.

Niestety, ale wtedy np inne obiekty korzystajace z tegoz
pracowalyby np. na zamknietym polaczeniu nic o tym
nie wiedzac.

Niestety nie ma zlotego srodka.
jest tylko bezpieczniejszy (ten ktory jest).

Do problemow slabych wiazan warto uzywac weakref

PS: dobra , juz zmieniam sposob pisania (bo mnie juz samego meczy)
        dostosowany bardzej do p.Wojewodzkiego

AK

"Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> wrote:

> Co można rozumieć że nie woła, ale użycie słowa directly wskazuje na to że
> nie woła bezpośrednio (wprost).

> Jednak można to rozumieć, że woła nie wprost.

Nie wola w ogole.
__del__() wywoluje wylacznei smieciarka.

> Tak czy inaczej praca z del powoduje prędzej czy później odpalenie
> __del__()

Nie.

> Zatem __del__() odpalono przed raw_input.

I co z tego ?
Panie kolego z tego nic nie wynika .

>> W ogole nie dotyka __del__()
>> To tylko zbieznoisc nazw.
>
> Rozumiem, zatem co służy do odpalania __del__()?

obiekt.__del__()
Nie polecam jednak.

> Albo dalej co służy do
> zwalniania zasobów w szczególności różnych od ramu lub pliku.

__del__()

>  A może panuje
> wolność jeden sobie nazwie "endzik", drugi "finalizik",
> trzeci "a_idz_baco_do_domu". Może - tego jeszcze nie zbadałem.

Pan sie pcha na pole minowe.
Do zwalniania zasobow obiektu slyzy __del__()

AK

Witam

Adam Karpierz wrote:

> "Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> wrote:
> 
>> Panie A.K. czyżby myślał Pan że nie czytałem o del i __del__? To proszę
>> kuknąć na [1]. I powiedzieć mi czy działanie tych funkcji jest
>> ortogonalne?
> 
> Panie kochany.
> Jest w pelni ortogonalne.

Może, ale nie w sensie funkcji korelacji. Zawsze po del ubywa trochę
zajętości ramu, cokolwiek to jest. I po del gc wie, że może sobie sprzątać,
jak ma ochotę, lub jak go pełny pęcherz pomęczy. Np. sito Erastotenesa
szybko męczy pęcherz i trzeba sprzątać - po ok. 3 sekundach ok. 100 MB
zajęte, szybko zabraknie dowolnej ilości ramu.

> Dla scislosci
> del obiekt nie jest zadna funkcja (w sensie jezyka)
> to statement i tak nalezy go rozumiec.

To dobrze. W C++ delete też nie jest funkją.
 
>> A tak na marginesie to jaki jest zatem preferowany styl uznawany przez
>> ogół
>> do oznaczania finalizatorów klas/obiektów np. jak napisałem wcześniej
>> zamykanie połączenia z bazą danych, czy gniazda?
> 
> __del__()

To mnie intuicja i czytanie dokumentacji nie zawiodły. Dziękuję.
 
>> A Pan robi to samo z C++. Więc jesteśmy po jednakich pieniądzach.
> 
> Mysle ze znam C++.

Tak jak ja Pythona?

> Panu sie moze wydaje ze znajomiosc jezyka polega
> na scislym poznaniu jego wszystkich jego zakamarkow ?.

Nie ale w zakamarkach dziabeł czycha :-). Poza tym dla mnie zakamarki to też
przeróżniaste frameworki, które działają czasami niespodziewanie (dobrze) i
wykorzystują różne ficzery i sztuczki w języku.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

Witam

Adam Karpierz wrote:

>> Jednak można to rozumieć, że woła nie wprost.
> 
> Nie wola w ogole.
> __del__() wywoluje wylacznei smieciarka.

Śmieciakra, która współpracuje z licznikiem odwołań czy innym sposobem
kontroli. A który jest częściowo determinowany przez del, częściej przez
koniec fukcji, czy klasy.
 
>>  A może panuje
>> wolność jeden sobie nazwie "endzik", drugi "finalizik",
>> trzeci "a_idz_baco_do_domu". Może - tego jeszcze nie zbadałem.
> 
> Pan sie pcha na pole minowe.

Tak, bo zasoby to nie tylko plik, czy ram.

> Do zwalniania zasobow obiektu slyzy __del__()

Super! Dziękuję.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

Użytkownik "Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> napisał:

>> Panie kochany.
>> Jest w pelni ortogonalne.
>
> Może,

Nie 'moze' ale 'napewno'.

> ale nie w sensie funkcji korelacji.
> Zawsze po del ubywa trochę zajętości ramu, cokolwiek to jest.

Nie.
Panie Wojewodzki, czy kazdy dzisiejszy 'wymiatacz' C++ ma obsesje
braku pamieci ?
Czy PAn mysli ze _jedyna_ pamiecia ktorej uzywaja jezyki jest ta brana 
mallockiem
czy innym sbrk ?
Czy Pan sobie moze wyobrazic ze na takiej Odrze 1325 bylo
32kW pamieci i jakos dalo sie naprawde duze rzeczy policzyc/oprogramowac ?
Niech sie Pan wyleczy z tej obsesji zwlaszac dzisiaj gdy brakujaca pamiec 
mozna
znalezc w kazdym smietniku.

> To dobrze. W C++ delete też nie jest funkją.

jest

>
>>> A tak na marginesie to jaki jest zatem preferowany styl uznawany przez
>>> ogół
>>> do oznaczania finalizatorów klas/obiektów np. jak napisałem wcześniej
>>> zamykanie połączenia z bazą danych, czy gniazda?
>>
>> __del__()
>
> To mnie intuicja i czytanie dokumentacji nie zawiodły. Dziękuję.

Otoz zawiodly Pana i to zupelnie.
Do rzeczywitych problemow slabych wiazan uzywa sie weakref.
Natomiast to co Pan probuje zrobic to zamach na elementarna logike.
Probuje Pan 'sfinalizowac' obiekt jeszcze przez kogos uzywany.
To ze w Pan w swoim scope chcesz zamknac np socketa
i placzesz ze nie da sie przez del obiekt, bo sie __del__ nie wykona
to Pana blad bo Pan w ogole nie myslisz o innych.
Zdaj sie pan na gc. Ono bedzie najlepiej wiedziec kiedy juz
_faktycznie_ ten socket nie bedzie nikomu potrzebny.

> Nie ale w zakamarkach dziabeł czycha :-). Poza tym dla mnie zakamarki to 
> też
> przeróżniaste frameworki, które działają czasami niespodziewanie (dobrze) 
> i
> wykorzystują różne ficzery i sztuczki w języku.

No taaak.
Teraz wszytsko jasne.

AK

Użytkownik "Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> napisał:

> Śmieciakra, która współpracuje z licznikiem odwołań czy innym sposobem
> kontroli. A który jest częściowo determinowany przez del, częściej przez
> koniec fukcji, czy klasy.

Nie.
Smieciarka nie wspolpracuje z licznkiem odwolan.
Ona mu sie tylko czasem (jak jej sie w ogole czasami zechce) przyglada
ale _wszelkie_ decyzje podejmuje autonomicznie.

> Tak, bo zasoby to nie tylko plik, czy ram.

Nie o to chodzi.
Pan nie mysli o innych.

AK

Witam

Adam Karpierz wrote:

> Czy Pan sobie moze wyobrazic ze na takiej Odrze 1325 bylo
> 32kW pamieci i jakos dalo sie naprawde duze rzeczy policzyc/oprogramowac ?

A w ZX Spectrum, który do dziś jest używany było 48-128k ramu i co z tego.
Na DSP też jest mało ramu i liczy się dużo i szybko, co to ma za znaczenie.

>> To dobrze. W C++ delete też nie jest funkją.
> 
> jest

słowem kluczowym?

Jesli jest fukcją to co zwraca delete? void?
 
> Otoz zawiodly Pana i to zupelnie.
> Do rzeczywitych problemow slabych wiazan uzywa sie weakref.
> Natomiast to co Pan probuje zrobic to zamach na elementarna logike.
> Probuje Pan 'sfinalizowac' obiekt jeszcze przez kogos uzywany.

Tak. To ciekawe. Myslałem że rozróżnianie weakref i innych ref to typowe dla
C++. A ja myślałem, że to obrzydliwe, aby musieć się koncentrować na
technikaliach.

> To ze w Pan w swoim scope chcesz zamknac np socketa
> i placzesz ze nie da sie przez del obiekt, bo sie __del__ nie wykona
> to Pana blad bo Pan w ogole nie myslisz o innych.
> Zdaj sie pan na gc. Ono bedzie najlepiej wiedziec kiedy juz
> _faktycznie_ ten socket nie bedzie nikomu potrzebny.

A jeżeli ja go otwarłem w konstruktorze? To właśnie zmartwienie moje polega
na tym, że lepiej komuś go odstąpić, może sobie chce wykorzystać?

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

Użytkownik "Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> napisał:

>>> To dobrze. W C++ delete też nie jest funkją.
>>
>> jest
>
> słowem kluczowym?

Tak.
Operatorem ? Tak.
Funkcja ? Tak.

> Jesli jest fukcją to co zwraca delete? void?

Czy funkcja w C/C++ cos musi zwracac ?
To nie Pascal.

> Tak. To ciekawe. Myslałem że rozróżnianie weakref i innych ref to typowe 
> dla
> C++.

W C++ nie ma weakref.
Ani w ARM ani w ISO => W C++ nie ma.

> A ja myślałem, że to obrzydliwe, aby musieć się koncentrować na 
> technikaliach.

Jakich technikaliach ?
Wystarczy sie koncentrowac na logice.
Naprawde poza logika trudno ad hoc wyczuc,
ze ktos inny jednak jeszcze zechce uzyc tego socketa ktory
Pan sie upadl wlasnie teraz zamknac.

>> To ze w Pan w swoim scope chcesz zamknac np socketa
>> i placzesz ze nie da sie przez del obiekt, bo sie __del__ nie wykona
>> to Pana blad bo Pan w ogole nie myslisz o innych.
>> Zdaj sie pan na gc. Ono bedzie najlepiej wiedziec kiedy juz
>> _faktycznie_ ten socket nie bedzie nikomu potrzebny.
>
> A jeżeli ja go otwarłem w konstruktorze?

Co to zmienia ?
To zapobiega ze ktos go moze uzyc ?

> To właśnie zmartwienie moje polega
> na tym, że lepiej komuś go odstąpić,
> może sobie chce wykorzystać?

No to co za problem ?.
Gdy zechce i sam sobie wezmie, albo Pan mu da, to sie __del__
nie wykona.
Wykona sie dopiero i tylko wtedy gdy juz _nikt_ nie bedzie korzystal.
Wiec __del__() jest idealne dla Pana w tym przypadku.

AK

Witam

Adam Karpierz wrote:

>> Jesli jest fukcją to co zwraca delete? void?
> 
> Czy funkcja w C/C++ cos musi zwracac ?

Tak. W szczególności void.

>> Tak. To ciekawe. Myslałem że rozróżnianie weakref i innych ref to typowe
>> dla
>> C++.
> 
> W C++ nie ma weakref.

To może o czym innym mówimy. Ja mówię o boost::weak_ptr, który np. służy do
rozbijania cykli w grafach zależności pomiędzy bytami.

> Wystarczy sie koncentrowac na logice.
> Naprawde poza logika trudno ad hoc wyczuc,
> ze ktos inny jednak jeszcze zechce uzyc tego socketa ktory
> Pan sie upadl wlasnie teraz zamknac.

Właśnie o tym mówiłem. Ze czasami trzeba pomyśleć nie tylko o sobie ale też
o innych. I dlatego preferuję sprzątanie po każdej akcji. A tak na
marginesie, to jeśli woli Pan mieć otwarty socket, to przecież Panu go nie
sprzątam, tylko oddaje zabierając swoje inne śmieci. To jest do ustalenia w
programie.

>>> To ze w Pan w swoim scope chcesz zamknac np socketa
>>> i placzesz ze nie da sie przez del obiekt, bo sie __del__ nie wykona
>>> to Pana blad bo Pan w ogole nie myslisz o innych.
>>> Zdaj sie pan na gc. Ono bedzie najlepiej wiedziec kiedy juz
>>> _faktycznie_ ten socket nie bedzie nikomu potrzebny.
>>
>> A jeżeli ja go otwarłem w konstruktorze?
> 
> Co to zmienia ?
> To zapobiega ze ktos go moze uzyc ?

A jeśli ktoś chce go użyć w innej wersji. Np. zmiana TCP na UDP?
 
Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

Witam

Adam Karpierz wrote:

>> Tak, bo zasoby to nie tylko plik, czy ram.
> 
> Nie o to chodzi.
> Pan nie mysli o innych.

Aha. No to już nie mam argumentów :-).

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

To reply remove "n0-5p4m-" from e-mail address.

Użytkownik "Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com> napisał:

>> Czy funkcja w C/C++ cos musi zwracac ?
>
> Tak. W szczególności void.

Czyli void to jakis typ ?
Bo pierwsze slysze aby mozna cos w C++ zwrocic co nie ma typu.

PS: Panu sie najwyrazniej C++ z Pythonem myli.

AK 

Witam

Adam Karpierz wrote:

> Użytkownik "Seweryn Habdank-Wojewódzki" <habdank@n0-5p4m-gmail.com>
> napisał:
> 
>>> Czy funkcja w C/C++ cos musi zwracac ?
>>
>> Tak. W szczególności void.
> 
> Czyli void to jakis typ ?
> Bo pierwsze slysze aby mozna cos w C++ zwrocic co nie ma typu.

Wot taka definicja:

void foo ( void );
 
> PS: Panu sie najwyrazniej C++ z Pythonem myli.

Możliwe.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia 11-04-2007, śro o godzinie 10:46 +0200, Adam Karpierz napisał(a):

> > To dobrze. W C++ delete też nie jest funkją.
> 
> jest

Oba stwierdzenia mogą być prawdziwe, zależnie od tego, o czym mówimy.

W C++ jest instrukcja delete, która nie jest wywołaniem funkcji,
i operator delete, który jest funkcją.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Użytkownik "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> napisał:

> > > To dobrze. W C++ delete też nie jest funkją.
> >
> > jest
>
> Oba stwierdzenia mogą być prawdziwe, zależnie od tego,
> o czym mówimy.
>
> W C++ jest instrukcja delete, która nie jest wywołaniem funkcji,
> i operator delete, który jest funkcją.

Nie Pan nie wypisuje kolejnych bzdur.
W C++ w ogole _nie istnieje_ instrukcja delete.
(Tak samno jak _nie istnieje_ instrukcja throw np.)

W C++ jest tylko i wylacznie _operator_ delete,
(a raczej dwa) a jak tez dobrze wiadomo operatory
w C++ to sa po prostu funkcje badz metody.
Nawet tak sa nazywane: funkcje operatorowe.

Wiec podsumowujac Panie Qrczak zeby sie Panu utrwalilo:
delete w C++ jest tylko i wylacznie _funkcja_ a nie zadna instrukcja.

PS: standardy wszelkie niby ma Pan w glowie, a _tez_
      tworzy wlasne teorie. Nie posadzalem Pana o to.

AK

Adam Karpierz wrote:
> Wiec podsumowujac Panie Qrczak zeby sie Panu utrwalilo:
> delete w C++ jest tylko i wylacznie _funkcja_ a nie zadna instrukcja.
> 

Qrczak ma rację. Zobacz do punktów: 5.3.5 i 3.7.3.2 standardu C++.

Pozdrawiam
KK

Dnia 12-04-2007, czw o godzinie 09:21 +0200, Adam Karpierz napisał(a):

> W C++ w ogole _nie istnieje_ instrukcja delete.
> (Tak samno jak _nie istnieje_ instrukcja throw np.)
> 
> W C++ jest tylko i wylacznie _operator_ delete,
> (a raczej dwa) a jak tez dobrze wiadomo operatory
> w C++ to sa po prostu funkcje badz metody.

Nie.

Pomyliłem się tylko o tyle, że to nie instrukcja, tylko wyrażenie
(o wyniku typu void, więc w praktyce używane wyłącznie po dodaniu
średnika jako instrukcja). Wyrażenie delete woła destruktor i operator
delete.

Z kolei wyrażenie delete[] woła destruktory elementów i operator
delete[] (zwykle z argumentem przesuniętym względem tego, który dostało
wyrażenie delete, i odpowiednio powiększonym rozmiarem, bo rozmiar
tablicy większość implementacji zapisuje przed tablicą).

Podobnie wyrażenie new dla typu nie będącego typem tablicowym woła
operator new, a potem konstruktor, przy czym jeśli konstruktor rzuci
wyjątkiem, to przed jego propagacją wołany jest operator delete.

Dla typu tablicowego w wyrażeniu new wołany jest operator new[]
zamiast operatora new, wskaźnik i rozmiar mogą być przesunięte, a jeśli
któryś konstruktor rzuci wyjątkiem, to dodatkowo wołane są destruktory
elementów skonstruowanych przed nim.

Wyrażenie delete to co innego niż operator delete, wyrażenie delete[]
to co innego niż operator delete[], wyrażenie new to co innego niż
operator new i operator new[].

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Użytkownik "Krzysiek Kowaliczek" <this@poczta.fm> napisał:

> Qrczak ma rację. Zobacz do punktów: 5.3.5 i 3.7.3.2 standardu C++.

Zobacz sobie gramatyke C++ w tymze standardzie.

AK 

Witam

Marcin 'Qrczak' Kowalczyk wrote:

> Dnia 11-04-2007, śro o godzinie 10:46 +0200, Adam Karpierz napisał(a):
> 
>> > To dobrze. W C++ delete też nie jest funkją.
>> 
>> jest
> 
> Oba stwierdzenia mogą być prawdziwe, zależnie od tego, o czym mówimy.

Słusznie. delete jako deleki kuzyn/dziadek del w pythonie. Lub jako operator
w szczególności, który można przeładować, dla jakiegoś obiektu.
 
Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Adam Karpierz wrote:
> 
> Zobacz sobie gramatyke C++ w tymze standardzie.
> 

Zobaczyłem i co miałem miało mnie tam zaskoczyć? Jest *delete 
expression* i *delete operator*. Czyli to co napisał Qrczak, w ostatnim 
poście.

Pozdrawiam
KK

"Krzysiek Kowaliczek" <this@poczta.fm> wrote:

> Zobaczyłem i co miałem miało mnie tam zaskoczyć? Jest *delete expression* 
> i *delete operator*. Czyli to co napisał Qrczak, w ostatnim poście.

A jest gdzies *delete statement* o czym tak wszytscy (lacznie z qrczakiem)
przekonywali pewnie ?

Ale zgadzam sie z tym ze powinna byc w C++ instrukcja delete
(tak jak w Pythonie np.),  a nie chory operator delete i to instrukcja
dzialajaca na referencji a nie na oblesnym przekazywanym
przez wartosc wyrazeniu.

A qrczak wyraznie miesza synktatyke/gramatylke z semantyka
wykonania.
Pisze wiec nie na temat.
Pisze zreszta w jakichs miejscach nieprawde.

AK

Witam

Adam Karpierz wrote:

> Użytkownik "Krzysiek Kowaliczek" <this@poczta.fm> napisał:
> 
>> Qrczak ma rację. Zobacz do punktów: 5.3.5 i 3.7.3.2 standardu C++.
> 
> Zobacz sobie gramatyke C++ w tymze standardzie.

Rozdział 2.11.

delete jest słowem kluczowym.

Kto da więcej?

Co to jest instrukcja? W standardzie nie jest określone co to jest
instrukcja. Może ma Pan jakąś definicyjkę pod ręką co by się nieco
usprawiedliwić.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

"Seweryn Habdank-Wojewódzki" <habdank@gmail.com> wrote:

> Co to jest instrukcja? W standardzie nie jest określone co to jest
> instrukcja.

Kurde Panie wojewodzki, przestan Pan
ludziom robic wode z mozgu.
W standardzie jezyka nie jest okreslone _co to jest_
instrukcja ?
No lepszego kabaretu ostatnio nie widzialem :)

>  Może ma Pan jakąś definicyjkę pod ręką co by się nieco
> usprawiedliwić.

Pan niech sie usprawiedliwi ze swojej indolencji.

AK 

Witam

Adam Karpierz wrote:

> Kurde Panie wojewodzki, przestan Pan
> ludziom robic wode z mozgu.

Jak na razie To Pan robi różne podchody i prowokacje.

> W standardzie jezyka nie jest okreslone _co to jest_
> instrukcja ?

Cytuję za wikipedią:

Instruction (computer science) ? a single operation of a processor within a
computer architecture.

Może też komenda:

In computing, a command is a directive to a computer program acting as an
interpreter of some kind, in order to perform a specific task. Most
commonly a command is a directive to some kind of command line interface,
such as a shell.

Teraz otwieram draft standardu C++. Wpisuję: "instruction"

Total instances found: 0

Dobra. Spróbuję command:

Total instances found: 0

> No lepszego kabaretu ostatnio nie widzialem :)

Chyba jednak nie ma. Przykro mi.

Może jest w Pańskim standardzie C++?

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

"Seweryn Habdank-Wojewódzki" <habdank@gmail.com> wrote:

>> Kurde Panie wojewodzki, przestan Pan
>> ludziom robic wode z mozgu.
>
> Jak na razie To Pan robi różne podchody i prowokacje.

Nie przecze.

>
>> W standardzie jezyka nie jest okreslone _co to jest_
>> instrukcja ?
>
> Cytuję za wikipedią:

Prosze Pana,
nie rozmawiamy o zyciu erotycznym salamander.

> Teraz otwieram draft standardu C++. Wpisuję: "instruction"
> Total instances found: 0
> Dobra. Spróbuję command:
> Total instances found: 0

>> No lepszego kabaretu ostatnio nie widzialem :)
> Chyba jednak nie ma. Przykro mi.
> Może jest w Pańskim standardzie C++?

Panie Wojewodzki, jesli by Pan troche dluzej
zyl na swiecie to wiedzialby ze odpowiednikiem
slowa statement w _fachowej_ (a nie w 24h itp)
literaturze  informatycznej odnosnie jezykow
programowania _zawsze_ byla instrukcja
(potwierdzi to ktos z innych ?).
Pisze byla bo byl aprzez dlugie ;ata a teraz w tej
degrengoladzie ktora sie dokonuje w polskich
uczelniach to sie mozan wszytskiego spodziewac.

Wiec niech Pan sobie  wpisze ten statement
i zobaczy czy tam jest slawetny operator delete.

I niech Pan juz wiecej nie bzdurzy.

W C++ delete mozna nazwac operatorem ew wyrazeniem
albo funkcja.
Zadnych innych alternatyw nie ma.
Zadna instrukcja , zaden statement Panie Wojewodzki.

Jesli dla pana statement to to samo co expression to
ja sie.. poddaje.

AK

Adam Karpierz <karpierz@_nospam_python.pl> napisal:
> Czyli void to jakis typ ?
> Bo pierwsze slysze aby mozna cos w C++ zwrocic co nie ma typu.
> PS: Panu sie najwyrazniej C++ z Pythonem myli.

Ech, te stare dobre jezyki: w Algolu-68 byl typ void
z jedyna wartoscia opisywana jaka empty.
-- 
Pozdrawiam,

Jacek

Dnia 12-04-2007, czw o godzinie 19:09 +0200, Adam Karpierz napisał(a):

> W C++ delete mozna nazwac operatorem ew wyrazeniem
> albo funkcja.

Nie. Czym innym jest wyrażenie delete (nie jest wywołaniem funkcji),
a czym innym jest operator delete (jest funkcją). Przy czym większość
kodu w C++ zawiera tylko to pierwsze i większość programistów C++ styka
się wyłącznie z tym pierwszym. Stwierdzenie, że delete jest funkcją,
jest wyjątkowo mylące, bo sugeruje, że wyrażenie delete jest funkcją
(albo wywołaniem funkcji), co jest nieprawdą.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Użytkownik "Jacek Pietraszek"  napisał:

> Adam Karpierz <karpierz@_nospam_python.pl> napisal:

>> Czyli void to jakis typ ?
>> Bo pierwsze slysze aby mozna cos w C++ zwrocic co nie ma typu.
>> PS: Panu sie najwyrazniej C++ z Pythonem myli.
>
> Ech, te stare dobre jezyki: w Algolu-68 byl typ void
> z jedyna wartoscia opisywana jaka empty.

W C++ jest tu jak zwykle degrengolada

<mniej personalnie>.
Raz sie mowi ze void to typ a raz nie,
W zachowaniu podobnie
niby mozna "rzutnac" (void)fun();
ale juz bron Boze
void i;
czy
void i = fun1();

gdzie oczywiscie :
void fun1() {}

No i oczywiscie void w C++ nie ma zadnej wartoisci
typu empty w A68 czy None w Pythonie.
Czyli niby typ, a nie typ :)
Raczej taki brzydki typek :)

Nieprawda jest wiec to co napisal Pan Wojewodzki ze
funkcja w C++ zwraca void.
Nie zwraca bo zwracac nie moze bo nie ma i nigdy
nie bedzie zadnej wartosci/obiektu typu void.
Funkcja w C++ wiec albo zwraca wartosc typu roznego
od void albo niec nie zwraca.
Owszem, funkcaj moze byc typu void. (tyle ze co to za typ:)
</mniej personalnie>.

BTW: Algol68 hm.. nie byl tez strzalem w dziesiatke :)
 mial syndrom dzisiejszego export z C++, chyba nigdy
 nie powstala jego pelen implementacja - tak w ogole
to z Algolem60 mial malo wspolnego)

AK 

Użytkownik "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> napisał:

> W C++ delete mozna nazwac operatorem ew wyrazeniem
> albo funkcja.

> Nie. Czym innym jest wyrażenie delete (nie jest wywołaniem funkcji),
> a czym innym jest operator delete (jest funkcją).

Kurde kurczak nie pisz rzeczy oczywistych.
Widzisz gdzies sprzecznosc miedzy tym co ja napisalem a ty ?
Tam jest ALBO.
Poza tym pisz scisle.
Powinno byc:
"Czym innym jest wyrażenie delete (nie jest li tylko wywołaniem funkcji 
delete),"

> Stwierdzenie, że delete jest funkcją,
> jest wyjątkowo mylące, bo sugeruje, że wyrażenie delete jest funkcją
> (albo wywołaniem funkcji), co jest nieprawdą.

void ::delete(void* ptr)
{
}

To jest pies czy funkcja ?

delete x;

Wyrazenie czy pies ?

void ::delete(void* ptr)
{
}


ALBO

delete x;

Prawda czy falsz ?

AK