Re: [Boost-users] Macro to contruct/allocate a shared_ptr?

From: Zolenko Yevgeniy (zolenkoe_at_[hidden])
Date: 2006-07-15 20:50:25

>> 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.