Reputation: 691
I've been searching for answers for my problem but it seems most people are interested passing std::string across .dll boundaries. But I am more interested in using a std::string in a class that is in a .dll that I am creating.
I am releasing my .dll (emailing) to a group of people on forum I am apart of, so my question is can you use std::string in a .dll without having limitations like compiler needing to be the same, version, CRT needing to be the same, etc.
Can you give me examples on what is not safe and what IS safe?
Example: Would this be safe for the "downloader" to use SetSender function?
Mail.h
class _declspec(dllexport) Mail {
struct ENVELOPE {
std::wstring SenderEmail; //Should the type be LPWSTR or can it safely be std::wstring
LPWSTR SenderName;
}Envelope;
public:
int SetSender(LPWSTR SenderEmail);
Mail();
~Mail();
};
Mail.cpp
#include "stdafx.h"
#include "Mail.h"
int CoffeeBeans::Mail::SetSender(LPWSTR Email) {
//Pass LPWSTR instead of std::wstring across .dll boundary
if (Email == nullptr || lstrcmp(Email, L"") == 0) {
throw L"Email was either nullptr or empty.";
}
this->Envelope.SenderEmail = SenderEmail;
return 0;
}
Upvotes: 4
Views: 788
Reputation: 5920
Using a pointer to the string buffer like LPWSTR
, or wchar_t*
, etc will always be safe as long as your dll code is not invoking an unspecified behavior (memory is allocated correctly, pointer is initialized, you are not passing pointer to the local buffer, etc). Using an std::string
will be safe only as long, as your dll and a host are using the same CRT version. If versions differ, your strings could cause an Access Violations on any execution stage (usually it happens on the string destruction). You may insure CRT matching by distributing your dll sources or by compiling different dll versions for all existing CRTs (Oracle, for example, does this for their OCCI
library). This approach of course would not work if a client is not using C++.
Upvotes: 2