ARCHIV

"Troufl bych si tvrdit, že se jedná o jednu z nejméně doceněných předností C++ oproti C."

pripada mi, ze rozdil mezi mysql::query() a mysql_query() je ciste esteticky. prinasi namespaces jeste neco jineho krome jakes takes prevence kolize nazvu?

Mezi mysql::query() a mysql_query() je v principu stejný rozdíl jako mezi /etc/passwd a _etc_passwd nebo mezi java.util.Date a java_util_Date. O užitečnosti adresářů (u normálních disků) a javovských package (u středně velkých projektů) snad nikdo nepochybuje. Oproti názvu se zakomponovanou cestou zlepšují přehlednost a zjednodušují správu systému s větším počtem souborů/javovských tříd/C++ identifikátorů, rovněž umožňují neúplnou kvalifikaci. U disků s 5 soubory/javovských programů se 3 třídami/C++ hello world příkladů adresáře/package/namespace smysl nemají.

tak z Vasi odpovedi vidim, ze budete namespaces branit do roztrhani tela. ja vyhody nezpochybnuji, jen je nevidim. sice jste mi to krasne "natrel" s hello world priklady, ale z konkretnich prinosu jste uvedl jeden - umoznuji neuplnou kvalifikaci.

cim se mi zjednodusi sprava projektu? kolize jmena nejakeho namespace hrozi uplne stejne, jako to, ze nekdo pojmenuje vsechny sve public identifikatory s prefixem mysql (kdyz uz jsme mysql pouzili jako priklad).

takze zatim vidim, ze v ramci namespace mysql nemusim psat mysql::query(), ale staci query(), coz je oproti mysql_query() uspora.

urcite v tom bude jeste neco. :-)

Vsak jste to napsal sam, "jakas takas prevence kolize nazvu" je myslim dostatecnou vyhodou.

To je prave to co to moc neposkytuje, v cistem C se muzu kolizim jmen branit vpodstate stejnym zpusobem. Ale je to takovy syntakticky cukr, jehoz nejvetsi vyuziti je prave v tehle prefixech.

ze bych nebyl jediny kverulant? ;-)

mne se totiz zda, ze to je takova vlastnost kvuli image. aby c++ vypadalo, ze je in.

nebo jinak - predstavte si, ze pracujete na rozsahlem projektu v tymu napr. 10 lidi. kazdy z nich pouzije jiny (svuj) namespace? asi tezko, je to jeden projekt, tak tech namespace bude malo, nejspis jen jeden.

krome toho, mnozstvi kodu pouzitelneho v jinych projektech je obvykle velmi male (v porovnani s celkovym mnozstvim vyprodukovaneho kodu). coz sice neni idealni stav, ale je to podle mych zkusenosti realita.

No nicmene, pravdou je, ze cosi podobneho muzete rict o temer celem C++.

to zase ne, oop obecne ma podle me zajimavy vliv na vyvoj aplikace. dedicnost sama o sobe mi prijde velmi uzitecna a i jen kvuli ni bych uprednostnil c++ pred c.

spousta kritiku c++ vytyka existenci pointeru a treba to, ze c++ nevynucuje oop pristup.
ale mne se na c++ libi prave to, ze mi dava svobodu - chci psat jako prase, muzu. chci psat ciste, taky muzu.

Ano. Ale "OOP" na styl C++ muzete mit stejne dobre v C a to bez nejake velke namahy. Bude to mit jednu krasnou vyhodu - neprekvapi vas na kazdem rohu nejake zcela nelogicke chovani, ktere sam nechcete.

Dřív, když jsem C++ (narozdíl od čistého C) moc neuměl, jsem ho používal na objektově orientované problémy (gui, obecné datové struktury, ...) jako C + třídy s možností dědičnosti a virtuálních metod. Ničím mě takto omezené C++ nepřekvapovalo a přišlo mi to snažší a lepší než C. Uznávám, že "správně" napsaný kód ve stylu C++ překvapit programátora může docela snadno.

Podle mě jste si v podstatě odpověděl sám. Namespace není žádný zázračný nástroj (s tím s Vámi souhlasím), jen trochu usnadňuje práci u velkých projektů a především knihoven. Příjde mi lepší věšet spoustu rozumně krátkých identifikátorů na strom než na jednu hromadu a ten strom vytvářet názvem identifikátoru. U javovských package a filesystemu se tohle všeobecně uznává, u C++ namespace ne, asi z důvodů historického vývoje a kvůli (pochopitelné a často oprávněné) snaze o kompatibilitu s C. Jiný rozdíl v tom nevidím.