There is something wrong in the idea.
bringiton> i disagree. The aim of c++ is to hide implementation details. ie bringiton> std::vector hides array memory management, std::list hides linked list bringiton> implementation. Yep. And they hide it completely (supposed to at least). bringiton> i think it defeats the purpose of having a memory management class bringiton> where the user manages the memory. i can see all sorts of problems bringiton> with the following: True. If you use any kind of weak contract, that's what you eventually get. (By weak I mean not enforced by compiler, or at worst -- runtime). bringiton> i don't want to assume that users will use the interface correctly. if bringiton> i have a choice, i'd rather make the interface bulletproof. bringiton> i've made a shared_ptr wrapper. it is very strict how it manages bringiton> memory + the user can not break it. Yes, so you went by the path of total control. I don't know how you did it, but first simplest thing that comes in my mind is something like that (the class itself controls its allocating): class Test { public: typedef shared_ptr<Test> Ptr; static Ptr Allocate() { return Ptr(new Test()); } private: Test() {} }; From here what user can pretty much do is just follow you way: Test::Ptr test = Test::Allocate(); Things like those will fail at compile time: Test test; Test* test = new Test(); ((Test*)malloc(sizeof(Test)) will still work though, but that will be useless if there is some initialization to do) bringiton> object<Test> o; bringiton> o.NewObject(1, 'a', "hello"); Well, for this to work you object<> has to be like a transparent proxy. As long as users can't allocate whatever classes you use, or can't use them with your code unless allocated like that -- it will work good.
there should be either total freedom or total control.
bringiton> i dissagree again. ok, stl and boost need to be very generic because bringiton> it needs to be used in many types evironments/programs. bringiton> however, for my needs, i am writing 1 program in particular, and would bringiton> like my objects to behave only in a manner that is appropriate for bringiton> that program. Yep, so you went the second road. Just don't stop halfway :). If user can't normally break it -- you are fine.