On 7/15/06, Zolenko Yevgeniy
bringiton> I'm trying to define a MACRO that creates a shared_ptr and hides bringiton> memory allocation. Here is what i have so far:
bringiton> #define NEW0(T) boost::shared_ptr<T>(new T()); bringiton> #define NEW1(T, p1) boost::shared_ptr<T>(new T(p1)); bringiton> #define NEW2(T, p1, p2) boost::shared_ptr<T>(new T(p1, p2)); bringiton> #define NEW3(T, p1, p2, p3) boost::shared_ptr<T>(new T(p1, p2, p3));
There is something wrong in the idea.
I mean from the design point of view. I think you should either trust your users to know enough about shared pointers so as not to screw up memory allocation (I am paranoid in this regard too though :)). Or you should hide the shared pointer altogether.
So this:
boost::shared_ptr<Test> p0 = NEW0(Test);
Will become something like this (and make all the constructors private):
Test::Ptr p0 = Test::Allocate();
That requires more work, but it does fully enforce the contract.
If you maintain that consistently, throughout all you code, you will have the control you desire. Down to transparent use of custom allocators.
A wrapper (macro or else) just to ease the use of shared pointers is pointless, since it does nothing to force its usage, and more often than not, you will see it bypassed because of some momentary inconvenience.
Then, all of a sudden, you decide to allocate memory on a user's newly installed brain implant (instead of old microchip), you modify you macro or whatnot to use custom allocators (since new/delete used by shared pointer are working with the old one), but in all the weird places it would not be used. The head will explode then.
That is, however you do it, there should be either total freedom or total control.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
i disagree. The aim of c++ is to hide implementation details. ie std::vector hides array memory management, std::list hides linked list implementation. i think it defeats the purpose of having a memory management class where the user manages the memory. i can see all sorts of problems with the following: shared_ptr<int> p(new int(1)); for example: int x = new int(1); shared_ptr<int> p(v); shared_ptr<int> q(v); // OUCH!!!! i don't want to assume that users will use the interface correctly. if i have a choice, i'd rather make the interface bulletproof. i've made a shared_ptr wrapper. it is very strict how it manages memory + the user can not break it. object<int> o; o.NewObject(1); object<string> o; o.NewObject("hello"); object<Test> o; o.NewObject(1, 'a', "hello");
there should be either total freedom or total control.
i dissagree again. ok, stl and boost need to be very generic because it needs to be used in many types evironments/programs. however, for my needs, i am writing 1 program in particular, and would like my objects to behave only in a manner that is appropriate for that program.