Thread: Probably another bad idea... Pointer question..

Here's the code. The question follows.

Code:

#pragma once
#define SAFE_DELETE(var) if ( var ) { delete var; var = 0; }
template<class T>
class Type
{
public:
    //Default constructor
    Type()
        :is_good(false),
         typePtr(0)
    {/*Empty code block*/};

    //Assignment constructor
    Type(const T& val)
        :is_good(false),
         typePtr(0)
    {
        //Allocate memory with assigned value
        typePtr = new T(val);
        if ( *typePtr == val )
            is_good = bool(true);
        else
        {
            SAFE_DELETE(typePtr);
        }
    };

    //Copy constructor
    //Does not copy pointers. Copies values.
    Type(const Type& copy)
        :is_good(false),
         typePtr(0)
    {
        //Allocate memory with copy values
        typePtr = new T(*copy.typePtr);
        if ( *typePtr == *copy.typePtr )
            is_good = bool(true);
        else
        {
            SAFE_DELETE(typePtr);
        }
    };

    //Destructor
    ~Type()
    {
        is_good = false;
        SAFE_DELETE(typePtr);
    };

    //Copy assignment
    const Type& operator=(const Type& copy)
    {
        if ( typePtr )
        {
            is_good = bool(false);
            SAFE_DELETE(typePtr);
        }
        typePtr = new T(*copy.typePtr);
        is_good = copy.is_good;

        return *this;
    };

    T& operator*()
    {
        return *typePtr;
    };

    T* operator->()
    {
        return typePtr;
    };

    operator bool()
    {
        return is_good;
    };
private:
    bool is_good;

    //The pointer to the type
    T* typePtr;
};

#undef SAFE_DELETE

Ok, first off. The SAFE_DELETE is defined then undefined, because most of my classes need a different version of it.

The point of the class is to wrap the handling of the pointer. Pretty much to disallow modifying the pointer without ugly code.
My thought on this is that with this class I can do something like the following.

Code:

Type<int> Test(100);
if ( Test )//check if the ptr is good
   std::cout << *Test << std::endl;

//As opposed to
int * Test = new int(100);
if ( Test != 0 )
   std::cout << *Test << std::endl;
delete Test;

I realize that there isn't much difference between them, but I thought I would see what you guys thought. Well Thank you.

EDIT:
Also, if I am not mistaken the only way to directly modify the pointer, or to prematurely delete would be to do this right?

Code:

Type<int> Test(100);
delete Test.operator->();//Am i right?

I only saw one question, and the answer to that question: Ewww! Anyone writing that deserves to have it blow up; don't worry about it.

Soma

So is the class a good/mediocre/bad idea?

So is the class a good/mediocre/bad idea?

Ah... it isn't a bad idea per say... just very incomplete. (For example, if you give it a polymorphic type your copy mechanism will fail. If you change the behavior of the copy mechanism indirectly through a customizable--template class that can be specialized, interface you could allow a provider of such a polymorphic class to support your pointer-thing. You should still provide a default behavior matching what you have for all normal types.) I see only three paths by which this might evolve: 1) It evolves until it mimics 'copy_ptr'. 2) It evolves until it mimics 'std::vector<?>'. 3) It evolves until it mimics Alexandrescu's policy based pointers--providing a slightly odd mechanic for at least one policy.

So... do you want to reinvent the wheel? If so, go for it. (Unlike most people, I think reinventing the wheel is good for you; you are bound to learn something if you are unfamiliar with that particular flavor of wheel.)

Soma

Originally Posted by CornedBee

When writing smart pointers, there are four well-known copy strategies: disallow (boost::scoped_ptr), move (std::auto_ptr, C++0x std::unique_ptr), share (boost::shared_ptr) and clone (various clone_ptr implementations, and your class). Of these, clone is the least useful. This is for a reason.

A clone_ptr would relieve you of having to write deep copy constructors, if the class holds its internal pointers in clone_ptrs. I'd call that a huge win.

Originally Posted by CornedBee

Do you have many classes that have pointer to single objects they own as members? I don't.

Not really. I've only needed such a thing a few times, but it was nice to not be forced to write a huge redundant copy constructor, which I can potentially make a typo in, just to deal with a single weird field.

Since value semantics rule, a clone_ptr would be important for use with classes and class hierarchies that you wish to have keep those value semantics, right?

I've run into a couple of occasions where I would like to have used a clone_ptr without the extra headache of having to write a clone() function. I think using a pimpl with a class you wish to be copyable was one example. That said, I've never actually gone ahead and done it, so I can't say whether it would truly be useful or not.