Temat: [Kurs] Objective C/Cocoa - 03. Obiekty. Składnia. Typy zmiennych.

Napisał normanek

Smuggi, nie wiem, czy cos przegapilem, ale wydaje mi sie (za najnowszym wydaniem "Cocoa Programming in Mac OS X" Pana Aarona Hillegassa), ze settery bez deklaracji rowniez dzialaja (przynajmniej u mnie dzialaly, gdy programowalem uzywajac KVC, a dopiero potem autor przeszedl do deklaracji ;]), natomiast slowo @property sluzy jednoznacznemu wskazaniu, w jaki sposob maja one funkcjonowac (np. copy).

Nie przegapiles, to dziala bo KVC uzywa metody:

Kod:

- (id)valueForKey:(NSString *)key

Jednak dopiero deklaracja @property pozwala okreslic:
- jak ma dzialac przypisanie wartosci na te zmienna (assign - jest domyslnie), masz wlasnie copy czy tez retain.. Oprocz tego mozesz ustawic czy to jest zmienna tylko do odczytu, oraz czy jest ona atomic
- oraz pozwala Ci po prostu na dostep do tej zmiennej w inny sposob niz przez valueForKey (np. przez standardowe settery lub z uzyciem kontrowersyjnej ".")

No ta "kontrowersjyna "."", to tylko dlatego jest, że jednak Apple chce się przypodobać za bardzo reszcie programistów z innych języków.
Ale to wszystko robi się po to aby było "lepiej".
Chociaż dla mnie przerabianie czegoś, żeby wyglądało jak coś innego, to nie jestdobry pomysł.


Pozdrawiam.

Napisał sannindan

@BilboBaggins
Może i dobrze piszesz. Ale zauważ, że ja użyłem takiej składni:

Kod php:

NSString * string = @"cos tam napisane"; 


A w tym wypadku nie zwalniasz pamięci.

Gwoli scislosci. Przyczepilem sie do konstrukcji Twojego setter'a. To setter nie zwalnia aktualnie przypisanych obiektow, a co za tym idzie prowadzi on do wycieku pamieci. ObjC (jak pewnie doskonale wiesz) nie ma garbage collector'a, a co za tym idzie wymaga od Nas (czyt. programistow) liczenia referencji.

Twoj kod:

Kod php:

-(void) ustawNazwisko: (NSString *) n
{
    nazwisko = n;
}

-(void) ustawWiek: (int) w
{
    wiek = w;
}

-(void) ustawNazwisko: (NSString *) n iWiek: (int) w
{
    nazwisko = n;
    wiek = w;
} 


W polaczeniu z:

Kod php:

    [jozek ustawNazwisko: @"panaNazwisko"];
    [jozek ustawWiek: 25];
    
    printf("%s ma %d lat.\n", [[jozek nazwisko] cString], [jozek wiek]);
    
    [jozek ustawNazwisko: @"paniNazwisko" iWiek: 24];    
    printf("A %s ma %d lat.\n", [[jozek nazwisko] cString], [jozek wiek]); 


Zaowocuje tym, ze w momencie nadpisania nazwiska obiektem @"paniNazwisko" obiekt @"panaNazwisko" zostanie dalej w pamieci, pomimo braku referencji do niego. Taka sytuacja bedzie miala miejsce w ObjC 1.0. Jak bedzie w 2.0 tego nie wiem, bo jeszcze zwlekam z czytaniem o garbage collector'ach w ObjC 2.0. Wole w miejsce tego dokonczyc moja aplikacje w PyObjC i opanowac poruszanie sie po API . Jak to zrobie to sie doedukuje.

No chyba, ze ten kursik wczesniej zahaczy o to zagadnienie . Dodam, ze bede sledzil Twoj kurs, poniewaz chce sprawdzic siebie i przy okazji sie czegos nowego nauczyc.

Dzieki raz jeszcze za Twoja inicjatywe . Moje komentarze wynikaja z tego, ze sam wiem ile wysilku kosztowalo mnie opanowanie zarzadzania pamiecia w ObjC 1.0, pomimo dosc dlugiego doswiadczenia w programowaniu. Im wczesniej sie to omowi, tym lepiej .

PS. W KVC da sie programowac uzywajac wlasnosci klas i accessor'ow. Ja tak koduje caly czas, choc nie ukrywam, ze trzymanie danych w NSMutableDictionary i zarzadzanie nimi przez valueForKey: i setObject:forKey: jest wygodniejsze. Robie tak jak robie, bo tak mi latwiej okielznac wlasny kod .

Heh.
Pamiec dla tych napisów jest zawsze zwalniana z końcem programu.
Jak wiesz to ten zapis, to dokładnie korzystanie z NSConstantString (może i powinienem tego zapisu użyć, ale tak było prościej),
jest to statyczny obiekt:

Kod php:

NSString *str01=@"Napis"; <=> NSConstantString *str01=@"Napis"; 


Dlatego też dla potrzeb tej częsci nie było potrzeby używać żadnych AutoRelasePool ani żadnych takich podobnych w setterach. Skoro i tak używałem tylko składni const. No i nie od razu na pierwszą część o zarządzaniu pamieci - to by od razu nie jednego zraziło

Tak jest z każdą zmienną deklarowaną jako static. Dlatego nie ma mowy o wycieku pamięci ani takich innych sprawach Tym bardziej że wyciek pamięci jest tylko wtedy jeśli stracimi wzkaźnik/referencje do obiektu, ale tylko w przypdaku kiedy nie korzystamy z GC.


Tu masz małe przypomnienie o zwalanianiu pamieci:

Kod php:

NSString *str01 = @"Napis01";
NSString *str02 = [NSString stringWith*:];      // w miejsce * wstaw cokiolwiek kończące metode np. stringWithString, stringWithCString itp
NSString *str03 = [[NSString alloc] init]; 


I tak:
W pierwszym przypadku str01 nie trzeba zwalniać.
W drugim str02 pamieć jest zwalniana poprzez NSAutoReleasePool.
Trzeci przypadek, czyli str03 sam zwalniasz poprzez [str03 release];
No i dochodzi jeszcze GC, ale o tym przy okazji Objective C 2.0


Pozdrawiam.
PS.
Wiem wiem. cString jest deprecated, ale zawsze to przykład i jeszcze tego używają

@Tojot
No tak masz racje. Ale jak się rozejdziemy aż do takich tłumaczeń, to możemy od razu będziemy tłumaczyć co robi kompliator i linker i jak wygląda kod maszynowy
A tak na poważnie, to zawsze warto wybierać kompromis pomiędzy rzeczami które mamy tłumaczyć dogłębnie a które nie i kiedy to zrobić.

@giku
(Jak najbedziej będzie po angielsku -0 już to pisałem wiele razy. Tylko to było na cele 1części o programowaniu aby zrozumieć niektóre rzeczy).


Proponuję przeczekać, aż do końca kursu
Potem oceniać. Bo całość lepiej się widzi niż tylko jego część, którą nie stanowi całości.

Pozdrawiam.

Założenie było takie, że znamy podstawy C. W takim przypadku mnie ten kurs w 100 procentach satysfakcjonuje.

Dzięki!