Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Xxxxxx 04. 09. 2018, 06:10:47

Název: Old C++ VS C++11, 14, 17
Přispěvatel: Xxxxxx 04. 09. 2018, 06:10:47
Tady to je furt rust, go, java, c#.

Ale co vy C++kari, jedete postaru, nebo v C++17, jak jste si zvykli, kdy jste poprve zjistili, ze je C++11? Kam az to povede, zmeni se C++ postupne v "Rust"?
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Xxxxxx 04. 09. 2018, 06:12:50
Jak se vam libi boost?
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: n 04. 09. 2018, 06:56:07
Osobni nazor: Dneska uz jedine c++14 a novejsi, boost fuj.
C++ se zmenilo hodne. Da se v nem dneska psat uplne jinym zpusobem, nez ve starem C. Na raw pointry skoro clovek nemusi narazit, pokud pouziva nove featury.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: oss 04. 09. 2018, 07:31:53
U mna to bol skok, povodne som zacinal na old C++, potom som robil dlhodobo ine jazyky, a nasledne som sa vratil k C++11/14 a bol to uplne iny svet.
Na pointerovu aritmetiku clovek nenarazi, na pointre len ked vytvara pole, sprava pamete sa stala zrazu neuveritelne jednoducha a intuitivna (uniq_ptr, moove constructor), pridana podpora funkcionalnych prvkov, const expressions,...
Prosto parada.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: aaaa 04. 09. 2018, 08:10:25
me tak napadlo, ze misto move by se mohl pouzit nejaky znak.
jako je = bezne copy, tak neco by mohlo byt pro move, neco jako <=<
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: JSH 04. 09. 2018, 08:28:43
me tak napadlo, ze misto move by se mohl pouzit nejaky znak.
jako je = bezne copy, tak neco by mohlo byt pro move, neco jako <=<
Tím myslíš, že by
Kód: [Vybrat]
a = std::move( b )
šlo zkrátit na
Kód: [Vybrat]
a <=< b
Byl by to nový operátor s vlastním přetěžováním? Nebo jenom syntaktický cukr, co by využíval současný operátor přiřazení?

Osobně si myslím, že to za to nestojí. Při přiřazování používám move jen výjímečně. Daleko častěji přesouvám při předávání parametrů, nebo v konstruktorech. A navrch se při přiřazování použije move automaticky, pokud přiřazuju třeba návratovou hodnotu funkce. Takže by to bylo užitečné akorát při přesunu z jedné proměnné do druhé.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: MarSik 04. 09. 2018, 08:58:39
Taky musím říct, že "znovu-objevení" C++11 a 14 byl velký skok a příjemné překvapení.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: JSH 04. 09. 2018, 09:00:15
A jinak k původní otázce, C++14/17 je úplně jiný jazyk, než to původní. Píše se v tom výrazně líp. Že se už nemusím mrcasit s new/delete je fajn, ale to šlo s knihovníma smart pointerama i postaru. To, jak vylepšili auto je fakt supr.
Třeba
Kód: [Vybrat]
auto [iter, inserted] = muj_set.insert( ... );
nebo
Kód: [Vybrat]
std::lock_guard lock( muj_mutex ); // překladač sám doplní typ do šablony
nebo se konečně dají pořádně vnořovat namespacy
Kód: [Vybrat]
namespace foo::bar::baz {
}
A třeba při použití variadických šablon a "if constexpr" se už šablonový kód dá občas i číst. :)
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Madafa 04. 09. 2018, 09:01:10
Kód: [Vybrat]
a <=< b

To už je, říká se tomu https://cs.wikipedia.org/wiki/Brainfuck
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: JSH 04. 09. 2018, 09:16:29
Kód: [Vybrat]
a <=< b

To už je, říká se tomu https://cs.wikipedia.org/wiki/Brainfuck
Tak zlé by to zas nebylo, ale pořád to není nic, co bych v c++ viděl rád. Kór když to porovnám třeba s novým "spaceship" operátorem <=> pro porovnávání. Ten ušetří kopec práce.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Sten 04. 09. 2018, 09:29:07
Kromě výše uvedeného mě také velmi potěšil for-each a přidání inicializátoru do if a while:
Kód: [Vybrat]
if (auto code = service.call(); code.is_success()) {
    …
}
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Bacsa 04. 09. 2018, 10:09:26
Opravdovou revolucí jsou (budou) koncepty. Jinak kromě auto a inference parametrů šablon (tady je clang dokonce dál než g++) jsou fajn nové kousky v STL jako any a variant.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Miloslav Ponkrác 04. 09. 2018, 13:09:59
Citace
Ale co vy C++kari, jedete postaru, nebo v C++17, jak jste si zvykli, kdy jste poprve zjistili, ze je C++11? Kam az to povede, zmeni se C++ postupne v "Rust"?

Staré standardy, tedy C++98 a C++03 byly dobré. Ale C++11, C++14 a C++17 přinášejí velmi dobrá vylepšení.

Přechod na poslední standard není problém, C++ ctí až puntičkářsky zpětnou kompatibilitu, takže přechod směrem dopředu je bezproblémový a hladký.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Miloslav Ponkrác 04. 09. 2018, 13:11:14
Citace
Jak se vam libi boost?

Nelíbí. Boost přináší řadu knihoven velmi proměnlivé kvality. Ale hlavně boost je spíše laboratoř pro to, co přidat do standardu C++, spíše než cokoli jiného.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: x14 04. 09. 2018, 14:05:33
Moderní C++ znamená, že jsem si v týmu prakticky zakázali new/delete.
Z boostu používám snad už jen wformat, jinak se držím STL.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Petr 04. 09. 2018, 14:39:47
C++11 podle mě minimum a C++17 pro nové projekty určitě:

  - stricter expression evaluation order (C++17) - šel bych ještě dál
  - guaranteed copy elision (C++17)
  - noexcept in typedefs (C++17)
  - nested namespaces (C++17)
  - [[fallthrough]], [[maybe_unused]], etc... (C++17)
  - std::string_view (C++17)
  - relaxed constexpr (C++14)
  - enum : type (C++11)
  - constexpr (C++11)
  - move semantics / rvalue (C++11)
  - lambdas (C++11)
  - auto (C++11)
  - a mnoho dalších

Možná další ne až tak důležité věci, ale konečně:

  - Removing trigraphs (C++17)
  - Removing 'register' keyword (C++17)
  - Removing throw(...) specifications (C++17)

Z knihoven bych určitě zmínil <cmath>, <atomic>, <utility> a <type_traits>, které jsou podle mě super použitelné. Pro některé to může být i threading, ale já osobně si radši dělám vrstvu nad OS sám. Kontejnery z std nepoužívám, protože teď většinou píšu knihovny a tam je potřeba aby to neházelo výjimky nebo rovnou mělo C-API. S C++17 jsem celkově spokojený a je to určitě krok dopředu, ale asi bych byl radši, kdyby se specifikace víc zaměřovala na jazyk samotný a ne na to co je v std.

Co se týče překladače tak bych doporučil Clang a hned za ním GCC - MSVC a ICC jsou dnes už hodně pozadu. Občas o tom i něco napíšu tady (https://asmbits.blogspot.com/ncr), ale není moc času no :)
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Miloslav Ponkrác 04. 09. 2018, 16:14:34
Citace
S C++17 jsem celkově spokojený a je to určitě krok dopředu, ale asi bych byl radši, kdyby se specifikace víc zaměřovala na jazyk samotný a ne na to co je v std.

Tak toto můžu jedině podepsat. Uvítal bych, kdyby se méně řešilo STL, ale o to více samotný jazyk C++.

Citace
Co se týče překladače tak bych doporučil Clang a hned za ním GCC - MSVC a ICC jsou dnes už hodně pozadu

Je naprosto běžné, že kompilátory implementují standardy s cca dvouletým zpožděním. To je do jisté míry i znakem serióznosti kompilátoru. Chcete dělat svůj projekt a mít odladěný kompilátor. Doby, kdy si člověk hrál na alfa testera kompilátoru (u Borlandských C++ překladačů) jsem zažil kdysi dávno - a nikdy více.

Tedy osobně bych posečkal s bezhlavým používáním C++17, a projekty jedu s tím, že C++14 je jistota. A C++17 je ještě příliš příliš čerstvé, abych čekal odladěnost, podporu a spolehlivost kompilátorů.

Standard C++17 byl vydán v prosinci 2017. Očekávat, že kompilátory nebudou mít problémy - je naprostý nesmysl.

***

Co mě naprosto nevyhovovalo a nevyhovuje je situace v GCC. GCC se snaží implementovat vše, co je v draftech a diskusích standardizační komise. Tedy i to, co se může, a nejspíše také bude velmi měnit a konečná podoba ve standardu bude s vysokou pravdědpobností odlišná. Momentálně se snaží implementovat vše, co se šustne kolem budoucí revize C++2x.

Ve výsledku je to tak, MSVC implementuje mnohem lépe C++17 a ve větší šíři než GCC. Clang je na tom s implementací ještě hůře než GCC. Kdyby se raději GCC a Clang snažili korektně, seriózně a úplně implelentovat už existující standardy C++ a revize - udělaly by lépe.

https://en.cppreference.com/w/cpp/compiler_support#cpp17

Osobně jsem měl v minulosti opakovaně problém právě s GCC a C++. Jsem zvyklý využívat celý standard, a v C++ nadšeně používám skoro vše, co umí. A narážel jsem až příliš často u GCC na nesouhlad se standardem C++. Po časem mě to přestalo bavit, a GCC používám jen neochotně.





Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Petr 04. 09. 2018, 16:49:17
Já jsem myslel pozadu co se týče optimalizací, což mi přijde u C++ jako jedna z nejdůležitějších věcí. Co se týče standardu tak GCC/Clang na tom jsou velmi dobře a přijou mi hodně striktní - úroveň varování se dá navíc nastavit celkem jednoduše a každý warning má svůj název a ne nějaké hloupé číslo jak v případě MSVC.

Těžko odpovědět na zbytek, pokud nemátě něco konkrétnějšího co by se dalo demonstrovat např. přes <a href="https://godbolt.org/>Compiler Explorer[/url]. Co se týče otestovanosti tak už hodně dlouho se mi nestalo, že bych hitnul nějaký compiler bug u GCC/Clang, ale stalo se mi to ve VS2015 i VS2017 a na opravu bugu ve VS se čeká roky!
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Petr 04. 09. 2018, 16:51:15
Compiler Explorer (https://godbolt.org/) (nějak mi ten odkaz předtím uletěl)
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Miloslav Ponkrác 04. 09. 2018, 17:10:44
Citace
Já jsem myslel pozadu co se týče optimalizací, což mi přijde u C++ jako jedna z nejdůležitějších věcí. Co se týče standardu tak GCC/Clang na tom jsou velmi dobře a přijou mi hodně striktní - úroveň varování se dá navíc nastavit celkem jednoduše a každý warning má svůj název a ne nějaké hloupé číslo jak v případě MSVC.

Přitom úsměvné je, že GCC na tom velice dlouho bylo špatně s optimalizacemi, a generoval mnohem pomalejší kód než MSVC.

Složité šablony a STL kontejnery jsem i na Linuxu odlaďoval tak, že jsem si přepnul do Windows a MSVC. Na MSVC jsem to odladil, a pak se vrátil do Linuxu. Důvodem byly zmatené chybové zprávy a warningy v GCC - pokud vůbec. Když uděláte chybu v STL kontejneru, tak to jednoduše v GCC tiše sletí. V MSVC vám napíše, co jste udělal špatně. To co bych hledal za chybu v GCC tři dny, to mi MSVC napíše rovnou po prvním spuštění - takové jsou mnohaleté praktické zkušenosti se souběžným vývojem na MSVC a GCC.

Zbytečně pomlouváte MSVC, přičemž já bych si ho pro C++ vybral tisíckrát raději pro vývoj než cokoli jiného. Je to seriózní kompilátor zaměřený na seriózní vývoj. Lépe hlásí chyby, jak kompilátor, tak runtime - zejména ve složitých šablonách.







Těžko odpovědět na zbytek, pokud nemátě něco konkrétnějšího co by se dalo demonstrovat např. přes <a href="https://godbolt.org/>Compiler Explorer[/url]. Co se týče otestovanosti tak už hodně dlouho se mi nestalo, že bych hitnul nějaký compiler bug u GCC/Clang, ale stalo se mi to ve VS2015 i VS2017 a na opravu bugu ve VS se čeká roky!
[/quote]
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Miloslav Ponkrác 04. 09. 2018, 17:12:50
Citace
Těžko odpovědět na zbytek, pokud nemátě něco konkrétnějšího co by se dalo demonstrovat.

Spíše to vypadá tak, že chválíte a haníte kompilátory podle vašich sympatií a antipatíí. Přičemž realita je často naprosto opačná než tu píšete.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Petr 04. 09. 2018, 17:28:51
To samé se ale dá říct o vás. Vyzdvyhujete tu MSVC a přitom tu nepadl žádný konkrétní argument / příklad - kód je pro mě v tomto případě víc než slova. Já se aspoň snažím v tom blogu (když mám čas) a moje hodnocení je vždy na základě vygenerovaného kódu a né osobních preferencí.

GCC před 4.0 byl porod používat a MSVC v té době generoval mnohem lepší kód, s tím souhlasím, ale já žiju v současnosti a mám k dispozici mnohem lepší nástroje než tehdejší 10 let starý GCC. Navíc vyrostla obrovská konkurence jménem Clang, takže tu máme 2 open source překladače, které si vzájemně konkurují a profitujeme z toho všichni.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: m 04. 09. 2018, 19:04:56
GCC před 4.0 byl porod používat a MSVC v té době generoval mnohem lepší kód, s tím souhlasím, ale já žiju v současnosti a mám k dispozici mnohem lepší nástroje než tehdejší 10 let starý GCC. Navíc vyrostla obrovská konkurence jménem Clang, takže tu máme 2 open source překladače, které si vzájemně konkurují a profitujeme z toho všichni.

j to je presne. Nynejsi GCC a LLVM Clang je nesrovnatelny s tim co bylo pred 10 lety.

A to taky zabilo veci jako MSVC:D
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: y, 04. 09. 2018, 19:59:56
MSVC bylo zabity Microsoftem kvuli jejich pristupu "nedelame prekladac pro standard C++, delame prekladac pro windows".
Zkusite si dneska MSVC 18 (kde se chlubi, ze podporuji C++11 kompletne a C++14 castecne, iirc), prelozit treba takovou aktualni verzi OpenFST (take C++11 a zadne extremni silenosti).
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Sten 04. 09. 2018, 20:37:34
S C++17 jsem celkově spokojený a je to určitě krok dopředu, ale asi bych byl radši, kdyby se specifikace víc zaměřovala na jazyk samotný a ne na to co je v std.

C++17 se zrovna na jazyk zaměřuje hodně:

Pár velkých zvažovaných věcí vypadlo (koncepty, reflexe), ale to kvůli tomu, že potřebují víc času, vývoj pro C++17 se u nich hodně posunul.

Je naprosto běžné, že kompilátory implementují standardy s cca dvouletým zpožděním.

Možná ten microsoftí, ten má dodnes problémy s C++14 (https://msdn.microsoft.com/cs-cz/library/hh567368.aspx) :D Clang až na pár drobností C++17 podporuje. (https://clang.llvm.org/cxx_status.html) Velmi dobře podporoval C++17 už před oficiálním vydáním toho standardu, dokonce tak dobře, že jsme ho začali používat už v loňském březnu. Žádné problémy jsme u oficiálně podporovaných vlastností nepozorovali.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: hawran diskuse 04. 09. 2018, 20:50:30
...
To s tou reflexí mne mne uhodilo do mých starých oků, určitě si to pak můžu dohledat (na isocpp už jsem se nedíval fakt hodně dlooooouho), ale teď by mi stačil rychlý nástřel: navrhuje/plánuje/... se reflexe v c++?
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Rado2 04. 09. 2018, 21:00:32

Možná ten microsoftí, ten má dodnes problémy s C++14 (https://msdn.microsoft.com/cs-cz/library/hh567368.aspx) :D
Tak to je niekolko rokov stary dokument pre stare VS 2015 :) :) Ak ta to zaujima, novsi si najdes, inak VS sa dost casto aktualizuje a stale nieco zo standardu pribuda, ale nesladujem to, nepouzivam najnovsie veci.
Toto porovnanie ani nie je pre mna az tak dolezite, ak cielim na win, pouzijem MSVC, ak na Mac tak clang v Xcode (i ked to IDE je cisty masochizmus). Na linux som v poslednej dobe viac-menej pokusne pouzival z win Visual Studio IDE s jeho remote kompilaciou na linuxe - myslim gcc. Vsetko na jednom cross-platform projekte. Uz si nepamatam co to bolo, ale nejaku feature c++ som pouzil v MSVC a musel som ju dat prec, lebo nesla na gcc a tiez sa mi stalo ze nejaky kod gcc doslednejsie kontroloval podla standardu a co povodne slo na MSVC som musel upravit. To su ale drobnosti.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Sten 04. 09. 2018, 21:17:59
To s tou reflexí mne mne uhodilo do mých starých oků, určitě si to pak můžu dohledat (na isocpp už jsem se nedíval fakt hodně dlooooouho), ale teď by mi stačil rychlý nástřel: navrhuje/plánuje/... se reflexe v c++?

Plánuje se, compile-time reflexe byla jako možnost plánovaná už pro C++17, tak snad v C++20 bude, i když pořád tam je vedena jen jako „possibly“. Run-time reflexe je spíš na wishlistu, nějaké návrhy jsou (třeba operator $), ale konkrétní revize standardu, kam by to chtěli dát, zatím nepadla.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Rado2 04. 09. 2018, 21:21:36
Este k povodnej otazke - roky som pouzival stare C++ - ale hlavne s MFC, std skoro vobec. Potom som presiel na C# a teraz trochu C++11/14/17. Co sa tyka jazyka (ale aj std), robi sa s tym samozrejme lepsie a to ani nepouzivam a nepoznam vsetky vylepsienia.
Stale som fanusik C++, ale bohuzial robi sa s tym stale horsie ako v C#, hlavne koli std kde nie je ani poriadna podpora pre stringy. Taktiez iteratory sa krkolomne pouzivaju, mozno sa to zlepsi prichodom ranges. V dnesnej dobe je dost hadicap ze std nema vstavanu podporu pre unicode stringy, aj ked chapem ze by to znacne zvacsilo kniznicu, ale aj jednoduche operacie ako rozdelenie stringu na slova so zadanym oddelovacom a pod. treba zlozito riesit vlastnymi utility funkciami, alebo pouzivanim BOOST. Zakladna kniznica musi byt spravena tak, aby nad stringami clovek nepotreboval ziadne vlastne utility a externe kniznice.
Mimochodom BOOST je velky moloch. Chcel som pred par rokmi pouzit len stringove kniznice, ale ten ich tool, ktory ma z boostu vysekat len vybrane veci mi generoval neskompilovatelny vycuc z boostu (a to som sa s tym pol dna hral a postupne pridaval veci, co mu chybali), musel som ho nakoniec pouzit cely  :-\
No a naposledy som zabil snad niekolko dni aby som zistil, ako cross-platformovo sformatovat sumu v narodnom formate s vlastnym symbolom pre menu. Takze ja by som povedal ze by sa bolo treba zamerat na riesenie praktickych problemov.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Petr 04. 09. 2018, 21:46:02
S tím zaměřením na jazyk samotný myslím hlavně to, že C++ Committee se zabývá blbostma typu "2D graphics library", které nemají v samotném C++ co dělat.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: hawran diskuse 04. 09. 2018, 22:29:24
To s tou reflexí mne mne uhodilo do mých starých oků, určitě si to pak můžu dohledat (na isocpp už jsem se nedíval fakt hodně dlooooouho), ale teď by mi stačil rychlý nástřel: navrhuje/plánuje/... se reflexe v c++?

Plánuje se, compile-time reflexe byla jako možnost plánovaná už pro C++17, tak snad v C++20 bude, i když pořád tam je vedena jen jako „possibly“. Run-time reflexe je spíš na wishlistu, nějaké návrhy jsou (třeba operator $), ale konkrétní revize standardu, kam by to chtěli dát, zatím nepadla.

Aha, OK, díky za hint.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: ava 04. 09. 2018, 22:41:45
Este k povodnej otazke - roky som pouzival stare C++ - ale hlavne s MFC, std skoro vobec. Potom som presiel na C# a teraz trochu C++11/14/17. Co sa tyka jazyka (ale aj std), robi sa s tym samozrejme lepsie a to ani nepouzivam a nepoznam vsetky vylepsienia.
Stale som fanusik C++, ale bohuzial robi sa s tym stale horsie ako v C#, hlavne koli std kde nie je ani poriadna podpora pre stringy. Taktiez iteratory sa krkolomne pouzivaju, mozno sa to zlepsi prichodom ranges. V dnesnej dobe je dost hadicap ze std nema vstavanu podporu pre unicode stringy, aj ked chapem ze by to znacne zvacsilo kniznicu, ale aj jednoduche operacie ako rozdelenie stringu na slova so zadanym oddelovacom a pod. treba zlozito riesit vlastnymi utility funkciami, alebo pouzivanim BOOST. Zakladna kniznica musi byt spravena tak, aby nad stringami clovek nepotreboval ziadne vlastne utility a externe kniznice.
Mimochodom BOOST je velky moloch. Chcel som pred par rokmi pouzit len stringove kniznice, ale ten ich tool, ktory ma z boostu vysekat len vybrane veci mi generoval neskompilovatelny vycuc z boostu (a to som sa s tym pol dna hral a postupne pridaval veci, co mu chybali), musel som ho nakoniec pouzit cely  :-\
No a naposledy som zabil snad niekolko dni aby som zistil, ako cross-platformovo sformatovat sumu v narodnom formate s vlastnym symbolom pre menu. Takze ja by som povedal ze by sa bolo treba zamerat na riesenie praktickych problemov.

Hmm, tak to by se ti asi mohl líbit Rust. K železu má asi stejně blízko jako C++, ale stringy jsou UTF8 by default, iteratory se používají normálně, std má batteries included, když člověk chce 3rd party knihovny z crates.io, tak je triviálně vloží do projektu podobně jako přes C# nuget. Platformová přenositelnost je znamenitá. K tomu spousta dalších radostí a pár starostí. Pořád to není takové pohodlí jako v jazycích s GC, ale to je principiální problém, a v rámci tohoto omezení se s Rustem pracuje dost pohodlně.. učící křivka je teda dost strmá a dlouhá, ale to je nakonec i u C++...
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Xxxxxx 04. 09. 2018, 22:48:27
Ucicj krivka je bud strma, ze se to naucis hned, nebo neni strma a je dlouha, ze to trva dlouho se to naucit.
viz. Prechodova charakteristika, strmost je rychlost uceni se.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: ava 04. 09. 2018, 23:10:28
Ucicj krivka je bud strma, ze se to naucis hned, nebo neni strma a je dlouha, ze to trva dlouho se to naucit.
viz. Prechodova charakteristika, strmost je rychlost uceni se.

Myslel jsem to tak, že učení je náročný na přemýšlení (strmost) a je toho hodně (délka). Něco jiného může být náročný na přemýšlení (strmost), ale přitom útlé téma (malá délka), něco ještě jiného se sice učí snadno (malá strmost), ale jsou toho kvanta (délka).

Tak doufám že to teď dává lepší smysl. Každopádně do toho nechci víc zabředávat.
Název: Re:Old C++ VS C++11, 14, 17
Přispěvatel: Xxxxxx 05. 09. 2018, 05:16:04
Ucicj krivka je bud strma, ze se to naucis hned, nebo neni strma a je dlouha, ze to trva dlouho se to naucit.
viz. Prechodova charakteristika, strmost je rychlost uceni se.

Myslel jsem to tak, že učení je náročný na přemýšlení (strmost) a je toho hodně (délka). Něco jiného může být náročný na přemýšlení (strmost), ale přitom útlé téma (malá délka), něco ještě jiného se sice učí snadno (malá strmost), ale jsou toho kvanta (délka).

Tak doufám že to teď dává lepší smysl. Každopádně do toho nechci víc zabředávat.

Ano, takto se vysvetluje ten omyl proc si lidi zvykli rikat, ze tezke uceni je strma ucici krivka. Strmost jim pripomina drapani se na horu znalosti.