Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: anonym 26. 04. 2017, 14:25:55
-
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.
-
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?
Ty hlavičkové soubory jsou tam pro programátory, kteří chtějí v C++ psát strukturovaně.
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.
Statické třídy jsou vlastně jen náhradou za namespace u strukturovaného programování. V OOP je dobré se jim vyhnout.
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.
Dynamická alokace je na heapu, statická je vlastně jen náhradou globálních proměnných a proto se dělá už v době kompilace.
-
1) Staticky alokované věci nejsou ani stacku, ani na heapu, jsou jinde (společně) - ale statické třídy jsou něco jiného
2) ad. hlavičkové soubory - to, co není nutné, nemusí být zároveň "best-practice"...
-
Ale ja nemluvim o statickych tridach, ale o staticke alokaci, kde misto:
Trida *t = new Trida();
Napises
Trida t();
Pricemz se ptam, co se stane, kdyz udelam:
For(int i = 0; i<10; i++)
someVector.push_back( Trida() )
-
deklarace:
Trida t(); // "t" je uloženo na stackuhádám, že pak má být:
someVector.push_back( t ); // udělá se kopie, a ta se uloží do toho vektoru
-
deklarace:
Trida t(); // "t" je uloženo na stackuhádám, že pak má být:
someVector.push_back( t ); // udělá se kopie, a ta se uloží do toho vektoru
kopie se asi neudela protoze push_back( Trida &trida)
-
kopie se asi neudela protoze push_back( Trida &trida)
no ovšem, potom tam tedy je reference na zásobník = špatný nápad
-
deklarace:
Trida t(); // "t" je uloženo na stackuhádám, že pak má být:
someVector.push_back( t ); // udělá se kopie, a ta se uloží do toho vektoru
kopie se asi neudela protoze push_back( Trida &trida)
jsem to zkusil a prošlo to (g++)
-
kopie se asi neudela protoze push_back( Trida &trida)
špatný nápad
jistě, že není, bude dynamicky alokovat string abyste ho mohl předat << ?
-
kopie se asi neudela protoze push_back( Trida &trida)
špatný nápad
jistě, že není, bude dynamicky alokovat string abyste ho mohl předat << ?
Rozdíl je v tom, co s tím ten operátor << udělá, když nenechá odkaz na ten string, tak je to v pořádku.
-
kopie se asi neudela protoze push_back( Trida &trida)
no ovšem, potom tam tedy je reference na zásobník = špatný nápad
cituju cos napsal: "Staticky alokované věci nejsou ani stacku, ani na heapu, jsou jinde (společně) - ale statické třídy jsou něco jiného"
Nechces se radeji zdrzet odpovedi a nechat odpoved nekomu, kdo tomu rozumi?
-
kopie se asi neudela protoze push_back( Trida &trida)
no ovšem, potom tam tedy je reference na zásobník = špatný nápad
cituju cos napsal: "Staticky alokované věci nejsou ani stacku, ani na heapu, jsou jinde (společně) - ale statické třídy jsou něco jiného"
Nechces se radeji zdrzet odpovedi a nechat odpoved nekomu, kdo tomu rozumi?
A v čempak se pletu?
-
deklarace:
Trida t(); // "t" je uloženo na stackuhádám, že pak má být:
someVector.push_back( t ); // udělá se kopie, a ta se uloží do toho vektoru
kopie se asi neudela protoze push_back( Trida &trida)
jsem to zkusil a prošlo to (g++)
Jasne ze to proslo, co by to asi jineho melo udelat?
OMG...
-
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?
Ty hlavičkové soubory jsou tam pro programátory, kteří chtějí v C++ psát strukturovaně.
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.
Statické třídy jsou vlastně jen náhradou za namespace u strukturovaného programování. V OOP je dobré se jim vyhnout.
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.
Dynamická alokace je na heapu, statická je vlastně jen náhradou globálních proměnných a proto se dělá už v době kompilace.
Staticke triedy a staticky alokovane objekty su 2 rozdielne veci. Ale verim ze v phpcku a podobných orezaných jazykoch ako java si sa s tym asi nestretol :D
-
OOP se vzdyt dela v Jave. C++ je jen nepovedeny hack. Vzdyt i samotny kernel je psan radeji v cistem C.
-
Pěkně komické vlákno. To má potenciál!
-
Samej odborník na C++ tady :D :D :D Ještě by mohli přijít Javaman() :D :D ÁÁÁ já se lámu smíchy :D
-
Nejdriv jsem si myslel že troll je jen autor, teď tak půlka diskutujících...
-
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.
-
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ě.
-
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() )
-
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.
-
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++.
-
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 {} )
-
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.
-
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.
-
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á.
-
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.
-
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ť.
-
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?
int someGlobal;
void someFunction() {
int someLocal = 10;
&someGlobal = &someLocal;
}
void segmentantion_fault() {
someGlobal = 123;
}
void main() {
someFunction();
segmentation_fault();
}
-
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ť.
Co je na tom složitého? Funguje to out of the box.
-
Jasně, už tomu rozumím, prostě mimo scope se staticka alokace vždycky dealokuje. Takže závěrem se dá říct, že když nebudu v kódu, vyjma psaní parametrů metod a funkcí, kde potřebuju předávat odkzem, používat při práci s objekty &objekt, tzn. nebudu pracovat s jejich adresami (nevim ani jaky bych k tomu mel mit duvod), nemůže se mi nijak stát, že narazím na segfault.
Tak to zní jednoduše :)
-
Zboj: Jenže zase, co je potom rychlejší, provádět ústavičně memcopy, nebo prostě alokovat dynamicky? Nebude pak i ta Java rychlejší, než psaní v C++ samým statickým alokováním? Protože sám si řekl, že operator new je lepsi vubec nepouzivat.
-
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á.
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?
int someGlobal;
void someFunction() {
int someLocal = 10;
&someGlobal = &someLocal;
}
void segmentantion_fault() {
someGlobal = 123;
}
void main() {
someFunction();
segmentation_fault();
}
-
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?
int someGlobal;
void someFunction() {
int someLocal = 10;
&someGlobal = &someLocal;
}
void segmentantion_fault() {
someGlobal = 123;
}
void main() {
someFunction();
segmentation_fault();
}
Ne, protože do &proměnná se nedá přiřazovat.
(Po opravě překlepů a doplnění návratové hodnoty main):
test.cc:6:18: error: expression is not assignable
&someGlobal = &someLocal;
~~~~~~~~~~~ ^
1 error generated.
Zboj: Jenže zase, co je potom rychlejší, provádět ústavičně memcopy, nebo prostě alokovat dynamicky? Nebude pak i ta Java rychlejší, než psaní v C++ samým statickým alokováním? Protože sám si řekl, že operator new je lepsi vubec nepouzivat.
operator new interně používá STL (či make_unique) a move konstruktory slouží právě proto, aby se to pořád nekopírovalo.
-
Zboj: Jenže zase, co je potom rychlejší, provádět ústavičně memcopy, nebo prostě alokovat dynamicky? Nebude pak i ta Java rychlejší, než psaní v C++ samým statickým alokováním? Protože sám si řekl, že operator new je lepsi vubec nepouzivat.
Nejrychlejší je to neřešit. Slovy klasika: "Just use the STL, it's been written by people way smarter than you." Žádné memcopy se nedělá, typicky to je move, což je bez overheadu. Alternativou je použití shared_ptr, ale to už má overhead (počítání referencí).
-
Zboj: Jenže zase, co je potom rychlejší, provádět ústavičně memcopy, nebo prostě alokovat dynamicky? Nebude pak i ta Java rychlejší, než psaní v C++ samým statickým alokováním? Protože sám si řekl, že operator new je lepsi vubec nepouzivat.
Nejrychlejší je to neřešit. Slovy klasika: "Just use the STL, it's been written by people way smarter than you." Žádné memcopy se nedělá, typicky to je move, což je bez overheadu. Alternativou je použití shared_ptr, ale to už má overhead (počítání referencí).
A jak funguje ten move, předpoladam že se nekopuje cely blok pameti, ale jen adresa? Protoze jinak by to asi nebylo o moc rychlejsi nez memcopy. Takze ten move v podstate by mel fungovat tak, ze znovu alokuje pamet jiz vyhrazenou pro nejakou tu staticky alokovanou promennou a ta pamet pak jiz spada pod scope promenne, do ktere bylo move provedeno, je to tak?
-
Zboj: Jenže zase, co je potom rychlejší, provádět ústavičně memcopy, nebo prostě alokovat dynamicky? Nebude pak i ta Java rychlejší, než psaní v C++ samým statickým alokováním? Protože sám si řekl, že operator new je lepsi vubec nepouzivat.
Nejrychlejší je to neřešit. Slovy klasika: "Just use the STL, it's been written by people way smarter than you." Žádné memcopy se nedělá, typicky to je move, což je bez overheadu. Alternativou je použití shared_ptr, ale to už má overhead (počítání referencí).
A jak funguje ten move, předpoladam že se nekopuje cely blok pameti, ale jen adresa? Protoze jinak by to asi nebylo o moc rychlejsi nez memcopy. Takze ten move v podstate by mel fungovat tak, ze znovu alokuje pamet jiz vyhrazenou pro nejakou tu staticky alokovanou promennou a ta pamet pak jiz spada pod scope promenne, do ktere bylo move provedeno, je to tak?
Alokuje nový objekt a obsah přesune. To už závisí na konkrétním objektu, jak přesně se dělá move.
-
Přiřazením ne, spíš při čtení pointru na něco, co už neexistuje. V C++ obecně platí: nepoužívat pointry. Pak se nemůže nic zlého stát. Překladač je dostatečně inteligentní na to, aby se postaral o veškeré kopie a přesuny (move) a když se dodrží pár víceméně univerzálně platných principů, it just works. Princip práce C++ je jednoduchý a STL je dostatečně robustní na to, aby se člověk nestřelil do nohy, když nedělá kraviny (jako třeba použití new).
Jak se realizuje třídní polymorfismus v C++ bez new?
-
Přiřazením ne, spíš při čtení pointru na něco, co už neexistuje. V C++ obecně platí: nepoužívat pointry. Pak se nemůže nic zlého stát. Překladač je dostatečně inteligentní na to, aby se postaral o veškeré kopie a přesuny (move) a když se dodrží pár víceméně univerzálně platných principů, it just works. Princip práce C++ je jednoduchý a STL je dostatečně robustní na to, aby se člověk nestřelil do nohy, když nedělá kraviny (jako třeba použití new).
Jak se realizuje třídní polymorfismus v C++ bez new?
SomeA a = SomeB();
To v Rustu nemate?
-
Přiřazením ne, spíš při čtení pointru na něco, co už neexistuje. V C++ obecně platí: nepoužívat pointry. Pak se nemůže nic zlého stát. Překladač je dostatečně inteligentní na to, aby se postaral o veškeré kopie a přesuny (move) a když se dodrží pár víceméně univerzálně platných principů, it just works. Princip práce C++ je jednoduchý a STL je dostatečně robustní na to, aby se člověk nestřelil do nohy, když nedělá kraviny (jako třeba použití new).
Jak se realizuje třídní polymorfismus v C++ bez new?
Přes ukazatele. Ono to new je samozřejmě schované v STL, ale explicitně je kravina ho používat, když chce člověk bezpečný kód, takže to chce make_shared apod. Proto má taky C++ auto, aby člověk nezešedivěl při rozepisování typů.
-
Zboj: Jenže zase, co je potom rychlejší, provádět ústavičně memcopy, nebo prostě alokovat dynamicky? Nebude pak i ta Java rychlejší, než psaní v C++ samým statickým alokováním? Protože sám si řekl, že operator new je lepsi vubec nepouzivat.
Nejrychlejší je to neřešit. Slovy klasika: "Just use the STL, it's been written by people way smarter than you." Žádné memcopy se nedělá, typicky to je move, což je bez overheadu. Alternativou je použití shared_ptr, ale to už má overhead (počítání referencí).
A jak funguje ten move, předpoladam že se nekopuje cely blok pameti, ale jen adresa? Protoze jinak by to asi nebylo o moc rychlejsi nez memcopy. Takze ten move v podstate by mel fungovat tak, ze znovu alokuje pamet jiz vyhrazenou pro nejakou tu staticky alokovanou promennou a ta pamet pak jiz spada pod scope promenne, do ktere bylo move provedeno, je to tak?
Alokuje nový objekt a obsah přesune. To už závisí na konkrétním objektu, jak přesně se dělá move.
Tak obecně je move konstrukce efektivnější jen v případě, že se v dané třídě odkazuje na nějaká dynamicky alokovaná data. Obyčejné membery stejně musíš zkopírovat.
-
Tyy vole co to zas ma byt to Object slicing, proc sakra nejde jednoduse udelat
A a = ChildOfA()
?
Jak bych fakt nekoho videl vyuzivat v kodu jakymkoliv zpusobem object slicing, tak bych ho normalne poslal do pejci. Jazyk by vubec nemel neco takoveho umoznovat.
Uz chapu, proc se tolik lidi vysralo na statickou alokaci a proste vsude v C++ pouzivaji operator new, to aby nemuseli resit a chapat tyhlety C++ srajdy, to nemuze chtit zadny normalni clovek chapat. Ty vole dyt to je horsi nez javascript. Kaslu na C++ a napisu si to v Céčku, ja na blbosti nemam cas. C++ vypada asi tak, jako uz od pohledu ten blazen Soustrup.
-
Tyy vole co to zas ma byt to Object slicing, proc sakra nejde jednoduse udelat
A a = ChildOfA()
?
Jak bych fakt nekoho videl vyuzivat v kodu jakymkoliv zpusobem object slicing, tak bych ho normalne poslal do pejci. Jazyk by vubec nemel neco takoveho umoznovat.
Uz chapu, proc se tolik lidi vysralo na statickou alokaci a proste vsude v C++ pouzivaji operator new, to aby nemuseli resit a chapat tyhlety C++ srajdy, to nemuze chtit zadny normalni clovek chapat. Ty vole dyt to je horsi nez javascript. Kaslu na C++ a napisu si to v Céčku, ja na blbosti nemam cas. C++ vypada asi tak, jako uz od pohledu ten blazen Soustrup.
No tak jako představa, že přijdu k C++ a za dva dny se ho naučím, je značně pomýlená. Je to powerfulní, ale komplexní jazyk.
-
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ť.
Ale ono je to naprosto jednoduchy. Jen o tom musis neco vedet a nemyslet si, ze kdyz znas python a javascript, tak s tim vystacis.
-
tohle je nejake desne rafinovane aprilove vlakno?
-
Uz chapu, proc se tolik lidi vysralo na statickou alokaci a proste vsude v C++ pouzivaji operator new
Je to bezpečný způsob použití velmi podobný jiným rozšířeným jazykům. Krom toho, při alokaci objektů na zásobníku některé OOP mechanismy nefungují (stejně tak v konstruktorech). Samozřejmě je třeba si hlídat memory leaky, ať už jakýmkoliv způsobem.
C++ nabízí dost prostředků, které se vám mohou hodit např. v případě, že píšete něco náročného na výkon. Ale nikdo je vás nenutí využívat, když nechcete. Prostě si vyberte podmnožinu věcí, co C++ umí, a používejte ji; časem ji můžete obohatit např. o nějaké to šablonové peklo.
-
btw na stl vektoru atd je fajn ze ani nedovoli napsat nejakou idiotskou kombinaci ktera by mohla udelat ten vektor nekonzistentni/faultujici. strkat tam reference, objekty co nemai copy constructor atd atd neprojde uz na urovni kompilace a to nejhorsi co se muze stat neni crash ale ze se budou delat idiotske kopie.
tak to je prakticky se vsemi zde uvadenymi examply tech zarucene faultujicich kodu, zadna z nich neni ani prelozitelny....
-
Tyy vole co to zas ma byt to Object slicing, proc sakra nejde jednoduse udelat
A a = ChildOfA()
?
Jak bych fakt nekoho videl vyuzivat v kodu jakymkoliv zpusobem object slicing, tak bych ho normalne poslal do pejci. Jazyk by vubec nemel neco takoveho umoznovat.
Uz chapu, proc se tolik lidi vysralo na statickou alokaci a proste vsude v C++ pouzivaji operator new, to aby nemuseli resit a chapat tyhlety C++ srajdy, to nemuze chtit zadny normalni clovek chapat. Ty vole dyt to je horsi nez javascript. Kaslu na C++ a napisu si to v Céčku, ja na blbosti nemam cas. C++ vypada asi tak, jako uz od pohledu ten blazen Soustrup.
A proč ne make_shared teda? S tím OOP funguje podle předpokladů. Jinak někdy je fakt lepší čisté C, případně něco relativně blízkého - Rust, Go etc.
-
Uz chapu, proc se tolik lidi vysralo na statickou alokaci a proste vsude v C++ pouzivaji operator new
Je to bezpečný způsob použití velmi podobný jiným rozšířeným jazykům. Krom toho, při alokaci objektů na zásobníku některé OOP mechanismy nefungují (stejně tak v konstruktorech). Samozřejmě je třeba si hlídat memory leaky, ať už jakýmkoliv způsobem.
C++ nabízí dost prostředků, které se vám mohou hodit např. v případě, že píšete něco náročného na výkon. Ale nikdo je vás nenutí využívat, když nechcete. Prostě si vyberte podmnožinu věcí, co C++ umí, a používejte ji; časem ji můžete obohatit např. o nějaké to šablonové peklo.
Jo? Tak asi zase tak moc bezpecny zpusob to neni, kdyz tady zboj radi operatory new vubec nepouzivat a kdyz uz, tak misto nich shared pointry. Sam v tom nemas jasno, tak radeji mlc a najdi si o tom neco na stackoverflow.
-
Uz chapu, proc se tolik lidi vysralo na statickou alokaci a proste vsude v C++ pouzivaji operator new
Je to bezpečný způsob použití velmi podobný jiným rozšířeným jazykům. Krom toho, při alokaci objektů na zásobníku některé OOP mechanismy nefungují (stejně tak v konstruktorech). Samozřejmě je třeba si hlídat memory leaky, ať už jakýmkoliv způsobem.
C++ nabízí dost prostředků, které se vám mohou hodit např. v případě, že píšete něco náročného na výkon. Ale nikdo je vás nenutí využívat, když nechcete. Prostě si vyberte podmnožinu věcí, co C++ umí, a používejte ji; časem ji můžete obohatit např. o nějaké to šablonové peklo.
Jo? Tak asi zase tak moc bezpecny zpusob to neni, kdyz tady zboj radi operatory new vubec nepouzivat a kdyz uz, tak misto nich shared pointry. Sam v tom nemas jasno, tak radeji mlc a najdi si o tom neco na stackoverflow.
On to hlavně radí Stroustrup nebo třeba Sutter, lidi, co navrhli C++ tak, aby new bylo někde hluboko ve standardní knihovně. Jinak je new dobré je pro vytvoření objektu, který potřebuji dát odkazem mimo C++, třeba do C nebo C#. Jinak unique_ptr má zanedbatelnou režii.
-
Jo? Tak asi zase tak moc bezpecny zpusob to neni, kdyz tady zboj radi operatory new vubec nepouzivat a kdyz uz, tak misto nich shared pointry. Sam v tom nemas jasno, tak radeji mlc a najdi si o tom neco na stackoverflow.
I se smart pointery se interně alokuje dynamicky a je dobré o tom vědět. Moje poznámka o bezpečnosti se vztahovala k tomu, že při použití dynamické alokace se vše bude chovat podobně jako jsou lidé zvyklí z jiných jazyků. Že se práce s čistými pointery nedoporučuje, je jasné. Ani smart pointery ale neřeší všechno.
Když budete používat new a čisté ukazatele, sice se nevyhnete problémům s memory leaky a obecně s pointery (což není nic objevného), ale zase se vyhnete věcem, nad kterými tady nadáváte.
-
OOP se vzdyt dela v Jave. C++ je jen nepovedeny hack. Vzdyt i samotny kernel je psan radeji v cistem C.
Pokud můžu mluvit za WIndows kernel, tak některé části v C++ jsou (např. Windows Driver Framework) a někteří výrobci své ovladače píší také v tomto jazyku. Pokud si člověk dává pozor, nepředstavuje C++ v jádře problém.
-
C++ na nic nového nepoužívej. Jak dlouho asi ještě potrvá, než se přijde na to, že C++ byla fakt slepá ulička... Ani ryba, ani rak.
Jedeš na výkon a jde o systémové/low level věci? -> C
Jedeš na výkon a jde o matematiku? -> Fortran
Jedeš na výkon a jde o kritické věci? -> Ada
Nejde o výše uvedené a jedeš na výkon? -> na této úrovni to nevězí, zvol si vhodnou low level/matematickou/kritickou knihovnu a svou vrstvu napiš v čem chceš. C++ a Brainfucku bych se ale vyhnul.
:D
-
OOP se vzdyt dela v Jave. C++ je jen nepovedeny hack. Vzdyt i samotny kernel je psan radeji v cistem C.
Pokud můžu mluvit za WIndows kernel, tak některé části v C++ jsou (např. Windows Driver Framework) a někteří výrobci své ovladače píší také v tomto jazyku. Pokud si člověk dává pozor, nepředstavuje C++ v jádře problém.
macOS dtto.
-
macOS je ObjectiveC ne C++, je to dost rozdil.
-
macOS je ObjectiveC ne C++, je to dost rozdil.
Jenže řeč je o kernelu, a tam je část v C++.
-
C++ na nic nového nepoužívej. Jak dlouho asi ještě potrvá, než se přijde na to, že C++ byla fakt slepá ulička... Ani ryba, ani rak.
Jedeš na výkon a jde o systémové/low level věci? -> C
Jedeš na výkon a jde o matematiku? -> Fortran
Jedeš na výkon a jde o kritické věci? -> Ada
Nejde o výše uvedené a jedeš na výkon? -> na této úrovni to nevězí, zvol si vhodnou low level/matematickou/kritickou knihovnu a svou vrstvu napiš v čem chceš. C++ a Brainfucku bych se ale vyhnul.
:D
Tato sada pravidel vypadá docela rozumně. C++ bych však úplně nezatracoval - dá se využít tam, kde je na vývoj dostatek času a musí se přitom šetřit každá nanosekunda běhu aplikace.
-
C++ na nic nového nepoužívej. Jak dlouho asi ještě potrvá, než se přijde na to, že C++ byla fakt slepá ulička... Ani ryba, ani rak.
Jedeš na výkon a jde o systémové/low level věci? -> C
Jedeš na výkon a jde o matematiku? -> Fortran
Jedeš na výkon a jde o kritické věci? -> Ada
Nejde o výše uvedené a jedeš na výkon? -> na této úrovni to nevězí, zvol si vhodnou low level/matematickou/kritickou knihovnu a svou vrstvu napiš v čem chceš. C++ a Brainfucku bych se ale vyhnul.
:D
Tato sada pravidel vypadá docela rozumně. C++ bych však úplně nezatracoval - dá se využít tam, kde je na vývoj dostatek času a musí se přitom šetřit každá nanosekunda běhu aplikace.
No tak je to samozřejmě s nadsázkou, C++ mě živilo nějakých 15 let. :) Ale právě proto tvrdím, co tvrdím. Jeden z mých posledních C++ projektů byla modifikace průmyslového firmware (128 KB @ ARM7TDMI) tak, aby se určitý nový výpočet vešel do synchronního rámce a jeho algoritmus a potřebná data do paměti, v níž zbývaly nějaké 4 KB. To ++ opravdu nebylo nic jiného než jen 4 zkřížené klacky pod nohama toho C. I programy v Assembleru se mi upravovaly pohodlněji a příjemněji než v C++.
Momentálně jsem na úplně novém C projektu (zahájen před 2 lety from scratch) a ty klacky tu nikomu nechyběj. Aplikační vrstva se vyvíjí v Elixiru. Po dlouhé době mě práce opět baví. Je to jako kdyby se člověk zbavil koule na noze a cítíme to všichni v týmu. Prostě to objektové pojetí v C++ mi nikdy nesedlo a ani si nevzpomínám, že bych kdy viděl program, u něhož bych mohl říct "sakra, to je vono, takhle by to mělo vypadat". Narozdíl od Obj C nebo Smalltalku. Takže jestli někdo víte o nějakém open source projektu v C++ o němž byste řekli, že tak by to mělo vypadat, tak se rád mrknu.
-
C++ na nic nového nepoužívej. Jak dlouho asi ještě potrvá, než se přijde na to, že C++ byla fakt slepá ulička... Ani ryba, ani rak.
Jedeš na výkon a jde o systémové/low level věci? -> C
Jedeš na výkon a jde o matematiku? -> Fortran
Jedeš na výkon a jde o kritické věci? -> Ada
Nejde o výše uvedené a jedeš na výkon? -> na této úrovni to nevězí, zvol si vhodnou low level/matematickou/kritickou knihovnu a svou vrstvu napiš v čem chceš. C++ a Brainfucku bych se ale vyhnul.
:D
Tato sada pravidel vypadá docela rozumně. C++ bych však úplně nezatracoval - dá se využít tam, kde je na vývoj dostatek času a musí se přitom šetřit každá nanosekunda běhu aplikace.
No tak je to samozřejmě s nadsázkou, C++ mě živilo nějakých 15 let. :) Ale právě proto tvrdím, co tvrdím. Jeden z mých posledních C++ projektů byla modifikace průmyslového firmware (128 KB @ ARM7TDMI) tak, aby se určitý nový výpočet vešel do synchronního rámce a jeho algoritmus a potřebná data do paměti, v níž zbývaly nějaké 4 KB. To ++ opravdu nebylo nic jiného než jen 4 zkřížené klacky pod nohama toho C. I programy v Assembleru se mi upravovaly pohodlněji a příjemněji než v C++.
Momentálně jsem na úplně novém C projektu (zahájen před 2 lety from scratch) a ty klacky tu nikomu nechyběj. Aplikační vrstva se vyvíjí v Elixiru. Po dlouhé době mě práce opět baví. Je to jako kdyby se člověk zbavil koule na noze a cítíme to všichni v týmu. Prostě to objektové pojetí v C++ mi nikdy nesedlo a ani si nevzpomínám, že bych kdy viděl program, u něhož bych mohl říct "sakra, to je vono, takhle by to mělo vypadat". Narozdíl od Obj C nebo Smalltalku. Takže jestli někdo víte o nějakém open source projektu v C++ o němž byste řekli, že tak by to mělo vypadat, tak se rád mrknu.
jak resite interoperabilitu c / elixir?
-
K čemu jsou v C++ hlavičky? No každá kompilační jednotka (cpp soubor) je kompilována samostatně oddělené od ostatních. Musí tedy být kompletní a samostatná. Překladač pro prohnání zdrojáků preprocesorem se zabývá jen tím jedním souborem a ničím jiným. To třeba umožňuje překládat na jiném stroji (distcc).
Každopádně, hlavičky jsou potřeba, aby se společné definice vložily všude tam, kde jsou třeba. Nechceš je tam snad pořád dokola přepisovat. Když mám například dva soubory cpp, které používají jednu třídu, je třeba tu třídu strčit do nějakého společného souboru, který se vloží do každého cpp, aby tu třídu překladač viděl v každém tom cpp. Tomuto souboru se říká hlavičkový soubor.
-
jak resite interoperabilitu c / elixir?
Přes NIFy.
-
no nevim, pohybuju se kolem grafiky a tam naopak neexistuje prakticky jiny jazyk nez c++. jeho zastoupeni tipuju na 99%.
nemyslim ze z soucasnych jazyku se da poskladat alternativa, a kdyz za 2 roky vznikne, tak stejne v produkcni kvalite bude tak za 10 let. hlavne ani nevidim zadne tendence a uvahy o tom ze existuje i neco jineho nez c++, teda krome kousku cuda,opencl,hlsl,glsl kde se vyuzije zpetna kompatibilita s c.
osobne v c++ napisu rychleji i jednorazovky na urovni shellovych scriptu, urcite to neni ani pomaly jazyk na prototypovani....
-
no nevim, pohybuju se kolem grafiky a tam naopak neexistuje prakticky jiny jazyk nez c++. jeho zastoupeni tipuju na 99%.
nemyslim ze z soucasnych jazyku se da poskladat alternativa, a kdyz za 2 roky vznikne, tak stejne v produkcni kvalite bude tak za 10 let. hlavne ani nevidim zadne tendence a uvahy o tom ze existuje i neco jineho nez c++, teda krome kousku cuda,opencl,hlsl,glsl kde se vyuzije zpetna kompatibilita s c.
osobne v c++ napisu rychleji i jednorazovky na urovni shellovych scriptu, urcite to neni ani pomaly jazyk na prototypovani....
To je o zvyku a zkušenostech, někdo v C++ během chvilky napíše kdeco, jiný (pseudoprogramátor à la Javista) si vytrhá všechny vlasy nad první třídou.
-
no nevim, pohybuju se kolem grafiky a tam naopak neexistuje prakticky jiny jazyk nez c++. jeho zastoupeni tipuju na 99%.
nemyslim ze z soucasnych jazyku se da poskladat alternativa, a kdyz za 2 roky vznikne, tak stejne v produkcni kvalite bude tak za 10 let. hlavne ani nevidim zadne tendence a uvahy o tom ze existuje i neco jineho nez c++, teda krome kousku cuda,opencl,hlsl,glsl kde se vyuzije zpetna kompatibilita s c.
osobne v c++ napisu rychleji i jednorazovky na urovni shellovych scriptu, urcite to neni ani pomaly jazyk na prototypovani....
To je o zvyku a zkušenostech, někdo v C++ během chvilky napíše kdeco, jiný (pseudoprogramátor à la Javista) si vytrhá všechny vlasy nad první třídou.
Pry pseudoprgramator ala Java, a kdyz se v C++ musis stvat se zavislostma protoze nemate nic jako je Maven, musíš vyplňovat stohy zbytečných .h hlaviček a stohy dalších věcí, o nichž se vsadím, že v tomto tématu byla řečena pouze malá část, tak to si potom teprve budeš připadat jako ten pravý programátor? A jak se cítíš, když ti přijde výplatní páska a na ní máš míň než tvůj ekvivalent pracující v Javě - nejsi potom tak trošku z toho zamindrákovaný, že tu svou efektivitu práce vidíš i na výplatě? No to se ale nesmiš divit, uklízečce taky nikdo nezaplatí víc, když bude pečlivě čistit záchody zubním kartáčkem.
-
no nevim, pohybuju se kolem grafiky a tam naopak neexistuje prakticky jiny jazyk nez c++. jeho zastoupeni tipuju na 99%.
nemyslim ze z soucasnych jazyku se da poskladat alternativa, a kdyz za 2 roky vznikne, tak stejne v produkcni kvalite bude tak za 10 let. hlavne ani nevidim zadne tendence a uvahy o tom ze existuje i neco jineho nez c++, teda krome kousku cuda,opencl,hlsl,glsl kde se vyuzije zpetna kompatibilita s c.
osobne v c++ napisu rychleji i jednorazovky na urovni shellovych scriptu, urcite to neni ani pomaly jazyk na prototypovani....
To je o zvyku a zkušenostech, někdo v C++ během chvilky napíše kdeco, jiný (pseudoprogramátor à la Javista) si vytrhá všechny vlasy nad první třídou.
Pry pseudoprgramator ala Java, a kdyz se v C++ musis stvat se zavislostma protoze nemate nic jako je Maven, musíš vyplňovat stohy zbytečných .h hlaviček a stohy dalších věcí, o nichž se vsadím, že v tomto tématu byla řečena pouze malá část, tak to si potom teprve budeš připadat jako ten pravý programátor? A jak se cítíš, když ti přijde výplatní páska a na ní máš míň než tvůj ekvivalent pracující v Javě - nejsi potom tak trošku z toho zamindrákovaný, že tu svou efektivitu práce vidíš i na výplatě? No to se ale nesmiš divit, uklízečce taky nikdo nezaplatí víc, když bude pečlivě čistit záchody zubním kartáčkem.
Necítím se nijak, mám svou firmu (za mořem), kde se dělá v Javě i C++.
-
c++11 je pomerne kompletni a da se v nem psat velmi rychle. driv vadila ona nekompletnost pro jednoduche veci, casto nahrazovana boostem a jinymi knihovnami, dnes je to nejen vykonny jazyk ale pise se v nem kod uplne stejne rychle jak v vyssich jazycich. bezne pisu multithread skoro kazdou blbinu, protoze tam neni prakticky zadna rezie navic, pokud timto zpusobem jste zvykli i premyslet
-
c++11 je pomerne kompletni a da se v nem psat velmi rychle. driv vadila ona nekompletnost pro jednoduche veci, casto nahrazovana boostem a jinymi knihovnami, dnes je to nejen vykonny jazyk ale pise se v nem kod uplne stejne rychle jak v vyssich jazycich. bezne pisu multithread skoro kazdou blbinu, protoze tam neni prakticky zadna rezie navic, pokud timto zpusobem jste zvykli i premyslet
V C++11 ještě pár věcí chybělo, řekl bych, že uspokojivého stavu dosáhlo C++14. A teď je za dveřmi C++17.
-
11 byla revolucni, 14, 17 beru jako evoluce. jinak se asi shodnem.
-
no nevim, pohybuju se kolem grafiky a tam naopak neexistuje prakticky jiny jazyk nez c++. jeho zastoupeni tipuju na 99%.
nemyslim ze z soucasnych jazyku se da poskladat alternativa, a kdyz za 2 roky vznikne, tak stejne v produkcni kvalite bude tak za 10 let. hlavne ani nevidim zadne tendence a uvahy o tom ze existuje i neco jineho nez c++, teda krome kousku cuda,opencl,hlsl,glsl kde se vyuzije zpetna kompatibilita s c.
osobne v c++ napisu rychleji i jednorazovky na urovni shellovych scriptu, urcite to neni ani pomaly jazyk na prototypovani....
To je o zvyku a zkušenostech, někdo v C++ během chvilky napíše kdeco, jiný (pseudoprogramátor à la Javista) si vytrhá všechny vlasy nad první třídou.
Pry pseudoprgramator ala Java, a kdyz se v C++ musis stvat se zavislostma protoze nemate nic jako je Maven, musíš vyplňovat stohy zbytečných .h hlaviček a stohy dalších věcí, o nichž se vsadím, že v tomto tématu byla řečena pouze malá část, tak to si potom teprve budeš připadat jako ten pravý programátor? A jak se cítíš, když ti přijde výplatní páska a na ní máš míň než tvůj ekvivalent pracující v Javě - nejsi potom tak trošku z toho zamindrákovaný, že tu svou efektivitu práce vidíš i na výplatě? No to se ale nesmiš divit, uklízečce taky nikdo nezaplatí víc, když bude pečlivě čistit záchody zubním kartáčkem.
Necítím se nijak, mám svou firmu (za mořem), kde se dělá v Javě i C++.
Zboj, pošli mi nějaké love, naco jich budeš mít tolik? Já tě za to budu chránit na root.cz.
-
Pry pseudoprgramator ala Java, a kdyz se v C++ musis stvat se zavislostma protoze nemate nic jako je Maven, musíš vyplňovat stohy zbytečných .h hlaviček a stohy dalších věcí, o nichž se vsadím, že v tomto tématu byla řečena pouze malá část, tak to si potom teprve budeš připadat jako ten pravý programátor? A jak se cítíš, když ti přijde výplatní páska a na ní máš míň než tvůj ekvivalent pracující v Javě - nejsi potom tak trošku z toho zamindrákovaný, že tu svou efektivitu práce vidíš i na výplatě? No to se ale nesmiš divit, uklízečce taky nikdo nezaplatí víc, když bude pečlivě čistit záchody zubním kartáčkem.
Jejda, tak nevím, kdo je tu zamindrákovanej :-)
-
hlavičkové soubory jsou pro interface, cpp soubory jsou pro implementaci.
-
To je zase sranda ;D
-
.... na C++ se vyser Java je mnohem lepší ;D a .h soubory stejně nepotřebuješ ani v C++ ani v Javě ani nikde jinde...
-
.... na C++ se vyser Java je mnohem lepší ;D a .h soubory stejně nepotřebuješ ani v C++ ani v Javě ani nikde jinde...
To by mě zajímalo, jak v C++ programujete bez hlavičkových souborů
-
.... na C++ se vyser Java je mnohem lepší ;D a .h soubory stejně nepotřebuješ ani v C++ ani v Javě ani nikde jinde...
To by mě zajímalo, jak v C++ programujete bez hlavičkových souborů
Napise cely projekt do jednoho souboru :D
-
Jinak to byva popsano v knihach vetsinou hned na zacatku.
-
hlavičkové soubory jsou pro interface, cpp soubory jsou pro implementaci.
Toto neplatí zdaleka vždy. Existují header-only knihovny (např. v Boostu je jich většina), které není třeba linkovat, protože veškerá implementace je v headerech.
Při programování šablon stejně implementace bude nejšíš v headeru, ale na to přijdeš sám, proč.