On 7/16/06, Zolenko Yevgeniy
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@lists.boost.org 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