Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

QListWidget::addItems() Data type question



  • Hi,

    as a newbie in C++ programming, I'm wondering why the following code lines work:

    QStringList *list = new QStringList(QStringList() << "Item1" << "Item2" << "Item3");
    list->append("Item4"); // this line just to demonstrate that the string list can be changed so it can't be a const, right?
    
    QListWidget *listWid = new QListWidget;
    listWid->addItems(*list); // <-- QListWidget::addItems(const QStringlist &list)
    

    Question 1:
    How can "*list" be a "const reference to a variable (list)" ? I mean, as the list is editable, it shouldn't be const, right?
    Question 2:
    I just passed the variable where the list pointer points to as an argument, not a reference of it while using "*list", right? So how can the compiler accept this code?

    Thank you in anticipation!
    Kind regards


  • Lifetime Qt Champion

    Hi,

    First thing, there's no need to allocate a QStringList on the heap.

    The * operator dereferences what is pointed to by the pointer.

    The const means that the variable passed cannot be modified in the method that you passed it to and the reference that a reference to it will be passed rather than the whole variable content copied.


  • Moderators

    Adding const is an operation that compiler can do whenever it needs to. Adding const does not "harm" the object in any way so adding it is a safe operation. This doesn't go the other way around. Removing const is an unsafe operation and compiler doesn't do it on its own. It requires an explicit const_cast to tell compiler that you know what you're doing.

    To answer your questions:

    1. list is a pointer. *list is the variable it points to and so it can be passed to a function requiring a reference. As mentioned earlier you can pass a reference where a const reference is required. Compiler will treat the object as const automatically. This wouldn't go the other way - you can't pass a const object where a nono-const object is required.

    2. Consider function void foo(const int&). You can give it a const int&. You can also give it a const int and, as mentioned before, you can give it an int and the const will be added for you. If you have a int* bar then *bar is of type int so it can be passed where const int& is needed. Same here. A const reference to a list is needed and when you dereference the pointer you get a list type and const is added to it for you.

    Btw. Don't write code like that. You're not deleting the pointer so it leaks. Also in the first line you create a list, append some elements to it and then create dynamically another list and call a copy constructor. That's very wasteful. There's rarely a reason to allocate containers on the heap. Simply do

    QStringList list {"Item1", "Item2", "Item3"};
    ...
    listWid->addItems(list);
    


  • Hey guys,
    thank you for your fast replies.

    The point was that I did not know that it is possible to re-declare a variable as "const" afterwards.

    I mean, in a call-by-value condition, I would have understood that the new copy of my variable is function-internally declared const. But with passing the origin variable by reference, compiler addes the "const" status to my already existing variable, right?

    So, shouldn't be the consequence that:
    a) I can't change the stringlist after this function call or does compiler "un-const" the list after returning from the function again? Removing an item after this call didn't throw an error...
    b) As I inserted the list-values by reference to the stringlist, shouldn't manipulating the stringlist after this function call affect the listwidget? Otherwise I wouldn't understand the sense why to pass the list by reference and why it has to be re-declared as "const"...

    And one more, maybe stupid question - sorry for that but I'm interessted in it and google won't give me an answer, maybe noone has ever asked that :-)
    You both tell me not do use pointers that are allocated on the heap on QStringLists and other containers. Is there any kind of "rule" which class objects are "large enough" to allocate them on the heap? How do you manage this?

    Thank you really much for your support.
    Greetings, Binary


  • Lifetime Qt Champion

    @Binary91-0 said in QListWidget::addItems() Data type question:

    compiler addes the "const" status to my already existing variable, right?

    No, it does not.
    If you do not specify a by-value parameter as const you can change the variable which was passed as parameter:

    void foo(int &value) ;
    int myValue;
    foo(myValue) // Here foo can change myValue
    
    void foo(const int &value)  // This one can't
    

  • Moderators

    a) I can't change the stringlist after this function call or does compiler "un-const" the list after returning from the function again? Removing an item after this call didn't throw an error...

    No. It's not that the compiler modifies your variable's constness. It's just that when you pass it to a function that takes const reference it is treated inside of it like a const reference i.e. it is guaranteed that the function won't change the value of that variable.

    b) As I inserted the list-values by reference to the stringlist, shouldn't manipulating the stringlist after this function call affect the listwidget? Otherwise I wouldn't understand the sense why to pass the list by reference and why it has to be re-declared as "const"...

    Again no. You pass parameters by const reference to avoid a copy on the interface level, but you don't know what happens inside. In case of a list there's space allocated for a new value in the buffer and then the value you passed is copied in. If you passed the parameter by value instead of by reference there would be two copies - one at the interface level when passing a parameter and another to put the value inside the list. As for constness of the reference - this is a contract with you as the user of that function. It tells you that you can give this function a variable and it won't modify it so you can be sure your variable is in the same state before and after that call.

    Maybe it would be helpful to get one thing straight - your processor has no notion of constness. There's just memory, addresses and some arithmetic. Everything else is just language abstraction that gets compiled away. So to your processor an int and a const int is just a 32bit data in a register. It doesn't even know that there was some const in the source code or what it would even mean. On the language level const is an API construct. It is used so you can tell others how they can use your variable and to tell you how to use other's variables i.e. when it is okay to write to it. When you have a function that takes const parameter all it does is tell you that it won't modify that variable. It doesn't restrict you on what you can give it, const or no const, it just says that your variable won't be modified inside the function. When a parameter is non-const reference the contract is "if you give me something I might modify it". Because of that you can't give it a const variable - it would try to modify something that is const and that would be an error so this won't compile.

    You both tell me not do use pointers that are allocated on the heap on QStringLists and other containers. Is there any kind of "rule" which class objects are "large enough" to allocate them on the heap? How do you manage this?

    There are no hard rules, but there's something to keep in mind - stack allocations are a lot faster but there's limited amount of space on it (by default something around 1MB per thread on Windows). The heap on the other side is large (it's the whole RAM you have) but access to it is slow, because allocations on it go through the OS. So a rule of thumb is use stack as much as possible for small and local things - variables, parameters, small objects etc. Most containers fall under this definition because they are small - few bytes usually. The underlying data is allocated dynamically on the heap internally so there's no point in paying two times for dynamic allocation when all you need is the few bytes for the container. Also something to keep in mind is that a stack is just that - a stack. It means that when you put something on it in a scope, let's say inside a function, it will be taken off of it when you leave that scope (exit the function). So remember that stack variables are scope local. Heap allocations are managed entirely by you, independently of the scope. You decide when to allocate and when to delete it, but it's also your responsibility not to leak anything (allocate without deleting at some point).



  • Ah, now I think I got it!

    I did not know the internal management of QListWidget. So, to repeat, a QListWidget always copies the list I passed to it and stores this copy into a new allocated RAM.
    Now, to avoid another copy for the function itsself to work with, I pass the source list by reference. As this is a potential risk to my source list, the Qt's function guarantees not to harm my list, and this guarantee is done by declaring the function parameter as "const". But "const" in this sense does not mean to change my variable into a const (this is still not possible, I hope), but instead it is like a "function character" to tell the compiler to take a look at the function algorithm and to ensure that it will not manipulate the variable.

    I hope, I got this right. If not, tell me please :-)

    "There are no hard rules, but there's something to keep in mind - stack allocations are a lot faster but there's limited amount of space on it (by default something around 1MB per thread on Windows). The heap on the other side is large (it's the whole RAM you have) but access to it is slow, because allocations on it go through the OS. So a rule of thumb is use stack as much as possible for small and local things - variables, parameters, small objects etc."
    Ok, I will notice that and I think I'll have to study the internal management of containers. I didn't know that Qt internally allocated heap for my container items. So, what would happen if I create a general object list containing 5 QWidgets, for example in a QVector? The container itsself will be allocated on the stack, but the items inside are already allocated dynamically. Will Qt then internally re-allocate them dynamically after storing them into a list container?

    Greetings, Binary


  • Moderators

    I hope, I got this right. If not, tell me please :-)

    Yeah, that's close enough. There's basically some data object somewhere in the RAM. When you refer to it via your original variable it is non-const i.e. you can write to it. When you pass it to the function via const reference it creates another "view" so to speak, of that same area in RAM, only this time this view (or variable, whatever you call it) is treated as read only (const).

    Ok, I will notice that and I think I'll have to study the internal management of containers.

    That's how most containers work. Basically the sizeof(yourContainer) does not change (it can't really, it's a static type size) and the storage for data it holds is dynamically allocated/reallocated/deleted as an implementation detail of fuctions like append, push_back, erase, clear etc.

    So, what would happen if I create a general object list containing 5 QWidgets, for example in a QVector?

    You can't. To put an object into a QVector it needs to be copyable. QObjects are not copyable (they have deleted copy constructors and assignment operators). In most cases you store pointers to widgets in containers, not widgets.

    The container itsself will be allocated on the stack, but the items inside are already allocated dynamically. Will Qt then internally re-allocate them dynamically after storing them into a list container?

    Your container holds some memory on the stack. in that memory it has a size counter and a pointer to dynamically allocated area of memory. In that memory it stores whatever the type of your container is. When you put something in a container it reallocates the memory to fit the new data and then calls a copy constructor to put the new thing in. It does not modify the original in any way. In case of pointers to widgets it just copies those pointers, so you get two containers containing pointers to the same widget object. Kinda like:

    QWidget* w1 = new QWidget();
    QWidget* w2 = w1; //now they point to the same thing but there's still only one widget
    

    Except you copy entire container of those pointers, not just one. In case of QStringList you copy strings like you copy pointers, by value, i.e. you get another container with a fresh copy of those string values.



  • @Chris-Kawa Thank you really much for this detailed support. Now I think it is clear for me.

    What do you think is the best way to manage multidimensional string-lists that have to be viewed in 3 seperate QListWidgets that depend on each other?

    Example:
    Main QListWidget (#1) has 3 items. When the user clicks on one of those items, the second QListWidget displays the associated items, let's say again 3 items. When the user clicks on one of those 3 "sub-items", again 3 more items should be displayed in the third QListWidget.

    Till now, I'm using complicated, multi-dimensional QLists like this:
    A simple QStringList for level #1, a QList<QStringList> for level #2 and a QList<QList<QStringList>> for level #3.
    I catch user selection using "currentRowChanged", start a complicated for-loop to walk through the levels and choose the associated QStringList, clear the QListWidget and add the new List.

    Is there an easier and more performant way to manage this? Would QVector be a better solution for that? Or is a completely different approach better?


  • Lifetime Qt Champion

    @Binary91-0 To avoid linear search you can use a QMap<QString, QstringList> for second and third list widgets. Key is the string selected in the previous list widget, value is the list of strings asotiated with that key.



  • @jsulm is probably the quickest/simplest suggestion to suffice you. However, being purist, be aware that as it stands it "cuts a corner": if you can have the same string text at different levels of the tree with different children (i.e. the fact that they are the same string is a "coincidence"), it will not work without some further massaging.

    You could just invent a proper data structure to hold you data correctly. Create a class/struct, named Node, which holds a QString text for its string plus a QList<Node> for its children. That is what your data really is. Finding a node by text at a given level is a linear search through its parent's child list (only).

    I would start by looking at whatever data structure you currently have for your items and their sub-items and take it from there.



  • @jsulm This sounds great! I did not test it so far, but after reading the documentation part, it seems to exactly fit my intentions.

    @JonB Good aspect. Fortunatelly, no literally identical values will appear in the lists. The node system is very interessting. I think, for this purpose with only displaying the next level list-widget, maybe the node system is not needed, but it sounds like a good way to automatically walk through complex lists.
    In addition, I will maybe use a combination of both. What do you think about inheriting QString in a new class and adding a specifier like a pointer to the next level string-list to it. Then, on the one hand, I get my fast interaction by QMap and as a backup (e. g. for storage and loading procedures of the whole data) I will always have unique connections.

    How would you guys manage the local storage of such three-dimensional data structures? I know database management from PHP server-based, but I have never done such stuff with Qt in a local directory. Is it a possible and "easy to learn" method for this purpose or do you suggest any other storage method?



  • @Binary91-0 said in QListWidget::addItems() Data type question:

    What do you think about inheriting QString in a new class and adding a specifier like a pointer to the next level string-list to it.

    No! Your structure, with a string text plus children, is not itself a QString, and does not behave anything like one. So inheritance here would be wrong, use encapsulation (member QString plus children, as I wrote).



  • Ok, I understand.

    But if I am right, there is still no direct way to get a connection from a selected list item to the node, right? For example, I create a complex node hirarchy and pass the string-values of those nodes to the QListWidget, including duplicates. How is it possible now to directly associate a selected list item with the corresponding node? Do I simultaniously have to mirror the list structure in my nodes and catch the "currentRow" signal to walk through my node structure till I found the corresponding item?
    If this was the way I need to go, I'm asking myself how to easily react to changes in the list widget, e.g. changing the sort-mode from ascending alphabetically to descending alphabetically. Do I have to start a complex sort mechanism that walks through my nodes and sorts them by a given identifier or stuff like that?

    I mean, the perfect way would be to directly inherit from a list widget item or from QString to "infiltrate" the list so I can directly react to user selection with the corresponding node.

    Or am I missing the point?


  • Moderators

    One possible answer is that a list widget is not the best tool for this task. QListWidget is sort of a entry level widget if you don't need anything fancy. Usually when whatever customization needs to be done going for a lower level solution turns out to be far more suitable. You could implement an item model with a tree structure of nodes and then have 3 QListViews that point to different levels of the tree. On selection change you would simply get the selected row index and switch the views to point to the right tree node. I discourage you from using strings as indices. It's slow and gets complicated with non-unique strings. It's better to just deal with QModelIndexes. Handling sorting and filtering in this case could be done via QSortFilterProxyModel, which would handle the translation of indices from what's in the view to what's in the model. See Model/View Programming for details and specifically Proxy Models section for handling filters and sorting.



  • Ok, sorry for the belated reply, but it took me some hours to carefully read the whole topic to Model/View Programming. Thank you for that hint, I think I know understood the basic principle of this concept!

    I'm trying to solve my issue with a tree model now, what gives me most flexibility. For this, I'm coding an example as described in the link you posted (Simple Tree Model Example).
    Here, I have a problem understanding what we already discussed eralier: The syntax of a function call with a const reference of X within this function call:

    int TreeItem::row() const
    {
        if (m_parentItem)
            return m_parentItem->m_childItems.indexOf(const_cast<TreeItem*>(this));
    
        return 0;
    }
    

    What is that "const_cast" good for? My google research told me that, in a const function like the above, the "this"-pointer is a const pointer to a CONST object. Instead, in a non-const function, the "this"-pointer was a const pointer to a NON-CONST object. Am I right?
    Why do I have to use this const_cast now to call a const function? I mean, the "indexOf"-function is const, so why shouldn't it be possible to pass a const object?

    Sorry, but I really try to understand that stuff..


  • Lifetime Qt Champion

    @Binary91-0 said in QListWidget::addItems() Data type question:

    I mean, the "indexOf"-function is const, so why shouldn't it be possible to pass a const object?

    Because m_childItems contains TreeItem pointers, not const TreeItem pointers.



  • @Christian-Ehrlicher So, it is not possible to pass either TYPE &var or const TYPE &var to a function that declares its argument itsself as const? What is the sense of that?


  • Lifetime Qt Champion

    @Binary91-0 said in QListWidget::addItems() Data type question:

    that declares its argument itsself as const?

    I don't understand - m_childItems is of type QList<TreeItem*> - so indexOf() expects a TreeItem pointer, not a const TreeItem pointer. Therefore you have to cast the const this pointer to a non-const pointer. An automatic conversion from a const to a non-const value is not allowed (otherwise const would be completely useless when you think about it)



  • @Christian-Ehrlicher Ok, I know that I am wrong, but I try to explain what I do not understand:
    The syntax of indexOf is:

    indexOf(const T &value) const
    

    In my case, "T" is a TreeItem*, so the argument would be a "const TreeItem* &" what means a reference to a pointer of a const TreeItem, or not?

    EDIT:
    Ah, no. "T" is a Pointer to a TreeItem, and the indexOf()-function requires a const T &, so that means it requires a reference to a const pointer to a TreeItem, BUT NOT a const pointer to a CONST TreeItem, right?
    And what does the const ensure in this function? Does it ensure that the pointer will not point to another QTreeItem after the function call or does it ensure that the QTreeItem will not be modified in any way? Or both?


  • Lifetime Qt Champion

    @Binary91-0 said in QListWidget::addItems() Data type question:

    Does it ensure that the pointer will not point to another QTreeItem

    The const means, as already explained from others above, that the value is not modified inside the function.



  • @Christian-Ehrlicher And the "value" in this example is the const pointer "this", right? So the only thing, the function guarantees is, that this pointer can't be changed, right? Does that mean, that the object it points to can be changed?


  • Lifetime Qt Champion

    @Binary91-0 said in QListWidget::addItems() Data type question:

    that the object it points to can be changed?

    No, not in this case since the pointer itself is not const.



  • @Christian-Ehrlicher Oh, I don't know what's wrong actually but I simply do not understand it.

    Look at this example that I found on my google research. It exactly explains this situation.

    There is written, that a "this"-pointer is a const pointer, hence T* const this.
    Now, in a const function, the object, this const pointer points to will also get const, hence const T* const this

    So why do you say that in this case, the pointer itsself was not const?



  • Sorry for double posting, but this may exceed the threads topic now.

    I created an example application with a test class to try all possible combinations of pointers and classic variables in const member functions and non-const member functions.

    class myQTest
    {
    private:
        int iPriv = 1, *iPPriv = nullptr;
        
        void fPriv();
    
    public:
        int iPub = 2, *iPPub = nullptr;
        
        myQTest();
        ~myQTest();
        void fPub1(int);
        void fPub2(int) const;
        void fPub3(int*);
        void fPub4(int*) const;
        void fPub5(int *const);
        void fPub6(int *const) const;
        void fPub7(const int);
        void fPub8(const int) const;
        void fPub9(const int*);
        void fPub10(const int*) const;
        void fPub11(const int *const);
        void fPub12(const int *const) const;
    };
    

    The first thing I realized is, that a "this"-pointer isn't const. So the explanation in the external link topic I mentioned above is either wrong or I missunderstood it.

    The second thing I do not understand is, that I can write the following code without compiler error:

    void myQTest::fPub3(int *const i) // The declaration was int*, NOT int const*!
    {
    
    }
    

    How is it possible to define this function with a const pointer to int although it was declared as a non-const pointer to int?


  • Moderators

    @Binary91-0 I think it would be good to take a step back and go through it step by step, going back to your example:

    int TreeItem::row() const
    {
        if (m_parentItem)
            return m_parentItem->m_childItems.indexOf(const_cast<TreeItem*>(this));
    
        return 0;
    }
    

    We're inside a const function, so this is of type const TreeItem*, so pointer to constant TreeItem.

    m_childItems is of type QVector<TreeItem*>, so vector's T in this case is TreeItem* - non-const pointer to non-const TreeItem.

    QVector has a int QVector::indexOf(const T & value, int from) const method, so substituting T it is:

    int QVector::indexOf(TreeItem * const & value, int from) const
    

    meaning it takes a reference to constant pointer to non-const TreeItem. The const on the function means it won't change any member of QVector. It has nothing to do with the parameter. And it makes sense, because finding an index of an item has no business modifying the container.

    Btw. const position in C++ syntax is a bit crazy so be careful not to fall into the trap. If you just naively replace T like this: const T& -> const TreeItem* & then you've done it wrong. This would give you a reference to non-const pointer to const TreeItem, which is not what is happening here. Look up the "east const vs west const" to have a peek at the war that is going on in the language lawyers world :)

    Ok, so we have a this pointer which is a non-const pointer to const TreeItem and we have a function that expects a reference to const pointer to non const TreeItem. We have two mismatches here - first is on the type of the pointer and the second is on the item. The first one is easy because, as we previously discussed ,const can be added implicitly. The second one needs to take const off the item, and, as we also discussed, this can't be done automatically, so a const_cast is required to take the const off.

    So to summarize:

    this                                    ->    const TreeItem*
    const_cast<TreeItem*>(this)             ->    TreeItem*
    indexOf(const_cast<TreeItem*>(this))    ->    TreeItem* const &
    

    that const in last type evaluation says that the function promises not to change the value of TreeItem*, so the pointer. It could, if it wanted, change the value of TreeItem or call a non-const members on it, but this is a generic container and it won't even know what T is, so it doesn't know T is a pointer and so it won't try to dereference that pointer.


  • Moderators

    @Binary91-0 said:

    The first thing I realized is, that a "this"-pointer isn't const

    this is a prvalue. Yes, it's complicated, but one of the things it means is that, while you can't put a const (or volatile) on it, it is still non-modifiable, like nullptr or the result of built-in expressions. You can only assign it to stuff.

    To make it a little more confusing (because why not :P) some compilers (e.g. msvc and gcc in the past) implemented this as T* const in non-const methods and const T* const in const methods to ensure that non-modifiability, but that is not standard conforming and it kinda blew up when C++11 introduced r-value references. Oh well, it's a subtle corner case I guess.


  • Moderators

    @Binary91-0 said in QListWidget::addItems() Data type question:

    How is it possible to define this function with a const pointer to int although it was declared as a non-const pointer to int?

    The standard says that cv-qualifiers (const and volatile) of function parameters don't affect function type, meaning that you can drop const and volatile keywords in the declaration. IMO this is silly and unnecessary, but it doesn't harm anyone (apart from confusion and readability I guess). The interface says it might modify the parameter (no const in declaration) but it doesn't (const in definition).

    Btw. sorry for tripple posting. I wanted to answer each issue separately not to mix things up.



  • First of all, thank you really much again for this detailed support. It made things much clearer!

    We're inside a const function, so this is of type const TreeItem*, so pointer to constant TreeItem.

    The const on the function means it won't change any member of QVector. It has nothing to do with the parameter. And it makes sense, because finding an index of an item has no business modifying the container.

    Ok, this is clear for me now. The declaration of a member function to be const just tells the compiler to ensure that no object members are changed inside of it.

    Btw. const position in C++ syntax is a bit crazy so be careful not to fall into the trap. If you just naively replace T like this: const T& -> const TreeItem* & then you've done it wrong. This would give you a reference to non-const pointer to const TreeItem, which is not what is happening here. Look up the "east const vs west const" to have a peek at the war that is going on in the language lawyers world :)

    That's it! Thank you so much! This was the main thing I did not understand. But after thinking about it, it makes sense. The function wants to tell the user that the "thing" he passes to it will be const. By passing a pointer, hence the pointer will be const.

    Ok, so we have a this pointer which is a non-const pointer to const TreeItem and we have a function that expects a reference to const pointer to non const TreeItem. We have two mismatches here - first is on the type of the pointer and the second is on the item.

    The first one is easy because, as we previously discussed ,const can be added implicitly.

    What do you mean with "implicitly"? Do you mean that the compiler does an implicit type conversion of T to T const because we call the function by reference? If yes, then compiler had to do a re-conversion back to non-const after returning from the function to ensure not to have changed the source, right? What I mean: Will the source (i.e. the QTreeItem*) be re-declared as a QTreeItem *const inside the function body as I call it by reference or is it again just a hint for the compiler to handle the non-const QTreeItem pointer as a const pointer without "really/physically" changing anything of the source/source type?

    What would happen in a call-by-value condition? As it is possible to copy variables or pointers of the same type T into variables or pointers of type T const, it should be no problem at all, right? In this case, compiler shouldn't have to do any "implicit type conversions" as there will only be a copy created. On the other hand, in a call-by-value condition, I can't see any sense in declaring the function parameter as const, because no changes can be done to the origin source, right? (This is just for me to see if I slowly get the point of this stuff or if I'm still far away from understanding the usability of using const and call-by-ref vs non-const and call-by-val).

    The standard says that cv-qualifiers (const and volatile) of function parameters don't affect function type, meaning that you can drop const and volatile keywords in the declaration.

    Interestingly, I can't do this arbitrary adding of "const" in every of the functions mentioned above.
    Origin:

    void myQTest::fPub1(int i)
    {
    }
    
    void myQTest::fPub3(int *i)
    {
    }
    

    These definition changes are possible:

    void myQTest::fPub1(const int i)
    {
    }
    
    void myQTest::fPub3(int *const i)
    {
    }
    

    But this one gives a compiler error:

    void myQTest::fPub3(const int *i)
    {
    }
    

    As I know now, that const can be added "arbitrarily", I wonder why the last example dosn't work. I mean, it is possible to initialize a non-const pointer to a const int with a non-const pointer to a non-const int, because the following code works:

        int i1 = 1;
        int *iP1 = &i1;
        int const *icP1 = iP1;
    

    What's the reason for this behavior?


  • Moderators

    What do you mean with "implicitly"? Do you mean that the compiler does an implicit type conversion of T to T const because we call the function by reference? If yes, then compiler had to do a re-conversion back to non-const after returning from the function to ensure not to have changed the source, right?

    I thought we already covered that before? No, compiler does not change the source code and it does not change the meaning of your variables. It just manages memory blocks with language provided attributes (like const). Consider this example:

    int variable;  //1
    
    void Foo(int& a) { }
    void Bar(const int& b) { }
    void Bazz(int c) { }
    
    Foo(variable);  //2
    Bar(variable);  //3
    Bazz(variable); //4
    

    This is basically what the compiler is doing (not really, but you can think about it this way if you don't want to go into detail on Abstract Syntax Trees):

    • //1 Lets reserve 32bits of memory at address 0x1234 and refer to that memory as variable. Whenever we refer to variable we can read or write from the memory it names.
    • //2 Lets jump to code pointed by a function named Foo
      Lets take the memory named variable and now call it a. We can read and write to memory named a.
      Lets jump back out to where we were before.
    • //3 Lets jump to code pointed by a function named Bar
      Lets take the memory named variable and now call it b. We can only read from memory named b and any write access made through that b name will be a compile error.
      Lets jump back out to where we were before.
    • //4 Lets jump to code pointed by a function named Bazz
      Lets reserve 32bit of memory at address 0x5678 and call it c. We can read and write to memory named c.
      Lets copy 32bits from memory named variable to memory named c.
      Lets jump back out to where we were before.

    in a call-by-value condition, I can't see any sense in declaring the function parameter as const, because no changes can be done to the origin source, right?

    Yes, there's pretty much no point in declaring by-value params as const. It does prevent the function from changing the value inside, but the caller doesn't care, because it's not his variable that gets modified so it's basically just a documentation of the internal implementation. Some might consider this a bad practice because of that reason.

    As I know now, that const can be added "arbitrarily"

    It's not arbitrary. Basically you can differ in declaration/definition on how the parameter is passed to the function, not on the type of the parameter itself. In other words:
    int * -> int* const : changes non const "something" to const "something", that's ok
    int *-> const int* : changes non-const "something" to non-const "something else", that's not allowed.

    Anyway, let me be on the record that it's an obscure language quirk and I strongly discourage you to do that in practice. Keep it simple, make life of other programmers reading your code easier and make your declarations and definitions match.


  • Moderators

    As an interesting side note about those a,b,c variables - as you can see all it does is it kinda attaches read or write modifiers to some symbolic names. When you create a new name (the parameter of a function) it gets its own set of modifiers and doesn't affect the name it got created from. You can actually never change those attributes for a given name. You can only create a new name with different set of attributes that names the same data.

    This is also the reason why const_cast is so dangerous. What it does is:

    const int a = 42;
    int& b = const_cast<int>(a);
    

    Memory referred by name a will never be written to. Memory referred by name b can be written to. Everything is fine, nothing to look at. But hey, guess what - both names name the same memory block, so if compiler made some assumptions based on that a declaration, like, for example, placed it in a read only memory of the device, you're in trouble.

    Sometimes, like in the Qt example, const_cast is just a hacky workaround for some interface and if you don't actually use that variable to write it will be fine, but sometimes it can silently blow up and then it's a bad day at work. So use it sparingly and try to design your interfaces in a way that won't require const casts (I'm looking at you QAbstractItemDelegate::createEditor :) ).



  • I thought we already covered that before? No, compiler does not change the source code and it does not change the meaning of your variables. It just manages memory blocks with language provided attributes (like const).

    Sure, but I didn't understand how compiler is internally handling this. As I see, in a call-by-ref-condition, a reference to my source is created and const-attributed. This ensures that whatever I passed to the function, it will be not changed. If it was a variable, then its contents are safe. If it was a pointer, then the pointer itsself is safe, but its dereferencing stuff can be edited.
    In a call-by-value-condition, new variables are physically created with corresponding new memory space. Therefore, no const attribute is needed, cause the source variable will never be reachable for the function.

    As an interesting side note about those a,b,c variables - as you can see all it does is it kinda attaches read or write modifiers to some symbolic names. [...] You can actually never change those attributes for a given name. You can only create a new name with different set of attributes that names the same data.

    So you mean, inside the function, it would not be possible to change the attribute of a function parameter? Is that behaviour different of "normal" variables other than function parameters?

    When you create a new name (the parameter of a function) it gets its own set of modifiers and doesn't affect the name it got created from.

    You mean that declaring a function argument e.g. as const does not affect the origin source variable which I pass to the function, right? Yes, that was one thing I had to internalize. I thought that by handling references, everything will affect the source variable.

    It's not arbitrary. Basically you can differ in declaration/definition on how the parameter is passed to the function, not on the type of the parameter itself. In other words:
    int * -> int* const : changes non const "something" to const "something", that's ok
    int -> const int : changes non-const "something" to non-const "something else", that's not allowed.

    This is what I'm still trying to comprehend, because the following code works just fine:

        int i1 = 1;
        int *iP1 = &i1;
        int const *icP1 = iP1;
    

    Here, I initialize a int const* with a int* and it works. In the function call, it doesn't work.

    Memory referred by name a will never be written to. Memory referred by name b can be written to. Everything is fine, nothing to look at. But hey, guess what - both names name the same memory block, so if compiler made some assumptions based on that a declaration, like, for example, placed it in a read only memory of the device, you're in trouble.

    Haha, I see, this is very dangerous! I'm asking myself whether there is a way to tell compiler like in a forward declaration that this variable may be kind of mutable so it will be never stored in a read-only memory part of the device...

    I am sorry for all those questions, I think I could already profit a lot from your great support and I simultaniously do a google recherche for all of this, but it's pretty difficult to find good matching answers to this "specific" questions.
    If you can recommend any literature to that, I would really appreciate that.


  • Lifetime Qt Champion

    @Binary91-0 said in QListWidget::addItems() Data type question:

    In the function call, it doesn't work.

    You don't do this in the function call (as I already said) - you do

    const TreeItem *myItem = this;
    TreeItem *myNonConstItem = myItem;
    

    And, as I already told you, is not allowed since this would kill the whole idea of const.


Log in to reply