CYFROWY BARON • PROGRAMOWANIE • Zobacz wątek - Zamykanie otwartego pliku(!)

Zamykanie otwartego pliku(!)

dział ogólny

Zamykanie otwartego pliku(!)

Nowy postprzez Slynx » niedziela, 26 czerwca 2011, 18:30

Mam problem z... zamknięciem pliku.

Mianowicie, jest pewna funkcja, która wykonuje jakieś operacje na pliku i w wyniku błędu plik nie zostanie zamknięty, tak więc żadna inna funkcja nie może uzyskać dostępu do niego.
Nie ma żadnej funkcji, która "odcinałaby" dostęp do pliku. Żeby plik zamknąć, trzeba go wcześniej otworzyć, a żeby otworzyć - plik musi być wcześniej zamknięty, bo inaczej rzuci wyjątkiem.
Jak zamknąć taki plik ?
Avatar użytkownika
Slynx
Mądrosław
Mądrosław
 
Posty: 350
Dołączył(a): piątek, 17 grudnia 2010, 21:59
Podziękował : 11
Otrzymał podziękowań: 0
System operacyjny: Windows 7 32
Kompilator: Visual C++ 2005; Visual C++ 2008; Visual C++ 2010; Visual C# 2010;
Gadu Gadu: 0
    Windows 7Chrome

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Cyfrowy Baron » niedziela, 26 czerwca 2011, 18:38

Nie napisałeś w jaki sposób otwierasz tenże plik. Jeżeli używasz klasy np. klasy FILE to otwierasz plik funkcją fopen, a zamykasz fclose, np:

KOD cpp:     UKRYJ  
 FILE* f;
 if( f = fopen(fname.c_str(), "r+") ) {/* jakaś operacja na pliku */ }

fclose(f); // zamykam plik


Każda klasa, która otwiera w ten sposób plik, ma również funkcję, która go zamyka.
Jak rozumiem jednak nie w tym problem, gdyż piszesz o jakimś błędzie, ale czy mimo tego błędu nie można jednak wywołać funkcji zamykającej plik?!
Avatar użytkownika
Cyfrowy Baron
Administrator
Administrator
 
Posty: 4716
Dołączył(a): niedziela, 13 lipca 2008, 15:17
Podziękował : 12
Otrzymał podziękowań: 442
System operacyjny: Windows 7 x64 SP1
Kompilator: Embarcadero RAD Studio XE2
C++ Builder XE2 Update 4
SKYPE: cyfbar
Gadu Gadu: 0
    Windows XPFirefox

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Slynx » niedziela, 26 czerwca 2011, 19:07

Rozpatrujemy krytyczny przypadek gdy w kodzie naszej funkcji zabrakło obsługi zamknięcia pliku. Poza tym, inna funkcja nie powinna się sypać tylko dlatego, że plik wcześniej został otwarty. Mówisz o fopen i fclose.... chyba muszę pokazać to na przykładzie kodu

KOD cpp:     UKRYJ  
function xxx(){
System::IO::StreamReader^ sr = gcnew StreamReader(file_path);
sr->ReadLine();
// cos co powoduje nieznany błąd przerywający działanie funkcji (sr->Close() nie zostanie wywołane)
sr->Close();
}

function yyy()
{
File::Open(file_path); // i tu wyrzuci nam wyjątek jako, że plik nie został wcześniej zamknięty
// Przed tym powinno być coś w stylu if (File(file_path)->IsOpened()) File(file_path)->Close()
}
 

Zakładając, że xxx i yyy to funkcje, które wykonują się po kolei.

Obrazując to na Twoim kodzie to musiałbyś przyjąć, że w drugiej funkcji nie mamy zmiennej plikowej f, tak więc nie wiesz co zamknąć, znasz jedynie ścieżkę. (nie wiem jak reaguje fopen na próbę otwarcia otwartego pliku)

---
Swoją drobną lukę już poprawiłem. Nie mogłem znaleźć w której funkcji w przypadku błędy brakowało zamknięcia strumienia. Jednak pytanie pozostaje aktualne. Można też zapytać inaczej. Czy da się zamknąć plik otwarty nie przez nas ?
Avatar użytkownika
Slynx
Mądrosław
Mądrosław
 
Posty: 350
Dołączył(a): piątek, 17 grudnia 2010, 21:59
Podziękował : 11
Otrzymał podziękowań: 0
System operacyjny: Windows 7 32
Kompilator: Visual C++ 2005; Visual C++ 2008; Visual C++ 2010; Visual C# 2010;
Gadu Gadu: 0
    Windows 7Chrome

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Cyfrowy Baron » niedziela, 26 czerwca 2011, 20:14

Slynx napisał(a):(nie wiem jak reaguje fopen na próbę otwarcia otwartego pliku)


To w sumie nieistotne dla tego problemu, ale nie otworzy otwartego pliku.

Co się tyczy Twojego problemu, to jeżeli sr ma uchwyt do pliku, to sr powinien go zwolnić funkcją Close(). Jeżeli zniszczysz sr to plik powinien zostać zwolniony automatycznie. Rozważając Twoją funkcję:

KOD cpp:     UKRYJ  
function xxx()
{
  System::IO::StreamReader^ sr = gcnew StreamReader(file_path);

  sr->ReadLine();

 /* TUTAJ BŁĄD */

  sr->Close();
}
Jeżeli wystąpi błąd przed wywołaniem Close(), to również sam obiekt sr, który jest tworzony lokalnie nie zostanie zniszczony (w przykładzie brak funkcji delete) i będziesz miał wyciek pamięci, czyli dwa problemy. Przewidując ewentualny problem z błędem utworzyłbym obiekt sr globalnie i przed każdym otwarciem pliku, przez drugą funkcję, próbowałbym go zamknąć. Coś álá to:

KOD cpp:     UKRYJ  
System::IO::StreamReader^ sr = gcnew StreamReader(file_path); /* definicja globalna */

function xxx()
{
 sr->ReadLine();

 // cos co powoduje nieznany błąd przerywający działanie funkcji (sr->Close() nie zostanie wywołane)
 
 sr->Close();
}
//------------------------------------------------------------------------
function yyy()
{
 sr->Close();
 File::Open(file_path); // i tu wyrzuci nam wyjątek jako, że plik nie został wcześniej zamknięty

 // Przed tym powinno być coś w stylu if (File(file_path)->IsOpened()) File(file_path)->Close()

}
Avatar użytkownika
Cyfrowy Baron
Administrator
Administrator
 
Posty: 4716
Dołączył(a): niedziela, 13 lipca 2008, 15:17
Podziękował : 12
Otrzymał podziękowań: 442
System operacyjny: Windows 7 x64 SP1
Kompilator: Embarcadero RAD Studio XE2
C++ Builder XE2 Update 4
SKYPE: cyfbar
Gadu Gadu: 0
    Windows XPFirefox

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Slynx » niedziela, 26 czerwca 2011, 21:56

Wiem, wiem, ale tu nie rozważamy tego globalnie. Mówimy raczej tylko o lokalnych obiektach. Ale jeszcze coś. Mówisz o wycieku pamięci.... czy aby na pewno ? Gdy zostanie wywołany błąd uniemożliwiający kontynuowanie wewnątrz lokalnego bloku (czyli naszej funkcji) powinien się uruchomić garbage collector i automatycznie wyrzucić to z pamięci, bo tracimy jedyny kontakt z tym obiektem (nie można go już w żaden sposób kontrolować, bo był tylko w bloku lokalnym), tak więc plik powinien zostać otwarty (chyba że w wywoływanym destruktorze jest funkcja zamykająca plik), a pamięć powinna zostać zwolniona.

I czegoś takiego jak definicji globalnej zrobić nie możesz. Albo deklaracja i definicja wewnątrz funkcja, albo całość jako statyczna.

To w sumie nieistotne dla tego problemu, ale nie otworzy otwartego pliku.

Istotne, bo jeśli rzuci wyjątkiem to warto by to przewidzieć w innym przypadku aplikacja się sypnie.

Wiem, że jest coś w klasie fstream. Funkcja (chyba) ofstream ma metodę IsOpened(), którą można sprawdzić czy plik jest otwarty. Tylko to w sumie niewiele zmienia, bo i tak nie można go zamknąć z racji tego, że nie mamy żadnej zmiennej do pliku przypisanej.
To mimo wszystko było tylko pytanie teoretyczne, bo momenty w których plik pozostaje otwarty nie powinny się zdarzać.
Avatar użytkownika
Slynx
Mądrosław
Mądrosław
 
Posty: 350
Dołączył(a): piątek, 17 grudnia 2010, 21:59
Podziękował : 11
Otrzymał podziękowań: 0
System operacyjny: Windows 7 32
Kompilator: Visual C++ 2005; Visual C++ 2008; Visual C++ 2010; Visual C# 2010;
Gadu Gadu: 0
    Windows 7Chrome

Re: Zamykanie otwartego pliku(!)

Nowy postprzez polymorphism » niedziela, 26 czerwca 2011, 22:29

Gdy zostanie wywołany błąd uniemożliwiający kontynuowanie wewnątrz lokalnego bloku (czyli naszej funkcji) powinien się uruchomić garbage collector i automatycznie wyrzucić to z pamięci

Oj, to nie działa w ten sposób. Garbage collector zwolni pamięć kiedy będzie miał na to "ochotę" ;) Mało tego, o ile dobrze pamiętam, w CLR jest niedeterministyczna finalizacja obiektów, zatem taki obiekt zostanie zniszczony, gdy garbage collector uzna to za stosowne. To "stosowne" nie musi oznaczać wyjście z bloku. Między innymi dlatego kod zarządzany bywa szybszy od niezarządzanego w przypadkach, gdzie dochodzi do częstego tworzenia i niszczenia obiektów.
C++ Reference - opis wszystkich klas STL-a i funkcji C.
Avatar użytkownika
polymorphism
Doświadczony Programista ● Moderator
Doświadczony Programista ● Moderator
 
Posty: 2156
Dołączył(a): piątek, 19 grudnia 2008, 13:04
Podziękował : 0
Otrzymał podziękowań: 200
System operacyjny: Windows 8.1
Windows 10
Linux Mint 21.1
Kompilator: Visual Studio
Visual Studio Code
MSYS2 (MinGW, clang)
g++
clang
Gadu Gadu: 0
    Windows XPFirefox

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Slynx » niedziela, 26 czerwca 2011, 23:54

O tym wiem. Tak samo jak ustawienie null dla obiektu nie jest równoznaczne z wydaniem mu "polecenia" delete. To jest jedynie informacja, że "należałoby" się obiektu pozbyć. I dobrze, że jesteśmy przy tym temacie. Miałem o coś zapytać, ale wtedy nie chciałem zakładać nowego tematu dla jednego tematu. Aha, i mówimy tu o C# a nie o c++;

KOD cpp:     UKRYJ  
function xxx()
{

while (cos tam)
{
ListViewItem lvi = new ListViewItem();

lvi.Add("");
// cos tam, cos tam...
listView.Item.Add(lvi);
}

}
 

Czy w takim przypadku dojdzie do wycieku pamięci ? Teoretycznie powinno, bo przy tworzeniu nowego obiektu na tej samej deklaracji bez wcześniejszego usunięcia... W C# nie ma delete, a i nie nie ma gcnew tylko new, więc teoretycznie programista powinien usunąć zmienną. Czy może to jest zrobione tak, że automatycznie usuwa poprzednią zmienną jeśli dochodzi do nowego tworzenia obiektu na tej samej deklaracji ?
Avatar użytkownika
Slynx
Mądrosław
Mądrosław
 
Posty: 350
Dołączył(a): piątek, 17 grudnia 2010, 21:59
Podziękował : 11
Otrzymał podziękowań: 0
System operacyjny: Windows 7 32
Kompilator: Visual C++ 2005; Visual C++ 2008; Visual C++ 2010; Visual C# 2010;
Gadu Gadu: 0
    Windows 7Chrome

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Cyfrowy Baron » poniedziałek, 27 czerwca 2011, 08:40

Slynx napisał(a):I czegoś takiego jak definicji globalnej zrobić nie możesz. Albo deklaracja i definicja wewnątrz funkcja, albo całość jako statyczna.


To chyba tylko u Ciebie. W C++Builder mogę tworzyć takie definicje bez problemu zarówno w pliku nagłówkowym poza klasą jak i w pliku źródłowym w dowolnym miejscu poza jakąkolwiek funkcją. W domyśle wszystkie obiekty prywatne, publiczne i globalne są statyczne, więc nie muszę ich deklarować jako statycznych.

Slynx napisał(a):Mówisz o wycieku pamięci.... czy aby na pewno ?


Na pewno! Obiekt nie został zniszczony, nie masz co prawda do niego dostępu i ponowne wywołanie funkcji tworzy nowy obiekt, lecz pamięć po starym nie została zwolniona automatycznie, nie w C++Builder.

Slynx napisał(a):Czy w takim przypadku dojdzie do wycieku pamięci ? Teoretycznie powinno, bo przy tworzeniu nowego obiektu na tej samej deklaracji bez wcześniejszego usunięcia..


W C++ dojdzie wdo wycieku pamięci, a w C# - nie wiem. W C++ każdy obiekt tworzony przez new trzeba zniszczyć, niezależnie od tego czy mamy do czynienia z obiektem lokalnym, prywatnym, publicznym czy globalnym.

Slynx napisał(a):Czy może to jest zrobione tak, że automatycznie usuwa poprzednią zmienną jeśli dochodzi do nowego tworzenia obiektu na tej samej deklaracji ?


Pisząc o zmiennej masz na myśli oczywiście obiekt nie zmienną. Obiekty tworzone w pętli, czy innym bloku np. if są niejako lokalne-lokalnie, więc powinny być zniszczone w tym bloku.
To tyle jeżeli chodzi o C++. Jak to jest w C# niech się wypowie ktoś inny, sam jestem ciekaw, czy ten kod automatycznie usuwa takie porzucone obiekty.
Avatar użytkownika
Cyfrowy Baron
Administrator
Administrator
 
Posty: 4716
Dołączył(a): niedziela, 13 lipca 2008, 15:17
Podziękował : 12
Otrzymał podziękowań: 442
System operacyjny: Windows 7 x64 SP1
Kompilator: Embarcadero RAD Studio XE2
C++ Builder XE2 Update 4
SKYPE: cyfbar
Gadu Gadu: 0
    Windows XPFirefox

Re: Zamykanie otwartego pliku(!)

Nowy postprzez polymorphism » poniedziałek, 27 czerwca 2011, 10:24

To jest jedynie informacja, że "należałoby" się obiektu pozbyć.

Może inaczej. Przypisanie nulla spowoduje zmniejszenie licznika referencji danego obiektu. Jeśli istniała tylko jedna referencja, to wtedy tak, jest to info, że obiekt można zniszczyć.

Czy w takim przypadku dojdzie do wycieku pamięci ?

Wprawdzie nie znam C#, ale jestem pewny, że nie dojdzie do wycieku, ponieważ w C# każda pamięć alokowania dynamicznie jest zawsze pod kontrolą garbage collectora. Tu nie ma takiego zróżnicowania w sposobach zarządzania pamięcią jakie masz w C++/CLI. Następna rzecz to to, że obiekt spod lvi* przekazujesz dalej kontrolce listView. A co później dzieje się z obiektem to już sprawa kontrolki, nie Twój problem ;)

*) gwoli ścisłości, lvi to referencja.

Czy może to jest zrobione tak, że automatycznie usuwa poprzednią zmienną jeśli dochodzi do nowego tworzenia obiektu na tej samej deklaracji ?

Mechanizm podobny jak przy przypisaniu nulla. Patrz wyżej.

p.s. trudno mówić tutaj o "tej samej deklaracji", ponieważ mowa o referencji zdefiniowanej wewnątrz pętli. Taka referencja teoretycznie istnieje tylko na czas trwania pojedynczej iteracji. Co każdy obrót pętli jest tworzona na nowo i ponownie niszczona... teoretycznie of coz ;)
C++ Reference - opis wszystkich klas STL-a i funkcji C.
Avatar użytkownika
polymorphism
Doświadczony Programista ● Moderator
Doświadczony Programista ● Moderator
 
Posty: 2156
Dołączył(a): piątek, 19 grudnia 2008, 13:04
Podziękował : 0
Otrzymał podziękowań: 200
System operacyjny: Windows 8.1
Windows 10
Linux Mint 21.1
Kompilator: Visual Studio
Visual Studio Code
MSYS2 (MinGW, clang)
g++
clang
Gadu Gadu: 0
    Windows XPFirefox

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Slynx » poniedziałek, 27 czerwca 2011, 12:50

Taka referencja teoretycznie istnieje tylko na czas trwania pojedynczej iteracji. Co każdy obrót pętli jest tworzona na nowo i ponownie niszczona...

No właśnie to chyba nie jest prawda. Przecież gdy do obiektu cały czas coś dodajesz to obiekt cały czas pozostaje aktywny, a nie ginie i jest tworzony na nowo po każdej iteracji. Chyba, że dorzucimy tutaj GC i uznamy, że to on decyduje o tym czy przy następnej iteracji obiekt jeszcze jest potrzebny.

Następna rzecz to to, że obiekt spod lvi* przekazujesz dalej kontrolce listView. A co później dzieje się z obiektem to już sprawa kontrolki, nie Twój problem

No nie do końca. To jest tak jak przekazywanie kopii obiektu, a referencji do niego.
Mój obiekt (ListViewItem) cały czas istnieje po przekazaniu do ListView. ListView jedynie go odczytuje, dopisuje do swojej kolekcji i zostawia w spokoju. W C++/CLI ZAWSZE używałem delete jak robiłem coś takiego w pętli (jak w przykładzie). Pewności nie miałem, a delete zaszkodzić nie może, więc na wszelki wypadek wrzucałem (bo tak czy inaczej obiekt powinien zostać usunięty po wykorzystaniu).

*) gwoli ścisłości, lvi to referencja.
- Referencja ? A to z czego wynika ? W całość kodu korzystamy jedynie z naszego "zarządzanego wskaźnika" (czy jak to tam się nazywało), nigdzie nie używamy referencji, a ListView->Items->Add() też nie pobiera referencji, a jedynie ten nasz wskaźnik.

Poza tym, gdyby to była referencja, to rzeczywiście ListView mógłby czyścić nasz obiekt ListViewItem, a tego nie robi.... chyba... bo już nie wiem czy głupot nie gadam ; p
Avatar użytkownika
Slynx
Mądrosław
Mądrosław
 
Posty: 350
Dołączył(a): piątek, 17 grudnia 2010, 21:59
Podziękował : 11
Otrzymał podziękowań: 0
System operacyjny: Windows 7 32
Kompilator: Visual C++ 2005; Visual C++ 2008; Visual C++ 2010; Visual C# 2010;
Gadu Gadu: 0
    Windows 7Chrome

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Cyfrowy Baron » poniedziałek, 27 czerwca 2011, 12:56

Slynx napisał(a):No właśnie to chyba nie jest prawda. Przecież gdy do obiektu cały czas coś dodajesz to obiekt cały czas pozostaje aktywny, a nie ginie i jest tworzony na nowo po każdej iteracji.


Przecież odwołujesz się do niego porzez referencje, a to oznacz, że w każdym obiegu pętli tworzysz referencję na nowo. Nie tworzysz obiektu, lecz przekazujesz mu wartości poprzez referencję. Obiekt nie ginie, lecz ginie referencja i w każdej iteracji na nowo tworzona jest referencja nie obiekt.
Avatar użytkownika
Cyfrowy Baron
Administrator
Administrator
 
Posty: 4716
Dołączył(a): niedziela, 13 lipca 2008, 15:17
Podziękował : 12
Otrzymał podziękowań: 442
System operacyjny: Windows 7 x64 SP1
Kompilator: Embarcadero RAD Studio XE2
C++ Builder XE2 Update 4
SKYPE: cyfbar
Gadu Gadu: 0
    Windows XPFirefox

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Slynx » poniedziałek, 27 czerwca 2011, 13:16

C++/CLI uses a "^%" syntax to indicate a tracking reference to a handle. It is similar in concept to using "*&" (reference to a pointer) in Standard C++.

* = pointer
^ = managed pointer
& - reference
% - managed reference

Gdzieś użyliśmy znaku % ? Czyli referencji ? Nigdzie.

Jeszcze jedno, czym jest dokładnie "^%" ? referencja do wskaźnika (uchwytu) ? Kilka razy to stosowałem (a raczej jak mnie polymorphism poprawił). To chyba miało zastosowanie w iteracji elementów tablicy, pozwalało odwoływać się do pojedynczych metod i pól typu elementu danej tablicy, gdy samo "^" odwoływało się do elementu tablicy jak całego obiektu... mniej więcej... tutaj to moje pojęcie o tym jest dość "mgliste" ; p
Nigdy do końca tego nie rozumiałem, tak samo jak "*&". Dochodziłem do tego raczej metodą prób i błędów.
Avatar użytkownika
Slynx
Mądrosław
Mądrosław
 
Posty: 350
Dołączył(a): piątek, 17 grudnia 2010, 21:59
Podziękował : 11
Otrzymał podziękowań: 0
System operacyjny: Windows 7 32
Kompilator: Visual C++ 2005; Visual C++ 2008; Visual C++ 2010; Visual C# 2010;
Gadu Gadu: 0
    Windows 7Chrome

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Cyfrowy Baron » poniedziałek, 27 czerwca 2011, 13:23

Nie wiem jak to jest w C++/CLI, a podany przez Ciebie przykład:

KOD cpp:     UKRYJ  
function xxx()
{

while (cos tam)
{
ListViewItem lvi = new ListViewItem();

lvi.Add("");
// cos tam, cos tam...
listView.Item.Add(lvi);
}
Też nie wygląda mi na referencję, gdyż jest tutaj użyty operator new tworzący mowy obiekt i masz tutaj wyciek pamięci, gdyż obiekt lvi nie jest niszczony.

Slynx napisał(a):Przecież gdy do obiektu cały czas coś dodajesz to obiekt cały czas pozostaje aktywny, a nie ginie i jest tworzony na nowo po każdej iteracji.


Obiekt nie pozostaje aktywny (lvi), gdyż w każdym obiegu pętli jest porzucany i tworzony jest nowy. Do listView przepisywana jest zawartość obiektu lvi w każdej pętli, dlatego dla listView nie ma znaczenia, czy obiekt został porzucony, czy też zniszczony, gdyż listView nie przechowuje obiektu lvi, lecz tylko pobiera z niego zawartość. W każdym obiegu pętli porzucasz obiekt lvi i tworzysz nowy.
Avatar użytkownika
Cyfrowy Baron
Administrator
Administrator
 
Posty: 4716
Dołączył(a): niedziela, 13 lipca 2008, 15:17
Podziękował : 12
Otrzymał podziękowań: 442
System operacyjny: Windows 7 x64 SP1
Kompilator: Embarcadero RAD Studio XE2
C++ Builder XE2 Update 4
SKYPE: cyfbar
Gadu Gadu: 0
    Windows XPFirefox

Re: Zamykanie otwartego pliku(!)

Nowy postprzez polymorphism » poniedziałek, 27 czerwca 2011, 13:25

No właśnie to chyba nie jest prawda. Przecież gdy do obiektu cały czas coś dodajesz to obiekt cały czas pozostaje aktywny,

Nie bardzo rozumiem. Coś mi się zdaje, że nie odróżniasz referencji od obiektu, na który ów referencja wskazuje.

Mój obiekt (ListViewItem) cały czas istnieje po przekazaniu do ListView. ListView jedynie go odczytuje, dopisuje do swojej kolekcji i zostawia w spokoju.

No i po zakończeniu iteracji obiekt staje się nieosiągalny (unreachable), zatem przeznaczony do skasowania, co z dużym prawdopodobieństwem będzie skutkować tym, że przy następnym tworzeniu obiektu tej samej klasy, pamięć zajmowana przez wspomniany obiekt zostanie ponownie wykorzystana (nastąpi finalizacja starego obiektu i konstrukcja nowego na tym samym fragmencie pamięci).

- Referencja ? A to z czego wynika ?

Z tego, że mówimy o C# i pamięci zarządzanej.
C++ Reference - opis wszystkich klas STL-a i funkcji C.
Avatar użytkownika
polymorphism
Doświadczony Programista ● Moderator
Doświadczony Programista ● Moderator
 
Posty: 2156
Dołączył(a): piątek, 19 grudnia 2008, 13:04
Podziękował : 0
Otrzymał podziękowań: 200
System operacyjny: Windows 8.1
Windows 10
Linux Mint 21.1
Kompilator: Visual Studio
Visual Studio Code
MSYS2 (MinGW, clang)
g++
clang
Gadu Gadu: 0
    Windows XPFirefox

Re: Zamykanie otwartego pliku(!)

Nowy postprzez Slynx » poniedziałek, 27 czerwca 2011, 13:35

Już miałem coś napisać, ale wcześniej coś doczytałem, tak więc już się nie odzywam :D

No i po zakończeniu iteracji obiekt staje się nieosiągalny (unreachable), zatem przeznaczony do skasowania, co z dużym prawdopodobieństwem będzie skutkować tym, że przy następnym tworzeniu obiektu tej samej klasy, pamięć zajmowana przez wspomniany obiekt zostanie ponownie wykorzystana (nastąpi finalizacja starego obiektu i konstrukcja nowego na tym samym fragmencie pamięci).
A w przypadku natywnego następowało zastąpienie adresu w pamięci bez wcześniejszego oczyszczania co skutkowało brakiem możliwość oczyszczenia tego obszaru. O ile dobrze pamiętam....
Avatar użytkownika
Slynx
Mądrosław
Mądrosław
 
Posty: 350
Dołączył(a): piątek, 17 grudnia 2010, 21:59
Podziękował : 11
Otrzymał podziękowań: 0
System operacyjny: Windows 7 32
Kompilator: Visual C++ 2005; Visual C++ 2008; Visual C++ 2010; Visual C# 2010;
Gadu Gadu: 0
    Windows 7Chrome

Następna strona

  • Podobne tematy
    Odpowiedzi
    Wyświetlone
    Ostatni post

Powrót do Ogólne problemy z programowaniem

Kto przegląda forum

Użytkownicy przeglądający ten dział: Brak zalogowanych użytkowników i 33 gości

cron