To solve a very peculiar problem in my application I need a shared-pointer to allocated data, but to the outside world, the underlying data type should remain hidden.
<The shared_ptr constructor that you use is actually a constructor template that looks like:
template <typename U>
shared_ptr(U* p) { }
It knows inside of the constructor what the actual type of the pointer is (X) and uses this information to create a functor that can correctly delete the pointer and ensure the correct destructor is called. This functor (called the shared_ptr's "deleter") is usually stored alongside the reference counts used to maintain shared ownership of the object.
Note that this only works if you pass a pointer of the correct type to the shared_ptr constructor. If you had instead said:
SharedVoidPointer sp1(static_cast<void*>(x));
then this would not have worked because in the constructor template, U would be void, not X. The behavior would then have been undefined, because you aren't allowed to call delete with a void pointer.
In general, you are safe if you always call new in the construction of a shared_ptr and don't separate the creation of the object (the new) from the taking of ownership of the object (the creation of the shared_ptr).
I think the implicit point of the question was that you can't delete by void*, so it seems strange that you can delete through shared_ptr<void>.
You can't delete an object via a raw void* primarily because it wouldn't know what destructor to call. Using a virtual destructor doesn't help because void doesn't have a vtable (and thus no virtual destructor).
James McNellis clearly explained why shared_ptr<void> works, but there is something else interesting here: Assuming you follow the documented best practice to always use the following form when invoking new...
shared_ptr<T> p(new Y);
...it is not necessary to have a virtual destructor when using shared_ptr. This is true whether T is void, or in the more familiar case where T is a polymorphic base of Y.
This goes against a long-standing conventional wisdom: That interface classes MUST have virtual destructors.
The OP's delete (void*) concern is solved by the fact that the shared_ptr constructor is a template that remembers the data type that it needs to destruct. This mechanism solves the virtual destructor problem in exactly the same way.
So even though the actual type of the object is not necessarily captured in the type of the shared_ptr itself (since T does not have to be the same type as Y), nevertheless, the shared_ptr remembers what type of object it is holding and it performs a cast to that type (or does something equivalent to that) when it comes time to delete the object.