Segfault when retrieving info from QSettings

[wysota]

Do you need members in those classes? I personally create and destroy the settings objects when I need them.

void C::m(p){
  QSettings s;
  QString v = s.value("xxx");
  //...
}

void C::m(p){
  QSettings s;
  QString v = s.value("xxx");
  //...
}

To copy to clipboard, switch view to plain text mode 

[codeslicer]

Eh.. well my application needs to access QSettings pretty often... creating all those QSettings would be a waste of space and a source of confusion...

[wysota]

Currently the number of those objects is a source of confusion And you'd have to sync() all the instances before every use.

[codeslicer]

Look, all I want to do is creat my own custom settings object, with members corresponding to different values. Later in my app, instead of declaring QSettings every time I need to use it, I could just create my settings object and just use settings.setValueOfSomething.

This is helpful because in some of my members I have the function process the input/output before returning/writing to disk.

Back on track, is this segfault preventable? Thanks!

[wysota]

Why don't you have a single settings object then which you will either pass as a pointer to every component that is to use it or make it a singleton? Your problems would instantly go away.

If you want me to help you with the current bad design, you have to at least tell me what the errors are, not only that they are different from previous ones.

[codeslicer]

I tried that but I got the error. Again, I'm using this custom settings class because I need some of the members to modify the information before continuing. All the relevant code is above. I'm willing to do anything, as long as I don't need to create a QSettings object for each member.

By the errors being different I meant in different parts of the code, ie in other members.


Thanks!

[wysota]

So why don't you run the debugger and analize the backtrace the same way as before?

I'd really suggest taking the singleton approach. You'll spend hours debugging the code and you could achieve the same result just less error prone by making your settings class a singleton with a static member returning the instance.

[codeslicer]

Sorry.. what do you mean by singleton?

Again, thanks for your help

[wysota]

http://en.wikipedia.org/wiki/Singleton_pattern

[codeslicer]

Thanks, but how does that help me? I have found out that the segfault originates when accessing ANY member function of QSettings. So this isn't a problem reading from the actual physical source, but from accessing the actual QSettings object. I have used these types of pointers before, nothing bad happened though... I'll check my source again.

Thanks!

[wysota]

You have null pointers and the singleton will eliminate that. Take a look at this:

class Settings : public QSettings {
public:
  Settings *instance() {
    static Settings *m_instance = new Settings;
    return m_instance;
  }
  //..
protected:
  Settings() : QSettings(qApp){}
};
 
void someClass::someMethod(){
  int v = Settings::instance()->value("param", 7).toInt();
}

class Settings : public QSettings {
public:
  Settings *instance() {
    static Settings *m_instance = new Settings;
    return m_instance;
  }
  //..
protected:
  Settings() : QSettings(qApp){}
};

void someClass::someMethod(){
  int v = Settings::instance()->value("param", 7).toInt();
}

To copy to clipboard, switch view to plain text mode 

[codeslicer]

Thanks for your help with the singleton approach, I will keep that in mind if I have to use it later, but I have located my problem.

I was referring to my custom settings class which used a pointer to a QSettings object. I fixed this by just explicately defining it in my header file. The reason for the error was that when I was experimenting before I commented the #include settings.h line and that caused the problem.

Thanks a lot for your help though, sorry for having you go through all that trouble

Also, one final question - if I define an object in a header file, what is it's parent?