Problem understanding the addressbook tutorial (part 3)

[Blackened Justice]

Hey everyone,

I've started learning Qt a few days ago, having a background of mostly procedural, relatively low level, C programming, also tinkering a bit with Python and C++. Well, I'm stuck on the end of the part 3 of the addressbook tutorial, the implementation of the next and previous methods. This may have to do with my complete lack of iterators...
My main problem is with this piece of code here:

if (i == contacts.end()){
        nameLine->clear();
        addressText->clear();
        return;
    }

if (i == contacts.end()){
        nameLine->clear();
        addressText->clear();
        return;
    }

To copy to clipboard, switch view to plain text mode 

From my understanding, end() represents NULL in a traditional single linked list, it's not an actual member of the list, right? In this case, however, it represents the failure to find in the QMap a key matching the current name. Isn't this kind of useless? When would the current name not be on the addressbook?

Cheers

[AlexSudnik]

HM , not sure if i got your problem but...it actually has nothing to do with a container's data...

The end() function of a container returns an iterator to the imaginary item one position past the last item in the container. end() marks an invalid position; it must never be dereferenced. It is typically used in a loop's break condition. If the list is empty, begin() equals end(), so we never execute the loop.

Search for "Container Classes" in Qt Documentation for full info.

[Blackened Justice]

Hmm... Here's the code of the function in full:

void AddressBook::previous()
{
    QString name = nameLine->text();
    QMap<QString, QString>::iterator i = contacts.find(name);
 
    if (i == contacts.end()) {
        nameLine->clear();
        addressText->clear();
        return;
    }
 
    if (i == contacts.begin())
        i = contacts.end();
 
    i--;
    nameLine->setText(i.key());
    addressText->setText(i.value());
}

void AddressBook::previous()
{
    QString name = nameLine->text();
    QMap<QString, QString>::iterator i = contacts.find(name);

    if (i == contacts.end()) {
        nameLine->clear();
        addressText->clear();
        return;
    }

    if (i == contacts.begin())
        i = contacts.end();

    i--;
    nameLine->setText(i.key());
    addressText->setText(i.value());
}

To copy to clipboard, switch view to plain text mode 

It seems to me that when the iterator is declared, and assigned to contacts.find(name), it will only get the contacts.end() "value" if the QString name isn't found in the QMap. However, how could this situation be possible?

[AlexSudnik]

Don't quite understand your problem..."how could this situation be possible? " it's possible when QMap does not contain desired key-value pair. Maybe you think that contacts.end() returns a value ? It's not , it returns an iterator. So all that happens here is :

1) From Qt Docs: "If the map contains no item with key key, the function returns end()." So if the current iterator (i) equals to the end()'s one : no entries were found,

2) If something was found , iterator is moved to the last entry (the one before the end() )

[Blackened Justice]

But if name is a QString variable read from the contents of nameLine, and everything that is shown on the nameLine has to previously have been entered by the user, and thus saved in the QMap, it isn't actually possible that the string won't be found. And so the iterator will never equal contacts.end()...

[ChrisW67]

I think you are correct because the name box is read only when in the browsing view: the only place that value can have come from is the existing data and therefore you would expect it always to be found. The programming is defensive and will continue to function even if a future maintainer removes the read only attribute.

[Blackened Justice]

Hm, okay. That's what I thought it would be, but then it's not very effective defensive programming. If it clears the content of the input fields, on a subsequent press of the Next or Previous buttons, nothing would happen, it would just stay blank. Only when another entry was added to the map, and the user didn't fiddle with the input fields, would it regain normal operation. With the way everything is set up, if you suddenly make the input fields writable, many things would stop making sense