C++ programming practice question

[Red Squirrel]

When creating my own library for something and it uses pointers, should I make it so I don't need to use the pointers when implimenting the class, and have a "wrapper" instead? Or is it just more efficient to use the pointers? I can see having a wrapper being more safe to avoid mistakes as the wrapper can handle all the deletes and what not.

Here's an example I'm working on, it's a TCP server class. I will declare a new server object, call listen with the port # and all that, then poll for new connections. It is non blocking. If it gets a new connection a new "client" object is gotten so I can use it within the implimetor application. Now, should this client object be a pointer (the socket class creates it as pointer) or should I have a wrapper class that contains that pointer?

Part of me says to have the wrapper class another part of me says to just give the pointer out. What is normally the best practice in situations like this?


Also, if I do make a non pointer wrapper class that contains the pointer, and that object gets passed around functions, put in arrays, etc... it gets copied around creating multiple instances of that object (But it's the same pointer so it's still pointing to same actual data). How do I go about making it so if I delete the pointer in one of the instances, the other instances will know that the pointer is deleted?


For example:

class A
{
//data and stuff
};

Class WA //wrapper class
{
A * data;
WA(); //creates a "A" object and stores to data
delete(); //deletes pointer to free memory
//more stuff
}

void function(WA a)
{
a.delete();
}

main()
{
WA wrapperinstance;

function(wrapperinstance)

//here is there a way I can know that the pointer was deleted if I try to use wrapperinstance? 

}

 

[Venix]

The standard library has shared_ptr and auto_ptr (which is soon to be deprecated in favor of unique_ptr). There is no reason to write your own wrapper.

 

[Red Squirrel]

Is unique_ptr part of STL? I'm hoping it is as I might look into it. I just don't like using 3rd party libraries if I can avoid it. Makes portability and deployment harder.

 

[Kirby]

I think it's in boost.

 

[Cogman]

I think it's in boost.

Yes, smart pointers is a boost thing. Boost is fairly portable, but a beast to compile (IMO).

As for the using just straight pointers. It CAN be just as efficient to use the wrapper class, IF all the wrapper class functions are inlined by the compiler. If not, then you get an excess of stack calls that will slow things down a bit. (You might get this even if the compiler inlines it).

Where you will see the inefficiencies is passing around the object pointer wrapper. for just a pointer, it is a single push for a function call and the pointer is passed. But for a object pointer wrapper you have a couple of pushes to get the entire object on the stack.

If speed is the key, then dump the object wrapper and make sure you free every new. If readability and maintainability are more important, then I would say that the overhead from using the objects is fairly minimal, and worth the loss in speed.

 

[Venix]

All three pointers I mentioned are part of the standard library, although unique_ptr is only available in C++0x (GCC 4.4? and Visual Studio 10).

There is zero overhead in using auto_ptr or unique_ptr, and minimal overhead for shared_ptr. If a heap-allocated object can be owned by a single other object, store it in a unique_ptr/auto_ptr and just pass references or pointers to the underlying object to anyone else who needs to use it. If you need shared ownership with reference counting, use shared_ptr.

 

[Red Squirrel]

I can't seem to find much info on how to impliment unique_ptr, could you point me to a document that shows how? I will look into this if it's part of the STL. I may just need to update my GCC (G++ is same thing right, that's what I use). I looked at boost but it just seems like a pain to use. I may use it for larger projects but don't want my custom header group / library to depend on it. It's just a little frame work I'm continuously updating to make repetitious things easier to code and I want it to simply consist of a copy to /usr/include and it's good to go.

 

[Nothinman]

Yes, smart pointers is a boost thing. Boost is fairly portable, but a beast to compile (IMO).

Why do you need to compile boost? If you're doing this on Linux there should already be boost packages for your distro. The Boost Asio library also seems to include network functions, so why waste time writing another library for it?

 

[pdusen]

Also, the shared_ptr library is header-only and doesn't need to be compiled, just included.

 

[Red Squirrel]

Why do you need to compile boost? If you're doing this on Linux there should already be boost packages for your distro. The Boost Asio library also seems to include network functions, so why waste time writing another library for it?

So when I'm compiling my program on another machine I don't have to deal with issues from system to system. The less dependencies, the easier it is to install the program.

 

[Nothinman]

So when I'm compiling my program on another machine I don't have to deal with issues from system to system. The less dependencies, the easier it is to install the program.

You deal with lots of systems that don't have boost packages available?

 

[pdusen]

The less dependencies, the easier it is to install the program.

This does not necessarily follow. I find it's definitely easier to depend on well-written libraries to access platform-specific functions rather than create my own wrappers, particularly in the space of well-written, highly-portable libraries such as boost.

 

[Red Squirrel]

Also, the shared_ptr library is header-only and doesn't need to be compiled, just included.

Hmm really, there's no library or anything, just drop the .h and good to go? Why can't every 3rd party library be this easy? I'll definably take a look at it. I figured it involved libs, possible kernel recompile, weird compile strings and crap like that. I've seen some 3rd party libraries that are quite involved to get going (ex: mysql++ - that one is a beast).

Is this the same for unique_ptr? If the others will be deprecated I may as well use this one.

I just want to make sure I'm clear on this, will unique_ptr allow me to tell from another function that a pointer was deleted in another function, like in my code example problem?

 

[Nothinman]

Hmm really, there's no library or anything, just drop the .h and good to go? Why can't every 3rd party library be this easy? I'll definably take a look at it. I figured it involved libs, possible kernel recompile, weird compile strings and crap like that. I've seen some 3rd party libraries that are quite involved to get going (ex: mysql++ - that one is a beast).

Is this the same for unique_ptr? If the others will be deprecated I may as well use this one.

I just want to make sure I'm clear on this, will unique_ptr allow me to tell from another function that a pointer was deleted in another function, like in my code example problem?

It does require libs, but they're part of the C++ standard library now.

Why in the hell would a userland app require a kernel recompile? You constantly seem to be attacking this problem from the wrong angle. If you'd work within the system instead of always trying to go around it I bet things would go a log easier for you.