C++ naco jsou hlavičkové soubory když budu psát OOP?

[Mirek]

Pěkně komické vlákno. To má potenciál!

[Reklama]

[egyptan_skinuhead]

Samej odborník na C++ tady Ještě by mohli přijít Javaman() ÁÁÁ já se lámu smíchy

[Sadd]

Nejdriv jsem si myslel že troll je jen autor, teď tak půlka diskutujících...

[ava]

OOP se vzdyt dela v Jave. C++ je jen nepovedeny hack. Vzdyt i samotny kernel je psan radeji v cistem C.

Presne tak, jestli C++ opravdu nutne nepotrebujes, utec dokud je cas. Timhle

For(int i = 0; i<10; i++)
 someVector.push_back( Trida() )

uz si potencialne zadelavas na segmentation fault, kdyz se treba budes pokouset pristupovat k polozkam toho vektoru mimo kontext kde vznikly. Techto oseru je C++ plne. Jestli potrebujes neco podobneho C++, ale done right, zkus radsi Rust, obzvlast kdyz mas svobodu teprve si vybirat.

[zboj]

Nejsem C++kář a potřebuju si v tom něco napsat OOP.

Naco jsou tam ty hlavičkové souboru *.h a k nim vždycky ještě *.cpp, když to budu psát OOP a už samotná třída definuje svoje rozhraní sama o sobě? Chápu to správně, že hlavičky slouží jen jako interface k binárce? Potom by mi ovšem stačil jen hlavičkový soubor k binárce, nemusím ho dělat ke každé třídě v rámci jedné binárky, ni?

Další věc statická alokace paměti. Veškeré třídy, jejichž instance se nebudou množit za běhu aplikace, můžu alokovat staticky bez operátoru new. Dá se to tak brát? Tzn. řekněme v praxi by mělo být tak cca 90% všech alokací v C++ statických.

Pokud nějakou instanci alokuji dynamicky, ale v rámci té třídy už alokuju staticky, pak předpokládám, že kompilátor není blbý a i ty statické alokace budou na heapu a ne ve stacku. Jako např. budu mít nějaký vector a do toho budu v cyklu přidávat staticky alokované instance, tak potom tyto instance budou ve výsledku alokovány na heapu, je to tak? Doufám že jo.

Díky.

New je lepší vůbec nepoužívat. Překladač není blbý, objekt se buď zkopíruje nebo se udělá move. Vnitřně to typicky skončí někde na haldě, ale to si řeší STL interně, konkrétně kolekce podporují && a objekty se tak paměťově spravují korektně.

[Reklama]

[anonym]

Nejsem C++kář a potřebuju si v tom něco napsat OOP.

Naco jsou tam ty hlavičkové souboru *.h a k nim vždycky ještě *.cpp, když to budu psát OOP a už samotná třída definuje svoje rozhraní sama o sobě? Chápu to správně, že hlavičky slouží jen jako interface k binárce? Potom by mi ovšem stačil jen hlavičkový soubor k binárce, nemusím ho dělat ke každé třídě v rámci jedné binárky, ni?

Další věc statická alokace paměti. Veškeré třídy, jejichž instance se nebudou množit za běhu aplikace, můžu alokovat staticky bez operátoru new. Dá se to tak brát? Tzn. řekněme v praxi by mělo být tak cca 90% všech alokací v C++ statických.

Pokud nějakou instanci alokuji dynamicky, ale v rámci té třídy už alokuju staticky, pak předpokládám, že kompilátor není blbý a i ty statické alokace budou na heapu a ne ve stacku. Jako např. budu mít nějaký vector a do toho budu v cyklu přidávat staticky alokované instance, tak potom tyto instance budou ve výsledku alokovány na heapu, je to tak? Doufám že jo.

Díky.

New je lepší vůbec nepoužívat. Překladač není blbý, objekt se buď zkopíruje nebo se udělá move. Vnitřně to typicky skončí někde na haldě, ale to si řeší STL interně, konkrétně kolekce podporují && a objekty se tak paměťově spravují korektně.

A co to, co zminuje ava, oser typu seg fault kdyz:

For(int i = 0; i<10; i++)
 someVector.push_back( Trida() )

[zboj]

OOP se vzdyt dela v Jave. C++ je jen nepovedeny hack. Vzdyt i samotny kernel je psan radeji v cistem C.

Presne tak, jestli C++ opravdu nutne nepotrebujes, utec dokud je cas. Timhle

For(int i = 0; i<10; i++)
 someVector.push_back( Trida() )

uz si potencialne zadelavas na segmentation fault, kdyz se treba budes pokouset pristupovat k polozkam toho vektoru mimo kontext kde vznikly. Techto oseru je C++ plne. Jestli potrebujes neco podobneho C++, ale done right, zkus radsi Rust, obzvlast kdyz mas svobodu teprve si vybirat.

Kecy, v tomto případě si kolekce dělá kopii nebo move (podle verze/třídy), ale chovat se to bude korektně. Akorát lepší než push je emplace.

[zboj]

Nejsem C++kář a potřebuju si v tom něco napsat OOP.

Naco jsou tam ty hlavičkové souboru *.h a k nim vždycky ještě *.cpp, když to budu psát OOP a už samotná třída definuje svoje rozhraní sama o sobě? Chápu to správně, že hlavičky slouží jen jako interface k binárce? Potom by mi ovšem stačil jen hlavičkový soubor k binárce, nemusím ho dělat ke každé třídě v rámci jedné binárky, ni?

Další věc statická alokace paměti. Veškeré třídy, jejichž instance se nebudou množit za běhu aplikace, můžu alokovat staticky bez operátoru new. Dá se to tak brát? Tzn. řekněme v praxi by mělo být tak cca 90% všech alokací v C++ statických.

Pokud nějakou instanci alokuji dynamicky, ale v rámci té třídy už alokuju staticky, pak předpokládám, že kompilátor není blbý a i ty statické alokace budou na heapu a ne ve stacku. Jako např. budu mít nějaký vector a do toho budu v cyklu přidávat staticky alokované instance, tak potom tyto instance budou ve výsledku alokovány na heapu, je to tak? Doufám že jo.

Díky.

New je lepší vůbec nepoužívat. Překladač není blbý, objekt se buď zkopíruje nebo se udělá move. Vnitřně to typicky skončí někde na haldě, ale to si řeší STL interně, konkrétně kolekce podporují && a objekty se tak paměťově spravují korektně.

A co to, co zminuje ava, oser typu seg fault kdyz:

For(int i = 0; i<10; i++)
 someVector.push_back( Trida() )

To funguje korektně, ale doporučuju emplace_back. A obecně, pokud to je pro Linux, použil bych libc++.

[anonym]

uz si potencialne zadelavas na segmentation fault, kdyz se treba budes pokouset pristupovat k polozkam toho vektoru mimo kontext kde vznikly. Techto oseru je C++ plne. Jestli potrebujes neco podobneho C++, ale done right, zkus radsi Rust, obzvlast kdyz mas svobodu teprve si vybirat.

Kecy, v tomto případě si kolekce dělá kopii nebo move (podle verze/třídy), ale chovat se to bude korektně. Akorát lepší než push je emplace.
[/quote]

A kdyby si neco kopii neudelalo, napr. nejaka custom kolekce, tak by k segfault skutecne doslo v pripade pristupovani k tem objektum z jinaciho scopu? (predpokladam ze scope je myslena hierarchie slozenych zavorech {}  )

[orcus]

OOP se vzdyt dela v Jave. C++ je jen nepovedeny hack. Vzdyt i samotny kernel je psan radeji v cistem C.

Presne tak, jestli C++ opravdu nutne nepotrebujes, utec dokud je cas. Timhle

For(int i = 0; i<10; i++)
 someVector.push_back( Trida() )

uz si potencialne zadelavas na segmentation fault, kdyz se treba budes pokouset pristupovat k polozkam toho vektoru mimo kontext kde vznikly. Techto oseru je C++ plne. Jestli potrebujes neco podobneho C++, ale done right, zkus radsi Rust, obzvlast kdyz mas svobodu teprve si vybirat.

Ale prd, radsi se priste koukni do dokumentace, kdyz necemu nerozumis.

Parametr funkce je sice reference, ale segmentation fault to nehodi. Nejdriv se vytvori objekt tridy Trida na stacku, pak se zavola push_back a preda se mu reference na ten objekt, metoda push_back vytvori kopii toho objektu pomoci copy constructoru (popr. v C++11 je parametr rvalue reference a tam se obsah objektu muze presunout bez kopie pomoci move constructoru) a po volani push_back se muze ten objekt ze stacku odstranit.
Jak se alokuji samotne objekty ve vektoru se urcuje allocatorem, ktery se nastavuje jako parametr sablony tridy vector.
Defaultni je pomoci fce new, takze po smycce for budou ve vektoru objekty alokovane z heapu a je ti jedno jestli tam sahnes mimo "kontext kde vznikly".

Bordel by to delalo jedine, kdyz by to byl vector<Trida&> misto vector<Trida>, ale predpokladam ze bez spravneho duvodu to tazatel delat nebude.

[ava]

For(int i = 0; i<10; i++)
 someVector.push_back( Trida() )

uz si potencialne zadelavas na segmentation fault, kdyz se treba budes pokouset pristupovat k polozkam toho vektoru mimo kontext kde vznikly. Techto oseru je C++ plne. Jestli potrebujes neco podobneho C++, ale done right, zkus radsi Rust, obzvlast kdyz mas svobodu teprve si vybirat.

Kecy, v tomto případě si kolekce dělá kopii nebo move (podle verze/třídy), ale chovat se to bude korektně. Akorát lepší než push je emplace.

Jo, zboj ma pravdu, zmatl me anonym s prispevkem "kopie se asi neudela protoze push_back( Trida &trida)". Omlouvam se za zmateni.

[zboj]

uz si potencialne zadelavas na segmentation fault, kdyz se treba budes pokouset pristupovat k polozkam toho vektoru mimo kontext kde vznikly. Techto oseru je C++ plne. Jestli potrebujes neco podobneho C++, ale done right, zkus radsi Rust, obzvlast kdyz mas svobodu teprve si vybirat.

Kecy, v tomto případě si kolekce dělá kopii nebo move (podle verze/třídy), ale chovat se to bude korektně. Akorát lepší než push je emplace.

A kdyby si neco kopii neudelalo, napr. nejaka custom kolekce, tak by k segfault skutecne doslo v pripade pristupovani k tem objektum z jinaciho scopu? (predpokladam ze scope je myslena hierarchie slozenych zavorech {}  )
[/quote] Ne, kopii dělá překladač. Pokud se předává hodnotou, překladač se o to postará.

[zboj]

Nejsem C++kář a potřebuju si v tom něco napsat OOP.

Naco jsou tam ty hlavičkové souboru *.h a k nim vždycky ještě *.cpp, když to budu psát OOP a už samotná třída definuje svoje rozhraní sama o sobě? Chápu to správně, že hlavičky slouží jen jako interface k binárce? Potom by mi ovšem stačil jen hlavičkový soubor k binárce, nemusím ho dělat ke každé třídě v rámci jedné binárky, ni?

Další věc statická alokace paměti. Veškeré třídy, jejichž instance se nebudou množit za běhu aplikace, můžu alokovat staticky bez operátoru new. Dá se to tak brát? Tzn. řekněme v praxi by mělo být tak cca 90% všech alokací v C++ statických.

Pokud nějakou instanci alokuji dynamicky, ale v rámci té třídy už alokuju staticky, pak předpokládám, že kompilátor není blbý a i ty statické alokace budou na heapu a ne ve stacku. Jako např. budu mít nějaký vector a do toho budu v cyklu přidávat staticky alokované instance, tak potom tyto instance budou ve výsledku alokovány na heapu, je to tak? Doufám že jo.

Díky.

A jen tak mimoběžně, proč to má být C++? Pokud pro to není vážný důvod, ještě bych to zvážil.

[TRLL]

Toto je dôvod prečo C++ považujem za najhorší programovací jazyk aký sa používa. To, že taká primitívna vec ako popísaná tu je tak komplikovaná a záludná je neuveriteľné. Ako toto môže niekto používať a ešte si to chváliť.

[anonym]

uz si potencialne zadelavas na segmentation fault, kdyz se treba budes pokouset pristupovat k polozkam toho vektoru mimo kontext kde vznikly. Techto oseru je C++ plne. Jestli potrebujes neco podobneho C++, ale done right, zkus radsi Rust, obzvlast kdyz mas svobodu teprve si vybirat.

Kecy, v tomto případě si kolekce dělá kopii nebo move (podle verze/třídy), ale chovat se to bude korektně. Akorát lepší než push je emplace.

A kdyby si neco kopii neudelalo, napr. nejaka custom kolekce, tak by k segfault skutecne doslo v pripade pristupovani k tem objektum z jinaciho scopu? (predpokladam ze scope je myslena hierarchie slozenych zavorech {}  )

Ne, kopii dělá překladač. Pokud se předává hodnotou, překladač se o to postará.
[/quote]

Jasně, chápu že když předáváš hodnou, dělá se kopie. Jenže vector je definován takto:

void push_back (const value_type& val);

Tzn. nepředává se hodnotou, ale odkazem. Nicméně v dokumentaci je uvedeno, ze se bude provadet move nebo copy, takze to nebudu dál rozebírat.

Takže segfaul by mohl vzniknout takhle?

Kód: [Vybrat]


int someGlobal;

void someFunction() {
  int someLocal = 10;
  &someGlobal = &someLocal;
}

void segmentantion_fault() {
  someGlobal = 123;
}

void main() {
  someFunction();
  segmentation_fault();
}