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

From: bringiton bringiton (kneeride_at_[hidden])
Date: 2006-07-15 21:53:51

On 7/16/06, Zolenko Yevgeniy <zolenkoe_at_[hidden]> wrote:
>
> >> 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.
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>

Yes Zolenko, that is what I was trying to say. To try and design so
that the compiler detects all misuse of the interface.

Initially my shared pointers that encapsulated memory managent could
only use the default contructor of T. ie:

template <class T>
class Ptr {
  void Allocate() {
     ptr.reset(new T());
  }

With the help of Roman, the class can now handle other constuctors.

        // 0 parameter
        void NewObject() {
                m_ptr.reset(new TTYPE());
        }

        // 1 parameter
        template <class P1>
        void NewObject(P1 p1) {
                m_ptr.reset(new TTYPE(p1));
        }

        // 2 parameters
        template <class P1, class P2>
        void NewObject(P1 p1, P2 p2) {
                m_ptr.reset(new TTYPE(p1, p2));
        }

        // 3 parameters
        template <class P1, class P2, class P3>
        void NewObject(P1 p1, P2 p2, P3 p3) {
                m_ptr.reset(new TTYPE(p1, p2, p3));
        }
etc...

*this can be done with iterative macros, but it went over my head.