Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Managed C++/CLI
  4. Manged pointer to local object

Manged pointer to local object

Scheduled Pinned Locked Moved Managed C++/CLI
performancequestion
4 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Offline
    L Offline
    LionAM
    wrote on last edited by
    #1

    Hello! When I have a managed pointer to a local object t that goes out of scope, the destructor of t is called. Does pt still point to valid memory (and I can mark t as invalid), or is there any other way to find out if the object pointed to by pt was destroyed?

    Test^ pt;
    {
    Test t;
    pt = %t;
    }

    pt->...

    Thank you! Alex

    M 1 Reply Last reply
    0
    • L LionAM

      Hello! When I have a managed pointer to a local object t that goes out of scope, the destructor of t is called. Does pt still point to valid memory (and I can mark t as invalid), or is there any other way to find out if the object pointed to by pt was destroyed?

      Test^ pt;
      {
      Test t;
      pt = %t;
      }

      pt->...

      Thank you! Alex

      M Offline
      M Offline
      Mark Salsbery
      wrote on last edited by
      #2

      LionAM wrote:

      is there any other way to find out if the object pointed to by pt was destroyed?

      pt is still valid in your code. There's no "pointers" here - these are managed references. You have created a new reference to t by assigning a tracking reference of t to pt. As long as pt stays in scope it is a valid Test reference. You can assign nullptr to references...

      Test^ pt;
      {
      Test t;
      pt = %t;
      }
      pt = nullptr;
      if (nullptr != pt)
      {
      pt->...
      }

      *edit* I played around with this and with stack based semantics the destructor is still called as you stated. This behavior makes code like your example dangerous. I'd prefer using all reference semantics if I was going to obtain additional references, something like

      Test^ pt;
      {
      Test ^t = gcnew Test();
      pt = t;
      }
      delete pt; // destructor called here!
      pt = nullptr;

      That seems clearer to me *shrug* Mark

      Mark Salsbery Microsoft MVP - Visual C++ :java:

      modified on Monday, August 18, 2008 3:17 PM

      L 1 Reply Last reply
      0
      • M Mark Salsbery

        LionAM wrote:

        is there any other way to find out if the object pointed to by pt was destroyed?

        pt is still valid in your code. There's no "pointers" here - these are managed references. You have created a new reference to t by assigning a tracking reference of t to pt. As long as pt stays in scope it is a valid Test reference. You can assign nullptr to references...

        Test^ pt;
        {
        Test t;
        pt = %t;
        }
        pt = nullptr;
        if (nullptr != pt)
        {
        pt->...
        }

        *edit* I played around with this and with stack based semantics the destructor is still called as you stated. This behavior makes code like your example dangerous. I'd prefer using all reference semantics if I was going to obtain additional references, something like

        Test^ pt;
        {
        Test ^t = gcnew Test();
        pt = t;
        }
        delete pt; // destructor called here!
        pt = nullptr;

        That seems clearer to me *shrug* Mark

        Mark Salsbery Microsoft MVP - Visual C++ :java:

        modified on Monday, August 18, 2008 3:17 PM

        L Offline
        L Offline
        LionAM
        wrote on last edited by
        #3

        Thank you. I see that the local (ref) object is also on the managed heap - the only difference is that the destructor is called. In my case, I need the local object because it is a lock (which has to be destroyed when leaving scope). Alex

        M 1 Reply Last reply
        0
        • L LionAM

          Thank you. I see that the local (ref) object is also on the managed heap - the only difference is that the destructor is called. In my case, I need the local object because it is a lock (which has to be destroyed when leaving scope). Alex

          M Offline
          M Offline
          Mark Salsbery
          wrote on last edited by
          #4

          LionAM wrote:

          In my case, I need the local object because it is a lock (which has to be destroyed when leaving scope).

          Makes sense. Just for reference, there's other ways to get the destructor called:

          (from Destructors and Finalizers in Visual C++[^]):

          Code authored in Visual C++ and compiled with /clr will run a type's destructor for the following reasons:

          \* If an object created using stack semantics goes out of scope.
          \* If an exception is thrown during the object's construction.
          \* If the object is a member in an object whose destructor is running.
          \* If you call the delete Operator (C++) on a handle (^ (Handle to Object on Managed Heap)).
          \* If you explicitly call the destructor.
          

          If your type is being consumed by a client authored in another language, the destructor will be called when:

          \* A call to Dispose.
          \* Calling Dispose(void) on the type.
          \* If the type goes out of scope in a C# using statement.
          

          Regardless, having a second reference outside the scope is a bad idea and shouldn't be necessary :) Cheers, Mark

          Mark Salsbery Microsoft MVP - Visual C++ :java:

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups