Názory k článku Taky vám přetéká?

Preco musia vsetky dobre clanky o nejakom probleme vychadzat tyzden po tom ako na to pridem sam :)??????

Samozrejme tym neznizujem kvalitu clanku, fakt sa mi pacil.

naozaj velmi pekny clanok! clovek sa uci kazdym dnom a ja vol rad ked mam moznost sa nieco nove naucit

dakujem! a prajem vela zdaru do pisania takychto clankov

Jo presna takhle to dopada, kdyz se nedodrzuji zakladni zasady psani :-). Vim to z vlastni zkusenosti, samotneho me tyhle veci parkrat vypekly.

Takhle neeee ;-)
char b[8];
memcpy(b, "BBBBBBBBBBBB", 12);

nebo radeji

char b[8];
memcpy(b, "BBBBBBBBBBBB", sizeof(b));

nebo mozna jeste lepe

#define BUF_SIZE 8
char b[BUF_SIZE + 1];
memcpy(b, "BBBBBBBBBBBB", BUF_SIZE);

Petr

...nebo nejlepe ;-)

char b[]="BBBBBBBBBBBB";

Petr

Vychazel jsem z toho, ze delka stringu BBBBB je neznama v dobe prekladu (coz sice neni z prikladu zretelne), tedy neco jako
void test(char *data){
.. kde data je kyzene "BBBBBB"

:-))
Petr

Ja bych rek, ze tohle nejni totez, pac dostanu pointer na retezec v pameti (ten retezec bude ale bezne ulozen v casti pameti pouze pro cteni, tudiz to nebude presne to, co sme asi chteli ;-)

Ja bych rekl, ze to dela presne to, co bysme chteli. Problem je ale samozrejme v tom, ze ten priklad s kopirovanim stringu pevne delky neni moc prakticky a na kopirovani retezcu bych asi tezko pouzil memcpy. Reseni jsou podle me tri:

1. Pouzit neco jako strncpy

2. Pouzivat strdup nebo neco podobneho

3. Vykaslat se na char * uplne a bud pouzit nejakou tridu v C++ nebo mam pocit, ze glibc obsahuje taky nejakou podporu pro "vyssi" retezce. Kdysi tady o takovych vecech vychazel serial.

Ma nekdo jeste jine reseni?

glibc? Skoro... Je to glib. Glib ma typ GString ale v praxi sa pouziva len zjednodusenie prace s retazcami, ktore casto menia obsah / dlzku.

std::string

no s tim memcpy bych si takle nehral bejt tebou,
mas to jako retezec, toznamena ze ti musi koncit nulou
a tu tam nedavas
tedy by melo byt b[7] = '\0';
resp b [BUF_SIZE] = '\0';
jasne ze na retezce je lepsi pouzivat str fce (strcpy, strncpy),
akorat tusim ze to strncpy tam tu nulu na konec taky nedava
a zas mam pocit ze mem fce sou rychlejsi nez str fce

jenom o ten wrapper - memcpy() a str[n]cpy() jsou
prakticky ekvivalentni funkce, jenom memcpy "se
zastavi," kdyz narazi na '\0' nebo [v pripade
strncpy()] po okopirovani n znaku, a to tak, ze nejprve
ozkouma delku kopirovaneho retezce a potom zavola
memcpy(), takze primym volanim memcpy() cas neusetrite,
neb tu delku musite tak jako tak zjistit.

Copak o to clanek je to hezky.

Ale mohly se dat ukazky kodu resp. ilustrativni texty do <pre><code> resp. <pre><tt> mozna by pak vzrostla citelnost?

No jo, ja vim sem kafral. :)

Vazne pekne. Vzdycky jsem vedel, ze to "tak nejak" funguje, ale nikdy jsem si nedal praci si to takhle otestovat.
Tesim se na dalsi pokracovani.

...jen tak dal.

Suhlasim s ostatnymi...
Velmi pekny clanok!
Inak zaujimalo by ma, ci sa uz vacsina programov typu "demon" nepise v C++. Pri pouziti tried taketo problemy v znacnej miere odpadaju... Alebo je problemom
rychlost???

dufam, ze sa najde nejaky zasveteny, co ma pouci ;)

Je pravda, ze pokud na retezce pouzijete nejakou inteligentni tridu, je to neprustrelne, ale na druhe strane mnohem pomalejsi. Prece jenom - alokace libovolneho mista na zasobniku trva (mluvim ted opravdu pouze o alokaci) asi tak jednu strojovou instrukci: odecteni cisla od ukazatele zasobniku.
Vsechny inteligentni retezce pritom z principu museji pouzivat pametovou hromadu, coz v horsim pripade obnasi volani jadra - a uz jenom dispatch do jadra a zpet je alespon 100x vice strojovych instrukci.

Jeden muj kolega - pokud napr. sestavuje SQL dotazy, stale pouziva:

char sql_dotaz[200];
snprintf(sql_dotaz, sizeof(sql_dotaz), "SELECT %s FROM ...", szSelectovane_sloupce,...);

Vyhody: je to ta nejprenositelnejsi, nejsnaze citelna a (pokud nahradite snprintf nekolika strcpy() a strcat()) take vubec nejrychlejsi konstrukce, kterou muzete v programu pouzit - pokud ovsem mate nejak omezene delky retezcu, se kterymi pracujete.
Takze bych rekl, ze to neni jen o lenosti. Pokud se snazite psat multiplatformni kod, ktery bude rychly, jednoduchy a citelny, pak je to velmi elegantni reseni!

Samozrejme pracujete-li s retezci ve kterych muze byt 9-9999999 znaku, pak se dynamicke alokaci nevyhnete:-).

Printf&spol. ale maji taky pomerne velky overhead. Tedy alespon v implementaci, kterou jsme si ukazovali ve skole.

... nemluve o tom, ze valna vetsina system-level programatoru nemuze C++ pro jeho obludnost vystat.

Dobrou cestou pro psani daemonu a spol. je premyslet v C++ a psat plain C.

snprintf neni moc prenositelne, nebo se mylim?

tak docela dobra prace na tohle tema je zde: http://www.enseirb.fr/~glaume/bof/report.html

K certu s ceckem, napiste to v Ade B-) a mate po problemech ... krome problemu abyste to vubec v tom hroznym jazyce dokazali napsat :-)

Pro mene zkusene: Ada je jazyk navrzeny pro potreby letectva a NASA s durazem na bezpecnost tak velikym, ze neco jako tohle nepripada v uvahu (krome toho ale v tom kramu nejde ani temer nic jinyho, bezpecnyho a musi se cokoliv uzitecnyho importovat z cecka - takze vsechno je vlastne relativni)

A co haskell? Tam by se neco takoveho nemohlo stat. Typova bezpecnost, nemoznost takovychto preteceni, hezka 2D syntaxe. Co vic si muze clovek prat? ;)

Uplne nejlepsi to bude napsat v Simule! (Komentar je urcen zejmena pro priznivce katedry kybernetiky na FAV ZCU v Plzni :-))))) )

Nejlepsi je visual basic!