memory management - Do I need to delete unmanaged objects in C++/CLI -


i have c++/cli method calling c structures , methods:

in c header:

typedef struct {   int left;   int top;   int right;   int bottom; } frame_t;  typedef struct {   int     width;   int     height;   int     group;   int     nb_hints;   frame_t *hints;    frame_t view;   frame_t dest;   int     page; } image_t;  int resize_to_fill(image_t *image, int width, int height); 

the c++/cli wrappers:

public ref class frame { public:     int left;     int top;     int right;     int bottom;      property int width {         int get() {             return (right - left);         }     }     property int height {         int get() {             return (bottom - top);         }     }      frame() {         top = 0;         left = 0;         bottom = 0;         right = 0;     }  internal:     frame_t tonative() {         frame_t f;         f.left = left;         f.top = top;         f.right = right;         f.bottom = bottom;         return f;     }      frame(const frame_t &f) {         left = f.left;         top = f.top;         right = f.right;         bottom = f.bottom;     } };  public ref class image { private:     void init(int nb_hints) {         this->view = gcnew frame();         this->dest = gcnew frame();         this->page = 0;         this->hints = gcnew array<frame^>(nb_hints);     }  public:     int width;     int height;     array<frame^>^ hints;      property int group {         int get() {             return group;         }     }     property int page {         int get() {             return this->page;         }     }     property frame^ view {         frame^ get() {             return this->view;         }     }     property frame^ dest {         frame^ get() {             return this->dest;         }     }      image(int nb_hints) {         this->init(nb_hints);     }      image() {         this->init(0);     }  internal:     frame^ view;     frame^ dest;     int page;     int group;      image(image_t native) {         this->width = native.width;         this->height = native.height;          this->hints = gcnew array<frame^>(native.nb_hints);         (int = 0; < native.nb_hints; i++)         {             this->hints[i] = gcnew frame(native.hints[i]);         }          this->group = native.group;         this->page = native.page;         this->dest = gcnew frame(native.dest);         this->view = gcnew frame(native.view);     }      image_t tonative() {         image_t i;         i.width = this->width;         i.height = this->height;         i.group = this->group;          // hints         i.nb_hints = this->hints->length;         i.hints = new frame_t[this->hints->length];         (int nb = 0; nb < this->hints->length; nb++)         {             i.hints[nb] = this->hints[nb]->tonative();         }          // output values         i.page = this->page;         i.view = this->view->tonative();         i.dest = this->dest->tonative();          return i;     } };  // later, in class static int resizetofill(image^ %image, int width, int height) {     image_t native = image->tonative();      int result = resize_to_fill(&native, width, height);      image = gcnew image(native);      // need ?     delete *native;      return result; } 

do need delete native structure instance ?

i've searched answer already, it's more disposing of managed resources unmanaged ones, seems evident people. i'm new c/c++ don't have memory management reflexes.

image = gcnew image(native); 

it entirely depends on statement does. library using not common 1 , image wrapper class not system::drawing::image there's no way tell snippet.

there 2 ways programmer of library have implemented it. if did smart way made problem , created shallow copy. in other words, new instance of image shares same underlying pixel buffer native. or have created deep copy , created new pixel buffer image object. in case can safely destroy image_t object.

that difference exists in .net well, bitmap::clone() makes shallow copy, bitmap(image^) constructor makes deep copy. there huge difference between two, shallow copy takes few handfuls of nanoseconds @ most. deep copy takes much, longer if image large, milliseconds.

dealing shallow copy if quite painful, can't change finalizer of image class. have keep image_t* around , signal image object no longer in use can safely delete it. you'll have restructure code. if guessed wrong got pretty nasty problem, isn't guaranteed crash code. you've got dangling pointer isn't cause access violation. seems work fine when test, corrupts displayed image or crashes program undiagnosably when you're not looking.

very important @ library's source code or documentation know does.


Comments

Popular posts from this blog

javascript - AngularJS custom datepicker directive -

javascript - jQuery date picker - Disable dates after the selection from the first date picker -