StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>There are two situations where I think it's worth having your own wrappers:</p> <p>1) You've looked at several different mutex implementations on different systems/libraries, you've established a common set of requirements that they can all satisfy and that are sufficient for your software. Then you define that abstraction and implement it one or more times, knowing that you've planned ahead for flexibility. The rest of your code is written to rely <em>only</em> on your abstraction, not on any incidental properties of the current implementation(s). I have done this in the past, although not in code I can show you.</p> <p>A classic example of this "least common interface" would be to change <code>rename</code> in the filesystem abstraction, on the basis that Windows cannot implement an atomic rename-over-an-existing-file. So your code <em>must</em> not rely on atomic rename-replacement if you might in future swap out your current *nix implementation for one that can't do that. You have to restrict the interface from the start.</p> <p>When done right, this kind of interface can <em>considerably</em> ease any kind of future porting, either to a new system or because you want to change your third-party library dependencies. However, an entire framework is probably too big to successfully do this with -- essentially you'd be inventing and writing your own framework, which is not a trivial task and conceivably is a larger task than writing your actual software.</p> <p>2) You want to be able to mock/stub/sham/spoof/plagiarize/whatever the next clever technique is, the mutex in tests, and decide that you will find this easier if you have your own wrapper thrown over it than if you're trying to mess with symbols from third-party libraries, or that are built-in.</p> <p>Note that defining your own functions called <code>wrap_pthread_mutex_init</code>, <code>wrap_pthread_mutex_lock</code> etc, that precisely mimic <code>pthread_*</code> functions, and take exactly the same parameters, might satisfy (2) but <em>doesn't</em> satisfy (1). And anyway, doing (2) properly probably requires more than <em>just</em> wrappers, you usually also want to inject the dependencies into your code.</p> <p>Doing extra work under the heading of flexibility, without actually providing for flexibility, is pretty much a waste of time. It can be very difficult or even <em>provably impossible</em> to implement one threading environment in terms of another one. If you decide in future to switch from pthreads to <code>std::thread</code> in C++, then having used an abstraction that looks exactly like the pthreads API under different names is (approximately) no help whatsoever.</p> <p>For another possible change you might make, implementing the full pthreads API on Windows is sort of possible, but probably more difficult than only implementing what you actually need. So if you port to Windows, all your abstraction saves you is the time to search and replace all calls in the rest of your software. You're still going to have to (a) plug in a complete Posix implementation for Windows, or (b) do the work to figure out what you actually need, and only implement that. Your wrapper won't help with the real work.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload