0

I have a class which contains a private pointer to a struct (This is managed C++ and the struct is native). The object this pointer points to is basically created in the constructor and lives until the containing class is disposed of. There is no code that reassigns the pointer to another object once it is assigned in the constructor of Foo and I don't envision there will be any in the future.

I am not interested in answers that pertain to using smart pointers, as I work with a lot of raw pointers in some legacy code. Porting everything over is another matter and something that is being planned.

My questions are:

  1. What can I assume about the pointer while working in the class in terms of validity?

  2. If I have several private functions that use the class...should I always check for a nullptr before dereferencing in those functions, or can I assume the pointer points to a valid object given the way the class is constructed (If this were native C++ I would just make the pointer an actual object to make this go away)?

  3. Any better ways of doing this that don't involve creating another managed wrapper for SomeStructType or smart pointers?

    public ref class Foo
    {        
        private:
    
        SomeStructType* pMyStruct;        
    
        void Initialize()
        {
            pMyStruct = new SomeStructType();
        }
    
        void DoSomethingElse1();  //Uses pMyStruct
        void DoSomethingElse2();  //Uses pMyStruct
    
        public:
    
        void DoSomething();  //Uses pMyStruct or calls private func that does
    
        Foo()
        {
            Initialize();
        }
    
        ~Foo()
        {
            delete pMyStruct;
        }
    }
    
user2079828
  • 645
  • 1
  • 8
  • 31
  • Recommend rewording "There should be no instances when the pointer is reassigned without another containing class instance being created" because I can read this three different ways and probably all of them are wrong. – user4581301 Feb 19 '17 at 21:22
  • I don't know my managed C++ extensions, but in Plain Jane C++ your example will quickly run afoul of the [Rule of Three](http://stackoverflow.com/questions/4172722/what-is-the-rule-of-three). – user4581301 Feb 19 '17 at 21:26
  • @user4581301 1. I agree with the "Rule of Three" comment. I haven't got that far (in how I'm going to refactor the class), yet 2. I re-worded that sentence. Really I'm just saying that the pointer is assigned in the constructor and deleted in the destructor. No plans for anything else except for accessing the object it points to. – user2079828 Feb 19 '17 at 23:03

1 Answers1

0

No, you don't need to check it every time, since the contract (and rules of C++) implies that the object will always exist at any point you could attempt to access it in a valid way.

If it can be reassigned, and you're in a multithreaded environment, you'd probably want to lock access to it. That would be the only issue I can think of.

Erix
  • 7,059
  • 2
  • 35
  • 61
  • Can you explain what you mean by "rules of C++". I assume you mean that since the pointer points to an object that exists for the lifetime of the class I don't need to worry about it? No need for locks as this will only be used in one thread. – user2079828 Feb 19 '17 at 22:57