How do I call Foo(long[][]) (C#) from Managed C++ (old syntax)? - managed-c++

I've got existing C# code with signature of Foo(long[][] longs) which I need to call from Unmanaged C++ (not C++/CLI). I just can't seem to figure out the right combination of __gc[] and __gc* to make the compiler happy.
With C++/CLI, this is straight-forward:
std::vector<__int64> evens;
evens.push_back(2); evens.push_back(4); evens.push_back(6); evens.push_back(8);
std::vector<__int64> odds;
odds.push_back(1); odds.push_back(3); odds.push_back(5); odds.push_back(7);
std::vector<std::vector<__int64> > ints;
ints.push_back(evens); ints.push_back(odds);
array<array<__int64>^>^ mgdInts = gcnew array<array<__int64>^>(ints.size());
for (size_t i = 0; i<ints.size(); ++i)
{
const std::vector<__int64>& slice = ints[i];
mgdInts[i] = gcnew array<__int64>(slice.size());
for (size_t j=0; j<slice.size(); ++j)
mgdInts[i][j] = slice[j];
}
Edit: As I'm using Visual Studio 2008, the "simple" solution is to put the C++/CLI code in its own file and compile with /clr; of course, it would be easier if I didn't have to do this (e.g., other .h files with Managed C++). The C# code can't change as it's auto-generated from a web reference.

Change the signature from this
Foo(long[][] longs)
to this:
Foo(Array longs)
Then when you look at the resulting type library in OleView.exe, you should see:
HRESULT Foo([in] SAFEARRAY(int64) longs);
From C++, that's fairly straight forward to call. You can just Win32 to create a SAFEARRAY, or I suggest include and then use the CComSafeArray wrapper class in ATL.
Even though both C# and C++ have richer array definitions, the interoperability between the two is typically done though the Type Library marshaller, 99% of which is legacy and based on what's "VB Compatible". The only array types that the Type Library marshaller supports is SAFEARRAY, so that's what you get when you follow the normal way of doing all this.
However, COM supports a richer array system (conformant arrays), which C# understands, it's harder to do, and you can't simply regasm your C# DLL and use the resulting type library in your unmanaged C++ program. Some of the techniques require tweaking the C# code with ILDASM. Others require you to keep two definitions of the interface, one in C++ and one in C#, and make sure they're in sync (no way to convert one to the other), then in the IDL for C++ adorn the parameter with size_is, and in C# with MarshalAs. It's kind of a mess and really the only type people do that is if they have an already published legacy interface that they cannot change. If this is your C# code, and you can define the interface, I wouldn't go there. Still, the technique is available. Here's a refernece: http://support.microsoft.com/kb/305990
Expect about a week or so to get through this if you've never done anything like this before.

The solution I came up with is to use List<>.ToArray():
System::Collections::Generic::List<__int64 __gc[]>* mgdInts = new System::Collections::Generic::List<__int64 __gc[]>(ints.size());
for (size_t i = 0; i<ints.size(); ++i)
{
const std::vector<__int64>& slice = ints[i];
__int64 mgdSlice __gc[] = new __int64 __gc[slice.size()];
for (size_t j=0; j<slice.size(); ++j)
mgdSlice[j] = slice[j];
mgdInts->Add(mgdSlice);
}
ClassLibrary1::Class1::Foo(mgdInts->ToArray());

Related

What parts of an object are stored when it's saved into a session variable [duplicate]

The title is obvious, I need to know if methods are serialized along with object instances in C#, I know that they don't in Java but I'm a little new to C#. If they don't, do I have to put the original class with the byte stream(serialized object) in one package when sending it to another PC? Can the original class be like a DLL file?
No. The type information is serialized, along with state. In order to deserialize the data, your program will need to have access to the assemblies containing the types (including methods).
It may be easier to understand if you've learned C. A class like
class C
{
private int _m;
private int _n;
int Meth(int p)
{
return _m + _n + p;
}
}
is essentially syntactic sugar for
typedef struct
{
int _m;
int _n;
// NO function pointers necessary
} C;
void C_Meth(C* obj, int p)
{
return obj->_m + obj->_n + p;
}
This is essentially how non-virtual methods are implemented in object-oriented languages. The important thing here is that methods are not part of the instance data.
Methods aren't serialized.
I don't know about your scenario, but putting in a library (assembly / dll) and using that in the other end to deserialize gets you all.
Ps. you probably should create some ask some more questions with the factors involved in your scenario. If you are intending to dynamically send & run the code, you can create awful security consequences.
I was confused when .NET first came up with serialization. I think it came from the fact that most books and guides mention that it allows you to serialize your 'objects' as XML and move them around, the fact is that you are actually hydrating the values of your object so you can dehydrate them latter. at no point your are saving your whole object to disk since that would require the dll and is not contained in the XML file.

cannot convert cont char* to LPCWSTR

I am stuck with an error in QT compiler however it works fine with VS2010. the error states that
I have seen other posts related to the same error but non has resolved my problem in QT. I have tried _T,L or TEXT but still not working
bq. error: C2664: 'HANDLE
LoadImageW(HINSTANCE,LPCWSTR,UINT,int,int,UINT)' : cannot convert
argument 2 from 'const char *' to 'LPCWSTR' Types pointed to are
unrelated; conversion requires reinterpret_cast, C-style cast or
function-style cast
my code is as below
Bitmap::Bitmap(std::string const& file_name) {
bitmap_ = static_cast<HBITMAP>(::LoadImage(0, file_name.c_str(), IMAGE_BITMAP,0,0,LR_LOADFROMFILE|LR_CREATEDIBSECTION));
}
please share if you have any idea to resolve this
Qt does not include a compiler. On Windows you're probably either compiling with mingw or Visual C++. Either way, the issue is that you're calling a function that expects a wide character string but you're trying to hand it an 8-bit character string.
For compatibility reasons, Win32 uses a different set of API functions if you have _UNICODE defined. In your case, you do have _UNICODE defined. You can continue using the 8-bit std::string but simply change the method from LoadImage() to LoadImageA(). Or if you don't mind changing your Bitmap class, you could switch from std::string to std::wstring to take advantage of Windows' Unicode features.
But perhaps the larger question is why use Win32 to load bitmaps and std::string if you're using Qt? Qt's QImage class and QString class provide a full-featured, cross-platform strings and image loaders. Like any comprehensive framework, Qt works best if you only use external features on an as-needed basis.
I'm not sure if this method is the best, but I've used them on my projects and it works fine, see:
char *source = "Hello world";
WCHAR target[size];
MultiByteToWideChar(CP_ACP, 0, source, -1, target, size);
LPCWSTR final = target;
MessageBox(0, final, TEXT("title"), 0); //Sample usage

How to create bindings qml to d?

I want to use qml with d language. But there is not bindings to d, and I want to create it. But I don't know how to begin. Tell me, please, how to begin to create bindings.
Since nobody answered:
From what I understand QML is the modelling language of Qt and I guess it depends heavily on Qt. I assume here it depends on Qt, at least to some extend.
First of all there was already an attempt to bind Qt to D: http://www.dsource.org/projects/qtd, but from what I've heared this project is kinda dead and not developed anylonger (last commit 2 years ago). You could use it as base for your work or as a reference on how you could bind QML and Qt.
1. Option, a C/C++ Glue-Layer
A C-Glue Layer means, you write your code basically twice. You write a complete C++ to C wrapper in C++ (the language which can directly interface with Qt and Qml). That means you wrap every method of a class inside a C function which takes a Pointer (to a struct representing this C++ Qt class). This could look like this (note this is an abstraction of GtkWebkit, which is written in C, but the snippet demonstrates how to do it quite well):
// somewhere in a header
typedef struct SurfiClient {
GtkWidget *window; // Offscreen window
// ....
}
typedef GdkPixbuf Pixbuf;
extern "C" {
Pixbuf* surfi_client_get_pixbuf(SurfiClient* client)
{
// in C++ this would gtk_offscreen_window_get_pixbuf would be a method of client->window
return gtk_offscreen_window_get_pixbuf(GTK_OFFSCREEN_WINDOW(client->window));
}
// here go the rest of these functions, probably thousands
}
You have to basically do this for everything you want to interface later on from the D side. Even worse you have to also do it for namespaces and free functions which are not marked extern "C", this could look like this (libsquish):
typedef unsigned char u8;
extern "C" {
void CompressMasked(u8 const* rgba, int mask, void* block, int flags) {
squish::CompressMasked(rgba, mask, block, flags);
}
}
As you can see by now, this is quite tedious...
Let's assume you have finished making the C/C++ Glue-Layer, now you have to create code in D which can interface it.
To stay with the gtk example:
extern(C) {
// Using an opaque struct is one option
struct SurfiClient;
// the other is to wrap the struct correctly
struct SurfiClient {
GtkWidget *window;
}
// The Pixbuf was only a typedef to GdkPixbuf which is already an opaque data structure, easy
struct Pixbuf;
Pixbuf* surfi_client_get_pixbuf(SurfiClient* client);
}
You see in this example a problem, if you want to wrap the SurfiClient struct correctly, you also have to wrap GtkWidget or do it incorrectly and use void* instead of GtkWidget*, which is no real soloution to the problem. You will most likely also run into this problem, you Glue-Layer struct has members which you don't have abstractions for, I would go here with the opaque struct and provide functions for the members which are really needed for the user.
I am not going more into detail on how to interface with C, there are already a few guides:
http://dlang.org/interfaceToC.html
http://www.gamedev.net/blog/1140/entry-2254003-binding-d-to-c/
https://github.com/D-Programming-Deimos (Not a guide but a collection of C bindings, could be used as reference)
The last step in the process of makind Qt, Qml bindings would be to rebuild the OOP-Api in D based on your newly made C-Bindings.
2. Option, SWIG/Binding generator
I am not an expert with SWIG, that's the reason why I am only covering it in a few sentences.
What you can use SWIG for is generate the whole C/C++-Glue Layer thingy for you. If you're lucky, your SWIG-File only consists of a few includes to Qt and SWIG will do all the work for you. If not, you have to define rules for Classes and Functions on your own, which can be tedious (but also easier and faster than doing 1. Option). So SWIG is definitly worth a try!
As a side-note: If you have a template/macro/ heavy/Header only C++ Library like glm SWIG can be tricky or in case of glm no option.
There are alternative Binding-Generators, e.g. the PySide Project started with Boost.Python then switched to Shiboken. I don't know how easily you can generate bindings with Shiboken for anything else than CPython, maybe hacking into Shiboken or even Boost.Python could work? Also worth a read: http://setanta.wordpress.com/binding-c/.
QtD used QtJambi so this might be a good start.
3. Option, the D way
D has the great idea of having extern(C++), which allows in theory making C++/D bindings without such a Glue-Layer: http://dlang.org/cpp_interface.html.
Nice idea, but unfortunatly too limited. E.g. there is no support for namespaces yet (there is an open issue on bugzilla, I can't find right now). In my opinion extern(C++) is too limited for Qt.
Manu Evans mentioned in his first talk at the D conference how to bind to C++ from D sucessfully with using Ds metaprogramming capabilities.
In a nutshell
A C/C++ Glue-Layer gives you the most flexibility, it will work, but is no simple and especially a long task (I would do this for rather small projects).
SWIG/Binding generators, the way I would go for Qt, once correctly setup they do all the work for you (in the best case).
extern(C++), nice idea, too limited for most serious C++ projects.
I hope this gives you a short overview of what you can do and the amount of work it requires.
they are already an article on this purpose how to interface C code to D?
Usually is not hard. Take function declaration and put it into an extern(C) block
And usually these module are written into a c package. Example:
src/
`-- appName
|-- c
| `-- dInterface.d
`-- dwrapper.d
The module appName.c.dInterface will define C function with an extern(C) block
While the module appName.dwrapper will provide a way that fit more with dlang.

qt QTranslator reuse

I noticed that the Qt documentation is not very verbose on some of the aspects of the translations. I was fooling around with it trying to figure out their behaviour using trial & error. The ultimate goal is to get the translation changed on runtime but I am very confused as to what extent the QTranslator object can be re-used.
Consider this (where 'a' is the main instance of the application):
QTranslator translator;
translator.load("mytranslation_cz");
a.installTranslation(&translator);
(...)
a.removeTranslation(&translator)
Now the translator was removed from the application but what happened to the translator object?
In my tests when above code was followed by this again
translator.load("mytranslation_fr");
a.installTranslation(&translator);
it did not do anything in main() and it crashed the application when called from one of the widgets (using pointer to main app).
Therefore I am suspecting that I would need to create one QTranslator object per translation I want to load in the application and that I cannot reuse the QTranslator object. Am I right in this assumption?
And as a side question. Assuming the QTranslator object is untouched by the removeTranslation(), is it possible to simply install it later again like this?
QTranslator translator;
QTranslator translator1;
translator.load("mytranslation_cz");
translator1.load("mytranslation_fr");
a.installTranslation(&translator);
(...)
a.removeTranslation(&translator);
a.installTranslation(&translator1);
(...)
a.removeTranslation(&translator1);
a.installTranslation(&trasnlator); //Will this work?
Thanks for any clarification as I am somewhat confused as to what happens to the QTranslation objects when installing and removing translations from the application and especially if the QTranslation object can be reused for multiple translations somehow on runtime?
QTranslator::load basically in simple sense can be considered as a function that opens a given .qm file, reads in all the translated values and loads it in for a specific language.
Now in general operation you would not want to reuse this for many languages as by "reusing" (even if its allowed) your adding the overhead of parsing this given .qm file for every language every time you switch your UI language, which is just basically an overhead you don't need.
Your assumption of creating a QTranslator for each language is correct. As for your side question, Yes you can also re-use it. Thats the benefit of having individual QTranslator objects per translation. Just call qApp->removeTranslator() with the current translation and then qApp->installTranslator() with the new one. This way you are reusing the loaded translations as and when you please.
The way we structure this is by sub-classing QApplication and adding 2 functions
void Application::CreateTranslators() {
// translators_ is a QMap<QString, QTranslator*>
if (!translators_.isEmpty())
return;
QStringList languages;
languages << "en" << "ar" << "zh";
foreach(QString language, languages) {
QTranslator* translator = new QTranslator(instance());
translator->load(language);
translators_.insert(language, translator);
}
}
Now this function is called at the very start of the application.
2nd function is as following
void Application::SwitchLanguage(QString language) {
// current_translator_ is a QTranslator*
if (current_translator_)
removeTranslator(current_translator_);
current_translator_ = translators_.value(language, nullptr);
if (current_translator_)
installTranslator(current_translator_);
}
That's it. Using the second function you can switch your language at run-time as you please.
Couple things you'll also need to be aware of is changing QTranslator at run-time will update all translations from your .ui file strings marked as translatable automatically, however those set from code will not be. To get that you will have to override QWidget::changeEvent() and then check if the event is of type QEvent::LanguageChange and then set the required strings for that QWidget accordingly (Don't forget the tr() while doing so)

ld linker question: the --whole-archive option

The only real use of the --whole-archive linker option that I have seen is in creating shared libraries from static ones. Recently I came across Makefile(s) which always use this option when linking with in house static libraries. This of course causes the executables to unnecessarily pull in unreferenced object code. My reaction to this was that this is plain wrong, am I missing something here ?
The second question I have has to do with something I read regarding the whole-archive option but couldn't quite parse. Something to the effect that --whole-archive option should be used while linking with a static library if the executable also links with a shared library which in turn has (in part) the same object code as the static library. That is the shared library and the static library have overlap in terms of object code. Using this option would force all symbols(regardless of use) to be resolved in the executable. This is supposed to avoid object code duplication. This is confusing, if a symbol is refereed in the program it must be resolved uniquely at link time, what is this business about duplication ? (Forgive me if this paragraph is not quite the epitome of clarity)
Thanks
There are legitimate uses of --whole-archive when linking executable with static libraries. One example is building C++ code, where global instances "register" themselves in their constructors (warning: untested code):
handlers.h
typedef void (*handler)(const char *data);
void register_handler(const char *protocol, handler h);
handler get_handler(const char *protocol);
handlers.cc (part of libhandlers.a)
typedef map<const char*, handler> HandlerMap;
HandlerMap m;
void register_handler(const char *protocol, handler h) {
m[protocol] = h;
}
handler get_handler(const char *protocol) {
HandlerMap::iterator it = m.find(protocol);
if (it == m.end()) return nullptr;
return it->second;
}
http.cc (part of libhttp.a)
#include <handlers.h>
class HttpHandler {
HttpHandler() { register_handler("http", &handle_http); }
static void handle_http(const char *) { /* whatever */ }
};
HttpHandler h; // registers itself with main!
main.cc
#include <handlers.h>
int main(int argc, char *argv[])
{
for (int i = 1; i < argc-1; i+= 2) {
handler h = get_handler(argv[i]);
if (h != nullptr) h(argv[i+1]);
}
}
Note that there are no symbols in http.cc that main.cc needs. If you link this as
g++ main.cc -lhttp -lhandlers
you will not get an http handler linked into the main executable, and will not be able to call handle_http(). Contrast this with what happens when you link as:
g++ main.cc -Wl,--whole-archive -lhttp -Wl,--no-whole-archive -lhandlers
The same "self registration" style is also possible in plain-C, e.g. with the __attribute__((constructor)) GNU extension.
Another legitimate use for --whole-archive is for toolkit developers to distribute libraries containing multiple features in a single static library. In this case, the provider has no idea what parts of the library will be used by the consumer and therefore must include everything.
An additional good scenario in which --whole-archive is well-used is when dealing with static libraries and incremental linking.
Let us suppose that:
libA implements the a() and b() functions.
Some portion of the program has to be linked against libA only, e.g. due to some function wrapping using --wrap (a classical example is malloc)
libC implements the c() functions and uses a()
the final program uses a() and c()
Incremental linking steps could be:
ld -r -o step1.o module1.o --wrap malloc --whole-archive -lA
ld -r -o step2.o step1.o module2.o --whole-archive -lC
cc step3.o module3.o -o program
Failing to insert --whole-archive would strip function c() which is anyhow used by program, preventing the correct compilation process.
Of course, this is a particular corner case in which incremental linking must be done to avoid wrapping all calls to malloc in all modules, but is a case which is successfully supported by --whole-archive.
I agree that using —whole-archive to build executables is probably not what you want (due to linking in unneeded code and creating bloated software). If they had a good reason to do so they should have documented it in the build system, as now you are left to guessing.
As to your second part of the question. If an executable links both a static library and a dynamic library that has (in part) the same object code as the static library then the —whole-archive will ensure that at link time the code from the static library is preferred. This is usually what you want when you do static linking.
Old query, but on your first question ("Why"), I've seen --whole-archive used for in-house libraries as well, primarily to sidestep circular references between those libraries. It tends to hide poor architecture of the libraries, so I'd not recommend it. However it's a fast way of getting a quick trial working.
For your second query, if the same symbol was present in a shared object and a static library, the linker will satisfy the reference with whichever library it meets first.
If the shared library and static library have an exact sharing of code, this may all just work. But where the shared library and the static library have different implementations of the same symbols, your program will still compile but will behave differently based on the order of libraries.
Forcing all symbols to be loaded from the static library is one way of removing confusion as to what is loaded from where. But in general this sounds like solving the wrong problem; you mostly won't want the same symbols in different libraries.

Resources