Delphi 2018 că anul în curs se pregătește


4) Și o mică surpriză: costul Turbo Delphi Pro a scăzut la 250 USD.

Asta este, în curând.

Numărul total de 1215 de postări din acest thread

>> Total posturi în subiect: 1215; pagini: 122; pagina curentă: 47







Răspuns la »mesajul 752« (Sergey Tarasov)
___________________________

Nu trebuie să rescrieți numerele de zaruri, trebuie să vă întoarceți la masă cu o cerere de a da un cub de anumite caracteristici.
Bineînțeles. Dar ce va da masa? O copie a cubului sau același număr (link)?

Răspundeți la mesajul "mesajul 749" (Anton Grigoriev)
___________________________
Ca un compromis, putem lua decizia făcută în Modula-3. Există două tipuri de link-uri: monitorizate și netrackate.


TYPE TracedPtr = REF MyType;
UntracedPtr = UNTRACED REF MyType;
VAR tp: TracedPtr;
up: UntracedPtr;

NOU (tp); NOU (sus); (* tp și sus sunt create în diferite grămezi *)

DISPOZITIV (tp); (* la fel ca tp: = NIL *)
DISPOZITIV (sus); (* este distrus *)

Răspundeți la mesajul "mesajul 749" (Anton Grigoriev)
___________________________

Ați uitat despre principala problemă a gestionării automate a memoriei prin calcularea referințelor (interfețe etc.) - imposibilitatea de a elibera referințe ciclice. Deci personal nu consider această opțiune pentru GC alternativă.
Am incercat sa spun despre asta :)

În ceea ce mă privește, pot recunoaște fără un butoi de arme că, în timp ce vorbim despre obiecte care folosesc numai memorie, mă bucur de ocazia de a le crea fără să mă gândesc la distrugere. Dar, de multe ori, trebuie să mă confrunt cu obiecte care utilizează alte resurse și pentru a lucra normal cu ele am nevoie de un instrument convenabil.
Dar aici puteți scrie cel puțin un set de obiecte de sistem, pe care toate complexitățile cu / folosind se vor ascunde în interiorul metodelor lor. Și programatorul de aplicații nu va mai trebui să se confrunte cu eliberarea explicită a resurselor.

Răspundeți la mesajul "mesaj 750" (Stan)
___________________________

Răspunde la »mesajul 747« (Sergey Tarasov)
___________________________
>>> Containerul este deținut de proprietarul obiectelor. Acesta oferă interfața proprie pentru a le accesa. De asemenea, controlează timpul lor de viață.
>>> Un exemplu tipic este o listă de obiecte.






Definiție de container foarte voluminoasă. Zece obiecte - cuburi "se află" pe masă (pe listă), am "rescris" în numerele de note ale tuturor cuburilor verzi. Ai o listă nouă în notebook. Unde este containerul?
O masă, desigur.
Nu trebuie să rescrieți numerele de zaruri, trebuie să vă întoarceți la masă cu o cerere de a da un cub de anumite caracteristici.

Răspundeți la mesajul "mesajul 748" (panda)
___________________________

Răspunde la »mesajul 747« (Sergey Tarasov)
___________________________

Un exemplu tipic este o listă de obiecte.
Acesta nu este un exemplu tipic. Acesta este "Bună ziua, lumea".

Uită-te la "mesajul 738" - a fost un bun exemplu. Pot exista mai mult de o legătură cu obiectul și apoi containerele nu se salvează. Dacă scrieți o bibliotecă de sistem care va fi folosită de programatorii de aplicații, atunci aceasta este o situație obișnuită.
Un exemplu este tipic, iar în 738 mesajul este o greșeală obișnuită.

Definiție de container foarte voluminoasă. Zece obiecte - cuburi "se află" pe masă (pe listă), am "rescris" în numerele de note ale tuturor cuburilor verzi. Ai o listă nouă în notebook. Unde este containerul? Apoi, "ars" notebook. Lista a dispărut, dar nu există obiecte.

Dacă începi să-mi dovedești că poate exista o greșeală atunci când masa cu cuburile a fost deja dezmembrată și lista din notebook încă mai există și acest lucru este greșit. Bineînțeles că sunt de acord cu dvs., dar cum arată acest exemplu că GC este inutil / dăunător?

Răspunsul la mesajul "mesajul 745" (panda)
___________________________
Ați uitat despre principala problemă a gestionării automate a memoriei prin calcularea referințelor (interfețe etc.) - imposibilitatea de a elibera referințe ciclice. Deci personal nu consider această opțiune pentru GC alternativă.

În ceea ce mă privește, pot recunoaște fără un butoi de arme că, în timp ce vorbim despre obiecte care folosesc numai memorie, mă bucur de ocazia de a le crea fără să mă gândesc la distrugere. Dar, de multe ori, trebuie să mă confrunt cu obiecte care utilizează alte resurse și pentru a lucra normal cu ele am nevoie de un instrument convenabil.

Răspunde la »mesajul 747« (Sergey Tarasov)
___________________________

Un exemplu tipic este o listă de obiecte.
Acesta nu este un exemplu tipic. Acesta este "Bună ziua, lumea".

Uită-te la "mesajul 738" - a fost un bun exemplu. Pot exista mai multe link-uri către obiect și apoi containerele nu se salvează. Dacă scrieți o bibliotecă de sistem care va fi folosită de programatorii de aplicații, atunci aceasta este o situație obișnuită.

Răspunsul la mesajul "mesajul 745" (panda)
___________________________

Răspunsul la mesajul "mesajul 745" (panda)
___________________________

Oponenții GC sunt întotdeauna gata să dea o mulțime de exemple când este incomod. Dar, chiar și „sub amenințarea cu arma“, refuză să recunoască faptul că viața lor au fost astfel de cazuri, atunci când managementul memoriei manual pentru o varietate de obiecte transferate între containere, transformat într-un coșmar.
Probabil că nu am întâlnit proiecte atât de complexe. Dar, vedeți, eliberarea eronată / neutilizarea memoriei de la obiecte este foarte des rezultatul erorilor în proiectarea sistemului ca un întreg. Prin urmare, colectorul de gunoi doar "ascunde" consecințele acestor erori, dar nu le rezolvă.

>> Total posturi în subiect: 1215; pagini: 122; pagina curentă: 47







Articole similare

Trimiteți-le prietenilor: