PDA

View Full Version : QString constants in a class



darkadept
4th September 2007, 22:47
This is another one of those "which way is best" questions. I am wondering which is the best way to use named constant QStrings in a class. For example:



class MyClass {
public:
void doStuff() {
{
QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL", "MySpecialDbName");
//do all sorts of database stuff here
db.close();
}
QSqlDatabase::removeDatabase("MySpecialDbName");
}
};


"MySpecialDbName" should be a named constant, right? Especially if doStuff() is complex or the call to removeDatabase() is done in another method etc.

One way I thought of is to use an enum and a function to translate the enum to a QString.


enum MyStrings {
DbName,
SettingsGroup,
ProgramName
};
QString getMyString(MyStrings string) {
switch (string) {
case (DbName):
return QString("MySpecialDbName");
case (SettingsGroup):
return QString("my/config/db");
case (ProgramName):
return QString("My Program");
default:
return QString();
}
}


Or even the enum as above and an array of QStrings or a QStringList.

Maybe I'm just being pedantic but I can't seem to find any examples of what other people do. And maybe it doesn't matter in the end anyway... but I figured I'd ask. :rolleyes:

Michiel
4th September 2007, 23:19
There's a more elegant way. Actual static constant string variables. C++ doesn't make this pretty, but here goes:

myclass.h

class MyClass {
private:
static const QString DbName;
};

myclass.cpp

#include "myclass.h"

const QString MyClass::DbName = QString("MySpecialDbName");

darkadept
4th September 2007, 23:36
Oh you're right, that ain't pretty. But maybe it's good enough. =)

jpn
4th September 2007, 23:55
I tend to do it this way mostly for the reason that header file remains clean:

myclass.cpp

#include "myclass.h"

static const QString DBNAME("MySpecialDbName");

MarkoSan
30th October 2007, 00:41
are, for instance, the following two declarations

static const QString strTable(QObject::trUtf8("xxxx")); // table "xxxx" unicode name

and


const static QString strTable(QObject::trUtf8("xxxx")); // table "xxxx" unicode name

identical?

pherthyl
31st October 2007, 07:08
I tend to just go:

#include "myclass.h"
#define DBNAME "MyDatabase"

Not very C++y, but it works and its simple. I don't see any reason to use a static variable instead.

jpn
31st October 2007, 08:19
are, for instance, the following two declarations identical?
Yes, as far as I know, the meaning is same. With some older compilers you might get warnings with the latter one, though.


Not very C++y, but it works and its simple. I don't see any reason to use a static variable instead.
Of course macros have their own use, but *cough* macros are evil! :) At least compilers and debuggers come along with typed variables. Try googling for "const vs #define".. http://www.comeaucomputing.com/techtalk/#definevsconst

spud
31st October 2007, 09:28
are, for instance, the following two declarations

static const QString strTable(QObject::trUtf8("xxxx")); // table "xxxx" unicode name

and


const static QString strTable(QObject::trUtf8("xxxx")); // table "xxxx" unicode name

identical?
A small note on trUtf8:

Warning: This method is reentrant only if all translators are installed before calling this method. Installing or removing translators while performing translations is not supported. Doing so will probably result in crashes or other undesirable behavior.
Not only that, but strTable will probably remain untranslated since strTable's constructor is likely to have been called before your translators were installed.
Why don't you just keep a
static const char strTable[]="xxx";
And call trUtf8() every time you access it? Then the user would be able to change localization at runtime.

Korgen
31st October 2007, 13:07
you could also think of using QSettings instead of the constant. You could hold the databasename and settings in an .ini file (also in the registry if you're on windows) and wouldn't have to recompile your application if the db-name changes

pherthyl
31st October 2007, 18:59
Of course macros have their own use, but *cough* macros are evil! :) At least compilers and debuggers come along with typed variables. Try googling for "const vs #define".. http://www.comeaucomputing.com/techtalk/#definevsconst

Funny position to take given that a lot of Qt goodness is due to macros and preprocessors :)

Anyway, none of those reasons apply in this case, since the point is just to put the name in one place. I'm against heavy use of macros as well (I hate it when people define macros like MWPTR MainWindowFactor::getInterfacePointer()->mainWindow()). Those just serve to obfuscate code, but in this case a define is the easiest way to go.

jpn
1st November 2007, 10:25
Funny position to take given that a lot of Qt goodness is due to macros and preprocessors :)
But there's quite a big difference, don't you think? Most of the macros providing this goodness are actually defined as empty. They are just used as markers for moc. ;)

pherthyl
1st November 2007, 18:11
Ah, that I didn't know... Thanks for the info.

Gopala Krishna
2nd November 2007, 09:52
I tend to just go:

#include "myclass.h"
#define DBNAME "MyDatabase"

Not very C++y, but it works and its simple. I don't see any reason to use a static variable instead.

This is fine but static const version is even better because it avoids creation of temporary QString objects at numerous place. And also, the assignment of const strings are faster thanks to implicit sharing of QString.

So according to me static const QString DBNAME("string") is better solution.