Nesnáším C++... ;-) (diskuse)

[Sinuhet]

Boze, boze...

Pretizeni operatoru [] je udelano takto kvuli tomu, ze std::vector ma modelovat plain pole z C. V C se [] nekontroluje, takze to same je i v STL. Kazdy to vi (a nebo to ma vedet), a proto pokud mu nezalezi na rychlosti, pouziva at, pokud naopak pozaduje maximalni vykon, ma tu [].

To mate z toho, ze nectete dokumentaci.

[paskma]

Bože, Bože...

No mě se tato logika právě nelíbí. Korektnost programu je pro mě důležitější než pár instrukcí navíc. Já bych operátor [] udělal tak, aby emuloval _funkčnost_ jeho obdoby z plain C, ne nutně i jeho nedostatky.

Dokumentaci čtu, ale tohle mě překvapilo, pane chytrej.

[VícNežNic]

A musí být vždy nedostatek, že se nekontrolují meze?

[VícNežNic]

I když, v tomhle případě, když o tom tak přemýšlím… se mi skoro zdá, že asi ano

[Luk]

To není chyba, to je vlastnost! Pokud mi na STL něco vadí, pak to rozhodně není tohle. Pokud přistupuji k prvkům kontejneru způsobem, který sám o sobě zaručuje, že se nemohu dostat mimo rozsah, nepotřebuji to znovu kontrolovat (a zbytečně se zdržovat). Pokud bych se mimo meze dostat mohl, použiju metodu at(), která kontrolu provádí. Nevidím na tom nic nelogického.

[paskma]

Jistě, že je to vlastnost, když je to popsáno v dokumentaci. Jde o to, jestli správná.

Pokud přistupuji k prvkům kontejneru způsobem, který sám o sobě zaručuje, že se nemohu dostat mimo rozsah, nepotřebuji to znovu kontrolovat (a zbytečně se zdržovat).

S tím zdržováním je to optimalizační fašismus. Optimalizace jako vypustit kontrolu mezí polí je dvacet let stará záležitost. Je mi líto, korektnost nade vše.

A jak víte, který způsob to sám o sobě zaručuje? To si ke každému programu děláte formální důkaz? Pokud nějaká kontrola je možná a je dostatečně levná, má být zaplá, protože normální programátoři jako já dělají chyby. Třeba:

for (unsigned i = myVector.size() -1; i <= 0; i--)
{
}

Selže, protože přeteče unsigned, když je kontejner prázdný. A které pako tam dalo unsigned? No já, protože

for (int i = 0; i < myVector.size(); i++)

hází warning na porovnávání znamínkových a neznamínkových typů, pač size() vrací unsigned. No a když pak náhodou chci předělat pořadí, chyba je na světě.

[Deleted [8409]]

Ja bych rekl, ze je spis dulezitejsi korektnost programatora, jak muzete cekat ze bude korektni program, kdyz bude spatne napsany? Jestlize pristupuji do pole za hranice nebo pred, je neco spatne.

co takhle:

uint i;
uint count = myVector.size();

for (i = count - 1; i != uint(-1); i--) {}

nebo

for (i = 0; i != count; i++) {}

Ani jeden pripad neselze, je to tak tezke pochopit?

Nekdy je proste vyhodne pouzit neznamenkove integery.

[paskma]

Když už udělám chybu, tak chci (pokud je to možné) rozumnou reakci a ne aby mi to ustřelilo nohu

for (uint i = count - 1; i != uint(-1); i--) {}

Nezlobte se na mě, ale tohle považuji za hackerství. Triky nebrat.

[#Tom]

var
  I: Word;
begin
  for I := Count - 1 downto 0 do
  begin
    { něco }
  end;
end;

[Deleted [8409]]

Myslim ze kod, ktery jsem napsal je dostatecne pochopitelny a neustreli nohu nikomu. Pokud si na takove programatorske urovni, ze si nejsi schopny uhlidat pole, tak pouzij vyssi programovaci jazyk, nebo si napis svou vlastni tridu, kterou budes kontrolovat.

Kod potom bude vypadat nejak takto:

char array[100];
uint i;
uint count = sizeof(array) / sizeof(array[0]);

for (i = 0; i != count; i++) {
  if (i < count) array[i] ... neco;
}

neznamenkove by to mohlo vypadat treba takto:

char array[100];
int i;
int count = sizeof(array) / sizeof(array[0]);

for (i = 0; i != count; i++) {
  if (i >= 0 && i < count) array[i] ... neco;
}

jestli se ti to libi tak to pouzivej, ale kdyby takto byla naprogramovana kazda aplikace tak se daleko nedostanem.

[elviin]

Lepe je pouzit nasledujici konstruce. Je to prehlednejsi, muzu menit kontejner z jednoho mista, vyznam promennych jasny.

    typedef vector<int>         vector_t;
    typedef vector_t::size_type vec_size;
    
    vector_t vec;
   
    ...
    ..
   
    vec_size count = vec.size();
    ...
    ..

Jinak nemam pochopeni pro autora blogu. Necetl jste dokumentaci a navic si stezujete. K tomu jsem taky nachylny. Je lepsi pred zapisem do blogu hledat problem mezi zidli a klavesnici:)

[machr]

	std::vector<int> x;

	// ....

	int c = x.size();
	int* t = &x[c-1];
	for(int i = c; i; i--, t--) {
		printf("%d\n", *t);
	}

... a jede to krasne bez zbytecnejch kontrol, bez varovani a bez chyb...

PS: pokud nekdo propaguje kontrolu mezi poli, tak by mel zemrit na mucidlech

[elviin]

Nemyslim si, ze to je to pravy vorechovy. Co kdyz bude nahodou, ale jenom nahodou vektor prazdny. Navic popirate to, k cemu kontejnery slouzi: typ prvku uz znate. Ve vasem pripade bude kdokoliv muset prohlizet cely kod, aby ho updatoval. Konverzi velikosti kontejneru na int muzeme prijit k urazu. Ale jak pisete, asi vam to vzdycky projde:/

    vector_t::iterator      first =  vec.begin();
    const vector_t::iterator last =  vec.end();

    while(first != last)
        cout << *first++ << endl;

[machr]

> Co kdyz bude nahodou, ale jenom nahodou vektor prazdny.

- tak t bude neplatny ukazatel. To ale nevadi, protoze se stejne nepouzije...

> Konverzi velikosti kontejneru na int muzeme prijit k urazu.

To jako kdyby v nem bylo vic nez 2**31 polozek ????

> Ale jak pisete, asi vam to vzdycky projde:/

jj. a sem presvedcenej, ze muj zpusob je rychlejsi...

[paskma]

Rychlejší! No to nás všechny trápí. Vy asi programujete pro nějaký mikročip s taktem 4 kHz...

[machr]

ne, ale to neznamena, ze by se melo zbytecne plytvat vykonem. Pristup k poli casto byva v nejvnitrnejsim cyklu a pokud ho 10x zpomalis, tak vysledek proste nemuze byt dobrej.

Kdyz si tohle rekne kazdej programator, tak se pak clovek nestaci divit, kolik jsou dnestni programy schopny sezrat pameti a vykonu....

[machr]

ne, ale to neznamena, ze by se melo zbytecne plytvat vykonem. Pristup k poli casto byva v nejvnitrnejsim cyklu a pokud ho 10x zpomalis, tak vysledek proste nemuze byt dobrej.

Kdyz si tohle rekne kazdej programator, tak se pak clovek nestaci divit, kolik jsou dnestni programy schopny sezrat pameti a vykonu....

[elviin]

> Co kdyz bude nahodou, ale jenom nahodou vektor prazdny?
- tak t bude neplatny ukazatel. To ale nevadi, protoze se stejne nepouzije...

Tak mi trochu pomozte. Rikate, neplatny ukazatel nevadi, resp. kdyz

	int c = x.size();
	int* t = &x[c-1];

c bude 0, tak volani &x[-1] asi nevyjde nebo ano?

> Konverzi velikosti kontejneru na int muzeme prijit k urazu.
To jako kdyby v nem bylo vic nez 2**31 polozek ????

Z principu. Proc proste nepouzit vector<int>::size_type, ktery se pouziva i pri kontrole mezi u at()?

[machr]

t = &x[-1] vyjde. Prvek se totiz necte, jen se zjisti jeho ukazatel. Klidne to vyzkousej. samozrejme nesmis pouzit *t ...

> Z principu. Proc proste nepouzit vector<int>::size_type, ktery se pouziva i pri kontrole mezi u at()?

nechapu kde je problem. A abych se priznal tak moc nemam rad tyhle typy jako size_t, size_type a tak podobne. Proc proste nepouzit int?

[machr]

abych jeste upresnil, jaktoze to vyjde. uvnitr je to delany priblizne nejak takhle:

        int & operator [] (int index) {
                return pole[index];
        }

pokud neni ve vektoru zadnej prvek, tak pole je pravdepodobne NULL. To ale nevadi, protoze navratovej typ funkce je int &. Takze se z pole nic necte, ale vrati se adresa pole + index. V nasem pripade 0 - sizeof(int) , coz je sice neplatna adresa, ale nicemu to nevadi, protoze ji stejne nepouzijem...

[machr]

navic. ted sem si vsiml. to prochazis smerem dopredu, ale v puvodnim prispevku slo (pokud si pamatuju) o prochazeni pozpatku

[Sinuhet]

Nac tak slozite, tohle je priklad na jednu radku:

std::copy(x.begin(), x.end(), std::ostream_iterator<int>(std::cout, "\n"));

[Sinuhet]

Pardon, ono se to tam ma cpat v obracen poradi.

std::copy(x.rbegin(), x.rend(), std::ostream_iterator<intgt;(std::cout, "\n"));

[Deleted [8409]]

Nejsem si tak jistý tou rychlostí, zkuste si zkompilovat nasledujici benchmark, zhotovil jsem ho asi pred mesicem, dnes trosku upravil pro nase ucely.

Nezapomente si zvolit spravnou optimalizaci, tedy -O3 a nekdo muze zkusit jeste -funroll-loops nebo -funroll-all-loops

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

typedef unsigned long long uint64;
typedef unsigned int uint;

static __inline__ uint64 rdtsc(void)
{
	uint64 x;
	__asm__ volatile (".byte 0x0f, 0x31" : "=A" (x));
	return x;
}

#define SIZE (1024*16)
#define OUTER_LOOP_SIZE (1024*256)

/*
 * Benchmark optimalizace smycky
 */
int main(int argc, char *argv[])
{
	uint tmp = 0;

	uint a;
	uint x;

	char *str = (char *)malloc(SIZE);
	char *ptr;
	uint64 t;

	if (!str) return EXIT_FAILURE;

	t = rdtsc();
	for (a = OUTER_LOOP_SIZE; a; a--) /* Velky cyklus, neni co optimalizovat */
	{
		/* maly cyklus, uvidime */
		ptr = str;
		for (x = 0; x != SIZE; x++) {
			tmp += ptr[x];
		}
	}
	t = rdtsc() - t;
	printf("Test pro pristup pres index pole: %llu cycles\n", t);

	t = rdtsc();
	for (a = OUTER_LOOP_SIZE; a; a--) /* Velky cyklus, neni co optimalizovat */
	{
		/* maly cyklus, uvidime */
		ptr = str;
		for (x = 0; x != SIZE; x++) {
			tmp += *ptr++;
		}
	}
	t = rdtsc() - t;
	printf("Test pro pristup pres pointery: %llu cycles\n", t);

	printf("\n\nVypiseme tmp, protoze kompiler by mohl smycky vypustit %u\n", tmp);

	free(str);
	return EXIT_SUCCESS;
}

[machr]

zajimavy. a jeste zajimavejsi je, ze pokud prohodim poradi provadeni testu (nejdriv pres pointery a potom pres index), tak to vyjde naopak...

dalsi zajimava vec je, ze se to o nekolik procent zrychlilo nahrazenim podminky != za < ...

nechtel bych podcenovat optimalizator gcc, ale tenhle tenhle test je podle me dost specificka situace - malej cyklus, kterej je mozno rozvinout. Navic i v pripade pristupu pres index se pracuje s ukazatelem - s cimz bych si u pristupu k trude vektor nebyl tak jistej...

[Deleted [8409]]

Čtu si reakci az teď, je to sice už outdated, ale vím proč se neliší výsledek testu když se pořadí testu přehodí, myslel jsem že 16MB je dost velký buffer, ale i v nasem pripade ma na test vliv cache procesoru. Abych to upřesnil, nechtěl jsem právě tento vliv.

Pokud má někdo opravdu zájem udělat si vlastí test rychlosti, asi bych doporučil pole, které se vleze do cache a pak už bude měřit opravdu rychlost kódu vygenerovaného kompilérem, protože přístup do RAM mimo cache ovlivní test jak jsme si mohli všimnout.

Jinak děkuji za upozornění na '!=' a '<', je to zajímavé a nenapadlo by mě ani ve snu, že by mohl gcc vygenerovat lepší kód.

[Sinuhet]

Korektnost programu je pro mě důležitější než pár instrukcí navíc.

Pokud pozadujete kontrolu, tak pouzivejte at - jak proste :).

Já bych operátor [] udělal tak, aby emuloval _funkčnost_ jeho obdoby z plain C, ne nutně i jeho nedostatky.

Nic vam nebrani v tom, abyste si s vyuzitim standardniho vytvoril vlastni, patricne upraveny kontejner.

Predstavte si, ze existuji exoti, kteri to nepovazuji za nedostatek, ale za vyhodu.

[paskma]

Nic mi nebrání napsat si svůj jazyk s vlastními knihovnami. Jenže já chci standardní univerzální řešení zadarmo a s co nejmíň nedostatky

[Sinuhet]

Nebyla rec o psani nove knihovny, nebo cele nove implementace vektoru.

[Michal Vyskočil]

Myslím, že samotný Bjarne Stroustrup řekl, že zatímco v C se můžete říznout do prstu, v C++ si můžete ustřelit rovnou celou nohu

[Michal Vyskočil]

Achjo, kdybych si nadpis "Nesnáším XXX" patentoval, mohl jsem být milionář

[VícNežNic]

Pak bych v ilegalitě sepisoval pamflety "Nesnáším Michala Vyskočila"

[Michal Vyskočil]

Moji právníci by si tě už našli

[Marek Bernát]

Žiadny problém. Máš fantastickú Javu, kde stringy môžeš indexovať pomocou chatAt() a všetky výnimky sú ošetrené. Nech sa páči.

Nám smrteľníkom nechaj škaredé C++, ktoré sa nikdy nespráva, tak ako má a padá na každom kroku. Díky.

[Luk]

C++ se opravdu někdy nechová, jak má. Ale za to může kompilátor, ne jazyk. A i když mi některé věci v STL nesedí, netvrdím, že je horší (ale ani lepší) než podobné věci v Javě.

[VícNežNic]

I v úžasné Javě se občas dějí zajímavé věci Třeba tu.

This method is public as an implementation side effect. do not call or override.

[Marek Bernát]

Ja mám na C++ veľmi zvláštny pohľad. Je to totiž prvý normálny jazyk, v ktorom som sa naučil robiť. Takže je to určitá zmes nostalgie a takisto aj dlhodobá skúsenosť. Ale medzičasom som videl už asi desať iných jazykov a pochopil som, že STL a niektoré ďalšie fičúrky sú len dolepené a to tak, že nie moc dobre.

Proste C++ to nemá ľahké. Je to niečo medzi C a objektovými jazykmi. Preto ho céčkari, ani javisti nemôžu mať radi. Ich vec.

No a pre mňa je to proste staré dobré C++. Neriešim to. Programuje sa mi v ňom dobre a to mi stačí

[paskma]

Samozřejmě, že mám Javu a C#. Jenomže tenhle projekt má nějaký legacy kód v plain C a C++ je pak cesta nejmenšího odporu.

[Marek Bernát]

Ako kedy. Ak ti C++ vadí príliš, tak by si mohol zauvažovať nad wrapperrom toho legacy kódu do Javy. Ale zrejme ti až tak nevadí

[Miloslav Ponkrác]

Pan paskma jakožto neúnavný hanič C++ ) Ok, nahodím udičku. Já mám verzi STL, která nejenže všechno hlídá a vyhazuje výjimky, ale kontroluje skutečně každou blbost. Takže přístup mimo rozsah pole u vectoru? Okamžitě výjimka. Použiji neplatný iterátor, je výjimka. Použiji iterátor na jiný objekt, než je platné, a šup výjimka. Já si na své STL nestěžuju...

Já asi napíšu zápis Miluju C++, protože C++ je jazyk, který považuji za nejlepší staticky typovaný kompilovaný jazyk, se kterým jsem se kdy setkal.

[Marek Bernát]

Já asi napíšu zápis Miluju C++, protože C++ je jazyk, který považuji za nejlepší staticky typovaný kompilovaný jazyk, se kterým jsem se kdy setkal.

Neviem, či toto mal byť vtip, ale ak nie, tak si pozri haskell. Je to najlepší staticky typovaný kompilovaný jazyk, s ktorým som sa stretol

[Miloslav Ponkrác]

No tak nevím, Haskell zrovna nemusím, opravdu ne.

Ona je taky otázka co u Haskellu znamená kompilovaný jazyk. Teoreticky zkompilovat se dá úplně všechno, naprosto každý jazyk do čehokoliv, ale já s C++ měl na mysli jazyk, který je prostě přímo dělaný na to, že z něj vyleze stroják a výsledná rychlost a efektivita kódu tomu odpovídá.

Možná jsem měl ještě napsat, že C++ považuji za nejlepší staticky typovaný, imperativní jazyk efektivně kompilovatelný do nativního kódu.

Ona je taky otázka, jestli v případě funkcionálního jazyka bych si vybral zrovna Haskell, ale to už je trochu off topic takže to nebudu rozvíjet.

[Marek Bernát]

No napríklad z GHC vylieza natívny kód. Dokonca vie kompilovať aj do C. A ten kód je navyše veľmi rýchly vo väčšine prípadov, pretože matici si za posledných 50 rokov dali dosť roboty s optimalizáciou. Ale máte pravdu, neviem ani ja, či nie sú ešte rýchlejšie funkcionálne jazyky.

Ale ak máte na mysli imperatívny jazyk, tak potom súhlasím

[paskma]

Abych pravdu řekl, nepátral jsem po tom, jetli mnou kritizované chování je předepsáno standardem nebo je to jen záležitost stdlibc.

Jakou používáte implementaci STL? Tu od SGI?

[elviin]

Reseni neni hledat tu spravnou implementaci, kde to delaji, tak "jak to vyhovuje memu zpusobu programovani". Co prenositelnost? Ale precist si dokumentaci. Chovani [] pri prekroceni mezi neni definovane. Tzn. ze kontrola muze byt provadena, ale nemusi.

Ze standardu je to proste nedefinovane, a tak by se mel clovek k tomu postavit.

[Sinuhet]

Pan Ponkrac ma zrejme na mysli specialni debugovaci verzi STL. Neco takoveho je treba k nalezeni u g++.