C++ design pattern

Can you help me? I'm wondering what is the best pattern for the situation I'll describe.

SITUATION 1


class Inside {
  public:
    Inside(int a, int b) {
        yada = a;
        foo = b;
    }
    int yada;
    int foo;
};

class Container {
  private:
    Inside *c;
  public:
    Container(Inside *i) {
        c = i;
    }
    ~Container() {
        delete c;
    }
};

This situation allows you to avoid deleting the parameter passed as argument, so you can do:

Container c(new Inside(10, 20));
and the Inside instance will be deleted automatically. Drawbacks following:

Inside i(10, 20);
Container c(&i);
FUCK, i've deleted the stack!

SITUATION 2


class Inside {
    ...
};

class Container {
  private:
    Inside *c;
  public:
    Container(Inside *i) {
        c = i;
    }
    ~Container() {}
};

Now you can do:

Container c(new Inside(10, 20));
but you get memory leaks, so you need to take around with you a pointer to the Inside instance, and this is pretty unconfortable!

How would you do?

How would you do?
Don't use C++ and do manual memory management like a real man.

FUCK, i've deleted the stack!
Don't do that then, you massive idiot.

>>1

class Inside
{ public:
    Inside(int a, int b)
    { yada = a;
      foo = b; }
    int yada;
    int foo; };

class Container
{ private:
    Inside *c;
    bool deleteInside;
  public:
    Container(Inside *i, bool d = false)
    { c = i;
      deleteInside = d; }
    ~Container()
    { if(deleteInside) delete c; }};

>>4
FrozenVoid?

>>5 I hate C++ and especially those OOP/Template abstractions.



______________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
However profound the complicated knowledge of the world, compared to enlightenment it is like one drop of water to the great ocean.

>>5 I hete-a C++ und ispeceeelly thuse-a OoOP/Templete-a ebstrecshuns. Bork Bork Bork!



______________________________________
http://xs141.xs.to/xs141/09303/av992393.jpg
Hooefer pruffuoond zee cumpleeceted knooledge-a ooff zee vurld, cumpered tu inleeghtenment it is leeke-a oone-a drup ooff veter tu zee greet ooceun.

>>6
I doubt that!

>>8 C++ is not C. Think about the layers above C. Thats whats built in C++.
I can happily use C++ compilers if they compile C code.



____________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
When everyone thinks the same, nobody is thinking.

>>8 C++ is nut C. Bork Bork Bork! Theenk ebuoot zee leyers ebufe-a C. Bork Bork Bork! Thets vhets booeelt in C++. Bork Bork Bork!
I cun heppeely use-a C++ cumpeelers iff zeey cumpeele-a C cude-a. Bork Bork Bork!



____________________________________________
http://xs141.xs.to/xs141/09303/av992393.jpg
Vhee iferyune-a theenks zee seme-a, nubudy is theenking.

>>9
The fuck are you on about? I was talking about coding style, shut up with your language and compiler bullshit. And use sage once in a while, jeez.

>>11 I describe why i hate C++, which >>8 doubted about..



_________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
I'd hate to wake up some morning and find out that you weren't you.

>>11 I descreebe-a vhy i hete-a C++, vheech >>8 duoobted ebuoot.. Bork Bork Bork!



_________________________________________________
http://xs141.xs.to/xs141/09303/av992393.jpg
I'd hete-a tu veke-a up sume-a murneeng und feend oooot thet yuoo veren't yuoo.

>>11
YHBT

>>7
I lol'd quite hard

If you're writing a toy program, use Python. Or just leak memory or do whatever is convenient.
For anything else, always place allocation and deallocation together in the same section of the code. Always. Always.

Don't listen to >>16. Use std::auto_ptr and you don't have to worry about manually freeing memory.

std::auto_ptr
don't have to worry

>>16 and >>6
Actually the point is not "what language should I use", but "what strategy is better". Also: frozenvoid, stop with your bullshit, I know you want to be worshipped, but here we are talking about C++, not about you.

>>4's solution is good, but asking it to the programmer would divert him from the BUSINESS LOGIC for language related issues. I don't think this would be a good thing.

Who owns the Inside object? If a Container instance owns the Inside object, then make a copy of it when you assign it and delete it in the deconstructor. If it's not owned by the Container instance, then don't delete it.

>>20
Yeah, what the fuck? Why was this hard?

>>4
Horrible, horrible solution.

>>1
This is a definite problem, and you shouldn't leave the code this way no matter how you've documented it. There are a few solutions...

- As >>17 said, use std::auto_ptr or boost::shared_ptr. This is ugly, but will prevent you from screwing up memory management (unless you go out of your way to do something stupid). However, it forces you to allocate an object to pass into it. You are likely to want to stack-allocate an Inside object.

- A better solution in this case is to just copy it. Your Inside object only has two ints, so it should support the copy operation; the overhead of an allocation is far greater than the extra int. However, this won't allow you to dynamically update the Inside without refreshing the container. For your Inside class (which seems to be just a point), this should not be dynamic anyway; it's obviously something intrinsic to the Container which should be abstracted away.

If you *really* need the update to be dynamic, use boost::shared_ptr, or if that's not available, simply do not delete the object in Container; delete it by the class it was created in.

Here's fixed code:


class Inside {
  public:
    Inside(int a, int b) {
        yada = a;
        foo = b;
    }
    int yada;
    int foo;
};

class Container {
  private:
    Inside c;
  public:
    explicit Container(const Inside& i) {
        c = i;
    }
    ~Container() {}
};

And now you can do this:


Inside i(5, 3);
Container c(i);

Or simply:


Container c(Inside(5,3));

What the hell are you trying to do anyway? Perhaps you should step back and think of a better way to conceptually solve your problem rather than give us a few fragments of code and effectively tell us "make this work".

>>19
“Doctor, it hurts when I lift my elbow up to here!”
«Well, don't do that, then.»
... is a perfectly topical answer. Learning to handle resource ownership is all well and good, but learning to use a language with proper memory management when appropriate first will be vastly more useful.

OP here.

>>22
Thanks for your answer, you are definitely part of the party that keeps this place alive.

>>23
Actually I don't need to do something similar, but I stumple into a similar code while reading a programming example, and suddenly I wtf-ed.

Thanks /prog/