Alapvetően ebben az exceptionös kérdésben nem értünk egyet, szerintem nem is fogunk, sebaj :)
>Tovabba a +1-es implementacios problema: ha az altalad javasolt modon jarunk el, akkor van az objektumodnak egy olyan allapota amikor a konstruktor mar bekrepalt, de az objektum a memoriaban van. Tehat potencialisan hasznalhatja valaki.
Nem, nincs, csak a statikus factory method láthatja ezt, de az az osztályhoz tartozik, nem baj.
>Megis melyik univerzumban szamit nullptr visszaadasa "egyertelmu hibajelzesnek"?
Bármelyikben, ha így van specifikálva az interface.
>mivel privat a destruktorod, ezert a make_shared<> szoba sem johet az objektumra mutato shared_ptr letrehozasara. Ez rogton azt jelenti, hogy ketszer kell memoriat foglalni az objektumodhoz.
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.
>vannak olyan konstruktorok (illetve tagabb ertelemben muveletek), amiknek nem fogsz tudni hibakodot atadni, a teljesseg igenye nelkul: copy constructor, move constructor, assignment operator, operatorok. Letilthatod a masolast es a move-olast, de ezzel kapasbol az osztalyod hasznalhatosagat korlatozod igen durvan.
Nem tipikus, hogy olyan osztályok, amiknél a copy/move -nak van értelme, hibáthatnak constructornál, persze előfordulhat.
>Tegyuk fel, hogy van 10 overload-od a konstruktorra (lasd pl. std::vector<>) azert eleg meredek lenne 10 factory method-ot is csinalni hozzajuk
Szintén nem tipikus, hogy az ilyen utility jellegű osztályok hibázzanak. bad_alloc -ra gondolhatsz, de az a kategória, amit említettem, hogy akkor már hagyjuk is, inkább szálljon el a program. (Persze nyilván van olyan eset amikor ez nem igaz, általában beszélek)
> Ha az osztalyod ososztalya vagy valamelyik adattag inicializaloja dob, akkor *nincs* ra mod, hogy megakadalyozd a kivetel tovabbadasat felfele.
Hát nyilván, ha az ősosztály olyan, hogy kivételt dob, akkor azt kezelni kell, bár ezt is be lehet csomagolni egy factory methodba... :)