Adding MySql.Data.dll to Qt C++? - c++

How do I add a MySql.Data.dll file to a Qt C++ project?

For QT, check out QSQL instead to connect to a database.
Or use the C++/C connectors:
For C++: MySQL++
For C: MySQL C API

Judging from the naming of the DLL and a little searching, I suspect that it is a .NET assembly, not a regular win32 dll. Unless you have a good reason to do so, you shouldn't try to use a .NET assembly in a native C++ application. It can be done, but it's messy.
Qt has an SQL module which should be sufficient in 99% of the cases. If you have questions about how to use it (e.g. connecting to a database, doing queries etc.), ask them as separate, specific questions.

Related

ReactNative expose C++ native module

We have a lot of business logic written in cross-platform C++. We want to write cross-platform UI for our application and use this business logic to create whole cross-platfrom application.
Is it possible to expose native module purely written in C++ to react-native?
We don't want to create wrappers around C++ code in native language (Java or Objective-C). Such wrappers will add more complexity it will make debugging and investigation much harder.
I am also looking for a way to do this directly in C++ without writing JNI for Android and Obj-C for iOS. I have found the CxxNativeModule class in the react native source. See the sample implementation SampleCxxModule.
The last thing to figure out is how to register that module in C++. In the JNI for React Native Android, implementation of NativeModule says
NativeModules whose implementation is written in C++ must not provide
any Java code (so they can be reused on other platforms), and instead
should register themselves using CxxModuleWrapper.
Then implementation of CxxModuleWrapper says
This does nothing interesting, except avoid breaking existing code.
So, this may help you get started. The last thing to figure out is how to register a CxxNativeModule so that it can be used in JS.
It seems as though you would need to find the code which is os dependent and write different versions of this code for different operating systems.
Here is a link which suggests how this might be done:
How do I check OS with a preprocessor directive?

c++ lua support with syntax checking and function completion

I recently added lua support in one of my c++ applications. The goal is that my application is the core and the users can access functions from my core using lua.
I have seen that it is possible to have syntax correction and auto completion like visual studio has. And that is exactly what I want to have, too.
How to I implement this feature? The lua file can be written inside a window of my application. Can I connect my c++ function pool with this lua scripting?
Any help on this would be greatly appreciated.
Fabian
Use Scintilla. It's crossplatform and is available as a library for different platforms and frameworks.
As an example, here are few links:
QScintilla for Qt4 and Qt5.
ScintillaNet for Windows Forms applications.
wxWindows has it already, and it's called wxStyledTextCtrl.
Sure, it is possible to use Scintilla even if you are not using any GUI editors and your application is pure code. It's just an external library, and can be either static (part of your binary after compilation) or dynamic (should be bundled with your application).

Using MFC in a "managed C++" application

One of our products is a C++ application - using MFC (MDI). (And we skin the application with Codejock.)
I've been asked if we could "port the application to .NET" - so it would be possible to use, e.g., C# libraries and other .NET features. I know there is something called "C++.NET" - or maybe (if I understand it right) it should be called "managed C++" now. But I don't know much about it.
My question: Is this at all possible? Could we run an MFC-application as "managed C++"? (And can an application using Codejock be run as a "managed C++" application?) There is some other threads about this, but I haven't been able to find "a definitive answer"...
I'd be very grateful for some good advice! :-)
As far as I understand, you want to keep your MFC/Codejock GUI and allow the use of .NET libraries from you application's C++ code.
This is indeed possible, but for a complete application that is currently compiled as "native" C++ it is probably not such a good idea to convert all of it to being compiled with C++/CLI. "It Just Works (IJW)" is a nice meme, but it doesn't work always :-)
We have the same situation, namely a C++/MFC/Codejock application that needs to call into .NET assemblies. This works mostly without problems:
We have C++/CLI modules that offer a native C++ DLL interface for the native C++ code to call into and that then route these call on to an assembly written in C#.
We also have C++/CLI assemblies that offer a .NET interface for the C# code and then call back into pure native modules.
It should also be possible to have a single (say, exe) project that is compiled natively and you only enable the /clr switch for selected cpp files that need managed interop. And at the end you link everything together. Since we've never mixed it that way, I can't really say anything about this approach however. What I can say for sure though is that it is possible to compile parts on a module as /clr and parts as native.
I faced a similar problem some years ago, and found that unless for trivial cases converting from un-managed to managed or reverse side was really painfull. I ended leaving the two worlds each in its side, and simply use interop to have the COM - .NET compatibility.
It was not very nice, but a lot cheaper. The conclusion that we should wait a major evolution to consider a full rewriting.

Wanted: Compiler Tool for Users of Software System

I am not sure if the title of this question gets to the point. I have written a large software system in C C++ for Windows, and want to give the users of this system the option to add compiled code to it. The user should be able to do basic stuff, and exchange data with my program.
Currently the implemented way is via DLLs. But for this, a grown up compiler is needed, and it is not as easy as I wished. Is there a tiny C compiler that can create Windows DLLs?
Another idea is the Java native interface. But this requires a complete Java system to run in the background, and it is not easy to run code in it.
Do you have any other ideas?
Any interpreted language? (TCL and Lua were designed as extension languages, but you can nearly as easily interface with any other).
How about python integration?
You could create an python interface that interfaces with your application. Python is rather easy to learn and should integrate easily with c/c++. The python documentation has an own chapter on that.
You could also use a tool like swig to generate the interface.
The advantage of this is that they wouldn't have to compile anything. They could just supply python files that could be loaded into your application and run within the software. This is a well known use for python, and something its simple syntax promotes.
As the other says you will be best of by providing an embedded language.
I would chip in for javascript and use the google v8 engine
By using javascript you get a language nearly everbody can use and program in.
There is other javascript engines you can embed like SpiderMonkey.
See this answer for what to choose.
An interpreted language is not good enough. I need speed. The software itself is an interpreted language. So I added support for the tiny C compiler. It is only C, and I do check mingw, which probably would not be as tiny as this. Thanks for all your hints.
Added after several months:
I have now two tools, actually: TinyC and Python. The speed difference between those is noticable (factor 5-10), but that usually does not matter too much. Python is much easier for the user, though I managed to integrate both into the Euler GUI quite nicely.
One of the ways is to add scripting. You application can host scripting environment and expose its services there. Users would be able to execute JScript/VBScript scripts and interact with your application. The advantage is that with reasonable effort you can get the power of well known and well documented scripting languages into your application (I suppose there is even debugger for scripting there). You will be required to shape your app services as COM interfaces and scripts will be able to access them automatically using method names you assigned on C++ side.
C++, Win32 and Scripting: Quick way to add Scripting support to your applications
MSDN Entry Point - IActiveScript interface

Database abstraction layers for (Visual) C++

What options exist for accessing different databases from C++?
Put differently, what alternatives are there to ADO?
What are the pros and cons?
Microsoft ODBC.
The MFC ODBC classes such as CDatabase.
OleDB (via COM).
And you can always go through the per-RDBMS native libraries (for example, the SQL Server native library)
DAO (don't).
3rd party ORM providers.
I would recommend going through ODBC or OleDB by default. Native libraries really restrict you, DAO is no fun, there aren't a lot of great 3rd-party ORM for C++/Windows.
Although this question and its answers are several years old, they are still valuable for people like me that cruise by on an evaluation trip. For this reason, I would like to add the Qt C++ framework's QtSql module as an option for database connectivity.
Note that I am familiar with Qt in general, but have no experience with QtSql in particular.
Pros (just a few that should also apply if you just choose Qt for its QtSql module): Qt is cross-platform. In my experience, Qt is well-designed, pretty intuitive to use, and extremely well documented. It has been around for a long time, is maintained by an active community and backed by Nokia, so it won't become unavailable over night. Since 2009, Qt has been licensed under the LGPL, so it is a real no-cost option even for commercial applications.
Cons: Qt is not small. You will introduce new types such as QString to your project. Qt is licenced under the LGPL, so you need to acknowledge its use even in commercial apps.
One thing - if speed is important and your code doesn't need to be portable, then it may be worth it to use the native libraries.
I don't know much about SQL Server, but I do know that the Oracle OCI calls are faster than using ODBC. But, they tie you to Oracle's version of SQL. It would make sense for SQL Server to be the same way.
There is the POCO Data library, which supports ODBC, MySQL and SQLite. Part of the free open source POCO C++ Libraries.