Inicializace dynamického pole v C++

12.9.2007 09:06 | Přečteno: 18420× | Programování | poslední úprava: 12.9.2007 11:08

Blíží se nám nový standard C++, který by měl přinést spoustu novinek a také odstranit některé otravné nepříjemnosti. Jednou z novinek je zavedení jednotné syntaxe pro inicializátory. Tohle mně inspirovalo k zamyšlení zda by nešlo v současném C++ udělat docela často potřebovanou věc, incializace dynamických polí hodnotou.

Starý a špatný způsob

Když vytvoříte v C++ dynamické pole, musíte ho pak inicializovat prvek po prvku. Tudíž aktuální kód by mohl vypadat nějak takhle.

int * pole = new int[10];
for (int i = 0; i < 10; i++)
{
    pole[i] = i;
}

I když tento kód vypadá naprosto v pořádku má jednu fatální vadu. Pokud budeme inicializovat pole objektů, musí mít daná třída defaultní konstruktor. To ale může být větším problémem než se může na první pohled zdát. Každý objekt totiž má svůj interní stav a kvůli možnosti vytvářet pole objektů musíme přidat stav vytvořen-ale-neinicializován, což může být (hlavně pokud jde o externí kód) nepřekonatelný problém.

Řešení

S myšlenkou že v C++ jde naprogramovat všechno, jsem si sedl ke Googlu a hledal. Naštěstí jsem už dopředu věděl co vlastně hledám, jelikož jsem na potřebný kód narazil už dříve (v jiném kontextu). I přesto mi hledání (pravděpodobně díky mé nekonečné blbosti) trvalo několik hodin, nicméně výsledek stál za to.

Základem celé myšlenky je málo známá varianta operátoru new. Operátor new totiž umožňuje totiž specifikovat paměťové místo kde má daný objekt inicializovat. Opravená verze výše uvedeného kódu, bude pak vypadat nějak takhle.

NaseTrida * pole = malloc(sizeof(NaseTrida)*10);
for (int i = 0; i < 10; i++)
{
    new(&pole[i]) NaseTrida(i);
}

Pozor si pak musíme dávat při uvolňování alokovaných objektů. Musíme jim explicitně zavolat destruktor a pak uvolnit paměťový blok pomocí free.

Objektový obal

Protože základní programátorskou poučkou programátora C++ je psát malé jednoúčelové zapouzdřené kusy kódu, tady je relativně primitivní objektový obal pro výše uvedený kód. Třída používá moje vlastní asserce, které jsou trochu více popisné než ty standardní. Rozhodně nezaručuji ze je třída na 100% funkční, nicméně zatím jsem nenarazil na žádný problém.

Obal poskytuje dvě metody pro předávání parametrů. Jedna předává všem třídám stejnou hodnotu, druhá je inicializace polem hodnot.

EDIT 12.9. 11:05 Kód přesunut do samostatného obarveného souboru: VariableArray.html

       

Komentáře

[Josef Kufner]

Každej normální člověk by udělal pole pointerů na objekty a když objekt není, tak tam je NULL.

[Let_Me_Be]

Eh co? Cetl si to vubec? Nemluve o tom ze sahat na neco pres dva pointery je rozhodne pomalejsi nez pres jeden.

[Josef Kufner]

Četl jsem to jen po nadpis "Řešení", pak mě to přestalo bavit a ten chuchvalec nepřehledného kódu bez jediného komentáře už jsem ani neprohlížel.

Dereferencovat o pointer navíc je sice o chlup pomalejší (záleží na situaci, většinou to stejně nevadí nebo se to dá obejít), ale když vidím kolik balastu tam natáhneš jen kvůli tomu, aby jsi tohle ušetřil... Je to krásná ukázka toho, jak C++ vede k nepřiměřeně nakynutým programům

[Let_Me_Be]

No ocividne si to necetl ani po ten nadpis. Radis totiz naprostou blbost, ktera s problemem nema vubec nic spolecneho. Jde o vytvareni poli objektu, kterych trida nema defaultni konstruktor a ne vytvarni sparse poli.

Ten balast je kompletni objektovy obal s kontrolou sahani mimo vytvorene indexy a kopirovani neinicializovanych poli. Kdyz se vypne podpora asserci smrskne se vetsina metod na jediny return prikaz. Jelikoz se vetsina metod inlinuje nema takovy objektovy obal na vyslednou binarku zadny vliv (to je krasa C++). Komentovat metody, u kterych je primo z nazvu jasne co delaji je blbost a ztrata casu.

Si krasna ukazka cloveka, ktery ma potrebu vyjadrovat se ke vsemu i kdyz ocividne nicemu nerozumi. Pristup pres pointer je naprosto neporovnatelne pomalejsi nez primy pristup, pro procesor to misto jedne instrukce predstavuje vykonani 3-5 instrukci.

Jen tak mimochodem tvoje paticka je out-of-date. V soucasne vypise glibc chybu: *** glibc detected *** ./a.out: free(): invalid pointer: 0x000000000040061c ***

[Josef Kufner]

To že se to po vypnutí assercí smrskne a nemá to na výslednou binárku žádný vliv je sice hezké, ale pořád to nemění nic na tom, že ten, kdo bude ten program používat/opravovat, se musí prohrabat tímhle svinčíkem. Když je to jen jedna třída/šablona, tak to vypadá celkem směšně, ale představ si, že takovýchle věcí bude ve výsledném programu pár desítek nebo i stovek a s mírou dokumentace, kterou jsi v kódu zanechal... Není to nepřekonatelný problém, ale bude to stát zbytečně moc času.

[elviin]

Nevim, jestli kod je spravne. Kdyz uz mluvite o svinciku, tak to prosim nejak dolozte. Je nekde mensi svincik? Jak byste si to predstavoval Vy?

[deda.jabko]

je fakt, ze ten kod neni opravdu z nejhezcich resp. nejuhlednejsich... nechce se me louskat jestli opravdu dela to co ma a jestli by to neslo napsat lip...

minimalne se me _osobne_ nelibi -- pouzivani identifikatoru zacinajicich podtrzitky... nekonzistence v pouzivani slozenych zavorek (jednou jsou obe zavorky najednom radku vcetne vyrazu, jindy ma kazda zavorka svuj radek), nebo nedodrzovani stejnych konvenci mezi operatory (jendou je pouzito 'a=b' jindy zase 'a != b')

[Let_Me_Be]

Njn, tak to dopada kdyz clovek zverejni interni kus kodu :) Podtrzitka si nenecham vzit, ale zbytek si vezmu k srdci.

[zde]

Po kouknutí na "řešení" jsem běžel zkontrolovat kalendář.

[Miloslav Ponkrác]

Proč se mixuje malloc a new? K čemu je to dobré? Chápu, když se používá jenom malloc/free a chápu, když se používá jenom new/delete. Ale jaký je důvod naalokovat paměť pro dynamické pole pomocí malloc namísto new a pak pomocí positionable new zkonstruovat objekt.

Aby nedošlo k nedorozumění tu dvoukrokovou konstrukci s positionable new chápu - je tu nutná a účelná. Ale nechápu proč samotná dynamická paměť používá malloc. Vždyť je pak daleko větší pravděpodobnost, že se seknete a to co bylo alokováno pomocí new někde uvolníte pomocí free a co bylo alokováno pomocí malloc se pokusíte uvolnit pomoc delete, nebo delete[], což se samozřejmě nesmí a obecně z toho může být velmi zapeklitá a těžko hledatelná chyba.

[Deleted [8409]]

V kodu se nemixuje malloc a new. Pouziva malloc k alokovani pole a new k vytvoreni instance. Ja osobne to delam taky tak a nevidim v tom problem.

[Miloslav Ponkrác]

A k čemu je to dobré to takto dělat?

[Deleted [8409]]

Treba kdyz je potreba realokace toho pole pro moveable instance.

[Miloslav Ponkrác]

Pokud v poli zkonstruujete objekty, jako je tomu v tomto případě, pak obecně je realokace nezaručenou operací, která velmi často končí krachem. Nelze jen tak obecně přesunovat objekty po paměťových lokacích, protože to taky může špatně dopadnout.

Jasan, že lze, pokud znáte vnitřní strukturu a implementaci třídy za jistých okolností si dovolit přesunout instanci na jinou paměťovou lokaci, ale to pak dáváme OOP a "zapouzdření" a dalším OOP věcech pěkně na prdel a posunujeme se s měrem úplně jinam.

Takže Váš argument nepovažuji za akceptovatený.

[Deleted [8409]]

moveable instance

[Miloslav Ponkrác]

Moveable instance a co? Pokud si chcete udělat ze zdrojového kódu prasečinu, guláš, špagety a bordel nejhrubšího zrna, pak si zahrávejte s takovými věcmi. Obecně instance moveable nejsou a nemusí být a pokud si hrajete na moveable instance, pak se pohybujete někde na úrovni strojového kódu a nechápu, proč používáte OOP.

[Deleted [8409]]

Cha cha cha. Pak Ponkrác se opět projevil.

Moveable instance není v C++ nijak neobvyklá věc, tak si tady nehrajte na hrdinu.

[Deleted [8409]]

Pak -> Pan

[Miloslav Ponkrác]

Ano, přiznám se, že programuji v C++ jen asi od roku 1991 a po většinu času jen asi 10 hodin denně. Uznávám, je to málo a asi nemám zkušenosti.

Ale moveable instance je věc, kterou jsem nikde neviděl, nepočítám-li prasárnu v Ultimate++. A rozumný člověk si do programu nezavádí věci, které mu přinášejí nekontrolovatelné závislosti do programu.

Znovu opakuji, že objekty nejsou a nebyly stvořeny k tomu, aby měnily adresu v paměti - tato technika nemá oporu v normě C++ a je spíše hackovací technikou, než něčím, co by se mělo normálně používat.

Ještě jinak: V normálním progrmaování je poměrně dost místa a prostoru na to, jak si tam zavléci nevědomky chybu, ale nechápu proč bych si měl situaci ještě přitěžovat.

[Deleted [8409]]

Moveable instance jsou i v Qt.

Nevidím problém v tom, že programátor označí nějakou třídu jako 'moveable' a pomocí částečné specializace šablon se udělá optimalizace pro tento typ (řekl bych že právě toto je motivace).

Asi by jste měl definovat, co to podle vás ten objekt je? Třeba toto?

struct Point { int x, y; }

Některé třídy (struktury) jsou přímo stvořeny k tomu, aby se přesouvaly s místa na místo, tak tady netvrďte bláboly. Dokonce i třída s virtualní tabulkou funkcí se takto muže přesouvat.

[Miloslav Ponkrác]

Rozlišujme objekty a struktury, i když v C++ se to nerozlišuje na úrovni klíčových slov. Aby nedošlo k mýlce, normální OOP a objekty je případ, kdy používám "encapsulation", a kdy prostě deklaruji, že k objektu přistupuji jako k černé skříňce přes jeho interface. Pokud si hraju s pamětí pomocí struktur o nic nejde, ale to není čisté OOP.

To, že se třída s virtuální tabulkou funkcí může přesouvat není důvodem, proč to takto dělat. Všimněte si, že v C++, ani ve standardní knihovně C++, či v jazyku není tato technika nikde použita, ani používána. Ani v dalším návrhu normy se o to nikdo nepokoušel. Dokonce ve "sborníku" nejlepších C++ knihoven tvořeném kovanými C++ programátory zvaném boost se tato technika nikde nevyskytuje. Lépe už Vám neumím naznačit, že u čistých objektů to má větší nevýhody, než výhody.

Jinak profesionální programátoři v C++ nijak nemají tendenci označovat třídy za moveable, protože je to hackerská technika. Zkusím z jiného soudku, ano já si taky vyzkoušel leccos. Například jsem kdysi za chodu měnil objektům virtuální tabulku a dělal z nich instance úplně jiné třídy, než se kterou byly zkompilovány. Ale to je taktéž hackerská technika, a přestože to jde, a přestože to bylo i použito, nikdo se nesnaží to využívat v normálních C++ zdrojových kódech. A je to tak správně, protože nikdo nestojí o záludné zbytečné chyby.

[Deleted [8409]]

Ano rozlišujme, ale jak? Třída je taky jen struktura no ne? Někdy nemůžete ani strukturu jen tak kopírovat nebo přesouvat v paměti, takže je tu naprosto zbytečné rozlišovat jestli jde o strukturu nebo třídu (ono je to pro C++ překladač stejně to samé).

To s tou virtuální tabulkou byl jen příklad, nemusíte se toho tak chytat. Mimochodem je docela běžné, když se v nějaké instanci mění ukazatel na funkce dle potřeby (backend) a toto bych právě přirovnal k té virtuální tabulce funkcí (stačí se na to podívat trošičku více z low level pohledu)

Jak už tady bylo někde zmíněno, C++ je prostě high level jazyk, který umožňuje dělat low level věci. A řekněmě si narovinu, že pokud chceme opravdu velmi rychlý kód (z nějakého důvodu), tak optimalizace nikdy nevypadají pěkně a nikdy nejsou příliš čitelné.

Nevím podle čeho se pozná opravdu profesionální programátor. Dělá rychlý kód? Čitelný kód? Dělá rychle? Pomalu? Dělá chyby? Programuje 10 hodin denně? Nebo mu stačí 5? Dokumentuje více? Nebo méně? Používá šablonu na každou blbost? Používá boost? (tím chci říct jen to, že každý programátor se hodí na něco jiného a těžko soudit)

[Miloslav Ponkrác]

Ok, se rozlišování struktur a objektů jsem zejména v C++ na hodně tenkém ledě.

S čím se shodnu je fakt, že optimalizace na brutální rychlost opravdu vypadají velmi ošklivě - prostě požadavek maximální rychlosti ničí vše hezké ve zdrojovém kódu. Nicméně tento požadavek je tak minimálně zřídkavý, že většina programátorů se s ním za celý programátorský život ani nesetká. Právě proto mi přijde prosazování hackerských low level technik jako zavádění si zbytečných problémů snížením spolehlivosti a zvýšeným množstvím chyb v programu, které nutně tyto hackerské techniky provázejí.

Profesionální programátor se pozná podle toho, že je schopen udělat co je potřeba efektivní metodou. Pokud je potřeba rychlý kód, dělá rychlý kód. Pokud je potřeba maximálně čistý kód, dělá ten. Používá šablony tam, kde jsou nejlepším řešením. Atd..

[Miloslav Ponkrác]

Jinak bych ještě podotknul, že Qt není čistý C++ zdrojový kód, takže se o něm nebavme při řešení C++ věcí.

[Deleted [8409]]

Movable v Qt nemá s MOC ani UIC co dělat. Mimochodem bych neřekl, že to není čisté C++, ty nástroje jen vygenerují jednu virtuální a jednu statickou metodu a pak se to dá zkompilovat obyčejným C++ překladačem.

Ale to hodně odbočujeme od tématu a dále bych to neřešil

[Luboš Luňák]

Jisteze je. Jak by to jinak GCC dokazalo primo prelozit?

[Miloslav Ponkrác]

Ano i bez preprocesoru moc Ne, Qt není čistý C++ kód, potřebuje speciální preprocesor, kterým se některé věci přechroustají.

Tím dál na Qt nebudu reagovat - Qt pro mě není čistá C++ knihovna. To už můžu argumentovat, že Pascalovský zdroják je C++, protože existuje preprocesor PasToC, s pomocí kterého ho přeloží g++. A taky znám preprocesor CobolToC, takže i Cobol je C++ zdroják, protože ho přeloží g++.

[Michal Kubeček]

Jak se díváte třeba na Borlandí C++ překladače, které si zavádějí vlastní jazykové konstrukce? Musím se přiznat, že jakkoli se takové properties příjemně používají, osobně mi tento přístup docela vadí.

[Miloslav Ponkrác]

Nijak. Borland C++ to udělat musel, protože potřeboval být kompatibilní se svým Pascal překladačem i na binární úrovni. Ale Borland C++ se snažil vyhovět normě s extenzemi. Ale jinak bych se vůbec nezlobil, kdyby borlanďácké properties byly v normě C++ a v každém překladači, je to IMHO velmi příjemná a skvělá věc.

Stejně tak se mohu třeba dívat na vlastní rozšíření gcc, kterých je mnoho. Gcc si také zavádí vlastní jazykové konstrukce a dokonce mám pocit, že třeba linuxové jádro je na nich tak závislé, že jej snad ani jiným překladačem vyhovujícím plně C normě přeložit nejde. To je úplně stejná situace jako u Borlandu. (Pokud se mýlím, opravte mě.)

[Michal Kubeček]

Souhlasím, že pokud by properties byly součástí normy C++, bylo by to fajn. Co se mi nelíbí, je spíš to používání věcí, které v normě (zatím?) nejsou, protože to svádí k tvorbě nepřenositelného software. Podle mne hlavní důvod, proč pod Windows není tak populární open source, není zdaleka jen v nižší technické zdatnosti typického uživatele, ale hlavně v tom, že když budete mít MSVC, zdrojáky projektu psaného v C++ Builderu vám moc platné nebudou (a naopak), zatímco když si stáhnete typický unixový open source projekt, s pomocí autoconfu ho přeložíte na většině běžně se vyskytujících unixových platforem.

[Miloslav Ponkrác]

Ano, mě by se také moc líbilo, kdyby programy byly nezávislé na překladači a šly běžně přeložit libovolným C++ překladačem vyhovujícím ISO C++ normě.

Osobně si nemyslím, že pod Windows není open source populární. Jen se tam neprojevuje GPL fanatismus. Důvodem, proč se u Windows tolik nezdůrazňuje open source je ten, že binární instalace programů nejsou ve světě Windows problém, zatímco u Linuxu to problém je - vzhledem k množství a různorodosti distribucí.

Mohu dokonce přihodit svůj postřeh - pokud je něco u Windows open source, je to většinou (po právní stránce) méně problematické, než u Linuxu. Protože u Linuxu je velmi často podmínka "používej zdrojáky, ale jen pokud ..." (různé GPL lincence apod..), u Windows je v open source často podmínka jen "dělejte si s tím co chcete, ale neručím za žádné škody". Velmi běžná licence u Windows věcí je "public domain" - tedy absolutní volnost.

Tím samozřejmě nevyvracím, že pod Windows je méně programů open source, než u Linuxu.

Jinak abych se vrátil k hlavnímu tématu, problém závislosti na překladači je jak ve světě Windows, tak ve světě Linuxu. Mnoho zdrojových kódu je "gcc/g++ only", věc jde dokonce tak daleko, že spousta lidí tady v linuxové komunitě nedokáže vůbec pochopit rozdíl mezi "jazykem C++" a "g++ kompilátorem", takže se pravidelně objevují kritiky jazyka C++, nebo STL knihovny argumentované vlastnostmi g++ kompilátoru.

Ve světě Windows je zase spousta věcí "Microsoft Visual Studio only", takže je to stejná situace v bleděmodrém. Problém je, že prostě ani jiný kompilátor nevyužijete, protože třeba gcc/g++ pro Windows nemá podporu mnoha potřebných věcí používaných ve Windows, jako je třeba SEH (Structured Exception Handling), podporu COM technologie a mnoha dalších, takže většina lidí stejně jako já nakonec gcc/g++ pro Windows opustí a začne používat MS Visual Studio.

Takže závěr: Naprostá většina programátorů celý život kuchtí v jednom jediném překladači a často ani netuší, že používají věci, které nejsou v normě C++, a že používají věci, také v jiném kompilátoru nepůjdou. A v tom bych viděl příčinu. Pokud by lidé přeskakovali alespoň mezi dvěma kompilátory na dvou různých platformách, automaticky by psali kód přenositelnější. Tohle je ale stav, který se sotva změní.

Stejně tak autoři kompilátorů vždy do každého kompilátoru nacpou haldu rozšíření nad rámec normy jazyka - a je jedno jestli mluvíme o gcc/g++, nebo o Microsoft překladači, o Intel překladači, nebo jiném. Takže pokušení použít nestandardní věci jsou veliká. A tohle se také nezmění.

[Mirek Fidler]

Jakou nekontrolovatelnou zavislost do programu zavadi U++ Moveable?

[zde]

Žádnou, samozřejmě. Pan Kubeček má prostě k C++ takový zvláštní vztah- nevadí mu POUZE ty obskurní vlastnosti, které shodou okolností používá. Vše ostatní je fuj a evil. .-)

[Let_Me_Be]

Ted jsem z toho jelen, jak jde udelat pomoci new alokace raw bloku pameti? Nebo pole, bez toho aby se volaly konstruktory objektu.

[Sinuhet]

char* buffer = new char[10];?

[Let_Me_Be]

No, to ale provede naprosto zbytecne nulovani pameti, coz je dost pomala operace.

[Miloslav Ponkrác]

Odkdy to nuluje paměť?

[Sinuhet]

Na to jste prisel jak?

[Michal Kubeček]

Nejspíš si neuvědomil rozdíl mezi objekty a POD typy.

[Let_Me_Be]

No, pokud vim tak pri pouziti new by se meli hodnoty inicializovat na defaultni hodnotu nezavisle na tom jestli jde o objekt nebo zakladni typ.

[Miloslav Ponkrác]

A proč by se to jako mělo dít? Nebo kde jste to sebral?

[Michal Kubeček]

Hm… Tak jsem se díval do specifikace a jestli to dobře chápu, opravdu by se to tak mělo chovat… :-(

[Sinuhet]

Tak jsem se do ni dival taky a POD promene jsou stale inicializovany na nulu jen pokud jsou deklarovany jako staticke.

[Michal Kubeček]

Máte pravdu, přehlédl jsem, že se v sekci 12.6 mluví výhradně o objektech.

[zde]

Samozřejmě že C++ nové objekty automaticky neinicializuje. To by bylo příliš jednoduché a příliš bezpečné, konstruktory by zely prázdnotou, a programátor by zvládl příliš mnoho práce. Co by mu zbylo na zítra?

[Sinuhet]

Vy zas perlite...

[Miloslav Ponkrác]

A proč by to dělal? Kdyby C++ automaticky inicializoval (zejména POD typy), tak by dělal naprosto zbytečnou práci, protože programátor to potřebuje nastavit po svém a kompilátor nemá naprosto šanci odhadnout jak. (Ale uznávám, jen co se křišťálová koule a tarotové karty stanou běžným interfacem počítačů, pak to bude jinak.). A kdyby docházelo ke zbytečné inicializaci, pak by program běžel pomaleji následkem neužitečné inicializace, kteoru stejně musí programátor přepsat po svém.

Jinak pokud například součástí objektu je další instance objektu, pak nemusí programátor hnout prstem a napsat ani jediný řádek kódu a C++ automaticky zinicializuje, protože je naprosto jasné co je potřeba - a kompilátor tak vykoná užitečnou práci.

Jinak i v jiných programátorských jazycích, kde se automaticky inicializuje patří k dobrému vychování a k dobrým programátorským technikám toto nevyužívat, ale explicitně to nastavit ve zdrojovém kódu. Ono hledat zapeklitou chybu, která spočívá v tom, že programátor spoléhal na automatickou inicializaci je skoro vždycky žůžo, které si rád podruhé odpustíte.

[deda.jabko]

A kdyby docházelo ke zbytečné inicializaci, pak by program běžel pomaleji následkem neužitečné inicializace,

vs.

i v jiných programátorských jazycích, kde se automaticky inicializuje patří k dobrému vychování a k dobrým programátorským technikám toto nevyužívat, ale explicitně to nastavit ve zdrojovém kódu.

hlavne, ze mate jasno....

[Miloslav Ponkrác]

A v čem nemáte jasno? Jsou prostě programovací jazyky, kde se na rychlost a efektivitu tolik nehledí a prostě inicializují, i když mnohdy zbytečně. Nějaký problém?

[deda.jabko]

patří k dobrému vychování a k dobrým programátorským technikám toto nevyužívat

jsou jazyky, kde se na efektivitu moc nehledi... tak to udelame jeste neefektivnejsi ;-]

[Miloslav Ponkrác]

Copak je tak těžké pochopit, že jsou prostě jazyky, kde jsou jiné priority? Pro C++ je priorita rychlost a efektivita na max, pro jiný jazyk třeba maximální spolehlivost, nebo bezpečnost, nebo udržovatelnost zdrojových kódů, či cokoli jiného. Že prostě existují jazyky, kde se vzdají nějakého zlomečku efektivity proto, že třeba priorita číslo jedna je pro ně jiná vlastnost jazyka?

Prostě s jazyky je to jako s lidmi - tisíc chutí, tisíc možností, jiné žebříčky priorit.

[zde]

To je legrační, už po několikáté slyším že pro C++ je rychlost prioritou. Proč tedy dostává tak často výprask (a to faktorem klidně 4x-15x) od podstatně pohodlnějších jazyků jako SML, Haskell, Clean, D, Erlang, Eiffel, Lisp, a dokonce i od interpretovaného Pythonu nebo od Lua?

The Computer Language Benchmarks Game

Jistě, souhlasím že uvedené problémy by šly v C++ napsat i lépe, ale uvedený test srovnává stejný problém, napsaný přímočaře a přirozenými prostředky daného jazyka s minimálním úsilím, bez jakéhokoliv ladění a optimalizování, což je IMHO spravedlivé, a pro praktické užití mnohem více vypovídající než úzce specializované a pečlivě laděné benchmarky.

[Miloslav Ponkrác]

Protože a jednoduše v C++ se musí umět psát, chcete-li tu rychlost vymáčknout. Mohu Vám zcela bez obalu říci, že dobře napsaný program v C++ zkušeným programátorem a přeložený kvalitním kompilátorem dá rychlostně na prdel naprosto všemu co není psáno v assembleru/strojáku.

Jenže C++ je prostě závodní auto formule 1, kde pokud budete špatný řidič, tak z něho vymáčknete podprůměrné výsledky, a nebo se klidně i zabijete.

Mimochodem o tom, že testy C++ píšou lidi, kteří jsou totální amatéři v C++ a ty výsledky testů tomu odpovídají už jsem dokonce konstatoval i ve svém blogu:

http://www.abclinuxu.cz/blog/miloslavponkrac/2005/12/6/112210

Procházel jsem kdysi dost testů ohledně C++ versus něco jiného a chtělo se mi zvracet z těch zdrojáků v C++ co byly součástí testu. Nebudete se doufám zlobit, že mě tímto Vaše testy nepřesvědčí.

[Let_Me_Be]

Ale o tom presne C++ je. Je to univerzalni jazyk.

Chci rychle neco napsat? Fajn, dokazu to skoro stejne rychle jako v nejakem skriptovacim jazyku. Chci mit neco hodne vykonne? Fajn, napisu to tak ze rychlejsi bude jenom assembler.

Zadny jiny jazyk tyto moznosti neposkytuje. C neposkytuje zadne abstrakce pro tvorbu na vyssich urovnich a Java, C#, etc.. zase nemuzou byt nikdy tak rychle jako optimalizovany C++ program.

[zde]

A proč by to dělal? Kdyby C++ automaticky inicializoval (zejména POD typy), tak by dělal naprosto zbytečnou práci, protože programátor to potřebuje nastavit po svém a kompilátor nemá naprosto šanci odhadnout jak.

Ad 1) Aby se předešlo celé třídě nedeterministických a proto obtížně odhalitelných programátorských chyb. Aby se dala vytvořit rozumná knihovna pro garbage collection, která nebude muset bojovat s tím že pointery v objektech nemusejí být vždy validní. Aby člověk nemusel psát tolik triviálního kódu do konstruktoru.

Ad 2) Proč by ta 6MB tlustá hromada sraček nemohla využívat statickou analýzu kódu, kterou beztak dělá. Konstruktor by na začátku vynulovat ty části objektu, pro které nejde garantovat že jsou inicializovány. Pokud programátor bezpodmínečně inicializuje vše, nemusí se nulovat nic.

[Miloslav Ponkrác]

Ad 1) A co Vám brání se vykašlat na C++ a přejít na jiný jazyk podle Vašeho gusta? Jestli jste to nepochopil, tak návrh a vývoj jazyka C++ je veden snahou o maximální rychlost jako prioritu číslo jedna. Proto rozhodnutí ohledně automatické inicializace byla rozhodnuta v jazyce C++ ve prostěch rychlosti a je to tak jak je. Pokud chcete něco jiného, jsou jazyky, kde jsou jiné priority, a kde je to jinak.

Nechápu Vašeho snahy neustále šťourat do jazyka, který byl vytvořen již od prvního okamžiku a celý jeho vývoj je veden s myšlenkou "vše je podřízeno rychlosti", že neustále argumentujete, že by mělo C++ zavést něco, co rychlost snižuje. Prostě Vaše snahy jsou liché - v C++ bude priorita rychlost i kdybyste se postavil na hlavu a cokoli zbytečně rychlost snižuje a nedá za to obrovsky nadměrný kopec výhod, s tím se v C++ nesetkáte ani náhodou a do C++ to nikdo neprosadí.

Tímto odmítám jakékoli další diskuse s Vámi tímto směrem - všechny potřebné odpovědi jsem Vám právě napsal v první dvou odstavcích tohoto příspěvku.

Ad 2) Protože je v C++ určeno, že to uděláte Vy. Já si dokážu docela dobře představit případy a jsou poměrně časté, kdy prostě některé části objektu leží (dočasně) ladem a netřeba je inicializovat vůbec. Pak by byla inicializace zbytečná, zbytečně by se snižovala rychlost kódu - a to by odporovalo první postulátu C++ = "vše pro rychlost", a tudíž to tak v C++ nebude.

Jinak dobrý kompilátor před neincializovanými věcmi varuje, a to nejen v objektech, ale nemůže tušit, zda to tak oopravdu nechcete.

[Luboš Luňák]

void* buffer = operator new ( velikost );
operator delete ( buffer );

[Let_Me_Be]

Tak na tuhle variantu operatoru new jsem zatim nenarazil. Diky

[Deleted [8409]]

Pro vytvareni instance pomoci 'positioned new' jsem si nedavno napsal tuto tridu:

template<class T>
struct Wde_StaticClass
{
	uint8_t _storage[sizeof(T)];

	inline void init() { new ((void*)_storage) T; }
	inline void destroy() { ((T*)(_storage))->~T(); }

	inline T& instance() { return *((T*)(void*)(_storage)); }
	inline const T& instance() const { return *((T*)(void*)(_storage)); }
};

Je to sice trosku brutal pretypovavani, ale plni to ucel pri staticke inicializaci instanci (to byla motivace). Kdyz se pretypuje operator -> tak se s tim muze pracovat jako s ukazatelem.

[Miloslav Ponkrác]

A k čemu je to vlastně dobré?

[Deleted [8409]]

Už se Vám někdy stalo, že jste potřeboval nadefinovat pořadí staticky inicializovaných objektů v C++ (prostě mít jistotu, že se objekt A inicializuje dřív než B) ?

V gcc existuje atributa init_priority, ale třeba msvc nic takového nemá.

Existují ale i jiná využití, kdy chci vytvořit instanci třídy jen někdy a mít kontrolu nad tím, kdy ji zničím (neberu teď v úvahu {}, prostě speciální případy, kdy se to vyplatí )

[Miloslav Ponkrác]

Ano, stalo se mi, že jsem potřeboval nadefinovat pořadí několika staticky inicializovaných objektů. Tedy stává se mi to značně zřídka. Ale co máte v té třídě, co nemůžete volat přímo?

Vytvořit instanci třídy jako pointer/referenci na objekt a mít konstrolu nad tím, kdy jí zničím, tedy kdy na to zavolám delete je přeci naprosto běžné a nepotřebuji to balit do žádné třídy.

[Deleted [8409]]

Jenže ta třída co jsem poslal vytvoří tu instanci na zásobníku, v tom je podstatný rozdíl. Dynamicky alokovat dočasné instance mi nepřijde zrovna nejrychlejší, ale tak pokud to pro vás není kritické tak není co řešit.

[Miloslav Ponkrác]

Dobrá, dobrá, nebudu se hádat. Vaše řešení Vám slouží a to je podstatné. Řekněme, že bych to sice řešil jinak, ale Vaše řešení má také něco do sebe.

[Jirka P]

A co takhle použít std::vector, který taky defaultní konstruktor nepotřebuje?

[Deleted [8409]]

někdo STL nepoužívá, třeba i já:)

[Josef Kufner]

A proč to?

[Let_Me_Be]

No napriklad proto ze GNU implementace je docela pomala? Pokud to strcite do jadra nejakeho narocneho algoritmu tak se z toho dokaze vyklubat i nekolikanasobne zpomaleni.

[Deleted [8409]]

Při použití STL není prakticky možné dělat sdílené knihovny, jediné využití co mně napadá je vnitřní, tady není problém (viz antigrain, boost, atd...)

Nechci aby to vyznělo že STL je špatná, ale proste není pro mně.

[Michal Kubeček]

Při použití STL není prakticky možné dělat sdílené knihovny

Mohl byste tuto myšlenku rozvést?

[Deleted [8409]]

Je to myšleno tak, že se stl bloat kompiluje do každé knihovny a každé další knihovny co používá onu knihovnu + existuje ryziko, že při nové verzi překladače toto nebude fungovat (že gcc?).

Další věc je ta, že pod windows je to ještě horší, protože se stl implementace liší (myslím mingw, msvc, borland --- toto asi není argument, protože se liší i ABI)

Prostě nemám dobré zkušenosti z stl. Stačí se podívat na výslednou binárku fluxboxu a openboxu (je to sice C x C++, ale jde mi konkrétně o to stl, protože fluxbox ho hodně využíva)

No nevím jestli toto u vás konkrétně obstojí, ale myslím že i vy máte na stl svůj názor:)

[Miloslav Ponkrác]

Asi takhle, to že si nepoužíváte STL je samozřejmě Vaše rozhodnutí - a do toho Vám nikdo mluvit nemůže.

STL knihovna není žádný ďábel a obsahuje spoustu užitečných věcí. Bez problémů jí používám pod gcc i pod Microsoft překladačem v mnoha programech a problémy Vašeho typu nepozoruji.

Riziko, že standardní knihovna nebude v nové verzi překladače fungovat je mizivé, to už můžete fanaticky přestat používat i strlen, memcpy, printf a celou standardní knihovnu. Stejně tak i operátory new/delete Vám čistě teoreticky mohou přestat fungovat v další verzi překladače, tak snad abyste je přestal používat. A vůbec cokoli z C++.

Pod Windows je STL implementace samozřejmě jiná, což je naprosto v pořádku, protože jako u každé knihovny nezáleží na implementaci, ale na interface knihovny, který je stejný a je určen ISO normou jazyka C++. Jinak osobně mohu říci, že na Windows je situace lepší, a díky příjemnější práci s STL pod Microsoft překladačem na něm STL často ladím i pro Linux. Znovu bych ale zdůraznil, že to, že se implementace STL na jednotlivých překladačích liší je naprosto, ale úplně v pořádku. U naprosto každé knihovny, nejen STL, je důležitý interface, tedy rozhraní knihovny, které voláte, nikoli implementace.

Jinak každá abstrakce, tedy i knihovna vás něco stojí - tedy vytvoří mírně delší program. Pokud Vás opravdu trápí každý bajt výsledné binárky, pak velmi doporučuji začít programovat ve strojovém kódu, kde máte netušené možnosti ve vytváření super krátkých programů. Mě už dnes nezajímá, jestli je výsledná binárka o pár desítek kilobajtů delší, když jí díky STL naprogramuji za třetinu času a ušetřím třeba týdny při programování.

Je třeba pochopit, že low level programování s minimem knihoven (tedy i bez STL) Vám samozřejmě umožní ušetřit pár kilobajtů ve velikosti výsledné binárky a výsledný program bude o 0,005% rychlejší. Zato to budete programovat třeba pětkrát tolik času, budete tam mít více chyb a nejspíše méně funkčnosti. Podle mě prostě low level přístup a nepoužívání STL za to nestojí.

Jinak STL není pomalá, ale musí se umět dobře používat. STL je navržená v normě C++ tak, že je tam uděláno i dost ústupků k tomu, aby byla dostatečně rychlá.

[Deleted [8409]]

Ja s vama i v mnoha bodech souhlasim.

Nikde jsem nerekl ze je STL pomala, ba naopak, ovsem za cenu brutalniho zvyseni binarni velikosti vysledne knihovny/aplikace. Jak jsem naznacil i vyse, u aplikace prakticky nevidim problem, ale nedokazu si predstavit, ze by hodne sdilenych knihoven v linuxu bylo treba 3x vetsi nez doposud (zalezelo by asi na masivnosti pouziti).

Opravdu nemam chut se o necem dohadovat, ale jen jsem chtel rict, ze pro sdilene knihovny se podle mne STL moc nehodi. Je to ciste muj nazor.

Ironie: predstavte si, ze by vetsina sdilenych knihoven a aplikaci v linuxu pouzivalo masivne stl a boost. Podle mne by to bylo katastroficke

PS: Ja mam cas si svuj kod vyladit, momentale nedelam nic za prachy v C++ tudiz to vidim tak jak to vidim. Az budu programovat aplikaci a budu mit termin, pouziji klidne stl a boost - no problem.

[Miloslav Ponkrác]

Myslím, že se shodneme až na to brutální zvýšení velikosti výsledné knihovny/aplikace. Pokud budete posuzovat velikost výsledné binárky u "Hello world", tak samozřejmě znatelný nárůst dostanete. Ale u běžné aplikace běžné složitosti to není nic strašidelného.

Mě by vůbec nevadilo, kdyby většina knihoven a alikací v Linuxu používalo STL a boost. Pokud by se tak stalo, bylo by to ok a žádné překvapení v negativním směru by se nekonalo.

Já taky leccos píšu i pro sebe, a leckdy nemusím spěchat, a přesto bez problémů STL použiji. Není v tom problém, protože v použití STL vidím mnohem víc výhod, než nevýhod. STL nezpomaluje program, ani neplýtvá velikostí paměti, či binárky.

[zde]

Divné. Myslel jsem že pro lidi kteří sáhnou po C++ není bloat na závadu. Inu furt se učím.

[Miloslav Ponkrác]

Jako provokace hezký. Tak šup šup, jesltipak už máš napsané úkoly z malé násobilky?

[Deleted [8409]]

nutno podotknout, že C++ nikoho nenutí STL používat, to je právě svoboda tohoto jazyka a důvod proč ho používám.

[Sinuhet]

Schvalne, co provede nasledujici kod?

#include "variablearray.h"

struct except
{
        static int counter;

        except(int i = 0)
        {
                ++counter;

                if( ! (counter % 3) )
                        throw "Vyjimka!";
        }
};

int except::counter = 0;

int main(int argc, char** argv)
{
        try {
                VariableArray<except%gt; va;
                va.Init(10);
        } catch(...) {
        }

        try {
                VariableArray<except> va;
                va.Init(10, 1);
        } catch(...) {
        }

        VariableArray<int> va;

        va.Init(10);
        va = va;

        return 0;
}

[Deleted [8409]]

1) leak 2) leak 3) undefined

[Jirka P]

3) undefined? mě z toho kódu vychází že 3 smaže obsah pole va, kde dělám chybu?

[Jirka P]

Jo, a jeste 1) neleakuje (zavolá destruktory na všechny excepty)

[Deleted [8409]]

To bych neřekl. Používá se placement new operator a překladač neví, že má volat destruktor. Druhá věc je, že při výjimce není označená ta šablona jako zinicializovaná. Podívejte se na konstruktor a destruktor té šablony. Mimochodem, otázka pro autora:
- je zde nějaký smysl použít virtuální destruktor?
- a zdvojená podmínka ?

assert(_length!=0,"Trying to free uninitialized pointer");
if (_length != 0) {} 

[Jirka P]

Právěže v 1) se placement new nepoužívá. [Init(int) vs. Init(int, T)]

Jo a ještě ve 2) je nedef. chování (paměť alokovaná mallocem se uvolňuje pomocí delete[])

[Deleted [8409]]

int main(int argc, char** argv)
{
        // 1) instance se naalokují pomocí placement new, ale vyjimka zpusobi
        // ze se neuvolni (viz implementace a destruktor), takze pokud byly
        // uvnitr alokovany dynamicke data -> leak
        try {
                VariableArray<except> va;
                va.Init(10);
        } catch(...) {
        }

        // 2) to same jako 1
        try {
                VariableArray<except> va;
                va.Init(10, 1);
        } catch(...) {
        }

        // 3)
        VariableArray<int> va;

        va.Init(10);
        // nedefinovane chovani, kopiruji se a alokuji vlastni 
        // data do vlastni třídy (viz kopirovaci konstruktor, tento
        // pripad neni osetren) -- toto bude asi dalsi leak nebo
        // primo segfault, zalezi na typu 'Type'
        va = va; 

        return 0;
}

[Jirka P]

int main(int argc, char** argv)
{
        // 1) instance se naalokují pomocí obyčejného new[], který při výjimce
        // sám zavolá destruktory dosud zkonstruovaných objektů
        // Naštěstí je pole označeno jako prázdné, takže destruktor va nic nemůže pokazit
        try {
                VariableArray<except> va;
                va.Init(10);
        } catch(...) {
        }

        // 2) tady se používá placement new, takže objekty except nikdo neuvolní. Navíc,
        // je pole označno jako plné, inicializované pomocí new[]
        try {
                VariableArray<except> va;
                va.Init(10, 1);
        } catch(...) {
        }
        // Destruktor va uvolnil paměť alokovanou mallocem pomocí delete[]. To je
        // nedef. chování

        // 3)
        VariableArray<int> va;

        va.Init(10);
        // tento případ není ošetřen, ale nejde o nedef. chování. Když se podíváte do kódu
        // operátoru=, zjistíte, že se chytne hned ta podmínka if(_length) Free(). Tím
        // se smažou nejen vlastní data, ale i data rhs a další kód s tím nic neudělá
        // nezáleží to vůbec na ničem
        va = va; 

[Deleted [8409]]

Jojo je tam to delete[] _data... to jsem prehledl.

Ad 1, 2) Poradne se podivejte na Init(). Data se neuvolni pokud je pool false a to pri vyhozeni vyjimky vzdy bude,navic nejste schopne zjistit kolik tech instanci uz bylo vytvoreno pomoci new(void*) operatoru.

Nedebugoval jsem ten kod a ani se mi nechce, ale myslim ze muj predpoklad je spravny.

[Sinuhet]

Bod 1) je podle me v poradku. Kdyz jse se na to znovu dival, tak jsem ani neprisel na to, proc jsem to tam prve daval...

[Jirka P]

Jenže tam jsou dva (relevantní) overloady Initu. Jeden alokuje pomocí new[] a druhý pomocí malloc+positioned new (který z nich byl použit se pozná z promenne pool). Ten první neleakuje, protože když při new T[] nastane výjimka, automaticky se zavolají destruktory na dosud zkonstruované objekty z toho pole, a automaticky se dealokuje paměť pro to pole. Ten druhý leakuje, a ještě nechá objekt v nekonzistentním stavu.

Předpoklad možná je správný, ale není úplně jasné, jaký.

[Deleted [8409]]

Mate uplnou pravdu, nevim jak jsem to mohl prehlednout:)

Ale v tom pripade je to spatne reseni, protoze se opravdu mixuje new a malloc pro '_data' jak uz tu nekdo upozornoval. Ciste reseni by asi bylo pouzit jen malloc() a nekde si ukladat pocet vytvorenych instanci, na ktere by se pri vyjimce zavolaly destruktory.

[Abraxis]

Jen takove postrehy z mych zkusenosti s Qt: - Pokud volam malloc, tak je neco HODNE spatne a je lepsi danou cast programu prepsat! - Provazani objektu pointrama zjednodusi a zprehledni kod (priklad z praxe: mechanika->medium->iso->label)

Obe tyto veci urcite maji nejaky performance hit, ale pokud nepisi low-level knihovnu (a tu asi v C++ nebudu psat a pouziji makroassembler zvany C ), tak je prehlednost a udrzovatelnost kodu dulezitejsi nez par procent vykonu.

[Deleted [8409]]

Já si myslím, že je dobré mít kvalitní a optimalizovaný základ, pak se může mrhat ve vyšších vrstvách a na výkonu to prakticky není znát:)

[Abraxis]

Ano, a tento zaklad se jmenuje Qt (OK, trochu flame-war, nicmene musim rict, ze v Qt se pise fakt nadherne - napr. maly multi-threadovy HTTP server na cca. 150 radcich )

[Deleted [8409]]

Qt by mohlo být ale více optimalizované

[rade-brno]

Je krásné, jak tady všichni polemizují, ale co takle nějaké srovnání?

 

Rychlost, uvolňování paměti atd? Já zkoušel porovnat následující:

1) vytvoření pole ukazatelů velikost 10000 na char velikosti 10000B

2) následně dealokace všech charů velikosti 10000B přes delete

3) alokace charů 1B na již existujících 10000 ukazatelů

4) alokace dalších 10000000 ukazatelů na char velikosti 1B

5) vyhodnoceni

 

Měření jsem provedl pro následující dvě varianty:

* to co navrhuje autor: pro seznam ukazatelů (malloc, realloc), pak (new, delete, new)...

* místo malloc použit vector: pro seznam ukazatelů (vector, push_back), pak (new, delete, new)...

 

Závěr: malloc lépe pracuje s pamětí - po delete ji sice systém neuvolní a program stále zabírá asi 100 MB v RAM, ale následně je plně využita pro další alokaci (po doběhnutí programu zabráno asi 191MB RAM)... vector má v mém měření skoro 2x vetší režii na paměť - po delete systém taky neuvolní paměť, ale při následné alokaci zabírá další a další RAM (nevyužije tu co byla uvolněna přes delete) a po doběhnutí program skončí na 350 MB RAM.

 

Příklad pro realokaci je zde:

http://www.krokodyyl.wz.cz/programovani/prog14.php

 

Pro mé konkrétní řešení se jednoznačně hodí metoda, kterou popisuje autor článku, případně je to ještě lépe popsáno v odkazu, který jsem uvedl... Ať si každý používá to, co mu vyhovuje, ne? Někdo extrémně optimalizuje rychlost a paměť (a musí si víc hlídat kód), někdo nepotřebuje optimalizovat, tak píše elegantní kód... Za mě velké díky za článek!

 

Radek