[C]Detekce konstanty Vyřešeno

[CZechBoY]

Takže jsem to udělal nejspíš správně... všude jsem mallocoval podle délky + 1 byte na \0.
Ok, takže je to celkem opruz dělat s řetězcema v C no

[Reklama]

[MiliNess]

Tisícovej buffer fakt nechci používat, však to žere 1kB paměti ať tam nacpu 2 znaky nebo 1000 ne?

To bylo myšleno spíš jako žert. Samozřejmě bys použil menší pole.
Jinak by ses možná divil, jak se dnes programuje. 1KB buffer je proti tomu zanedbatelnost.

[CZechBoY]

A co když budu chtít uložit víc jak je ten buffer
Odmítám tyhle blbosti.

[faraon]

Blbosti? A co když budeš chtít načíst celý proud dat neznámé délky? Znáš funkci realloc()?

To že je na vstupu víc dat než je velikost bufferu by v naprosté většině případů znamenalo že je v nich nějaká chyba. S chybami vstupních dat se samozřejmě musí počítat, ale v tomhle jazyce je to jen a pouze na programátorovi, aby si ošetřil vstup a dál už mohl pracovat s čistými daty bez zdržujících kontrol.

Zase takový opruz ty řetězce v Céčku nejsou, jen na ně nejsi zvyklý. Když do toho pronikneš hlouběji, tak zjistíš že je to vlastně docela dobře vymyšlené, celý koncept ASCIIZ. Má to jen jedinou nevýhodu, když chceš zjistit délku řetězce, musíš ho projít celý, jinak ve všem ostatním je proti jiným způsobům výhodnější.

Dokonce i to že C nemá typ string je v určitých případech výhoda, nic ti nebrání naimplementovat si ho podle okamžité potřeby libovolným způsobem sám, třeba jako strukturu, uděláš si vlastní knihovnu s pár základními operacemi, a zjistíš že s tím jde vlastně dělat víc než třeba v Javě!

[CZechBoY]

Jo, realloc používám při čtení a ukládání výstupu z tý síťový komunikace.
Teď už je po deadlinu tak můžu říct, že jsem dělal výpis složky pomocí protokolu ftp. Ty parametry bylo parsování url.

Tak vim, že pascal má tu délku na začátku, ale o to mi nešlo. Spíš proč nejde nějak normálně zjistit, jestli je ta proměnná v datovým nebo tom druhým segmentu, tzn. jestli to je konstanta nebo dynamicky naalokovaná proměnná.
Nakonec jsem to mohl udělat eště přes vlastní datovej typ a tam bych si ukládal i délku, no pozdě.

[faraon]

Ten pascalský způsob je pro určité věci také dost šikovný, ale pro jakoukoliv práci s ním je potřeba minimálně jedna proměnná navíc. V Céčku ne. Navíc má jako vedlejší efekt omezenou velikost na 255 znaků.
A třetí způsob, kdysi oblíbený u M$, je označení posledního znaku jedničkou v nejvyšším bitu. Kromě toho že se ušetří jeden bajt to snad ani žádnou výhodu mít nemůže, navíc tam není možné používat druhou půlku ASCII s národními znaky...

No, datový segment ti nezjistím, ale automaticky vytvářené proměnné jsou obvykle na zásobníku, zatímco ty alokované na haldě. A to už by zjistit šlo, jen by sis musel v tom programu dát práci s počítáním rozdílů adres proti nějaké referenční:

Kód: Vybrat vše

#include <stdio.h>
#include <stdlib.h>



int main(void)
    {
    int i,*u;
    char p[1000],*s;

    u=malloc(sizeof(int));
    s=malloc(1000*sizeof(char));

    printf("\nstreamy:\n");
    printf("stdin\t%u\n",stdin);
    printf("stdout\t%u\n",stdout);
    printf("stderr\t%u\n",stderr);

    printf("\nstatické:\n");
    printf("i\t%u\n",&i);
    printf("p[]\t%u\n",p);

    printf("\ndynamické:\n");
    printf("u\t%u\n",u);
    printf("s[]\t%u\n",s);

    return 0;
    }

Rozdíl v umístění je víc než patrný:

Kód: Vybrat vše

streamy:
stdin   3078068832
stdout  3078068672
stderr  3078068512

statické:
i       3219758004
p[]     3219757004

dynamické:
u       141828104
s[]     141828120


Ovšem nezaručím že v konkrétním případě a s jiným kompilátorem to nebude fungovat úplně jinak. Navíc musíš brát v úvahu optimalizace, třeba takový gcc dokáže šílené věci...
Potom záleží jak má paměť zorganizovanou operační systém, jak je fragmentovaná a co už má od spuštění za sebou, a v neposlední řadě se do toho míchá virtuální paměť a přepočet adres na fyzické, všimni si že ten stack mám na třech gigabajtech, ale RAM v počítači jen dva a půl!!!

[MiliNess]

A co když budu chtít uložit víc jak je ten buffer
Odmítám tyhle blbosti.

Pokud budeš tyhle blbosti odmítat a budeš kvůli každé kravině alokovat paměť, budeš psát programy totálně nahovno.
Při psaní nějaké kravinky s 20 funkcemi, prosím. Chci tě ale vidět, jak si hlídáš alokace, až budeš psát větší projekt.
Myslím, že faraon se mnou bude souhlasit.
Pokud ti na dynamické alokaci opradu tolik záleží, přesuň se např. k C++, kde můžeš používat chytré pointery, řetězce ukládat do objektů třídy string,
aniž by ses musel starat o alokaci a pod.

[CZechBoY]

Jasně, v C++ jsou destruktory. Tam je to celkem pohoda.
Ale řekni mi k čemu mi je 20 polí po 1kB když využiju sotva 10B? Když ještě neberu v potaz, že mi můžou v klídku přetýct a vznikne strašná chyba v paměti, vedoucí k padnutí programu.

[faraon]

A proč by měly přetékat?

char *fgets(char *s, int size, FILE *stream);

To je stejné jako strcpy() a strncpy(), použiješ pomalejší bezpečnou funkci na vstupu (jednou), abys mohl reagovat na chybná data, a tam kde máš řetězec už ověřený můžeš klidně použít rychlou funkci bez kontroly. Samozřejmě se počítá s tím že VŽDY kontroluješ návratovou hodnotu! Žádné try a catch které to dělají za tebe...

Tohle je v Céčku normální, prostě nechává vše na odpovědnosti programátora, a také mu nechává absolutní volnost. Ten samozřejmě nesmí udělat něco takového:

Kód: Vybrat vše

int pole[10],a,b,c;

pole[10]=12345;

Jestlipak uhodneš kde to číslo (pravděpodobně) najdeš?

[CZechBoY]

No jak do proměnný s max délkou 1024B načtu 1024 znaků?

Tipuju to na proměnnou a

[faraon]

Nenačteš. Pojme jen to co se do ní vejde, ty následně zjistíš že to nestačilo, prodloužíš buffer a pokračuješ v načítání. Nebo zvolíš jinou strategii, podle potřeby.
Máš v tom prostě absolutní volnost, a také absolutní odpovědnost

[CZechBoY]

Ono jde zvětšit proměnnou "za běhu"?