Article View: pl.comp.objects
Article #4738Re: Prawda o C++
From: Sektor van Skijlen
Date: Tue, 19 Jan 1999 14:35
Date: Tue, 19 Jan 1999 14:35
137 lines
6013 bytes
6013 bytes
In pl.comp.objects Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote:
: On 18 Jan 1999, Sektor van Skijlen wrote:
:> Dlaczego niby kojarzycie referencje ze wskaznikami ? To bez sensu.
:> Referencje to zupelnie co innego. Referencje moga CZASEM BYC
:> zaimplementowane przez wskazniki, ALE NIE MUSZA!
: Nieprawda. Referencja to jest praktycznie to samo co wskaźnik. Różni się
: wyłącznie składnią, przy czym niektóre operacje na wskaźnikach nie mają
: odpowiedników na referencjach.
Masz cos sensownego na poparcie tych glupot ?
: To, że niektórzy ludzie lubią sobie o tym myśleć w jakiś inny sposób,
: nie zmienia faktu, że referencje zawsze można zastąpić równoważnymi
: wskaźnikami (modulo makra i szablony, gdzie te same napisy są analizowane
: wiele razy w różnych kontekstach).
No i co to ma do rzeczy ?
:> ale np. tutaj juz nie:
:>
:> {
:> CosTam* nic = new CosTam;
:>
:> CosTam& rnic = *nic;
:>
:> rnic = { 2, 65 };
:> }
: To się przede wszystkim nie skompiluje (błąd składni w ostatnim
: przypisaniu - napis { 2, 65 } nie jest poprawnie zbudowanym wyrażeniem).
: Można to uratować następującym rozszerzeniem gcc:
: rnic = (CosTam) { 2, 65 };
Ok, przyznaje sie. Zamienmy to na:
CosTam dwa( 5, 5 ); // powiedzmy, ze to ma taki konstruktor
rnic = dwa;
: i jest to taka sama sytuacja jak poprzednio. Referencja może być
: zaimplementowana jako wskaźnik i prawdę mówiąc nie widzę innego sensownego
: rozwiązania.
Niestety kompletna bzdura, kolego. Zmiennej rnic w ogole nie bedzie. Zamiast
tego, kompilator to przypisanie zamieni na rownowazne:
*nic = dwa;
Zreszta... przeczytaj sobie ntt. post p. Janusza Stopy.
[ CIACH ]
:> Ile bedzie zawierac pol ? Dwa, czy trzy ?
: Trzy. Ale kod jest bezsensowny: inicjujesz rt wartością zależną
: od wartości zmiennej tab, która sama jest jeszcze w tym momencie
: niezainicjowana. Jakiekolwiek późniejsze użycie wartości wskazywanej
: przez rt ma pełne prawo wysypać program. Nie wierzysz - sprawdź.
To sie zgadza. Przyznaje sie do wlasnej glupoty; wyjatkowo programu nie
sprawdzilem. Jasne, ze bedzie zawierac ta zmienna referencyjna jako pole.
Natomiast co do inicjalizacji - mozna to zrobic tak:
Klocek( int d ): tab( new int[d] ), first( tab[0] ) {}
: Obawiam się, że musisz zrewidować swoje poglądy na temat istoty
: referencji.
Mozliwe. Sprawdzilem to dosc szczegolowo i faktycznie, nie udalo mi sie jak na
razie zrobic takiego przykladu, w ktorym zmienna referencyjna bylaby
"optimized away" (co nie znaczy, ze takich przypadkow nie ma).
A teraz maly tescik dla grupowiczow.
Zmienna referencyjna to zmienna, jak kazda inna, tak ?
Operator & uzyskuje adres zmiennej, tak ?
No wiec prosze powiedziec, co zwroci wyrazenie &ref, gdzie ref jest dowolna
zmienna referencyjna ?
:> A' propos - nie probowalem jeszcze kopiowac obiektow zawierajacych
:> odniesienia. Wydaje mi sie (jeszcze nie sprawdzalem, bo mi sie nie
:> chce), ze trzeba bedzie zrobic normalnie konstruktor (w tym i
:> kopiujacy), ktory przypisze odniesieniom odpowiednie obiekty docelowe.
: Domyślnego operatora przypisania w takich przypadkach nie ma (egcs mówi:
: non-static reference member `...', can't use default assignment operator).
: I trudno tutaj sensownie zaimplementować własny.
Chyba dla Ciebie trudno. Jak sie teoretyzuje, to zazwyczaj jest trudno (nie
zartuje! Doswiadczylem tego niejednokrotnie). Jezeli uzywasz zmiennych
referencyjnych jako pol obiektu, to zazwyczaj po to, zeby miec wygodniejszy
dostep do innych pol.
Jesli zmienne referencyjne naleza do pol, to niestety jest to dla mnie troche
dziwne. Bo jezeli mamy taka strukture:
struct Krotka
{
int a;
const int d = 2;
};
to pole d niby nalezy do pol struktury, a jednak struktura ma te sama
wielkosc, co int... niestety jesli zmienimy sposob inicjalizacji
struct Krotka
{
int a;
const int d;
Krotka(): d( 2 ) {}
};
juz mamy wtedy normalne pole (nie wirtualne), ktore ma swoja dlugosc i nalezy
do struktury. To pierwsze zreszta, to tylko rozszerzenie GCC, standard
zabrania takich inicjalizacji...
Szczerze mowiac, nie rozumiem, dlaczego nie moznaby zrobic tego tak, zeby
zmienna nie istniala. W koncu przeciez tak jak stala zmienna wskaznikowa, jak
i wartosc stala, jak tez i referencja nie maja mozliwosci przypisywania, totez
nie jest istotne, GDZIE te zmienne sa umieszczone, czy naleza do struktury,
czy nie (przypomne, ze np. stale statyczne sa umieszczane w segmencie kodu). W
szczegolnych przypadkach mogloby ich w ogole nie byc.
Zeby znow nie bylo nieporozumien - ja tylko mowie, jak MOGLOBY byc - ani
standard nie zabrania ani struktura jezyka nie przeszkadza, zeby to bylo tak
zrobione. Nie mozna zatem mowic, ze tak na pewno nie jest.
--
-=* P O Z D R A W I A M ! *=-
[-=* Ij waiet salden mijn spijr, ta faenen aire ats trauven diaenna *=-]
____....----````Sektor van Skijlen: sektor at beer.com''''----....____
<sPAm @ pROtEctIOn>
Technical Details
Message-ID:
<78256q$9l8$5@polonez.man.lodz.pl>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!mat.uni.torun.pl!news.nask.pl!news.man.lodz.pl!not-for-mailReferences:
<77o3bl$j0q$1@polonez.man.lodz.pl> <369FDDCE.7B94748A@interdata.com.pl> <77q41i$j7f$1@polonez.man.lodz.pl> <wU3o2.25549$U1.4744058@news.tpnet.pl> <77qi2q$42a$1@polonez.man.lodz.pl> <77qk38$ken$1@zeus.polsl.gliwice.pl> <77vn97$j3l$1@polonez.man.lodz.pl> <Pine.LNX.4.05.9901182050560.542-100000@qrnik.knm.org.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!mat.uni.torun.pl!news.nask.pl!news.man.lodz.pl!not-for-mail
From: Sektor van Skijlen <sektor@spam.org>
Newsgroups: pl.comp.lang.c,pl.comp.objects
Subject: Re: Prawda o C++
Date: 19 Jan 1999 14:35:06 GMT
Lines: 137
Message-ID: <78256q$9l8$5@polonez.man.lodz.pl>
References: <77o3bl$j0q$1@polonez.man.lodz.pl> <369FDDCE.7B94748A@interdata.com.pl> <77q41i$j7f$1@polonez.man.lodz.pl> <wU3o2.25549$U1.4744058@news.tpnet.pl> <77qi2q$42a$1@polonez.man.lodz.pl> <77qk38$ken$1@zeus.polsl.gliwice.pl> <77vn97$j3l$1@polonez.man.lodz.pl> <Pine.LNX.4.05.9901182050560.542-100000@qrnik.knm.org.pl>
NNTP-Posting-Host: zly.kis.p.lodz.pl
Mime-Version: 1.0
User-Agent: tin/pre-1.4-981225 ("Volcane") (UNIX) (SunOS/5.5.1 (i86pc))
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit