There is no standardized C++ ABI.
Do they include their own version of the stdlib functions? Do they include the stdlib as a shared library themselves?
If they were created with a different compiler the class layout maybe be very different and so passing objects between your code and the DLL's code may result in crashes or other undefined behaviour.
Exactly, and to illuminate what this means in practice for Vincent, its that when your app is compiled with, say, Visual Studio 2013, update 2, bugfix 12, only DLLs compiled with the same exact version is guaranteed to work as expected (and still only if the compiler configs are identical and suitable for the purpose). It means that DLLs compiled with newer versions of compiler may not work, and more importantly that when the client is compiled with a newer version of the compiler, all the existing older DLLs are potentially broken. If you control all the code for the client and DLLs, you can at least provide DLLs that are in sync with your client, but still a user might copy an incompatible plugin DLL into your plugin directory and cause havoc; but where it gets much more difficult is when you have 3rd-party DLLs -- did you ever notice the boneyard of browser plugins that no longer work with the latest firefox.
In practice, of course, things are more stable than that, but the spectre of everything being broken by a minor-version increment of your compiler is a cause for concern.
This is why other ABIs do exist, such as COM.
Assuming you do decide to go the native DLL route, then I highly recommend you look long and hard at COM and how it behaves to get an idea of how to structure your code.