Mate radi C++?

[quas4]

[Marek]

[quas4]

[MD]

Na jednoduchych prikladech #includy problem nejsou. Problem nastava az u vetsich projektu, ktere se vyviji, vazby mezi objekty jsou komplexni, obcas se pouzivaji templaty, obcas je potreba udelat refactoring ... A diky includam vznika pekny bordel.

Ja plne souhlasim s Eosie, ze inculudy jsou jedna z nejhorsich a nejzastaralejsich veci v C++. Je to velke zlo, ktere obzvalste vynikne, kdyz mate zkusenosti i s jazyky, ktere tento problem nemaji (C#).
_________________
- play with objects - www.krkal.org -

[Marek]

Návrh to nekomplikuje (aspoň mně ne zrovna), ovšem cykly při includování jsou celkem normální (Mesh -> Efekt -> Shader -> Mesh). Pak šablony - pochopitelně musí být v headerech. A,B jsou šablony tříd. Metoda třídy A používá třídu B a B používá třídu A, tzn. musím uvést celý kód třídy A kromě té metody, celý kód třídy B (+ závislé objekty) a až nakonec uvést tu jednu metodu A, kde už budu moct B použít - tzn. je umístěna ve zdrojáku daleko od ostatního kódu A, což může vést k nepřehlednostem. Vím, že by se to dalo řešit líp, ale už to, že musíš mít na paměti, co se ti kde includuje a v jakém pořadí, je nevýhoda.
_________________
AMD Open Source Graphics Driver Developer

[quas4]

[rezna]

quas4 a nebo pokud si neumis predstavit problem s includy asi jsi nenapsal kod v C/C++ ktery by mel 100k a vice radku a byl alespon castecne rozumne rozdeleny

taky mam tyhle problemy - firemni jadro ktery ja navic v COMu a vic nez sablony pouziva makra je taky boj upravit, protoze to poradi includu je tam priserne dulezity

naopak v C# neni problem ani pri 300k radcich

ono je to ale holt dano principem kompilatoru, kterej potrebuje vsechno mit v jednom souboru - ten kompilne a vyvplivne .obj, ktere finalne nalinkuje

[quas4]

[MD]

Ja bych to schrunul takto: inkudy vznikly v dobach temneho C, kdy se u parametru a membru vystacilo s typem void * Tyto doby jsou ale davno pryc, prislo typove bezpecne programovani a s tim prisly problemy, o kterych pise Eosie. Pointr na tridu je jeste OK, pracuje se s referencemi, da se to vyresit forward deklaracemi. Horsi jsou ruzne "chytre", vetsinou templatove tridy, ktere se predavaji hodnotou. Pak si clovek opravdu musi dobre hlidat graf zavislosti.

quasi, myslim ze bys rychle zmenil nazor, kdybys musel nejakou takovouhle zbesilost rozmotavat (Nejde o to, jestli to puvodne bylo nebo nebylo navrzeno dobre - kod nebyva idealni - a prave proto je dobre, kdyz je cas ho vylepsit.)
_________________
- play with objects - www.krkal.org -

[quas4]

[MD]

jj, C je stale pouzivane, ale nemyslim si, ze je to nejaka vyhra ... Visual Basic je taky konzistentnejsi nez C++, ale to mi nestaci, abych ho mel rad

Vetsina spatnych vlastnosti v C++ se da obejit, nahradit nejakym postupem, ktery nevyhody odstrani. Peklo muzou zpusobit makra nebo nevhodna prace s pointry... C++ je nastesti dost silny jazyk, aby se tam dalo programovat i pomerne ciste, takze se tem nevyhodam da vyhnout. (a to se mi na nem libi)

Inkludy jsou problem prave proto, ze tem se vyhnout neda a ma je kazdy projekt. Zadny prepinac kompilatoru "Zapni kompilaci, kde nezalezi na poradi deklaraci a pouziti" neni.

Zajimave ze ti to nevadi.. Bud jsi jako Chuck Norris a nevadi ti nic a zvladas vsechno, nebo jsi inkludovy masochista, no a nebo jsi si na to uz zvykl a jen si neumis predstavit o kolik by to bylo prijemejsi, kdyby tahle nevyhoda nebyla.
_________________
- play with objects - www.krkal.org -

[petr]

Firmám totiž fakt nejde o nic jiného, než o maximalizaci zisku (základní poučka z ekonomie). - no můžu ti říct, že v praxi tato poučka teda neplatí, alespoň ne ve všech případech (firmách) jak tvrdí nějaká zaručená příručka ekonomie.

Preferuji c++ programuji-li runtimovou aplikaci, občas se však nevyhnu VB (byť toto téma není o tomto jazyku, přesto si dovolím napsat pár slov) na kterém jsem před 9 lety (+-) začínal v pracovním poměru, záleží především na typu projektu, pokud mám dělat konverzi stringových dat do bináru (BCD), případně spolupracovat s DB (SQL), nevidím ve VB problém, ikdyž tzv. "klikačky" do kterých microsoft vtahuje nové "programátory" fakt nemusím, udělat všecho rychle naklikáním není dobré řešení a bohužel z praxe vím, že těchto programátorů-klikačů je snad čím dál tím víc a to nejen v klasických formulářových projektech, ale i dokonce těch jenž využívají klikací nástavby pro primitivní tvorbu her ve 3d (uff).

Na c++ mne taky trápí includy, nedávno jsem přebíral projekt zahrnující cca 25 tříd a vyznat se v provázanosti bylo dost peklo, je skoro nemožné pak vyseparovat jednu třídu pro odtestování.

Pro mně je hlavně zajímavá inforamce, že velmi málo firem (+- 10%) hledá programátory c++, za svou "kariéru" jsem se nesetkal s jedinou firmou která hledala jiné odborníky než céčkaře, proto bych si dovolil tvrdit, je velmi důležité v jakém programovacím prostředí (firmě) jste odkojenim, přeloženo programátorsky, záleží v jakém stavu (neznalosti) zůstanete zapouzdření (což je asi můj případ) ...

[Augi]

[Quiark]

To je podle mě jen prostě starý problém s neschopnými programátory. Akorát se to v tomhle případě projevuje tak, že se svoji neschopnost snaží zamaskovat použitím klikaček a tím na klikačky vrhají špatné světlo
_________________
Mám strach

[Augi]

No však, vrhají špatné světlo Ale v zásadě jsou klikačky jen generátory kódu a pokud ty generátory generují rozumný kód, proč je nepoužít a neušetřit si práci...