🚀 go-pugleaf

Marcin 'Qrczak' Kowalczyk wrote:

>>>Same obiekty nie potrzebują cechy lokalności
>>>na poziomie języka.
>>
>>Owszem, potrzebują, bo lokalność pozwala określić też czas życia
>>obiektu.
> 
> Gdyby tylko pozwalała, to byłby mały problem, ale w C++ ona do tego
> zmusza.

Tego właśnie oczekuję. W przypadku gdy tego nie oczekuję używam pamięci 
dynamicznej i (sprytnych) wskaźników. Wtedy wskaźniki są lokalne i mają 
czas życia sterowany zakresem, ale czas życia właściwego obiektu jest 
sterowany dowolnie, przez odpowiedni schemat użycia wskaźników (to samo 
w Adzie).

> Przez to nawet gdybyśmy trzymali obiekt za wskaźnik, to
> lokalna funkcja nie mogłaby odwoływać się do tej samej zmiennej
> wskaźnikowej po zakończeniu zewnętrznej funkcji, bo destrukcja
> wskaźnika, choć w praktyce nic nie robi, powoduje, że zmiennej
> nie wolno już używać.

Lokalna funkcja może bezpieczenie używać *kopii* wskaźnika. Oryginał 
może być zniszczony.

>>Często korzystam z obiektów tymczasowych, które nazwy nie mają a
>>mimo to polegam (!) na gwarancjach, które daje mi język w temacie
>>czasu ich życia. Bez takich gwarancji pewnych rzeczy w ogóle nie
>>mógłbym wyrazić tak, jak chcę.
> 
> Ja takich obiektów używam nieporównywalnie rzadziej niż lokalnych
> funkcji; w ogóle nie przypominam sobie przypadków, kiedy obiekt
> o destruktorze zwalniającym coś więcej niż pamięć miałby nie mieć
> nazwy.

Destruktor nie musi "zwalniać", żeby jego istnienie miało sens. Czasami 
używam destruktorów do wykonania konrektnych zadań, które ze zwalnianiem 
czegokolwiek nie mają nic wspólnego.
Faktem jest, że nie jest to ich typowe zastosowanie. Bardziej typowe są 
obiekty lokalne, które coś robią - otwierają i zamykają okna na ekranie, 
otwierają i zamykają pliki, połączenia do baz danych, sterują 
transakcjami, mrugają lampką, itd.

>>void foo()
>>{
>>     int local_object;
>>
>>     bind(
>>         void (int i) { cout << i; },  // lambda z jednym parametrem
>>         local_object                  // dowiązanie local_object do i
>>     )();                              // aplikacja obiektu funkcyjnego
>>}
> 
> To się nie skaluje do większych przykładów. Listowanie zmiennych
> wolnych każdej lokalnej funkcji będzie przykre.

I bardzo dobrze! O to właśnie chodzi, dokładnie tak samo jak z 
reinterpret_cast, static_cast, itd. - one też się nie "skalują" do 
większych przykładów. To *ma* wystawać z kodu i być widoczne. A w 
sytuacji, gdy programista zrobi potwora na 20 takich zmiennych, to ma 
być wskazówką, że robi coś podejrzanego, bo np. usiłuje stworzyć kod 
zupełnie pozbawiony struktury. Jeżeli sam nie ma hamulców, to może 
chociaż dostanie po łapach podczas code review od kogoś, kto to będzie 
musiał przeczytać i zrozumieć. Ukrywanie takich rzeczy pod niejawną 
składnią to nie jest żaden ficzer.

Nie twierdzę, że takie zastosowania są definitywnie złe - dlatego 
chciałbym mieć w C++ lambdy takie, jak pokazałem (podobnie, jak chcę 
mieć reinterpret_cast). Ale chcę, żeby takie rzeczy były jawne.


> Przykład. Oryginalna funkcja z mojego kompilatora
[...]

To jakieś nowe rozszerzenie Perla? :)

> Spróbowałem przetłumaczyć to
> na C++.

Jestem zdumiony, że Ci się chciało. Podziwiam, ale nawet po dłuższym 
przyglądaniu się nie jestem w stanie takiej sieczki prześledzić.

[sieczka ciach]

> Fajne, nie?

Super. I co to pokazuje?

1. Samochód nie działa jako łódź podwodna.
2. Samochód nie nadaje się do pokonania trasy Kraków-Gdańsk, bo akurat 
uparłeś się pokonać tą trasę łodzią podwodną (pomijam przeszkody typu 
zapory).

Problem z tym przykładem polega na tym, że usiłujesz swój model wyrazić 
w C++ - koncentrujesz się na środkach a nie na celach. Gdybyś 
koncentrował się na celach, to zauważyłbyś, że wiele kompilatorów i 
translatorów było pisanych w C++ (i w czymkolwiek innym) i nikt takiej 
sieczki tam nie napisał (pomijając to, że w C++ nie ma lambdy).

>>Oczywiście, local_object ma *skończyć życie* przy wyjściu z foo().
>>Nie ma prawa żyć dłużej, niż trwa wykonywanie foo().
> 
> Wolę mieć tutaj wybór.

Ja ten wybór wyrażam przez rozróżnienie pomiędzy obiektem lokalnym a 
lokalnym wskaźnikiem do obiektu (to samo tak samo w Adzie).

>>Twój model nie jest uniwersalny i nie trafia
>>w oczekiwania *wszystkich* programistów.
> 
> Ależ temu nie zaprzeczam. A do mnie nie trafia model C++.

I to jest zupełnie inne stwierdzenie, niż to, że model C++ jest martwy.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/