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.
Related
I've been looking in many, many places and I couldn't find any satisfying answer for my question: what is the benefit of using pointers to nested structs in Go?
Currently I am total newbie in Go, I started reading a book "Go programming language" and I do every excerice there to make sure I understand the syntax and use case. Until now. The goal of one of tasks was to create very simple GitHub client that retrieves a list of issues filtered by given params. It's an example showing how to use json unmarshalling. So there are some nested structs:
type SearchIssueResult {
TotalCount int
Issues []*Issue
}
type Issue {
Title string
Author *User
// ... other properties
}
And here's my question again: Why these nested structs have type of pointers to structs? I can use just struct type and it works as well (with slight modifications in usage of struct's instance) but I would like to understand when to use different approaches.
Thanks!
It depends on how complex your structure is. I'd suggest using pointers every time you refer to a structure. Here are some benefits of this approach:
Referred object can live longer than your structure.
It's faster to make a copy of a pointer than a copy of (complex) structure.
For some basic types like: int, float, string it can be faster to pass it by copy.
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!)
I have a C++ object pointer with many data members. I need them all available in QML. One obvious way would be to create a Q_PROPERTY for each member so they can be individually accessed via QML. However, if we are talking about dozens of data members, well that's a lot of lines of Q_PROPERTY, not to mention having to individually handle these in QML as separate properties as well (especially if dealing with "on changed" signals for each property).
I am wondering if it is possible to make a single Q_PROPERTY that would include all the data members I need. But what is not clear to me is the apparent mismatch between the types that QML supports and the types you can list in a Q_PROPERTY. For example, in QML, we have a basic string but its corresponding lising in a C++ Q_PROPERTY must be QString:
Q_PROPERTY(QString datastring READ showdata NOTIFY datastringChanged)
//in QML, `datastring` is just a plain string
Would there be more complex properties like lists or arrays that can be easily matched? QML has a list type and C++ has the QList but are these the same thing? Where can I find a listing of compatible types between C++ and QML?
On the other hand, having individual Q_PROPERTY for each data member could likely be better performance (my data is large and often changing) since the QML would not need to parse anything, perhaps.
Would there be more complex properties like lists or arrays that can
be easily matched? QML has a list type and C++ has the QList but are
these the same thing? Where can I find a listing of compatible types
between C++ and QML?
Have a look at the C++/JS data conversion help page. I think the list missed that QList<QObject*> is also possible.
On the other hand, having individual Q_PROPERTY for each data member
could likely be better performance (my data is large and often
changing) since the QML would not need to parse anything, perhaps.
Maybe, yes, depends on your performance needs. A C++ QList gets converted to a JavaScript list when accessed from QML/JS. That's a bit of conversion overhead indeed. Also, ff an item in the list changes, you need to emit the notify signal for the complete property, and every JS binding in which the list was used needs to be reevaluated, which will again be many list conversions. That could be better by having more fine-grained properties, but it really depends.
Btw, with Qt 5.1 there now is MEMBER, which makes writing Q_PROPERTYs a bit easier.
I am on several lines codes from a Qt project to appending into a Qvector every 1s. I noticed that in STL deque could have a better performance in adding a new element into the end that vector. What's the equivalent or similar Qt way? Cause I don't find any in Qt libraries.
Julio
There is no direct equivalent to the std::deque class in QT.
However, your best bet is to use QList.
Here is what the documentation says about QT container classes:
For most purposes, QList is the right class to use. Its index-based API is more convenient than QLinkedList's iterator-based API, and it is usually faster than QVector because of the way it stores its items in memory. It also expands to less code in your executable.
Anyways, if you are only appending items once every second, there will not be much impact to choose one over the other.
There is no need to have a Qt equivalent for every std container, you can use std::deque if that is what you are after.
Anyway, note that for the case when you do a lot of insertions at the end of the vector both std::vector and QVector have a member function named reserve (see the links) that can be used to pre-allocates a bigger buffer and make insertions at the end faster.
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.