What is the best way to export the code written in Qt to the script language TCL. In the code Qt, I use the data structure in Qt like QMAP, QLIST other than those in STL, so the SWIG may not recognize them and neither some other macros in Qt.
You need a linking function with this signature:
extern "C" int theFunctionName(ClientData clientData, Tcl_Interp *interp,
int argc, char **argv)
which you register with Tcl_CreateCommand. (Or there's Tcl_CreateObjCommand, which uses a more efficient type management system, but in principle it's pretty similar.) This is what SWIG would construct for you, with lots of guidance, but it's not too hard to DIY and you'll probably end up with a better interface anyway. (SWIG's handling of enumerations and bit-sets is usually very unidiomatic from a Tcl perspective.)
That linking function has to decide the values in argv to create the values that are passed to your Qt/C++ code, and then it uses Tcl_SetResult or Tcl_SetObjResult to store the result back in the Tcl_Interp context before returning TCL_OK or TCL_ERROR (for success or an exception).
I guess a QMap would look like a Tcl dictionary, and a QList like a Tcl list, but the details could get quite tricky. The details depend on exactly what's going on (stuff like callbacks gets a little tricky, especially in threaded code!)
Related
Is there any reason to use Qt standard function wrappers like qstrncpy instead of strncpy?
I could not find any hint in documentation. And I'm curious if there is any functional difference. It looks like making code dependent on Qt, even in not mandatory places.
I found this: Qt wrapper for C libraries
But it doesn't answer my question.
These methods are part of Qt's efforts for platform-independence. Qt tries to hide platform differences and use the best each platform has to offer, replicating that functionality on platforms where it is not available. Here is what the documentation of qstrncpy has to say:
A safe strncpy() function.
Copies at most len bytes from src (stopping at len or the terminating '\0' whichever comes first) into dst and returns a pointer to dst. Guarantees that dst is '\0'-terminated. If src or dst is nullptr, returns nullptr immediately.
[…]
Note: When compiling with Visual C++ compiler version 14.00 (Visual C++ 2005) or later, internally the function strncpy_s will be used.
So qstrncpy is safer than strncpy.
The Qt wrappers for these functions are safer than the standard ones because they guarantee the destination string will always be null-terminated. strncpy() does not guarantee this.
In C11, strncpy_s() and other _s() suffixed functions were added as safe string functions. However, they are not available in any C++ standard, they are C-only. The Qt wrappers fix this.
I am using Qt5 to create a Qt application.
Following is my code:
static QStateMachine *myStateMachine = new QStateMachine(nullptr);
I wanna create the QStateMachine just one time， use the same machine all
the time.
However, I learn that all QObjects should not be instantiated before QApplication instantiated.You can read Qt document about QApplication's Detailed Description.
My question is:
Why all QObjects should not be instantiated before QApplication instantiated?
In a 2014 thread on the Qt interest list, Thiago Macieira wrote:
Qt is not supported before the creation of QCoreApplication. Your use-case is not supported, so no answer is necessary.
Just don't do it.
Note: the doc is wrong.
He's a long-term Qt maintainer (and worked for Trolltech). Thus I would generally follow his advice.
What I'd imagine he means is that on various systems--features end up needing some kind of chance at initialization. It may not be all systems, and it may be a need that gets introduced in a later version. The Qt developers thus likely reserve the right to make any given feature require it...and offer no promises that anything in the system will work before the initialization.
(Note: This sort of parallels the concept of undefined behavior in C++)
However, he softens the stance slightly in a later post:
Does that mean static objects aren't supported either?
Not supported, but mostly they work. We will also fix bugs in uses that reasonably could happen in main() while parsing the command-line and other set-up procedures before QCoreApplication gets created.
Just be careful because some things will not work. For example, QString::fromLocal8Bit doesn't work before QCoreApplication.
Point being that giving a list of things you can do before QApplication instantiation today should be considered misleading. They don't want to make that list.
If you find you really have to do it, and you appear get away with it, then be prepared to have it break in a future release (or perhaps even on a different machine).
I'm currently trying to convert my QList<QString*> to an enum version so it can be faster.
I would like to do the following, QList<EnumType*>. I am wondering if there is any reason I shouldn't do this. I could really benefit from the pointer in the QList for my next step which is to convert it to a QQmlListProperty<EnumType> which takes a QList<EnumType*>.
There's no point in managing enum values or QStrings via pointer. Just use QStringList (which is a QList<QString>) or QList<SomeEnum>. QQmlListProperty is for managing QObjects, as the documentation says:
Note: QQmlListProperty can only be used for lists of QObject-derived object pointers.
Neither QStrings nor enums are. What the best solution is to expose the list to QML depends on your use case.
I'm fairly new to C so be gentle.
I want to use the library interception method for Linux to replace calls to the OpenCL library with my own library. I understand that this can be done using LD_PRELOAD. So I can just re-implement the OpenCL functions as defined in the OpenCL header file within my own library which can then be linked against.
The problem is that this OpenCL header also contains some extern struct definitions, e.g.
typedef struct _cl_mem * cl_mem;
which are not defined within the OpenCL header. Is it possible these structs are defined within the OpenCL shared lib? If not, where might they be defined?
Cheers
Chris
That typedef declares a type pointing to a struct, the contents of which are undeclared. This means code using it can't do things like checking its size, copying the struct, or inspecting its contents - it simply has no idea what size it is.
This is a traditional technique in C to create an opaque, or private, type. You can declare the struct inside your OpenCL library, and the official header puts no restrictions on what that struct contains. It could even be empty, if all you need is an ID you can store in the pointer itself, though this is rarely done.
An example of the same technique used in the standard C library is the FILE type. It might be as simple as an integer file descriptor, or as complex as a struct containing the entire filesystem state; standard C code won't know. The particulars are known to the library only.
In short, you can declare that struct however you like - as long as you implement every function that handles that struct. The program that links to your library never handles the struct, only pointers to it.
In QT we can connect signals and slots using the following simple syntax:
connect(pObject1, signal1, pObject2, slot2)
For instance, one can write something like:
A a;
B b;
connect(&a, SIGNAL(valueChanged(int)), &a, SLOT(setValue(int)));
With Boost::Signal the syntax we would write it this way:
A a;
B b;
a.valueChanged.connect(boost::bind(&B::SetValue, &b, _1))
IMHO, the boost signal's syntax is more complicated. Is there a way to make the Boost::Signal's syntax more QT like.
The thing with Qt is that it goes through a code generation phase during compilation, that Boost can't do. That means that Qt can do some very clever syntactic things that can't be copied without going through a similar process.
To quote Wikipedia:
Known as the moc, this is a tool that is run on the sources of a Qt program. It interprets certain macros from the C++ code as annotations, and uses them to generate additional C++ code with "Meta Information" about the classes used in the program. This meta information is used by Qt to provide programming features not available natively in C++: the signal/slot system, introspection and asynchronous function calls.
(I can't get the link to work, but it's http://en.wikipedia.org/wiki/Qt_(framework))
Edit: I think the Wikipedia quote is quite clear that the signal/slot system is implemented using the moc. I doubt very much that there's any way to use the same syntax without using a similar system.