Ok i tried to re-implement my function so that it exports an array of _UserIdentity in this way :
void get_all_users(UserIdentity **_UserIdentity)
{
std::lock_guard<std::mutex> locker(_locker);
for (auto& t : _IdenetyClass)
{
(*_UserIdentity)->id = t.second.id;
(*_UserIdentity)->name = t.second.name;
}
}So is my new implementation correct please ?
Like Zipster said, there may be other considerations at play here.
As far as the code itself goes though, a couple questions. First, does it compile? Second, have you tested it, and does it produce the desired results?
Something you might consider is setting aside the DLL issue for now and just focusing on implementing this in isolation, maybe even in a self-contained single-file terminal or command-line app. That way you could post your code in its entirety for others to look at.
What you have there appears to be the same thing you had before, just expressed differently. As such, it still likely doesn't do what you want.
Although I mentioned std::vector earlier, you might benefit from implementing this without such tools first in order to better understand the underlying concepts. How familiar are you with topics such as arrays, pointers, and manual memory management?
1- yes it does and it prints the result in the debug window
To be honest with you i'm 5/10 with topics such as arrays , pointers and manual memory management .☹️
17 minutes ago, randydom said:1- yes it does and it prints the result in the debug window
To be honest with you i'm 5/10 with topics such as arrays , pointers and manual memory management .☹️
I see. Regarding the testing, if it seems like it's working, I'm wondering if it's just circumstantial (e.g. maybe you're just testing it with one user identity). If you're not sure about that, you could post your test code for us to take a look at.
As for the topics under discussion (arrays, etc.), I think getting more comfortable with those would be helpful. The function you're trying to implement is, I think, a reasonable test bed for that, as it touches on a number of relevant issues, such as pointers, arrays, memory management, and ownership semantics. Although eventually using something like std::vector would probably be preferable, implementing it 'manually' might be a good starting point.
1 hour ago, Zakwayda said:I'm still curious as to what 'Idenety' means, but perhaps it's not important.
For name convention of Borland's made libraries typename identifiers began from "T" character to easily separate types and instances identifiers by name.
12 hours ago, randydom said:what i want is to be able to export a struct from my DLL .
It is wrong idea to use a templates (especially stl) and any dynamic created object to pass it to DLL. It no any warranty that it have a compatible memory managers and compiled using same implementation of STL or other templates (that can have incompatible formats of underlaying data structures under hood).
2 hours ago, randydom said:i'm a delphi programmer
Also you trying to follow a delphi way of dlls interoperation. Delphi/C++ Builder have especily made for dlls interoperation technology implemented by FastMM memory manager that uses especialy dll to serve ineroperability of objects that contain dynamic buffers under hood (strings dynarras and so on). But it interoperability applicable to Delphi/C++ Builder compiled dlls only (and most likely by same version only). In common case allocating a object in context of one dll and deleting it in context of another just will corrupt heap and lead to crash.
@ Fulcrum.013 many thanks so what do you suggest as an alternative way for achieving the export procedure ?
7 minutes ago, Fulcrum.013 said:For name convention of Borland's made libraries typename identifiers began from "T" character to easily separate types and instances identifiers by name.
I was asking about the word 'Idenety', not the prefix.
25 minutes ago, randydom said:so what do you suggest as an alternative way for achieving the export procedure
Really it only 3 ways exists - use a raw data and functions only to interdll calls like low-level APIs do, use a COM that have warranty that delete from same dll that initiyally create objec wil be used (by refcounting), or reinvent something similar to FastMM like .Net do (really it made by Borlands concepts enlarged to system-wide scale, but downgraded by restrictions of GC flexibility).
Other way is to review architecture and avoid using DLLs in similar cases. Really any templates intendend to inline code that have to be very fast, while dll calls have a huge overhead (code from it can not be inlined and only indirect call can be performed) and intended to increase flexibility, so better way is to avoid interdll calls anywhere where it possible.
