Miért nem működik a realloc (C nyelv)?

Demó pufferelt beolvasásra:

[link]

Megizzadtam, de ha jól értem, akkor egy szöveges fájlban tárolt double mátrixot szeretnél beolvasni, ahol egy érték maximum 10 ASCII karakteren van reprezentálva.

Így van?

X86, MMU-val védett rendszerekben allokálni csak egész rendszerlapméret N számú többszörösét szabad dinamikusan, nem pedig összevissza mindenféle egzotikus bájtmennyiséget, mert a futó rendszereden fogalmad sincs, mi történik a töredéklappal, vagy egyáltalán a foglalás sikerességéről.

így kérheted le a rendszered lapméretét:

size_t page_size = sysconf(_SC_PAGESIZE);

[link]

(általában 4 kilóbájt, de inkább a külső library-val kérdezd le, mert más gépeknél más lehet)

Azt, hogy te hogyan struktúrálod belül az allokált heapet, az már a te programozói problémád lesz.

#14 Tudnál linkelni valamilyen oldalt hogy honnan vetted ezt? Valahogy a hitelességét ennek erősen kétlem. Az oprendszer számára tökmindegy hogy a virtuális memóriában hány bájtot tesz írhatóvá.

Ahogy azt az általa linkelt oldalon is leírták, semmi sem garantálja hogy a malloc laphatártól lphatárig foglal majd ha egész lapméretet adsz meg, sőt semmi sem garantálja hogy annyit foglal le amennyit megadsz. Biztosan többet fog mert általában lefoglalás információit a pointer előtti területre írja, pl. hogy a free-nek mennyit kell felszabadítani. Az allocálás optimalizálását hagyd az oprendszerre.

"Az allocálás optimalizálását hagyd az oprendszerre."

Bizonyos utolsó mondatok egyike.

Ha valaki nem tud dinamikus memóriahasználatot optimálisan design-olni, annak akkor inkább még mindig jobb a statikus térben foglalni, mintsem kicsinálja a lehetséges vevő informatikai rendszerét, és ezzel akár milliárd dolláros kárt okozva neki. Jobb esetben maga a rendszer fog stderr-re kiküldeni misztikus Killed. üzeneteket szálankként, amik nem azonnal debugoláskor derülnek ki, hanem csak a sokadik, ezres nagyságrendű kódhívás után.

Az oprendszer nem azért van, hogy te ne is foglalkozz bizonyos alapvető runtime dolgokkal, hanem csak megkönnyíti a design dolgaidat azzal, hogy alapvető rendszerhívásokat előre csomagol neked.

A buffer méretezés meg pontosan olyan feladat, amit nem lehet csak úgy hasracsapva ledesignolni, mint egy sorbarendezést. A kódnak a 160-adik órádban is, az egymilliárdodik hívásnál is működnie kell, nemcsak az első 4 hívásnál, amit türelmesen ki tudsz debugolni munkaidőben.

Ha nem akarsz ilyen fragmentáció-debug dolgokkal foglalkozni, akkor tudsz használni erre a célra kifejlesztett library-kat. IPC-hez például NanoMSG.

Ha valaki ezt nem érti meg, akkor sürgősen hagyja abba a C/C++ nyelvek tanulmányozását, és váltson át mondjuk JAVA-ra (itt úgy fragmentálod a ramodat, ahogy neked éppen jólesik).

Te elolvastad amit írtam? Nekem úgy tűnik hogy nem igazán érted a program, O/S és a hardver kapcsolatát és hasráütésszerűen irkálsz valamit, de semmivel sem tudod alátámasztani azt. Meg sem próbálod alátámasztani amit írsz. Most cáfoltam meg miért nem szabad 4K memóriát lefoglalni: mert az nem 4K memóriát fog lefoglalni és még csak nem is úgy ahogy azt te akarod. A programnak csak a virtuális memória fölött van valamilyen szintű befolyása, a fizikai memória fölött nincs, és jó esetben amit a mallocal lefoglalsz már le van foglalva fizikailag is és a fizikai helyét az oprendszer úgy helyezi el hogy az ne töredezze a memóriát. Azaz egy már lefoglalt lapon belül, aminek a teljes kapacitását még nem használtuk ki. De még egyszer mondom, e fölött nincs befolyásod, és ha sokkal többet foglalsz le mint amennyire szükséged van legfeljebb lassítod a program futását. Ha nem érted hogy miről szól a virtuális memória akkor olvass utána:

[link]

A föntiek megértésének hiányában nem is értheted mit csinál a NanoMSG. Úgy tűnik nem is érted ha felhoztad témaként.

Tényeket írj ne valami "ha nem tudod optimalizálni a memóriát inkább használj JAVA-t minthogy dollármilliós károkat okozz"-féle wtf mondatokat. :)