1

I am attempting to write a C++ wrapper of OpenVG, which is very Open-GL like in its design. here is a simple wrapper for a path handle:

class Path {
        VGPath handle;

    public:
        Path() :
        handle(vgCreatePath(VG_PATH_FORMAT_STANDARD, VG_PATH_DATATYPE_F,
            1,0,0,0, VG_PATH_CAPABILITY_ALL)) 
        { 
        std::cout << "Path Handle created : " << (void*)handle << '\n';
        }

        ~Path() {
            std::cout << "Path destroyed  : " << (void*)handle << '\n';
            vgDestroyPath(handle);
        }

    };

unfortunately, openVG requires a context to function and will abort if vgCreatePath is called with no openVG context. This prevents me from creating (for testing purpose) a global Path object object in my code, since it is build before I can create a openVG context (I do so in the main). Is there any workaround to prevent this?

I think that leaving the handle unitialized at the object construction is a very bad idea... should I force the creation of a global context when I'm creating a Path object if no context is present?

genpfault
  • 51,148
  • 11
  • 85
  • 139
lezebulon
  • 7,607
  • 11
  • 42
  • 73

1 Answers1

4

Is there any workaround to prevent this?

Yes, use smart pointers, create it on demand using some kind of "factory" function, store it as long as it is needed in any variable.

In C++03:

typedef boost::weak_ptr<Path> PathWeakPtr;
typedef boost::shared_ptr<Path> PathPtr;

PathPtr createPath(){
    static PathWeakPtr lastPath;
    PathPtr result = lastPath.lock();
    if (!result){
        result.reset(new Path());
        lastPath = result;
    }
    return result;
}

...

void doSomething(){
    PathPtr path = createPath();//points to same path as in main*()
    ...
}

int main(int argc, char** argv){
    PathPtr path = createPath();//initialization
    doSomething();
    return 0;
}

In C++11 use:

typedef std::weak_ptr<Path> PathWeakPtr;
typedef std::shared_ptr<Path> PathPtr;

instead of

typedef boost::weak_ptr<Path> PathWeakPtr;
typedef boost::shared_ptr<Path> PathPtr;
SigTerm
  • 26,089
  • 6
  • 66
  • 115
  • @ChristianRau: DUde, boost dependency IS necessary, because not all compilers have shared_ptr/weak_ptr in std. – SigTerm May 30 '12 at 13:57
  • Well, not neccessary but an alternative (and surely the secondary when C++11 is supported). General suggestion of boost features without even mentioning their presence in the newest standard is bad practice. But you're right in that I have probably acted over my competences and shouldn't have replaced one rigid requirement by another. Made the matter clear, DUDE. – Christian Rau May 30 '12 at 14:01
  • @ChristianRau: "suggestion of boost features without even mentioning their presence in the newest standard is bad practice" That's your personal opinion which I will ignore. The question is not tagged c++11. Please avoid unnecessarily modifying answers (written by other people) in the future - if you can edit everything it doesn't mean you should actually do it. The example illustrates simple concept. Whether it is implemented using boost or c++11 is irrelevant. – SigTerm May 30 '12 at 15:34
  • Well, usually I am a bit more conservative with edits and keep it to comments, you're right in that I acted over my competences there. And still I wonder in whose opinion the suggestion of plain unneccessary third party dependences is a good idea, but well, be it so. – Christian Rau May 30 '12 at 15:35
  • @ChristianRau: "plain unneccessary third" C++03 compilers are still fairly common and some of them may or may not have shared_ptr (within tr1 namespace, if I remember correctly) or cstdint. Although I'm not a fan of Boost, in this situation it makes sense to use Boost, because it **guarantees** that shared_ptr, weak_ptr, cstdint types and similar things are present. Once C++11 compilers become more common (currently there's no complete support even in GCC, and AFAIK MS doesn't provide much of C++11 support),it'll be possible to safely remove boost dependency. However, this will take few years. – SigTerm May 30 '12 at 15:58
  • Sure, totally agree. It was just the complete omitting of the (if supported) much more platform-independent alternative (and it wasn't a good idea from me to just completely omit the boost alternative either). As it stands the answer is much better (but I already up-voted it long ago, anyway). – Christian Rau May 30 '12 at 16:06