Old library was written in Delphi. Now I'm trying to write library in c++.
Below there is function in Delphi's library:
function MyFunction(Path:string; Options:PInteger; var Data: array of Byte):Integer; stdcall;
How should this function look in C++? Is below declariation right?
int __stdcall MyFunction(char* Path, int* Options, char* Data);
The big problem is the buffer. Your Delphi function passes an open array. This is implemented by passing both the array length, and the pointer to the first element. Your C++ translation does not do that. You'll need to pass an extra parameter specifying the length of the array.
Since you can expect that the function will not modify Path you would likely declare the first parameter as const char*.
So, the function would then look like this:
int __stdcall MyFunction(const char* Path, int* Options, size_t len, char* Data);
Now, if you are expecting that the function is to be binary interchangeable with the original C++ version you have a problem. You'd need to match the internal implementation of a Delphi open array. You can do that. The function would become:
int __stdcall MyFunction(const char* Path, int* Options, char* Data, int high);
Note that the length parameter appears after the pointer to the first element, and is named high. That's because a Delphi open array receives high(A) rather than Length(A).
You really must get out of the habit of passing Delphi specific types across interop boundaries.
Of course, I'm assuming here that you are still creating a library for interop and this function is at the interop boundary. If the function is internal then the declaration would perhaps be:
void MyFunction(const std::string &path, int &options,
const std::vector<char> &data);
There's no need for a return value since errors can be signalled with exceptions. Strings are stored in std::string, and a byte array in C++ is std::vector<char>.
Related
I have this Rust function:
pub extern "C" fn do_something(my_string: &str) {
let s = String::from(my_string);
}
That I call on C++ with this:
std::string my_string("hello");
do_something(my_string.c_str());
Signature:
extern "C" void* do_something(const char*);
I get this error right on the String::from line:
memory allocation of 127963177044160 bytes failedAborted (core dumped)
I guess that it's because the string passed has no \n so it tries to make a string of the maximum size possible.
How to safely pass a std::string to Rust?
That I call on C++ with this:
do_something(my_string.c_str());
So on the C++ side you're calling a function with a C string as input (not an std::string, which is a very relevant distinction).
This means the Rust function should take a C string as input, which &str definitely isn't.
Thus do_something should be declared as:
pub extern "C" fn do_something(my_string: *const c_char) {
following which as Jmb notes you may want to use CStr in order to safely wrap the pointer.
The &str type is not FFI-safe. I would expect the Rust compiler to issue a warning to that effect. Rust slices consist of a pointer and a length and do not have a layout compatible with the C++ const char*.
One option would be to have do_something accept a pointer and a length (*const u8 and usize, respectively), call std::slice::from_raw_parts to exchange those for a &'a [u8], and call std::str::from_utf8_unchecked to exchange that for a &str. You must ensure the safety conditions documented along with each of those functions are upheld, including that the string contains valid UTF-8.
When defining a function which has a char array as one of its arguments, is it recommended to always pass the maximum array length as well as an extra argument? For example:
int somefunction(char* inputarray, int maxsizeofarray)
C-style strings are usually terminated by the \0 character. Most, if not all, of the functions from the standard library, such as strcpy or strcmp expect (and honor!) this convention. I'd suggest that any new function you write adhere to the same convention.
Having said that, in C++ (as opposed to C), I wouldn't use char* at all. Instead, I'd use the standard std::string class.
It totally depends on the function.Example, when you are traversing char array from last element to first element, in that case,it is wise to pass the size. But in C only.In C++, you have std::string .
It's normal to pass the array size when the function is writing to the array, or when it's problematic for the function to determine the size thereof (because it's not necessarily following a convention such as having a NUL terminator). For example:
int read(char* buffer, size_t n);
char *strncat(char *dest, const char *src, size_t n);
struct BinaryBlob
{
BinaryBlob(const char* buffer, size_t n);
...
};
class Student {
public:
string name;
};
vs
class Student {
public:
char* name;
};
Please correct me if I'm wrong. If we were to use char* instead of string, we will have to write our very own copy-constructor because we need to every time we have pointer variables as data members. Right?
So, my question is: Why use char* at all?
Using string, in the constructor, we can directly do:
Student(string s) {
name = s;
}
which is simpler compared to char*, which needs:
Student(string s) {
name = new char[strlen(s)+1]; // extra 1 to store the '\n'
strcpy(name,s);
}
Why not use string at all times instead of char* when being used as a data member of a class?
I think the only reason char* is used in C++ as a string is because of C. I'm sure if it was a new language, one which didn't strive to be compatible with C, char* would not be used like that. You will notice that functions that handle char* as if it were a string all come from C.
Note that in C, there is no string, so
struct Student { char* name; };
is perfectly valid C code, whereas
struct Student { string name; };
is not. Therefore, it is not unusual, when dealing with code which previously target C, to see those char* types.
There are usually little reason for using char* as a string, unless you are either writing a new string class, interfacing C functions, or dealing with legacy code.
You use char * instead of string, because a string is a string and a char * is a pointer to a character-aligned address.
Expanding on that, a string is an abstraction of a vector of characters with defined semantics. In C land, and in a lot of C++ programs, it represents an allocated block of memory along with a guarantee that it's terminated with the ascii NUL character 0x00. But a C++ implementation of string could instead use, say, a Pascal string with associated length, or it could represent strings in a string pool as a linked list.
A char * isn't providing that guarantee at all, and in fact might not be a string -- for example, it might be a collection of data with embedded 0x00 values. All it promises is that it's an address of something that the underlying architecture thinks is a character.
If you need a string, use std::string, not char*.
An obvious exception is interfacing to legacy code that uses char* to represent strings. Still, don't use char* outside of the interface layer.
You need to use char* when your data isn't a string, but a raw unstructured array of bytes. This is the case when you read or write binary data from files or network interfaces.
Sometimes, it is simpler to use char* instead of string, for example, when you are dealing with network and you need to transform a string full of bytes into a integer, float, etc.. I think that it's simpler to use a char*, instead of a string :
Using a char*
char* buffer[4];
read(buffer, 4); // A random read operation
int value = *((int*)(&buffer[0]); // Not sure if it was like that...
Using a string
std::string buffer;
buffer.resize(4);
read(buffer.data(), 4); // Will not work as buffer.data() returns a const char*
int value = *((int*)(&buffer.data()[0]));
The problem of string is that it's designed to prevent bad usage or strange manipulations. As someone said, it's also because C++ is inherited from C. So there is functions (from libc/glibc) which takes a char* and not a string.
EDIT
Even if char* is different from char**, it's pretty complex to build a bi-dimensional array using std::vector or std::string, you should either make your proper class, use char**, or library specific implementation (Boost, Maths libs, etc...)
About the only place where a competent C++ programmer will use char* is in the interface of an extern "C" program, or in very low level code, like an implementation of malloc (where you need to add a number of bytes to a void*). Even when calling into a C ABI, the char* needed by the interface will generally come from a &s[0], where s is an std::string, or if the interface is not const aware (and a lot of C interfaces aren't), then the results of a const_cast.
char const* is a bit more frequent: a string literal is, after all, a char const[], and I will occasionally define something like:
struct S
{
int value;
char const* name;
};
But only for static data, eg:
S const table[] =
{
{ 1, "one" },
{ 2, "two" },
// ...
};
This can be used to avoid order of initialization issues; in the above, the initialization is static, and guaranteed to take place before any dynamic initialization.
There are few other cases: I've used char const*, for example, when marshalling between to C ABIs. But they are rare.
I'm making an unmanaged C++ DLL which uses the C# managed DLL. I'm writting the C++ library as I need to use functions and headers defined in a software for which the C++ library can be added as an addon. But the things I want to make are so complex that my sparse knowledge of C++ would slow me down so I decided to do things in my favourite C# and connect the DLLs via COM and I was successful.
I'm somehow successful in making the code work, but less successful in keeping the code concise as I'm clearly not a professional C++ programmer.
The problem is with converting various string types. BSTR and const char * in particular.
The following code converst const char * to BSTR:
BSTR bstrt;
const char * someChar;
csharpInterfacedClassPointer->get_PropertyForSomeChars(&bstrt);
strcpy_s(nstring, (char *)bstrt);
someChar = nstring;
The problem is, I have plenty of discrete someChars with corresponding discrete interface methods...the property method is generated from the C# interface so I can't change it. Each of the "someChar" requires the following three lines of code so for 30 discrete variables, I'd need to write 90 lines of code.
csharpInterfacedClassPointer->get_PropertyForSomeCharX(&bstrt);
strcpy_s(nstring, (char *)bstrt);
someCharX = nstring;
The question is: how do write some shortcut for this so it'd fit just in one line?
I tried some sort of function with the "getter" function pointer and the someChar pointer.
typedef HRESULT (__stdcall *get_string_func)(BSTR * str); //getter function pointer
//the converting function
void ConvertAndAssign(get_string_func bstr_get_fx, const char * constCharString)
{
const size_t nsize = 1000;
char nstring[nsize];
BSTR bstrt;
bstrt = bstr_t(constCharString);
bstr_get_fx(&bstrt);
strcpy_s(nstring, (char *)bstrt);
constCharString = nstring;
}
//calling the function...as I thought that would work
ConvertAndAssign(sPtr->get_DataFile, someChar);
But then the compiler says some weird things aboud bound functions and how they are not allowed as pointers...I googled what does it mean and the solutions given required to alter the function definition but I can't do that since the definition is generated from the C# code (by regasm.exe).
Important note: I need to get the const char * type in the end because it is the required input type to the functions of the program for which I'm making the C++ DLL.
Disclaimer: it was a long time (7 years to be more precise) since I have touched C++/COM code for the last time.
Regarding binding an instance method to a function pointer check this SO question.
Another option is to use the IDispatch interface (if your COM component implement it)
Regarding ConvertAndAssign() implementation, IMO it has some issues. In order to make it easier to explain I have copied it bellow:
void ConvertAndAssign(get_string_func bstr_get_fx, const char * constCharString)
{
const size_t nsize = 1000;
char nstring[nsize];
BSTR bstrt;
bstrt = bstr_t(constCharString); // issue 1
bstr_get_fx(&bstrt);
strcpy_s(nstring, (char *)bstrt); // issue 2
constCharString = nstring; // issues 3 & 4
}
if your COM method returns a BSTR (i.e, it has an out parameter of type BSTR) you should not pass on a pre-allocated string otherwise you'll end up
leaking memory.
Casting bstr to char * will not work. BSTRs are Unicode strings. Also they are encoded such its length preceeds the actual characters.
If you are using ATL/MFC you can use one of the string conversion macros.
If you are NOT using ATL/MFC you can use WideCharToMultiByte() function or one of the "Smart" BSTR classes (CComBSTR in ATL, bstr_t, etc)
Assigning nstring to constCharString will have no effect on the outside string. If you are calling ConvertAndAssign like follows
char *outsideStr = NULL;
ConvertAndAssign(whatever, outsideStr);
Inside ConvertAndAssign() function consCharString will point to NULL in the begning. After the assignment constCharString does point to nstring but
outsideStr still points to NULL (remember, when you called ConvertAndAssign() function a copy of the pointer value was passed to it).
In order to get what you want you can either pass a reference or a pointer to a pointer:
void ConvertAndAssign(get_string_func bstr_get_fx, const char * &constCharString)
{
constCharString = nstring; // Assignment
}
or a pointer to a pointer:
char *outsideStr = NULL;
ConvertAndAssign(whatever, &outsideStr);
void ConvertAndAssign(get_string_func bstr_get_fx, const char **constCharString)
{
.
.
.
*constCharString = nstring; // Assignment
}
After fixing the previous issue you'll hit another one: You cannot return the address of a local variable! When your code resumes after ConvertAndAssign() returns, this
address is not allocated for you anymore (it's part of the stack, so it may even look to be working, but I assure you, it is not; the slightest changes
in your code may break it)
To fix this you need to pass a pre-allocated string:
char outsideStr[1000];
ConvertAndAssign(whatever, outsideStr);
void ConvertAndAssign(get_string_func bstr_get_fx, const char * constCharString)
{
strcpy_s(constCharString, /* result str here */ );
}
or allocate a string in the heap.
Given all the above, one possible implementation for ConvertAndAssign() and its usage is as follow:
char outsideStr[1000];
ConvertAndAssign(whatever, outsideStr);
void ConvertAndAssign(get_string_func bstr_get_fx, const char * constCharString)
{
BSTR bstrt;
if(SUCCEEDED(bstr_get_fx(&bstrt)))
{
// Assumes constCharString points to a buffer large enough to hold the converted string.
strcpy_s(constCharString, CW2A(bstr)); // not completely correct since bstr may contain the byte 0 but I guess thats not your scenario.
SysFreeString(bstr);
}
else
{
// error handling.
constCharString[0] = 0;
}
}
This question can be deleted if any mod is going to read this. I realized I have a totally different problem. Thanks Vagaus for his effort.
I am writing a C++ DLL that is called by an external program.
1.) I take an array of strings (as char *var) as an argument from this program.
2.) I want to iterate through this array and call a COM function on each element of the string array. The COM function must take a BSTR:
DLL_EXPORT(void) runUnitModel(char *rateMaterialTypeNames) {
HRESULT hr = CoInitialize(NULL);
// Create the interface pointer.
IUnitModelPtr pIUnit(__uuidof(BlastFurnaceUnitModel));
pIUnit->initialiseUnitModel();
int i;
for(i=0; i < sizeOfPortRatesArray; i++)
pIUnit->createPort(SysAllocString(BSTR((const char *)rateMaterialTypeNames[i])));
I think its the SysAllocString(BSTR((const char *)rateMaterialTypeNames[i])) bit that is giving me problems. I get an access violation when the programs runs.
Is this the right way to access the value of the rateMaterialTypeName at i? Note I am expecting something like "IronOre" as the value at i, not a single character.
If you're using Microsofts ATL, you can use the CComBSTR class.
It will accept a char* and create a BSTR from it, also, you don't need to worry about deleting the BSTR, all that happens in the dtor for CComBSTR.
Also, see Matthew Xaviers answer, it doesn't look like you're passing your array of strings into that function properly.
Hope this helps
Because a variable holding a C string is just a pointer to the first element (a char*), in order to pass an array of C strings, the parameter to your function should be a char**:
DLL_EXPORT(void) runUnitModel(char **rateMaterialTypeNames)
This way, when you evaluate rateMaterialTypeNames[i], the result will be a char*, which is the parameter type you need to pass to SysAllocString().
Added note: you will also need to convert the strings to wide chars at some point, as Tommy Hui's answer points out.
If the parameter to the function rateMaterialTypeNames is a string, then
rateMaterialTypeNames[i]
is a character and not a string. You should use just the parameter name itself.
In addition, casts in general are bad. The conversion to a BSTR is a big flag. The parameter type for SysAllocString is
const OLECHAR*
which for 32-bit compilers is a wide character. So this will definitely fail because the actual parameter is a char*.
What the code needs is a conversion of narrow string to a wide string.
const OLECHAR* pOleChar = A2COLE( *pChar );
BSTR str = SysAllocString( pOleChar );
// do something with the 'str'
SysFreeString( str ); // need to cleanup the allocated BSTR