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?

alt text

@kshegunov said in increasing QList<QStringList> contents twice!:

if it looks like a duck, swims like a duck, and quacks like a duck

s

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!

The easy way:
get rid of PortalMapItemInfo, store the values in 4 different QStringList and use a QStringListModel

The proper way:
in HomeController.h add Q_DECLARE_METATYPE(PortalMapItemInfo) http://doc.qt.io/qt-5/qmetatype.html#Q_DECLARE_METATYPE

Instead of a List store your data in a 1-column QStandardItemModel and expose it via a Q_PRPERTY