referencja odwolujaca sie do nowego inego obiektu

0

hej ! Mam napisac program w ktorym Zmienie utworzona juz referencje w taki sposob aby odwolywala sie do innego obiektu
Wszedzie gdzie czytam pisze to samo: Nie ma szans. Nie można oddzielić referencji od jej referenta.
Zadanie wziete z ksiazki Thinking in C++ Bruce Eckel rozdzial 11 zadanie 3

0

Zacytuj tutaj treść zadania bo możliwe, że źle je zrozumiałeś.
Nie można zmieniać referencji.
Czyli jka zrobisz:

Typ zmienna1 = 1;
Typ& referen = zmienna1;

to już nie możesz zmienić referen

0

tresc calego zadania: "Napisz program, w którym spróbujesz: 1. Utworzyć referencję niezainicjowaną podczas
tworzenia. 2. Zmienić utworzoną już referencję w taki sposób, aby odwoływała się do innego
obiektu. 3. Utworzyć pustą referencję."
w sumie odpoiedz na 1 i 3 mam ale pewnie zla wiec prosze o odpowiedz na dwa pozostale pytania rowniez

0

wszystkie trzy zadania są niemożliwe do skompilowania: referencja musi być zainicjowana, referencji monża tylko raz przypisać obiekt: przy inicjalizacji.

0

Prosta sprawa:

union ble
{
ble(int *v=0) : ref(*v) {}
ble(int &v) : ref(v) {}

int& operator=(int &v) { return *(p = &v); }
operator int() { return ref; }

int *p, &ref;
};

int fble()
{
int y = 6, z = 777;
ble a; // x.ref -> ?
ble b(z); // b.ref -> z

a = z; // a.ref -> z;

b = y; // b.ref -> y

return a;
}

0

wow 8-O
czy ktos by mi wytlumaczyl bo nic nie rozumie nie bralem w ogole uni a z tego co teraz przegladnalem w greboszu jest o tym 2 strony i nic na temat
tak ogolnie to dzieki za odpowiedz ale nawet nie czaje do ktorego to zadania 1,2,3?

0

Unia jest troche podobna do struktury. Przyjmuje dlugosc swego najdluzszego elementu, dzieki czemu na tej samej przestrzeni pamieci i pod tym samym identyfikatorem mozna zapisac zmienne roznego typu.

0
s. napisał(a)
union ble
{
  ble(int *v=0) : ref(*v) {}
  ble(int &v) : ref(v) {}

  int& operator=(int &v) { return *(p = &v); }
  operator int() { return ref; }

  int *p, &ref;
};


int fble()
{
  int y = 6, z = 777;
  ble a;   // x.ref -> ?
  ble b(z); // b.ref -> z
  
  a = z; // a.ref -> z;

  b = y; // b.ref -> y
  
  return a;
}

Należy zacząć od tego, że rozwiązanie przedstawione przez s. nie jest akceptowane przez wszystkie kompilatoray. Dla przykładu w BCB się skompiluje, ale w gcc już nie ponieważ nie zgadza się, żeby referencja była polem unii.
Unia ble przechowuje w tym samym obszarze pamięci jednocześnie wskaźnik na int i referencje do int (co sprowadza sie wsumie do tego samego). Pierwszy konstruktor inicjuje zmienną ref jako referencje do nieistniejącej zmiennej o adresie 0. Drugi konstruktor inicjuje ją normalnie - tak jak referencje. Najciekawszy jest operator przypisania - on powoduje rzeczywiste zmienienie już utworzonej referencji, ale ponieważ nie można zmieniać wartości zmiennej typu referencyjnego zmienia wartość wskaźnika znajdujacego się w tym samym obszarze pamięci.
Mimo wszystko wydaje mi sie jednak, ze zadanie przytoczone przez cześka z Thinking in C++ miało na celu zademonstrować właśnie, że nie można zmieniać referencji i tworzyć pustej referencji. Ale jak to widać wszystko można ;)

0

No, jakby nie było, ble to nie referencja.

0

kombinacje ciekawe, moze dojdziecie do czegos fajnego [green]

a zadanie ma pokazac czytelnikowi, ze tego nie da sie zrobic i zeby zobaczyl reakcje kompilatora na te bledne konstrukcje.

wczesniej w tym rozdziale (s. 361 w moim wydaniu) sa wypisane trzy punkty odnoszace sie do tego wlasnie zadania wyraznie mowiace ze nie powinno dac sie tego zrobic (jak wiadomo kompilatory roznie spelniaja standard).

0
vixen03 napisał(a)

a zadanie ma pokazac czytelnikowi, ze tego nie da sie zrobic i zeby zobaczyl reakcje kompilatora na te bledne konstrukcje.

wczesniej w tym rozdziale (s. 361 w moim wydaniu) sa wypisane trzy punkty odnoszace sie do tego wlasnie zadania wyraznie mowiace ze nie powinno dac sie tego zrobic (jak wiadomo kompilatory roznie spelniaja standard).

Jaki tam standard. [diabel]
Wygląda na to, że jacyś bogowie wkrótce wezmą to pod uwagę i zlikwidują całkowicie referencję w C++.
Wskaźniki też - w C# już nie ma - zlikwidowano tu wszystko co jest związane z pamięcią dynamiczną,
a Java - setka MB RAM na dzień dobry.

Już widzę jak to będzie w niedalekiej przyszłości:
uruchamiasz program - słownik lub coś prostego - ładuje się błyskawicznie - tak z 3 minuty,
ale jeśli na płycie siedzi mniej niż 2x512GB RAMu to... ratuje nas swap,
taki niewielki - tylko 5% dysku, czyli z 20GB :-D

0
adf88 napisał(a)

No, jakby nie było, ble to nie referencja.
ale unia będaca czasem referencją ;)
choć wsumie racja ...

vixen03 napisał(a)

kombinacje ciekawe, moze dojdziecie do czegos fajnego [green]
a zadanie ma pokazac czytelnikowi, ze tego nie da sie zrobic i zeby zobaczyl reakcje kompilatora na te bledne konstrukcje.

wczesniej w tym rozdziale (s. 361 w moim wydaniu) sa wypisane trzy punkty odnoszace sie do tego wlasnie zadania wyraznie mowiace ze nie powinno dac sie tego zrobic (jak wiadomo kompilatory roznie spelniaja standard).
to potwierdziło moje wcześniejsze przypuszczenia co do zamiarów autora

1 użytkowników online, w tym zalogowanych: 0, gości: 1