[Bssldr]

Kasutan uues projektis std::shared_ptr'it ja mõtlen, mis oleks hea disain - pidevalt std::shared_ptr<Class> kirjutada on pisut tüütu.

Hetkel olen olukorra lahendanud järgmiselt.

[Supiplex]

IMHO võiks pointerite tüüpe mitte ümber nimetada (ega ka muude standardsete asjade). Väga vaevaline on lugeda koodi, mis defineerib tüübid ümber (v.a. mõned elementaarsed). Kui sellega veel interfeissida tuleb, siis läheb päris põrgu lahti.

[siimannuk]

Üpris levinud kirjaviis on ka (mida ise kasutan):

[Bssldr]

Küsin veel teema jätkuks, et kui laialdaselt juba C++0x võimalusi kasutatakse, näiteks ettevõtetes? Ise kasutan peaaegu kõiki võimalusi, mida VS2010 toetab. Tuleb mainida, et shared_ptr on ikka väga hea - exceptionite viskamine/püüdmine osutub nüüd isegi kasulikuks ja try bloki sees memory leake ei teki. Samuti teevad lambdad koodi kirjutamise palju mugavamaks.

[THNS]

No shared_ptr on juba suhteliselt vana asi meil oli see kasutused alates Visual studio 2005-ga. lambda asemel sai kasutatud boost.bind. Kuna C++0x pole täielikult veel supporditud ja näiteks VS 2010 on suht uus IDE tasuks natuke oodata kuni nad enamus bugid ära parandavad. SP1 on väljas küll aga ikkagi päris palju bugisid sees.

Kirjapildi poolest nõustun siimannukiga.

[matik]

[THNS]

[Supiplex]

[THNS]

[Ho Ho]

[Supiplex]

Eks see ole igaühe enda asi kas ta defineerib oma tüübid ümber või mitte.

Minul teise koodi lugedes on igatahes lihtsam siis, kui on kasutatud ümber nimetamata standardseid tüüpe, tüübinimetusi ja keskkonnale omaseid tavasid. Asjad mis on ümber defineeritud suupärasemateks või lühemateks kurnavad asjatult niigi hõivatud lühimälu. Eks see toob ka veidi kibedust minu sõnadesse

[THNS]

Tasub ikka küll kasutada boost.integer headerit kuna cstdint headeris on bugid sees mille boosti tegijad ära parandasid.

Ma ei ütleks et pointer halb asi on, ta on väga hea. Temaga tuleb osata lihtsalt ringi käia. Muidugi parem on kasutada reference (ohutum).

[Ho Ho]

[matik]

[Supiplex]

Kontekstist. Mina isiklikult ei arenda STL-i. Ma arendan 95% oma ajast äriloogikat, mis pole ei taaskasutatav ega üldotstarbeline. Küll ta kas keeruline, puudulikult defineeritud või peab eilseks valmis olema. Tihti kõike korraga.

Selle käigus olen ma astunud paljude rehade otsa ja mulle ei meenu hetkel sellist mille puhul typedef päästaks. Küll olen ma hakanud hindama lihtsat, otsekohest koodi mis ei ennusta tulevikku ega ürita olla igaks juhuks modifitseeritav, laiendatav või taaskasutatav enam kui on nõutud - v.a. harvad juhud kus tulevik on juba tegemise ajal teada või harvad juhud kus tegemist on tõepoolest üldotstarbelise, taaskasutatava koodiga. Seniks aga on kõige lihtsam refaktoorida lihtsat koodi.

Ja jätkuvalt väidan ma, et kuna standardsete tüüpide ümberdefineerimine muudab koodi lugemise koormavaks ja API kasutamise keeruliseks, siis tuleks sellest hoiduda. Omaenda tüüpe käänab igaüks nii nagu soovib

[matik]

[Supiplex]

Okei, sinu näide on täiesti mõistlik ja mul pole põhjust sellele vastu vaielda. Aitab kah minu mölast

[Liuskur]

[Ho Ho]

Liuskur, sa vist ei süvenenud väga täpselt mu juttu

1) Loomulikult ei ole mõtet jalgratast taasleiutada kuid samas pole ka mõtet dubleerida asju läbi väliste teekide kui need juba su kompilaatoriga niigi kaasa tulevad. Kasutan ise tervet posu boosti nodi kuid ainult noid mida tõesti standardis kaasas pole seega pole mul ka midagi nende kasutamise vastu.

2) Selle koha pealt peame leppima eriarvamustele jäämisega. Peamine vastuolu on mul kuna olen näinud N+1 projekti kus sellega rämedalt üle pingutatakse ning ühed samad asjad eri kohtades eri nimedega ümber nimetatakse. Lisaks kui on mõistlikult namespacesid-klasse nimetatud siis valdavalt puudub vajadus nimede ümber defineerimiseks neist paremini aru saamiseks. Eks siis on loomulikult lihtsam kui oled programmi arendusega aegade algusest peale tegelenud. Kui on vaja kellegi teise projekt üle võtta ning see on taolisi typedef'e täis siis on seal navigeerimine parajalt piinarikas.

3) Ma rääkisin ainult pointeritest. (const) Referenced on igati head ning noid peaks ka valdavalt kasutama. Raw pointerite kasutamiseks ei näe ma ühtki mõjuvat põhjust, isegi smart pointereid saab valdavalt vältida.


Pointerite selgelt eristumise all pidasin silmas, et mitte teha typedef Foo* FooPtr stiilis pornot vaid pigem jättagi igale poole tärnid kuhu vaja et oleks kohe selgelt näha mis on pointer ja mis mitte.

[Liuskur]

Su vastust lugedes, tundub tõesti et ei süvenenud vist piisavalt.

Siiski:

Hea tava on jah mitte typedefida foo* fooPtr ega ka reference mitte, see kaotab läbinähtavust. Aga shared_ptr, auto_ptr jne tüübid typedefiks küll julgelt ära, projektil mil töötan äsja sai kuskil aasta tagasi just alles tehtud üks ports boosti shared_ptr typedefe mis nüüd ongi kujul FooPtr ja aitas loetavusele kaasa kõvasti.

Ühe ning sama asja ümbernimetamine erinevateks nimedeks võib olla vägagi kasulik loetavusel, eriti veel kui on vahetult koodis kasutusel näiteks mitmeid map-e, set-e, liste või mida iganes, mis on ühesugused aga erinevateks otstarveteks/andmeteks kasutusel. Kui pidevalt lugeda map<bla bla>::iterator vms või lihtsalt taolisi deklaratsioone, mis on erineva andmete hoidmiseks/töötlemiseks, siis läheb silme ees üsna kirjuks nende mapide tõttu ja jälgimisel on ekstra pingutust vaja, siis vaadata, mida parajasjagu too mapi iteratoriga või deklaratsiooniga tehakse, et teada saada milliseid andmeid nüüd kasutama hakatakse.

Typedefide asukoht peaks olema vastavalt vajadusele, kui klassile on mõistlik teha typedef, mis tegeleb ainult klassi member variablitega või ainult member funktsioonides, siis võiks ta olla klassi sees private deklaratsioonina. Kui aga klassile on mõistlik teha typedef mis on getter ja/või setter funktsioonide jaoks, võiks typedef olla klassi headeris aga klassist väljas, samas namespaces.