I inače tvrdo verujem da C++ ima budućnost samo ako naučimo da ne koristimo gole pointere osim kad je to apsolutno neophodno, već da sve "zamotavamo" u pametne pointere.

rivan: Sto se tice toga sta je bolje - ne postoji resenje koje je bolje u svakom slucaju - nekad ti je vazno vreme razvoja, a nekad vreme izvrsavanja...

upotrebom standardnih kontejnera i pametnih pointera ubijemo više muva jednim udarcem: dobijemo exception-safe kod i ispravnu copy semantiku.

Slažem se da ne postoje "univerzalno bolja" rešenja, ali ako su ti performanse izgovor da uopšte ne koristiš standardnu biblioteku, onda praviš veliku grešku koja se zove "Premature optimization". Otkud znaš da je rešenje sa golim pointerima brže nego sa vektorom?

možeš da uradiš npr nešto ovako:

rivan:
upotrebom standardnih kontejnera i pametnih pointera ubijemo više muva jednim udarcem: dobijemo exception-safe kod i ispravnu copy semantiku.

Kad to kazes impliciras da resenjem na gornji nacin neces imati ni exception-safe kod (a poenta je bila da gornji kod jeste exception-safe), ni ispravnu copy semantiku, sto jednostavno nije tacno

rivan:
Radi se o tome da tacnu semantiku tvoje klase znas samo ti (npr. znas da pomeranje niza objekata tvoje klase trpi i memcpy, a nema potrebe za pozivanjem operatora = ili copy konstruktora (ovo ne znaci da tvoja klasa ne sadrzi pointere)) pa ti mozes da napravis dinamicki niz koji ce se bolje ponasati od bilo kog template-a koji je pisan sa namerom da funkcionise u svim slucajevima.

rivan:
Tema je bila kako pisati kod koji nece imati curenja u konstruktoru - ti dajes predlog za kod koji opet ima probleme sa curenjem

rivan:
Sto se tice auto_ptr i slicnih template-a njihova primena je prilicno ogranicena na specificne slucajeve (prosledjivanje pointera kao parametara i slicno), a nikako ne predstavljaju neko univerzalno primenljivo resenje

rivan:
kako bi tim zezalicama implementirao asocijacije medju objektima gde mogu da se jave i curkularne reference i ko zna sta jos?).

rivan:
Poenta onog sto hocu da kazem je da ne treba izbegavati pointere (ako hoces da radis bez njih imas c# i javu), i da ne treba koristiti STL po svaku cenu (nema puno smisla izmisljati toplu vodu ako neki STL template radi TACNO ono sto ti treba i to onako kako ti hoces).

rivan:
Nisam hteo da davim (iako se malo oteglo), samo da predstavim drugu stranu medalje...

Može biti da mi je nešto promaklo, ali ne vidim da ovaj primer ima problema sa curenjem. Na šta misliš?

C# i Java imaju svoj način rešavanja problema sa curenjem memorije koji opet uvodi neke druge probleme, uglavnom taj način je dosta drugačiji od pametnih pointera u C++u i poređenje nije baš na mestu.

rivan: 
Zamisli da se desi exception prilikom alokacije bn - nece ti pomoci cinjenica da si koristio template a ne obicni pointer za an radi toga sto nece biti pozvan destruktor ni za a, a samim ti ni za objekte koje a sadrzi - u slucaju da se desi exception u konstruktoru ne poziva se destruktor...

rivan:
Ako je zabijanje glave u pesak sve dok se ne ostane skroz, ili bez 1/2 memorije, ako tako bese rade ti gc-ovi sa obilazenjem i kopiranjem, neko resavanje problema onda je definitivno bolje sto niko nije pokusao da u c++ "resi" problem na isti nacin

rivan: Interesantno bi bilo to probati na vise kompajlera - mislim da standard to pitanje ostavlja nedefinisano...

rivan: ono sto mnogim ljudima promice je da je redosled izvrsavanja inicijalizacija u listi isti kao redosled definisanja atributa u definiciji klase

Moral #1: Constructor function-try-block handlers have only one purpose -- to translate an exception. (And maybe to do logging or some other side effects.) They are not useful for any other purpose.

Moral #2: Since destructors should never emit an exception, destructor function-try-blocks have no practical use at all.[6] There should never be anything for them to detect, and even if there were something to detect because of evil code, the handler is not very useful for doing anything about it because it can not suppress the exception.

Moral #3: Always perform unmanaged resource acquisition in the constructor body, never in initializer lists. In other words, either use "resource acquisition is initialization" (thereby avoiding unmanaged resources entirely) or else perform the resource acquisition in the constructor body.

For example, building on Example 2(b), say T was char and t_ was a plain old char* that was new[]'d in the initializer-list; then in the handler there would be no way to delete[] it. The fix would be to instead either wrap the dynamically allocated memory resource (e.g., change char* to string) or new[] it in the constructor body where it can be safely cleaned up using a local try-block or otherwise.

Moral #4: Always clean up unmanaged resource acquisition in local try-block handlers within the constructor or destructor body, never in constructor or destructor function-try-block handlers.

Moral #5: If a constructor has an exception specification, that exception specification must allow for the union of all possible exceptions that could be thrown by base and member subobjects. As Holmes might add, "It really must, you know." (Indeed, this is the way that the implicitly generated constructors are declared; see GotW #69.)

Moral #6: If a constructor of a member object can throw but you can get along without said member, hold it by pointer and use the pointer's nullness to remember whether you've got one or not, as usual. Use the Pimpl idiom to group such "optional" members so you only have to allocate once.

And finally, one last moral that overlaps with the above but is worth restating in its own right:

Moral #7: Prefer using "resource acquisition is initialization" to manage resources. Really, really, really. It will save you more headaches than you can probably imagine.