Dotaz: Dilema stack vs heap.

[libertarian7]

Možno hlúpa otázka ale fakt si tým niec som istý:

#include <memory>
#include <vector>
#include <string>

using namespace std;

struct BinData {
	vector<char> content{};
	wstring contentType{ L"" };
};

class NejakaTrieda {
	shared_ptr<BinData> binData;
	NejakaTrieda() : binData(new BinData()) {

	}
};

ked nejaka struktura obsahuje staticke members, ale ja tu strukturu vytvorim na heape

1. bude cela struktura vratane jej clenov ulozena na heape (bude obsah BinData.content uložený na heape?)
2. struktura bude na heape jej cleny na stacku.

---

---

Odpovědi

[Gréta]

na heapu si myslim :D ;D

nóó a pokuď tam bude jakoby nějaká jakože static proměná/atribut kterej ale jakoby nikde v tom příkládku nevidim nato nemá vliv jestli ti jako dobře rozumim :O ;D

[Jendа]

Si vypiš adresy těch věcí, podívej se, jestli jsou u sebe, a případně porovnej s /proc/pid/maps jestli je to stack nebo heap. (ano, taky to nevím, ale takhle bych to zkoušel zjistit :)

[Bherzet]

A pointer na členskou proměnnou se vyrábí takhle.

[libertarian7]

Diky večer pozriem :)

[libertarian7]

Mal som sa na to vykašlať lebo teraz mám viac otázok ako odpovedí. Zistil som že:

1. Štruktúra alebo trieda začína na rovnakej adrese ako jej prvý member.
2. kontainer vector má úplne inú adresu ako samotný buffer s položkami, ktorý obaluje. To znamená že každý vector interne obaluje nejaký pointer. Ktorý ukazuje na heap. (aspoň podľa adries mám taký pocit)

vector<char> binDataStack {'a', 'b', 'c'};
cout << 'The vector address allocated on the stack' << (int)(&binDataStack) << endl;
cout << 'The vector buffer start address allocated on the stack' << (int)(&(binDataStack[0])) << endl;

vector<char>* binDataHeap = new vector<char>{'a', 'b', 'c'};
cout << 'The vector address allocated on the stack' << (int)binDataHeap << endl;
cout << 'The vector buffer start address allocated on the stack' << (int)(&(binDataHeap[0])) << endl;

3. to čo platilo pre kontainer vector<char> neplatí pre char[] alebo const char[]. Pole sa začína rovnakou adresou ako jeho položky.
4. teoreticky by mala byť celá štruktúra či classa na jednom mieste. V praxi to tak nie je. Pretože kontainery z stl ukladajú položky úplne inde ako programátor očakáva.

[rastos]

Štruktúra alebo trieda začína na rovnakej adrese ako jej prvý member.

Mno. To je dobrý zvyk. Pokiaľ sa do toho nezapletie nejaký alignment. Záleží na tom?

kontainer vector má úplne inú adresu ako samotný buffer s položkami, ktorý obaluje.

Pretože, ten kto písal implementáciu vector-u dopredu nevedel, aké veľké štruktúry do neho budú ukladané. A samozrejme nikde nie je povedané, že má práve jeden buffer s položkami. Opäť: Záleží na tom?

to čo platilo pre kontainer vector<char> neplatí pre char[] alebo const char[]

No iste. Lebo char [] (či už const alebo nie) je prakticky pointer na postupnosť char-ov.

teoreticky by mala byť celá štruktúra či classa na jednom mieste.

Prečo?

[Martin Tůma]

Mno. To je dobrý zvyk. Pokiaľ sa do toho nezapletie nejaký alignment

To není zvyk, to je zaručeno standardem C/C++ (bez ohledu na jakýkoliv alignment).

[MadCatX]

Přesně tak, alignment se projeví až na offsetu druhé a dalších členských proměnných:

@Libertarian7: študuj zde:

#include <iostream>

#define _S(x) #x
#define ADDROF(what) std::cout << "Address of " _S(what) << " is " << std::hex << uintptr_t(&what) << std::endl
#define OFFSETOF(what, where) std::cout << "Offset of " _S(what) " in " _S(where) " is " << uintptr_t(&((where*)0)->what) << std::endl
#define SIZEOF(what) std::cout << "Size of " _S(what) " is " << sizeof(what) << std::endl

class A {
public:
        bool a1;
        int a2;
};

class B {
public:
        int b1;
        bool b2;
        int* b3;
        char b4[4] = "def";
};

#pragma pack(push, 1)
class BP {
public:
        int b1;
        bool b2;
        int* b3;
        char b4[4] = "def";
};
#pragma pack(pop)

class C {
public:
        double c0;
        const char c1[3] = "xy";
        static const char c2[3];
};
const char C::c2[3] = "12";

int main()
{
        SIZEOF(A);
        OFFSETOF(a1, A);
        OFFSETOF(a2, A);

        SIZEOF(B);
        OFFSETOF(b1, B);
        OFFSETOF(b2, B);
        OFFSETOF(b3, B);
        OFFSETOF(b4, B);

        SIZEOF(BP);
        OFFSETOF(b1, BP);
        OFFSETOF(b2, BP);
        OFFSETOF(b3, BP);
        OFFSETOF(b4, BP);

        C c;
        SIZEOF(C);
        ADDROF(c);
        ADDROF(c.c1);
        ADDROF(c.c2);
        ADDROF(c.c1[0]);
        ADDROF(c.c2[0]);
}

[libertarian7]

Ďakujem tie makrá sa mi budú hodiť.

[Radovan]

To znamená že každý vector interne obaluje nejaký pointer. Ktorý ukazuje na heap

A jak by sis to představoval na stacku? A chceš tam řešit jeho overflow?

Nevím co očekáváš ty, ale pro mě se to jako pro opravdového programátora chová naprosto předvídatelně. To tvoje nadávání na STL začíná být dost trapný.

[libertarian7]

Vyzerá to tak že pán opravdový programátor je veľmi senzitívny, lebo veď ja vôbec nenadávam na STL... STL sa mi celkom páči a to ako funguje beriem ako holý fakt, nikdy by som si nedovolil na STL povedať krivé slovo.

Len som prekvapený, že jednoducho niektoré veci fungujú inak ako som si pôvodne myslel. Prepáč že nie som opravdový programátor a tiež prepáč, že sa ti kôli mojim príspevkom v poradni zrútil svet a že teraz kôli mne nemôžeš kľudne spávať, nebol to môj zámer.

[Radovan]

Jo, tohle podezřele smrdí debianem.

[libertarian7]

Netušim kto je debian :D ale tipujem že nejaký člen Abclinuxu, alebo nejaký "opravdový programátor".

Filozofia debianu sa mi moc nepáči. Takže ak už by som si mal vybrať nick podľa názvu distribúcie tak asi skôr Arch.

[Radovan]

Arch je pro impotenty. Debian převlečený do načančaných šatiček.

Zjevně neovládáš svaté texty: http://www.logix.cz/michal/humornik/Pojidaci.Kolacu.xp

A protože toho neovládáš víc, začni tady: https://blog.rfox.eu/cz/Programovani/Jak_se_stat_programatorem.html. Nejlépe tou částí o C++.

[Gréta]

vector neni prvek/datovej typ jazyka c++ ale jakoby třída v c++ napsaná tak se nechová jako datový typy ale jako třída. a rozhodně vector neni to samý co pole :D ;D

takže jako neni nic divnýho natom že položky ve vectoru maj jinou adresu než samotnej vector. tamtu alokaci ve vectoru si řeší vector posvým a s třídou ve který je vector jako member to už nemá nic společnýho. ta ví kde je vector nóó a vector zase ví kde má ten svuj buffer :O ;D

joa jeto přesně tak jak programátor vočekává žeto jakoby má bejt :O :D ;D ;D možná si nejdřiv přečti něco vo obyč cčku se ti to pro c++ bude 100% hodit ;D ;D

[MadCatX]

Body 1. - 3. už ti osvětlil rastos, k bodu 4. bych podotkl:

Struktura tak, jak ji asi znáš z C a třída v C++ jsou úplně jiné entity. Cčková struktura je jen kus paměti, jehož jednotlivé části mají předem daný "význam". Třída má kromě členských proměnných (ty kusy paměti s "významem") i metody, statické proměnné a statické metody. To všechno musí v paměti někde být. V C++ je to řešeno tak, že členské proměnné jsou uspořádány do Cčkové struktury. Ta se vytvoří buď na zásobníku nebo na haldě. Statické proměnné jsou buď v .data nebo .bss segmentu, podle toho, zda jsou inicializované při překladu nebo až za běhu. Metody jsou spustitelný kód, takže ty musí být v .text segmentu.

Teď ještě koukám, že v tom kódu z bodu 2. máš na posledním řádku chybu, viz:

#include <vector>
#include <iostream>

using namespace std;

int main()
{
        vector<char> binDataStack {'a', 'b', 'c'};
        cout << "The vector address allocated on the stack " << std::hex << uintptr_t(&binDataStack) << endl;
        cout << "The vector buffer start address allocated on the stack " << std::hex << uintptr_t(&binDataStack[0]) << endl;

        vector<char>* binDataHeap = new vector<char>{'a', 'b', 'c'};
        cout << "The vector address allocated on the stack " << std::hex << uintptr_t(binDataHeap) << endl;
        cout << "The vector buffer start address allocated on the stack (WRONG) " << std::hex << uintptr_t(&(binDataHeap[0])) << endl;
        cout << "The vector buffer start address allocated on the stack (RIGHT) " << std::hex << uintptr_t(&(*binDataHeap)[0]) << endl;

        return 0;
}

The vector address allocated on the stack 7ffede757af0
The vector buffer start address allocated on the stack 559807b9feb0
The vector address allocated on the stack 559807ba02e0
The vector buffer start address allocated on the stack (WRONG) 559807ba02e0
The vector buffer start address allocated on the stack (RIGHT) 559807ba0300

[libertarian7]

Diky za vysvetlenie, aj za opravu.

[Andrej]

ked nejaka struktura obsahuje staticke members

Ve tvém příkladu nemáš žádné statické členy. Takže, na co se vlastně ptáš? (Statičtí členové by nebyli na stacku ani na heapu, nýbrž tam, kde jsou ostatní globální proměnné — kdyby tam nějací byli, což nejsou.)

bude cela struktura vratane jej clenov

Jak by mohla ta struktura existovat nějak odděleně od svých členů? Co by ta struktura potom byla? Vzduchoprázdno?

bude cela struktura vratane jej clenov ulozena na heape (bude obsah BinData.content uložený na heape?)

Kterých přesně členů? BinData není členem NejakaTrieda. Jak tedy tahle otázka souvisí s členy? Jediný člen NejakaTrieda je std::shared_ptr<BinData>.

BinData::content bude v tomto případě skutečně na heapu, protože ho explicitně alokuješ pomocí new, což implicitně (pokud nepřetížíš operátor new) alokuje na heapu.

std::shared_ptr<BinData>, který je členem NejakaTrieda, bude přesně tam, kde bude celá instance NejakaTrieda, ať už to bude na heapu, na stacku, mezi globálními daty atd. atp.

struktura bude na heape jej cleny na stacku.

Tohle nedává smysl. Co si vojín Kefalín představuje pod pojmem struktura? Vzduchoprázdno?

[Gréta]

strukturou asi jako myslí tamtu struct bindata :D ;D

[libertarian7]

Ve tvém příkladu nemáš žádné statické členy. Takže, na co se vlastně ptáš? (Statičtí členové by nebyli na stacku ani na heapu, nýbrž tam, kde jsou ostatní globální proměnné — kdyby tam nějací byli, což nejsou.)

Objekty alokované na stacku používajú static binding a tak som ich nesprávne nazval statické members. Sorry písal som to unavený a v rýchlosti som to zle nazval. Samozrejme že to neni ani statický member a ani stasticky viazaný member, ale skôr member ktorý má staticky viazané členy. Ako sa takéto objekty vlastne nazývajú? Neviem ich nejako rozumne nazvať.

Jak by mohla ta struktura existovat nějak odděleně od svých členů? Co by ta struktura potom byla? Vzduchoprázdno?

Neviem. Vôbec netuším ako sú štruktúry fyzicky uložené v pamati. Teda teraz už tuším, keďže som si vypísal ich adresy. Ale doteraz som nevedel že štruktúra tvorí fyzicky jeden celok aj v pameti.

Kterých přesně členů? BinData není členem NejakaTrieda...

Asi som sa nevyjadril zrozumiteľne, ešte raz to skúsim zrozumitelnejšie (typ NejakaTrieda pojde z prikladu preč, bol to zlý príklad a je to tam zbytočne matúce) skúsim takto:

#include <memory>
#include <vector>
#include <string>

using namespace std;

struct BinData {
	vector<char> content{};
	wstring contentType{ L"" };
};

void main() {
    auto binData = make_shared<BinData>();
    binData.content // je kontainer vector memberu content fyzicky uložený na stacku alebo na heape? 
}

je kontainer vector, memberu content, fyzicky uložený na stacku alebo na heape? Z toho čo som zistil doteraz, tak asi na heape, ale potrebujem sa v tom uistiť. A nehovorím o jeho bufferi s itemami, ale len o samotnom kontaineri.

[libertarian7]

ešte málá oprava:

#include <memory>
#include <vector>
#include <string>

using namespace std;

struct BinData {
	vector<char> content{};
	wstring contentType{ L"" };
};

void main() {
    auto binData = make_shared<BinData>();
    binData->content // je kontainer vector memberu content fyzicky uložený na stacku alebo na heape? 
}

má má tam byť -> a nie . neni to síce podstatné, ale nechcem aby sa tomu zbytočne venovala pozornosť. Venujme sa prosím téme, ďakujem.

[MadCatX]

Obávám se, že máš sakramentský guláš v terminologii. Vím, že ajťáci rádi házejí fešáckými termíny zleva zprava, aby působili inteligentně a asi tě tím zmátli. Takže:

• Early a late binding nemá s haldou či zásobníkem nic společného a týká se pouze metod.
• Pokud nevíš, jak jsou v paměti reprezentované složené typy, je celá diskuse o tom, kde bude co uložené poněkud bezpředmětná
• Kde bude uložená členská proměnná content objektu binData (který je instancí třídy BinData) záleží ta tom, zda bude binData alokován na haldě nebo na zásobníku. Co udělá std::make_shared záleží na implementaci, velmi pravděpodobně ale bude alokovat na haldě. Pokud je binData na haldě, budou tam i všechny jeho nestatické členské proměnné a naopak.

[libertarian7]

Early a late binding nemá s haldou či zásobníkem nic společného a týká se pouze metod.

Určite? môžu mať objekty vytvorené na stacku tabulku virtuálnych metód? To že to súvisí s volaním metód je pravda - to ani nerozporujem a snáď je to z kontextu mojho predchádzajúceho príspevku jasné.

Pokud nevíš, jak jsou v paměti reprezentované složené typy, je celá diskuse o tom, kde bude co uložené poněkud bezpředmětná

Ajajaj. Načo je potom poradna? Nie náhodou na to aby som kládol otázky a dozvedel sa na ne odpovede? Je zakázané sa pýtať? Niekto múdry raz povedal, že neexistujú hlúpe otázky, ale len hlúpe odpovede. A tiež vraj múdri ľudia sa pýtajú a hlúpi ostávajú žiť v nevedomosti. Tak mi dovol aby som sa pýtal, ale asi nie teba. Začínam mať pocit, že ma trolluješ.

Kde bude uložená členská proměnná content objektu binData (který je instancí třídy BinData) záleží ta tom, zda bude binData alokován na haldě nebo na zásobníku. Co udělá std::make_shared záleží na implementaci, velmi pravděpodobně ale bude alokovat na haldě. Pokud je binData na haldě, budou tam i všechny jeho nestatické členské proměnné a naopak.

Ok myslel som si že si troll, ale teraz už vidím, že si len klon Sheldona Coopera. Keby som o tom nič nevedel, tak by si ma teraz zmiatol a v konečnom dôsledku by mi tvoja odpoveď vôbec nepomohla. Kedy bude make_shared alokovať na zásobníku? V 1 promile prípadov? Ale skôr by som povedal že nikdy. Prečo mi takéto zbytočné informácie vôbec sprostredkuješ? Prepáč, ale už od teba nechem žiadne odpovede. Chýba ti empatia a nedokážeš odpovede naformulovať tak aby mi pomohli. Prestav si že si laik, ktorý sa učí C++ a prečítaj si svoje odpovede. Máš pocit, že takéto odpovede budú mať pre mňa nejaký prínos? Žiaľ ty to ani nedokážeš podúdiť, máš binárne myslenie ako robot, buď je niečo pravda radšej si zaplatím kvalitného učiteľa.

[MadCatX]

Ad vtable:
Ukazatel na vtable je v C++ jen skrytá členská proměnná, kterou automaticky přidá kompilátor. Je tedy úplně fuk, kde v paměti je objekt vytvořený.

Ad WTF výlev:
C++ je ošklivý, překombinovaný a zmatený jazyk, který se snaží technikami z 80. let implementovat moderní programovací koncepty. (Nejen) proto v něm spousta věcí platí jen za určitých podmínek, závisí na použitém kompilátoru apod. Úplně nejhorší službu mi prokázaly právě různé polovičaté odpovědi, které tohle nezohledňovaly a já se pak nestačil divit. C++ laik by si měl podle mě opatřit kvalitní učebnici, podívat se na nějaké přednášky na YT apod. Učit se C++ (a vlastně cokoliv jiného) od náhodných autistů z internetových diskusí je cesta do pekel buď jak buď :)

[Gréta]

tvl ještě mu jako vynadej žese ti snaží pomoct ne asi jako :O :O :/ :/

[MadCatX]

Rozčílit se mohl nanejvýš proto, že jsem to neřekl úplně správně. binData je instancí std::shared_ptr<BinData> a ten bude na zásobníku. Na haldě bude až ten syrový ukazatel, který obaluje :) Moderní C++ je pro odhalování, jak na nízké úrovni funguje stroj dost nešikovný jazyk.

[Andrej]

Ajajaj. Načo je potom poradna? Nie náhodou na to aby som kládol otázky a dozvedel sa na ne odpovede? Je zakázané sa pýtať? Niekto múdry raz povedal, že neexistujú hlúpe otázky, ale len hlúpe odpovede. A tiež vraj múdri ľudia sa pýtajú a hlúpi ostávajú žiť v nevedomosti. Tak mi dovol aby som sa pýtal, ale asi nie teba.

Ufufuf. Tohle jsi četl? Jestli je, tak s chutí do toho! (Pokud možno dřív, než zcela propadneš představě, že poradna nějak zastupuje nebo nahrazuje hledání na webu + čtení. )

Ok myslel som si že si troll, ale teraz už vidím, že si len klon Sheldona Coopera. Keby som o tom nič nevedel, tak by si ma teraz zmiatol a v konečnom dôsledku by mi tvoja odpoveď vôbec nepomohla. Kedy bude make_shared alokovať na zásobníku? V 1 promile prípadov? Ale skôr by som povedal že nikdy.

On se ti snaží vysvětlit, že to není podstatné. A že se tím nemáš zabývat, pokud/dokud nevíš, která bije. Prostě se podívej na dokumentaci k STL na cppreference.com nebo cplusplus.com, použij, co ti vyhovuje, a řeš problémy teprve tehdy, až nastanou — tedy až spustíš nějakou svou binárku přes valgrind a valgrind ti řekne, že jsi něco posral. Do té doby všechno nech na STL; STL ví, co dělá.

Jestli tohle má být domácí úkol se zadáním typu "bez alokace na heapu udělejte to a to", bylo by hezké to specifikovat v dotazu, i když chápu, že to nemusí být snadné. Ale jak už tu někteří psali, stack obvykle roste dolů a má v adresách spoustu f, zatímco heap je někde dole a roste nahoru, takže … tolik asi pro jednoduchou kontrolu, co je kde.

Jo a jestli někdo tvrdí, že máš použít std::vector bez alokace na heapu, tak tvrdí nesmysly; implementace si může alokovat, co chce a kde chce a (skoro) kdy chce. (To skoro je podmíněné tím, jestli smí mít vlastní vlákna, což se mi teď nechce ve specifikaci hledat.)

Máš pocit, že takéto odpovede budú mať pre mňa nejaký prínos?

Máš pocit, že právě tenhle^^^ komentář bude mít přínos pro budoucí čtenáře tohoto vlákna a/nebo pro tebe? Mně přijde, že ne. Just sayin'.

[Gréta]

hhhíííííííííííííííííííííííííííííííííííííííííííííííííííííííííííííííííííííííípppppp :D :D :D :D ;D ;D

ale cosi to jako nevověřit tim pidem jak už jako psal jenda uplně nazačátku :O ;D

#include <iostream>
#include <memory>
#include <vector>
#include <string>
#include <cstring>

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

using namespace std;

//koukadlo vocaď https://stackoverflow.com/questions/16709946/how-to-determine-if-returned-pointer-is-on-the-stack-or-heap
// kouknem do souboru /proc/pid/maps na paměť a vemem z něj rosah heapu 
void get_heap_bounds(uint64_t* heap_start, uint64_t* heap_end){
    FILE *stream;
    char *line = NULL;
    size_t len = 0;
    ssize_t nread;

    stream = fopen("/proc/self/maps", "r");

    while ((nread = getline(&line, &len, stream)) != -1) {
        if (strstr(line, "[heap]")){
            sscanf(line, "%" SCNx64 "-%" SCNx64 "", heap_start, heap_end);
            break;
        }
    }

    free(line);
    fclose(stream);
}

// noa kouknem jestli adresa je na heapu jakože je v tom rosahu :O ;D
bool is_heap_var(void* pointer){
    uint64_t heap_start = 0;
    uint64_t heap_end = 0;
    get_heap_bounds(&heap_start, &heap_end);

    if (pointer >= (void*)heap_start && pointer <= (void*)heap_end){
        return true;
    }
    return false;
}


struct BinData {
	vector<char> content{};
	wstring contentType{ L"" };
};

int main() {
    auto binData = make_shared<BinData>();
    
    cout << "kdepak asi jako je binData?? :O :O" << endl;
    if( is_heap_var((void*)(&binData)))
        cout << "na heapu!!" << endl;
    else
        cout << "na stacku!!!!" << endl;
    
    cout << endl << "kdepak asi jako je binData->content?? :O :O" << endl;
    if( is_heap_var((void*)(&binData->content)))
        cout << "na heapu!!!!";
    else
        cout << "na stacku!!!!";
    
    cout << endl << endl << "hotovo!!!!!!!!!!!! mackni enter" << endl;
    cin.ignore();
    return 0;
}

noa piše si to do konzole

kdepak asi jako je binData?? :O :O
na stacku!!!!

kdepak asi jako je binData->content?? :O :O
na heapu!!!!

[Jendа]

        if (strstr(line, "[heap]")){

Btw. tady pozor, že alokátor si může kdykoli vymyslet (podle interní heuristiky), že nebude používat heapu ve smyslu brk(2), ale anonymní mapování. U programu s jednou strukturou, která má pár desítek bajtů, se to nestane, ale pokud to ve skutečnosti tazatel ladí v něčem větším, tak tam bude situace jiná.

[Andrej]

No ale tady pozor, já jsem dnes viděl jednu takovou slečnu a měl jsem z toho normálně brk(11) (minimálně)! Jo, to byla situace!

[Andrej]

je kontainer vector, memberu content, fyzicky uložený na stacku alebo na heape?

Na heapu.

A nemá to absolutně žádný význam. std::vector je jen několik málo bytů pointerů, jinak nic. Může být klidně na stacku nebo na heapu; je to úplně jedno. Na stacku je to výhodnější, z hlediska výkonu: o jednu úroveň indirekce méně. Implementace std::vector si pole pro ukládání prvků sama alokuje a spravuje na heapu. Není vůbec nic špatného na tom, když vytvoříš std::vector na stacku, ať už přímo nebo skrz nějakou jinou instanci alokovanou na stacku.

A nehovorím o jeho bufferi s itemami, ale len o samotnom kontaineri.

Uf. Přikládáš význam věcem, které význam nemají.

Předně, samotný kontejner neexistuje. Kontejner tvoří několik neoddělitelných součástí (tedy, v podobě, v jaké kontejnery najdeš v STL nebo v boost):

• algoritmy a jejich implementace
• malý pointer (nebo malé N pointerů), který je tam, kde alokuješ std::vector, tedy buď na stacku, nebo ve struktuře, kde je std::vector přímo členem, atd. atp.
• paměť, kterou si kontejner sám spravuje na heapu (pomocí konstruktoru, operátorů, destruktoru, iterátorů atd.)

Zjednodušeně to můžeš brát tak, že std::vector bude vždy na heapu, bez ohledu nato, kde (si myslíš, že) ho alokuješ. Taková představa rozhodně nebude daleko od pravdy (až na optimalizace pro prázdné vektory, které si na heapu nic nealokují).

kdo si vsadi ze je to inkonginto spamujici debian+ co nezvlada c+?

[Gréta]

nééééééééééééééé todleto je nějakej fortran hele :O :O :D :D ;D ;D

[&bnsp;]

z JS na C++, chudák