@GrecKo said in Iterator as a member: Tree/Graph-like structure: pick the container with the friendliest API depending on how you plan to access it. Still what @Christian-Ehrlicher and @JonB suggested doesn't sound too bad :) Will definitely try it. Similar question: Why is QButtonGroup using a QHash-map for its member buttons? :)) I doubt that there ever will be thousands of button widgets in one group :)

PointerList<QString> plist; plist.append(new QString("World")); plist.insert(0,new QString("Hello")); for(const QString* str : plist) qDebug()<<*str; print: "Hello" "World"

@jsulm Thank you. That works. What could have been the problem? That C Arrays are not compatible for the container classes?

@ChrisW67 Thank you! Yes, I thought about smart pointers as well but I am (yet) not very familiar with it and don't know which one is correct. Currently we work most of the time with raw pointers and the old Qt3 QPtrList . Maybe the qt-version: https://forum.qt.io/topic/19073/any-difference-between-std-shared_ptr-and-qsharedpointer/2 could be an option as well...

@J-Hilk Thanks! Ok, so removing the deleted move constructor and move assignment operator works. I was marking it delete because I wanted to avoid implicitly generated move semantics, but now I understand that it won't be generated by itself if I have a copy constructor already. It is still weird that QList was giving error for deleted move semantics when it is not using move semantics at all.

@dheerendra thsnls for your reponse. But how do I get the onChanged of param to run the if statements? Thanks

@JonB Thank you!

@Ketan__Patel__0011 said in How to get first element of QList: try this way QList<int> index; index.push_back(10); index.push_back(20); index.push_back(30); index.push_back(40); index.push_back(50); qDebug() << index.at(0); /// Answer Is 10 OP already figured out the function for obtaining the first element: https://forum.qt.io/post/650999 Their current problem is how to avoid calling it inside a loop.

Unless you have some hardcore use case, perhaps you don't need to cache at all? SQLite is pretty fast, and Qt comes with QSqlQueryModel / TableModel helper classes. In my (limited :D) experience, it works really well and fast, even on slow hardware.

So it looks like I was missing the variable statement after this. It works now. Thanks everyone for the help. QList<QObject*> list() const; for (int index=0; index < list.size(); index++) { QObject *test01 = list.value(0)->name(); qDebug() << test01; }

@SpaceToon I might worry at 20,000, but not at 20 :)

@Yash001 said in which container (Qvector or QList) is good to use for insert, delete, and access the last element.: I am adding data point at last position of container, and only accessing the last element of container. So which is better container? It's what we call Last In First Out ( LIFO) queue. So QStack seems an obvious candidate. QStack inherits from QVector.

@RAJ-Dalsaniya Super to hear \o/ Please mark as solved using the Topic Tool button at first post :)

@oblivioncth said in Why does the const Object returned by QList::at() block access to instance methods?: Hey, going above and beyond! Thanks again. You're most welcome! I'm not completely ignorant in the ways of C++ though, I'm not 100% certain, but fairly confident that: Const 1) Ensures the returned value can't be modified, Yep. the use cases of which I'll admit I'm not really privy to. Use case 1: Allow the caller to read the data without creating a copy, AND Make sure the data is read-only If the returned reference is non-const, the caller will be able to directly modify the object's internal memory. This breaks encapsulation. Use case 2: Allow the function to be called in another const function. There's a const and a non-const version of QList::operator[](int): T & operator[](int i) const T & operator[](int i) const Version #1 allows the caller to modify the QList element. However, it cannot be called in a const function -- it will cause the error in your original post. Thus, version #2 is required for use in const functions. I know that its only really useful when dealing with user defined classes and returning by value reference (which is the case in your example) to prevent memory modification if desired. (Acknowledging your typo) Why would it be "only really useful when dealing with user defined classes"? Notice that QList::at() returns a const reference. I do remember seeing something about this being somewhat obsolete in C++ 11 (or was it 17) and forward, though I'm not sure why. Returning const references is defintiely not obsolete. You might be remembering move semantics, which is said to make passing parameters by const-reference obsolete: https://stackoverflow.com/questions/10231349/are-the-days-of-passing-const-stdstring-as-a-parameter-over Qt will not be making this change anytime soon though; this is too disruptive. Const 2) The pointer argument "arg" in that class is for the type "const MyOtherClass", i.e. a pointer to a constant value (value cannot) Yep, myfunc() cannot modify the MyOtherClass object. (In other words, it can only call const methods of the object) Const 3) Marks the pointer "arg" itself as pointer, so that the pointer itself also cannot be modified) Yep. This is not very useful IMHO, but it's part of the language. Const 4) Thanks to you, I now understand this means that the function does not modify the object instance that the function is being called on/from (i.e. cannot manipulate member variables). Great! Next, start thinking about the difference between logical const-ness and physical const-ness: https://isocpp.org/wiki/faq/const-correctness#logical-vs-physical-state Btw I do like a lot of the explanations on that site as they provide a lot of detail and examples, and I had never read the article for const. Agreed

@n-2204 Please try to format your posts readably. For lines of code use the Code tag when posting, or but lines of 3-backticks above & below. You are also now asking this same question in a new thread you have created (https://forum.qt.io/topic/125774/qtableview-how-to-make-noneditable-column). You should stick to one thread, not create multiple ones. where i should give like it will be applicable for table1 or table2 I don't know what you mean. To use the flags() approach you must sub-class QStandardItemModel, which I assume is what your GAS_tool is, else this will have no effect. If you want to use the setFlags() approach, you do not need to sub-class, but must set the flags explicitly on each item which is to be non-editable. I also wrote this in your other thread.

@Lasith well std::bad_alloc often comes when out of memory. My guess is that <List1[0].size() is always true since you add to it for each loop and hence create an infinite loop. Did you try VRonin code? Update: If you just want list1 in [0] and list2 in[1] why all the loops then? [image: l1TWiB.png]

@kshegunov said in increasing QList<QStringList> contents twice!: if it looks like a duck, swims like a duck, and quacks like a duck [image: if-it-looks-kvixle.jpg] Slight thread derail, but I would say the op's question general is answered .

@VRonin a suggest read is a SO post As mentioned earlier aswel, I will use this iterator (first time :p) Thanks for all the help!

I just had a typo in the group ^^ Sorry!