Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Kontinuace je univerzálnější, ale taky abstraktnější (a někdy to je dost zmatek, stačí zkusit si pro kontinuaci napsat >>=). Nejlépe se tento typ kódu píše v CSP, je to triviální a univerzální.Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory....a generatory jsou o rad horsi nez kontinuace.
Zase ho strašíš další monádou?Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory....a generatory jsou o rad horsi nez kontinuace.
Jen tak pro informaci: http://www.i-programmer.info/news/150-training-a-education/10716-stanford-cs-moves-to-javascript.htmlPoužívejte === a ruční konverzi když si nejste jistý.Vymyslel jsem lepsi reseni: nepouzivam JavaScriptale vám na jednu stranu vadí maličkosti v JS a na druhou stranu obhajujete Go, kde vám různé speciální případy a nedokonalosti jazyka skutečně komplikují život.Ze v jazyce funguji veci naprosto neocekavatelnym zpusobem neni malickost, ale zcela zasadni showstopper, pokud clovek nechce zesilet.
O jakych konkretne "speciálních případech" a "nedokonalostech" se bavime u Go? BTW, neni pravda, ze bych ho obhajoval - nepouzivam ho aktivne a na muj vkus je to jazyk prilis jednoduchy, ale aspon ma (stejne jako ta Lua) svou logiku, ktera se da pochopit bez toho, aby si clovek zoufalosti vytrhal vsechny vlasy (specialita JS a C++) a ma velice user-friendly vyresenou konkurentnost, coz je aspon respektuhodne, kdyz uz nic jinyho.
macOS je ObjectiveC ne C++, je to dost rozdil.Jenže řeč je o kernelu, a tam je část v C++.
macOS dtto.CitaceOOP 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.
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.Kód: [Vybrat]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.
Tyy vole co to zas ma byt to Object slicing, proc sakra nejde jednoduse udelatA 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.
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.
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ů.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?
Alokuje nový objekt a obsah přesune. To už závisí na konkrétním objektu, jak přesně se dělá move.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í).
Ne, kopii dělá překladač. Pokud se předává hodnotou, překladač se o to postará.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.
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.
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 {} )
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.
Nejsem C++kář a potřebuju si v tom něco napsat OOP.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.
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.
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.
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.
To funguje korektně, ale doporučuju emplace_back. A obecně, pokud to je pro Linux, použil bych libc++.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() )
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.