> Nem, nincs, csak a statikus factory method láthatja ezt, de az az osztályhoz tartozik, nem baj.
Ez csak akkor lenne 100%-ig igaz, ha az objektum vakumban letezik. Mivel azonban ez nem igaz, igy eleg valtozatos interakciok elkepzelheto a "megkonstrualt, de nem valid" objektum es egyeb programreszek kozott. Ha pedig tobbszalu programrol beszelunk, akkor a lehetosegek tarhaza vegtelen.
> Bármelyikben, ha így van specifikálva az interface.
Jogosnak latszhat az erv, de ez a design hamarabb bizonyul rossznak, minthogy az elso demo elkeszulne. A nyelvet keszitoknek meg a valos vilag igen valtozatos kihivasainak kell megfelelni. Es a gyakorlatban a hibahoz hozzatartozik a hibakod, valami szoveg, neha meg szamos mas info is.
> Konstruktorra gondoltál, de miért ne lehetne? Ha a factory method shared_ptr (vagy unique-ptr) -t ad vissza, az meghívhatja a make_shared -et (make_unique) -ot.
Igen, konstruktorra gondoltam, bocsanat. A problema az, hogy a factory method meghivhatna a privat konstruktort, de a make_shared nem (hiszen privat). Illetve hat kacifantos friend deklaraciok utan talan, de a gyakorlatban nem. Ugyanis nem fogod tudni, hogy melyik fuggveny lesz, ami konkretan meghivja a konstruktort :). Az interfesz meg van adva a szabvanyban, de a megvalositas mindig mas nevu fuggvenyt hiv meg, ami elvegzi az allokaciot. Szoval a make_shared friend-e tetele egy szinten eleg bena megoldas (ami valoszinuleg sosem fog jol mukodni). Marad a ket memoriafoglalas koltsege.
> Nem tipikus, hogy olyan osztályok, amiknél a copy/move -nak van értelme, hibáthatnak constructornál, persze előfordulhat.
Ez rossz spekulacio szerintem. Elofordul es meg csak nem is hollo. Nyilvan nem moricka programok esetet kell extrapolalni. Epp az a lenyeg, hogy problemak szeles koret megnyugtatoan, sot minel biztosabban tudjuk kezelni, ha ugy hozza a szukseg. Nem veletlenul szerepelnek a szabvany konyvtarban az is_nothrow_default_constructible<>(), is_nothrow_copy_constructible<>(), is_nothrow_assignable<>() fuggvenyek.
Nezd nyilvan nem az lenyeg, hogy meggyozzelek teljesen az igazamrol (nyilvan eltero tapasztalatok eltero szokasokat szulnek). Azt azert szigoruan fenntartom, hogy kategorikusan elutasitani a kiveteleket nagy butasag. Nyilvan esetrol-esetre ki kell talalni, hogy milyen modon jelzi es kezeli a rendszer a hibakat. Ha nekem kellene fejlesztesi guideline-t adni, en azt mondanam, hogy alapbol kivetelek es ha vannak ertelmes ervek arra, hogy egy adott eset miert nem jo kivetelekkel, akkor keresni valami mast.