Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Kod koji daje neočekivani rezultat

[es] :: Art of Programming :: Kod koji daje neočekivani rezultat

Strane: << < .. 5 6 7 8 9 10 11 12 13 14 ... Dalje > >>

[ Pregleda: 107899 | Odgovora: 337 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

chupcko
Negde
Beograd

Član broj: 5560
Poruke: 1141

Sajt: www.google.com


+63 Profil

icon Re: Kod koji daje neočekivani rezultat06.07.2020. u 12:00 - pre 45 meseci
Nedeljko, tako je kako je, neko mudar je resio da napravi novu matematiku, a tebi ako se ne svidja, pa sedi i napravi novi chip :))))))))). Zato i ne treba matematicari da se smaraju programiranjem, smore barem dva puta, prvi put kada otrkiju toplu vodu, a onda kada shvate da ta topla voda je previse topla ;)))).


A i ti dramis, kao da ne mozes ono sto ti treba da sam izracunas :)
CHUPCKO
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
82.117.201.26



+1064 Profil

icon Re: Kod koji daje neočekivani rezultat06.07.2020. u 12:02 - pre 45 meseci
Inace jedina prednost GC-a se eliminise koriscenjem arena alokatora. Znaci najocigledniji primer je pisanje servera. Znaci jedan request
alocira kolko treba bez oslobadjanja i onda u cugu oslobodi sve sto je alocirano za dati req, sto je sigurno brze od bilo kakvog GC-a.
 
Odgovor na temu

Burgos
Nemanja Borić
Amazon Web Services
Berlin

Član broj: 12484
Poruke: 1947
54.239.6.*

Sajt: stackoverflow.com/users/1..


+480 Profil

icon Re: Kod koji daje neočekivani rezultat06.07.2020. u 12:03 - pre 45 meseci
Citat:
Ovo ces moci zakljuciti tek onda kada je N dovoljno veliko da se dealokacija izvrsi nekoliko puta


Apsolutno se slažem. Odgovarao sam na Nedeljkovo pitanje "Recimo da imamo veliki broj alokacija i dealokacija.". Generalno je teško dati odgovor na ovakva pitanja, ali je moguće napraviti primere.

Citat:
No pazi sad, a sta cemo sa .NET GC-om koji je compacting, to znaci da mora da iskopira heap pa apdejtuje *sve
reference* u programu.


Svakako, ali compating GC ima svoje prednosti. Kao i generational, kao i konkurentni, kao i... Sve je stvar kompromisa. Razlog zbog čega GC-u nije mesto u sistemskim jezicima je što zahteva kompromis.

Citat:
Generalno GC funckionise sve 5 dok program ne postane nesto vise od hello world primera, e onda ....


Ne slažem se sa ovim. Nekoliko godina sam pisao network-heavy aplikacije koristeći GC, koje su bez problema radile >3000 req/s po jednom CPU jezgru bez ikakvih problema (https://github.com/sociomantic-tsunami/swarm, https://github.com/sociomantic-tsunami/ocean, https://github.com/sociomantic-tsunami/dhtnode, ...).
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.



+2789 Profil

icon Re: Kod koji daje neočekivani rezultat06.07.2020. u 13:13 - pre 45 meseci
Citat:
chupcko: neko mudar je resio da napravi novu matematiku

Neki diletant je rešio da napravi novu matematiku
Citat:
chupcko: a tebi ako se ne svidja, pa sedi i napravi novi chip :)))))))))

Samo ne znam kako. Najviše što mi se nudi je FPGA.
Citat:
chupcko: Zato i ne treba matematicari da se smaraju programiranjem

Ne treba. Svako treba da se bavi svojim poslom. Samo, neki poslovi su multidisciplinarni. Opet treba da se sluša struka. Kada se implementiraju kriptoalgoritmi, mora neki kriptograf da se angažuje.
Citat:
chupcko: A i ti dramis, kao da ne mozes ono sto ti treba da sam izracunas :)

Ne radi se o tome, nego se radi o tome da ne postoji primer praktične primene onakvog operatora % kakav je u hardveru u slučajevima kada se razlikuje od onakvog kakav je u matematici.

Hvala svima na komentarima u vezi sa GC-om. To me je zanimalo.

Što se tiče toga šta GC inače postiže, evo šta piše na MSDN-u:
Citat:
Fundamentals of garbage collection

In the common language runtime (CLR), the garbage collector (GC) serves as an automatic memory manager. The garbage collector manages the allocation and release of memory for an application. For developers working with managed code, this means that you don't have to write code to perform memory management tasks. Automatic memory management can eliminate common problems, such as forgetting to free an object and causing a memory leak or attempting to access memory for an object that's already been freed.

Ovo nije tačno.

Problem automatskog čišćenja otpadaka je u opštem slučaju Tjuring nerešiv.

Otpadak se definiše kao podatak kome se ne može pristupiti u nastavku izvršavanja programa, za ma kakve ulaze u program.

Recimo, u kodu

Code:

{
    String str = new String("Pera");

    System.Console.WriteLine(str);

    // Do something without str
}


je str otpadak odmah po ispisivanju, ali GC to ne može da shvati. Čak i ako se izričito pozove da počisti šta može, džaba.

[Ovu poruku je menjao Nedeljko dana 06.07.2020. u 15:31 GMT+1]
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

Mihajlo Cvetanović
Beograd

Moderator
Član broj: 37636
Poruke: 1249



+96 Profil

icon Re: Kod koji daje neočekivani rezultat06.07.2020. u 15:38 - pre 45 meseci
Nije istina da program ne može da pristupi promenljivoj str. Može, ali neće. I zato str nije otpadak. Da zaista ne može da pristupi onda bi zaista bio otpadak. Recimo ovako:

Code:
{
    String str = new String("Pera");

    System.Console.WriteLine(str);
}

// Do something without str


Po definiciji C# jezika str je "živ" sve dok ne izađe iz svog opsega. To znači da je promenljiva dohvatljiva pomoću refleksije. Možeš da u programu izlistaš sve lokalne promenljive i da im tako pristupiš. Nema te logike koja može da pokrije sve slučajeve i sa 100% sigurnosti ustvrdi da li promenljivi pristupa i posle neke tačke u kodu, i zato se niko time i ne bavi, nego se sve svodi na oblast važenja, pa i definicija otpatka.
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.



+2789 Profil

icon Re: Kod koji daje neočekivani rezultat06.07.2020. u 16:50 - pre 45 meseci
Po definiciji otpatka jeste otpadak. Program nakon ispisivanja ne može da pristupi toj promenljivoj, je ma kakvi da su ulayi u pitanju u nastavku, do pristupa neće doći. Tad podatak je memorijski dostižan. Ako bismo zamrznuli izvršavanje i promenili program tako da sa zatečenim stanjem memorije (ne računajući kod, već samo podatke)

To je u opštem slučaju Tjuring neizračunljivo. Dam ti sors i ti kreneš da interpretiraš program, pri čemu interpreter može da pamti kakve god metainformacije o dotadašnjem toku izvršavanja. Identifikacija otpadaka je algoritamski nerešiva.

Postoje sistemi dovoljnih uslova pod kojima je nešto otpadak i to je ono što se implementira.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

chupcko
Negde
Beograd

Član broj: 5560
Poruke: 1141

Sajt: www.google.com


+63 Profil

icon Re: Kod koji daje neočekivani rezultat06.07.2020. u 18:44 - pre 45 meseci
Pa i dalje mi nije jasno sto ti mislis da je % operator u c-u ono sto je u matematici kongruencija ? Prosto nije, kao sto sto ima puno primera gde ne vazi ta tvoja tradicionalna matematika ;)

Jedan od lepih primera je:

Code:

#include <stdio.h>

int main(void)
{
  int i;
  int j;
  
  for(i = 1; i < 10; i++)
    for(j = 1; j < 10; j++)
      printf("%d %d = %d\n", i, j, (i/j)*(j/i));
  return 0;
}


a probaj posle i/j*j/i :)

CHUPCKO
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.



+2789 Profil

icon Re: Kod koji daje neočekivani rezultat06.07.2020. u 20:08 - pre 45 meseci
Da mi je znati šta je ovde u neskladu sa matematikom, osim tvojih iskaza.

Prvo, kongruencija nije operacija, već relacija, dok je ostatak pri delenju operacija. Da li se sećaš šta su kongruencije u algebri i čemu služe u matematici (šire od algebre)?

Drugo, ne vidim da je rad programa u suprotnosti sa matematikom. Ako je

, , ,

a jeste, onda je sve u redu. U programu piše da se štampa

što je ,

što naravno da u opštem slučaju nije 1. Ko je očekivao keca, taj nije dobro naučio matematiku.

Takođe, je ,

što takođe u opštem slučaju nije isto što i ono prethodno.


Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
109.72.51.23



+1064 Profil

icon Re: Kod koji daje neočekivani rezultat07.07.2020. u 03:55 - pre 45 meseci
Burgos:
Citat:
Ne slažem se sa ovim. Nekoliko godina sam pisao network-heavy aplikacije koristeći GC, koje su bez problema radile >3000 req/s po jednom CPU jezgru bez ikakvih problema (https://github.com/sociomantic-tsunami/swarm, https://github.com/sociomantic-tsunami/ocean, https://github.com/sociomantic-tsunami/dhtnode, ...).


Ti si verovatno tu natprosecan, ja sam mislio na gomilu ljudi koji su pre ili kasnije naisli na probleme sa GC-om, i kada ono forsiranje ciklusa kolekcije postane neminovnostost i kada convenience predje u thinkering zbog problema
sa performansama.
 
Odgovor na temu

Burgos
Nemanja Borić
Amazon Web Services
Berlin

Član broj: 12484
Poruke: 1947
54.239.6.*

Sajt: stackoverflow.com/users/1..


+480 Profil

icon Re: Kod koji daje neočekivani rezultat07.07.2020. u 10:07 - pre 45 meseci
Slažem se, i sam sam (pre ili kasnije) naišao na iste probleme, koje je bilo (ne)moguće zaobići uz manje ili više truda.
 
Odgovor na temu

chupcko
Negde
Beograd

Član broj: 5560
Poruke: 1141

Sajt: www.google.com


+63 Profil

icon Re: Kod koji daje neočekivani rezultat07.07.2020. u 21:32 - pre 45 meseci
e tako kao sto je / u c-u istvari ceo deo deljenje, tako je i % nesto deseto ... tako ti je to
CHUPCKO
 
Odgovor na temu

Rapaic Rajko
Bgd

Član broj: 4105
Poruke: 810
31.223.145.*



+62 Profil

icon Re: Kod koji daje neočekivani rezultat08.07.2020. u 09:29 - pre 45 meseci
Ja bih jos malo gnjavio na temu GC-a, konkretno opisacu mehanizam koji postoji u Delphi-ju (ne znam da li postoji u nekom drugom jeziku).

Delphi sam po sebi ne podrzava GC. Ali, postoje Delphi interface-i, koji funkcionisu otprilike ovako:

1) Delphi interface ima na sebi reference counter. Ukoliko counter postane nula (0), instanca na kojoj 'lezi' interface se brise (free).
2) Definisemo klasu koja na sebi implementira neki interface.
3) Ako kreiramo instancu klase preko interface-a, automatski se postavlja reference counter na 1.
4) Svako prosledjivanje interface-a nekoj metodi/funkciji/cemu god, automatski uvecava reference counter (bukvalno se prati stack); vazi i obratni put (vracanje iz stack-a).
5) Kad u jednom trenutku reference counter postane 0 (nema vise nacina da se instanci pristupi iz programa) instanca se brise.

Kako sam ja shvatio, ovo je neko polu/resenje opisanog problema detekcije 'stvarno' odbacenog podatka.

Koje su, po vama, performanse opisanog mehanizma u odnosu na klasican GC..?
 
Odgovor na temu

Burgos
Nemanja Borić
Amazon Web Services
Berlin

Član broj: 12484
Poruke: 1947
54.239.6.*

Sajt: stackoverflow.com/users/1..


+480 Profil

icon Re: Kod koji daje neočekivani rezultat08.07.2020. u 10:07 - pre 45 meseci
Za Delphi, Automated Reference Counting je dobar izbor. Najveći problem sa klasičnim GC-om u
aplikacijama koje se prave u Delfiju je stop-the-world faza kada GC mora da pauzira sve niti, što
rezultuje u blokiranju UI-a.

Prednosti ARC u odnosu na GC:

- Ne postoji velika "stop-the-world" faza, već se sve radi inkrementalno, nema blokiranja celog programa.
- Ne postoji "kašnjenje" u čišćenju, što rezultuje nižim utroškom radne memorije.

Mane:

- ARC ne može da se izbori sa ciklusima u drvu zavisnosti bez pomoći programera.
- Održavanje brojača, naročito u višenitnom okruženju nije besplatno, i plaća se svaki put.

Iz tog razloga, svaki put kada vidim std::shared_ptr (C++ wrapper za ARC) u kodu koji pregledam, tri puta postavim
pitanje da li je zaista potreban, i uglavnom nije. Olakšava upotrebu jezika, brigu o dealokacijama, ali u većini slučajeva
nije potreban, naročito ako nema nikakvog deljenja između niti. Mnogo je bolje samo alocirati objekat, pozaljmljivati ga,
davati ga uz pomoć std::move-a, kada nema potrebe da se zadrži, i uništiti ga automatski po isteku lifetime-a, ali je dosta
teže misliti o svemu ovome. Zato Rust blista, jer te lifetime-checker sprečava da uradiš nešto nebezbedno.
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.



+2789 Profil

icon Re: Kod koji daje neočekivani rezultat08.07.2020. u 11:51 - pre 45 meseci
Citat:
chupcko:
e tako kao sto je / u c-u istvari ceo deo deljenje, tako je i % nesto deseto ... tako ti je to

Samo se postavlja pitanje praktične primene tog desetog.

Zato sam ja postavio pitanje, koja je praktična primena operatora %, kod koga -2%10 i 8%10 nisu isto.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.



+2789 Profil

icon Re: Kod koji daje neočekivani rezultat08.07.2020. u 13:35 - pre 45 meseci
@Burgos


A da li zapravo C blista, jer te ne ograničava, nego vrši čak i custom alokaciju, po kakvim god hoćeš algoritmima, dok ti Rust ne da napraviš kružno pokazivanje?

Znam ja zašto to Rust radi. Koristi reference counting, koji ne funkcioniše u slučaju kružnih pokazivanja. Međutim, to onda znači da svoju ideju (pođimo od dvostruko uvezane liste) ne možeš da implementiraš direktno, već da moraš da implementiraš neku zamenu za tu tvoju ideju, što otežava programiranje u Rust-u.

Na kraju mi se najviše sviđa C - daje ti odrešene ruke da implementiraš šta hoćeš kako hoćeš. Može sve to i C++ uz nuđenje nekih dodatnih automatizacija, što je takođe dosta dobro.

Evo šta piše na sajtu programskog jezika D:

Citat:
Garbage Collection

Garbage collected programs are often faster. This is counterintuitive, but the reasons are:

- Reference counting is a common solution to solve explicit memory allocation problems. The code to implement the increment and decrement operations whenever assignments are made is one source of slowdown. Hiding it behind smart pointer classes doesn't help the speed. (Reference counting methods are not a general solution anyway, as circular references never get deleted.)

- Destructors are used to deallocate resources acquired by an object. For most classes, this resource is allocated memory. With garbage collection, most destructors then become empty and can be discarded entirely.

- All those destructors freeing memory can become significant when objects are allocated on the stack. For each one, some mechanism must be established so that if an exception happens, the destructors all get called in each frame to release any memory they hold. If the destructors become irrelevant, then there's no need to set up special stack frames to handle exceptions, and the code runs faster.

- Garbage collection kicks in only when memory gets tight. When memory is not tight, the program runs at full speed and does not spend any time tracing and freeing memory.

- Garbage collected programs do not suffer from gradual deterioration due to an accumulation of memory leaks.


Daleko od toga da su autori programskog jezika D za potcenjivanje, ali mi Banetovi i Burgosovi argumenti deluju uverljivije.

- Nisu uporedili reachability method i reference counting method u dužim razmacima izvršavanja programa.

- To što destruktori nemaju telo, ne znači da ne postoji programski kod koji oslobađa t memoriju. Postoji, samo što se pali ponekad, se upali GC.

- Destruktori ne oslobađaju memoriju samog objekta, već samo memoriju na koju atributi objekta pokazuju, tako da se ništa ne menja time da li je sam objekat na steku ili ne.

- Da, GC se pali ponekad, kada ponestane memorije, ali koliko je amortizovano vreme u oa slučaja?

- Programi sa GC-om mogu imati curenje, ako su loše napisani, baš kao i ostali.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

Burgos
Nemanja Borić
Amazon Web Services
Berlin

Član broj: 12484
Poruke: 1947
54.239.6.*

Sajt: stackoverflow.com/users/1..


+480 Profil

icon Re: Kod koji daje neočekivani rezultat08.07.2020. u 14:28 - pre 45 meseci
Code:
A da li zapravo C blista, jer te ne ograničava, nego vrši čak i custom alokaciju, po kakvim god hoćeš algoritmima, dok ti Rust ne da napraviš kružno pokazivanje?


Rust "blista" u kontekstu niske cene upravljanja resursima bez kompromisa u sigurnosti. Cena se plaća, samo na drugom mestu - između tastature i stolice :-).

Rust ne koristi reference counting, osim ako ne koristiš https://doc.rust-lang.org/std/rc/struct.Rc.html ili slično, već postoji sistem "pravila" koje moraš da poštuješ. Pojednostavljeno, to su:

- Svaki objekat može biti pozajmljen samo jednom istovremeno za pisanje.
- Svaki objekat može biti pozajmljen neograničeno mnogo puta za čitanje.
- Nijedan objekat ne može biti istovremeno pozajmljen za pisanje i čitanje istovremeno.

To naravno spotiče programera da napiše kod kakav želi, i ograničava ga na "sigurnu" teritoriju. Na primer, ovo ne da ne dozvoljava
da napraviš dvostruko ulančanu listu na uobičajeni način (https://rcoh.me/posts/rust-linked-list-basically-impossible/ - ako imaš A - B - C dvostruko ulančanu listu, čvorovi A i C moraju da budu vlasnici čvora B, a ne mogu istovremeno), nego ne dozvoljava ni jednostavne paradigme za koje ti kao programer znaš, ali kompajler ne može da dokaže da su ispravne:

Code:
if let Some(val) = map.get_mut(&id) { // Pozajmljivanje map za pisanje
   /* ... */
} else {
   map.insert(id, new_val); // map je već pozajmljena za pisanje na početku if statementa, ne možemo ovde da pišemo.
}


Rust tim radi na ovome, ovaj problem je već rešen, i videćemo šta će biti u narednih par godina: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md, https://github.com/rust-lang/rust/issues/43234 (mislim da su već daleko odmakli od situacije od pre par godina kada sam poslednji put pisao Rust). Sličnih primera sigurno ima, ali ja ne mogu da ih se setim, jer sam upravo najviše problema imao sa ovim. Inače, non-lexical lifetime upravo rešava problem koji si naveo:

Code:
{
    String str = new String("Pera");
    System.Console.WriteLine(str); // nakon ovoga, str je uništen bez obzira na to šta sledi, ako ništa što sledi ne koristi str.
}


Citat:
Na kraju mi se najviše sviđa C - daje ti odrešene ruke da implementiraš šta hoćeš kako hoćeš. Može sve to i C++ uz nuđenje nekih dodatnih automatizacija, što je takođe dosta dobro.


Da, to i mene privlači ka C++-u, ali... "Kako hoćeš" ima velikih problema kada radiš u timu od nekoliko stotina ljudi na jednom projektu. Nijedna osoba nema pregled celokupnog projekta, niti predstavu o tome šta si želeo. Na primer, ukoliko pozivaš neku funkciju foo i proslediš svoj string, ne možeš znati da li će foo uzeti referencu na string, tj. možda znaš sada, ali ne znaš za par dana, kada neko izmeni foo(), zbog nečega potpuno drugog, ne osvrćući se na to što si napisao. Ili kada ti uradiš isto to, nekoliko meseci kasnije. Sigurnost se svodi na dobar code-review, dobre testove, dobro deljenje znanja, itd. U nekim oblastima (kada je sigurnost od najvišeg značaja, čak ispred produktivnosti i performansi) to može biti neprihvatljivo.

Što se tiče D programskog jezika - projekti koje sam okačio na kojima sam radio godinama su upravo pisani u D-u. Autori nisu za potcenjivanje, ali argumenti koje su naveli su... malo pristrasni :-). Svakako da su to prednosti, ali nijedna mana nije navedena...
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.



+2789 Profil

icon Re: Kod koji daje neočekivani rezultat08.07.2020. u 14:53 - pre 45 meseci
@Burgos

Koliko znam, Rust koristi reference counting, a pravila koja nameće, a koja se proveravaju u fazi prevođenja, sprečavaju pravljenje kružnih pokazivanja, tako da reference counting može da funkcioniše.

Koliko ljudi radi na Linux kernelu, koji se piše u C-u? Kada su Linusa Torvaldsa pitali zašto ne koristi C++, koliko znam, naveo je tri razloga:

1. Ako C odbija budale sa projekta, to mu je već dovoljna prednost.

2. Sve što mu u sistemskom programiranju koristi od C++-a, to ima i C. Zašto onda potezati C++?

3. C++ kod se mnogo sporije kompajlira.

Što se autora programskog jezika D tiče, problem je što navedeni argumenti ne drže vodu. Dakle, to što su naveli kao razloge da je upravljani kod često brži od neupravljanog, jednostavno nije tačno. Ako postoje primeri gde je upravljani kod brži od neupravljanog, u takvim primerima razlozi svakako neće biti ti, jer to što su napisali su netačnosti.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

Burgos
Nemanja Borić
Amazon Web Services
Berlin

Član broj: 12484
Poruke: 1947
54.239.6.*

Sajt: stackoverflow.com/users/1..


+480 Profil

icon Re: Kod koji daje neočekivani rezultat08.07.2020. u 15:14 - pre 45 meseci
Citat:
Koliko znam, Rust koristi reference counting, a pravila koja nameće, a koja se proveravaju u fazi prevođenja, sprečavaju pravljenje kružnih pokazivanja, tako da reference counting može da funkcioniše


Ne, Rust jezik (bez stdlib dodataka kao Rc) ne koristi reference counting (koji se dešava prilikom runtime-a) već praćenje vlasništva nad objektima tokom kompajliranja. Pravila koja nameće nisu tu da bi sprečili kružna pokazivanja (iako je to nuspojava) već radi sigurnosti i efikasnosti izvršavanja:

1. pošto samo jedan entitet može biti vlasnik objekta, kada se završi život objekta, objekat se može uništiti, bez brige da li neki drugi entitet drži isti objekat - nema potrebe za reference countingom.
2. Ukoliko je vlasništvo preneseno drugom entitetu, prvobitan vlasnik ne može ni na kakav način da pristupi objektu, jer to može dovesti do situacije da je novi vlasnik uništio objekat, i pritom omogućava drugom vlasniku da uništi objekat kada želi/čim mu više nije potreban.

Sve ovo se dešava prilikom kompajliranja, i zna se da, ako se program uspešno kompajlira, program radi ispravno bez ikakve provere/reference counting-a/skupljanja đubreta tokom izvršavanja programa.
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.isp.telekom.rs.



+2789 Profil

icon Re: Kod koji daje neočekivani rezultat08.07.2020. u 16:52 - pre 45 meseci
Dakle, ponaša se kao ručno vođenje računa o tome kada uništiti objekat - uništava ga onaj ko ga je stvorio, osim ako je u međuvrmenu prebacio odgovornost na drugoga.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6041



+4631 Profil

icon Re: Kod koji daje neočekivani rezultat09.07.2020. u 15:47 - pre 45 meseci
Na kapiram, kako onda ti sa Rustom mozes da napravis multi-threaded kod? kako moze kompajler da predividi koji thread ce u kom trenutku imati pristup objektu?
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić
 
Odgovor na temu

[es] :: Art of Programming :: Kod koji daje neočekivani rezultat

Strane: << < .. 5 6 7 8 9 10 11 12 13 14 ... Dalje > >>

[ Pregleda: 107899 | Odgovora: 337 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.