Why is there no copying at QNetworCookieJar?

goetz

Class QNetworkCookie contains the URI the cookie is bound to. According to the API docs the methods allCookies() and setAllCookies() can be used to implement a permanent cookie storage. So I think the returned list of cookies contains all the necessary information. If not, I'd definitely call this a bug :-)

haithun

Your right the data is being set up in QNetworkCookie. So your funtion will work and I am happy now that I do not have to use this cast. :) Thanks

haithun

Hi,
I realized that my problem description was insufficient and the problem has not been solved yet.
I want to do something like this:
@void Class::SetCookieList(const QList<QNetworkCookie> &Cookies)
{
_CookieJar->setAllCookies(Cookies);
}

QList<QNetworkCookie> Class::CookieList() const
{
return _CookieJar->allCookies();
}@

But since the functions "setAllCookies" and "allCookies" are protected I am unable to do so. What is the proper way to do what I want to do?

? Offline

the docs say:

bq.
This function is suitable for derived classes to save cookies to disk, ....

So should you extend QNetworkCookieJar class and override these methods?

andre

[quote author="haithun" date="1287528028"]Hi,
I realized that my problem description was insufficient and the problem has not been solved yet.
I want to do something like this:
@void Class::SetCookieList(const QList<QNetworkCookie> &Cookies)
{
_CookieJar->setAllCookies(Cookies);
}

QList<QNetworkCookie> Class::CookieList() const
{
return _CookieJar->allCookies();
}@

But since the functions "setAllCookies" and "allCookies" are protected I am unable to do so. What is the proper way to do what I want to do?[/quote]
If all you want to do is access those methods from an outside class, then just make a trivial subclass of QNetworkCookieJar and make those two method public. You can then access them from your external class. If what you want to do really belongs to the cookie jar itself, perhaps implementing your functionality in that subclass itself would be a better choice. It may help to keep encapsulation.

haithun

That was also my idea but I have the problem that I want to write the data of a normal QNetworkCookieJar to my class which is quite difficult without a copyconstructor.
Anybody knowing a good solution?

andre

Why do you need more than one?

haithun

I dont need more than one but I want to give my function "SetCookieJar" a QNetworkCookie. Thats data should be saved in my extended class. I am doing this because I want to avoid to have two member variables and the different treatment in my functions.

goetz

So as Andre wrote - subclass QNetworkCookieJar, make the two protected functions public and use them to transfer the cookie data. No need for a copy constructor as far as I see. Left alone that a copy constructor would do quite the same.

@
this->setAllCookies(other->allCookies());
@

Or implement a cloneFromOther Method to simulate an assignment operator/copy constructor:

@
void MyCookieJar::cloneFromOther(const QNetworkCookieJar *other)
{
if(other)
setAllCookies(other->allCookies())
}
@

As mentioned before, QNetworkCookieJar is a QObject and there simply IS NO copy constructor. It does not help to ask again and again - the trolls will not add it :-)

haithun

I understood that there is no copy cunstructor and also the reason.
Well your code is very similar to the one that I wrote cause subclassing QNetworkCookieJar was also my idea. But your version wont work, because you try to call the protected "allCookies()" function of the "other" object as if it's public. Would it be public my problem would not exist.

goetz

If you derive class MyCookieJar from QNetworkCookieJar you have access to the protected methods of the base class QNetworkCookieJar. And of course you have access to the protected methods of the other object pointer in that method.

haithun

Well I tried to do it in a constructor of my class but it wont work.

Here the class with constructor:
@
class MyClass : public QNetworkCookieJar
{
Q_OBJECT
public:

CopyFromCookieJar(QNetworkCookieJar *Cookies, QObject *parent = 0) : NetworkCookieJar(parent)
{
    this->setAllCookies(Cookies->allCookies());
}

@

goetz

The code fragment wouldn't even compile:

Your class is named "MyClass", your Constructor is named "CopyFromCookieJar" - both names must be equal.

Also the argument of the constructor should be
@const QNetworkCookieJar *Cookies@

Additionally, you should check for a null pointer before calling any methods on the pointer.

haithun

Yeah sry I just changed the name of the function and forgot that it should be a constructor.

Why do you declare the pointer as const?

The reason of the compiler is "'QList<QNetworkCookie> QNetworkCookieJar::allCookies() const' is protected".

goetz

Sorry for the wrong guidance. You cannot access the protected method of the base class in a derived class using a base class pointer.

You must replace all appearences of QNetworkCookieJar with your derived class in your application and pass around only pointers/references of this derived class. Then you have access to the protected methods.

@
class MyCookieJar : public QNetworkCookieJar
{
Q_OBJECT
public:
explicit MyCookieJar(QObject *parent = 0)
: QNetworkCookieJar(parent)
{
// nothing
}

void cloneFromOther(const MyCookieJar *other) {
    setAllCookies(other->allCookies());
}

};
@

For the const pointer:
the other cookie jar will not be changed by the clone method (or the copy constructor), so it's actually a good idea to make the pointer const. There are good explanations on const correctnes on the "C++ FAQ":http://www.parashift.com/c++-faq-lite/const-correctness.html

haithun

Yeah but now we are right there where I started cause I did not want to pass my derived class. I want to pass a QNetworkCookieJar to the function and then I want to put the cookies into my derived class. The reason why I want to have just Qt classes is no real reason it's just that I hate it to include the header in every upcoming projects.

I guess my first version by using a reinterpretate cast is the only solution.

goetz

Then there's no solution to your problem - you can't have your cake and eat it too :-)

I would go for the subclass approach. reinterpret_cast is ugly and should be avoided whenever theres a more elegant (and save!) solution - just my 0,02 € - :-)