Best practice for managing large quantity of hard-coded string in application.

Maximilien

We come to a point where we have a lot of hard-coded string in our application (because laziness, design issues, release-scheduling, ...). Most of our string are in the resources (string tables) and are used in the UI part of the application, but some of them are in the non-UI part (libraries) that does not have a direct access to the resources, and we don't want to have a dependence on the resources. Is there a best-practice way to deal with large quantity of string ? Simple header file with <code>const char*</code> ?

const char* myString = "my string";

or with <code>#define</code> ? Easy but not user friendly for potential localization.

#define myString "my string"

or an XML file with something like that (rough idea)?

<string ID="myString">
my string
</string&g

Or stick with the main resource file and string tables ? or one new resource for each libraries and include them in the main application resource ? possible issues with ID conflicts ? Thanks. Max.

Watched code never compiles.

Aescleal

Have a look at gettext. I've used it in a couple of projects and it's worked okay. It doesn't require loads of changes to the source and it's not too bad for localisation. It also handles strings from libraries fairly well. One big bugger is that it's a bit arcane to support unicode, but you can get over that with a bit of reading. Cheers, Ash

Maximilien

Aescleal wrote:

Have a look at gettext.

gettext what ? I've googled a bit on MSDN and could not find a reference, are you talking about the gnu/linux/whateverux gettext ?

Watched code never compiles.

Eugen Podsypalnikov

A product family could have the following resourses division :) : - application level, with all libs used by an application: one resource.h and one directory for resource DLLs (the shared by applications libs could have a reserved ID-area in an external header) - that directory is the second (sub-)level: DLLs - for each needed language Of course, the only GUI-Strings should be placed in the resources (which must be localized (translated ?)). An application does set the resource handle to its needed dll, for itself and all its libs at the run time. A "counter question": what role can have a non-GUI string constant in a real code ? :)

virtual void BeHappy() = 0;

Aescleal

That's the one - GNU gettext. It's a library and a suite of tools for managing strings in applications. Cheers, Ash

Sameerkumar Namdeo

Maintain Excel File for reading the strings used in application. One Excel File for one language. Each sheet in Excel File for each of your module or application or library. Reading and writing from Excel File is easy with : BasicExcel - A Class to Read and Write to Microsoft Excel - The Code Project - C++

My Blog.
My codeproject Articles.

Shivanand Gupta

use "ini" file read string from ini file by GetPrivateProfileString method

Alain Rist

Hi, With something like

// AppStrings.h
#include <tchar.h>

// globally accessible const string ids
enum e_ID { ID_THIS, ID_THAT, ID_OTHER /*, etc...*/};

namespace App
{
const TCHAR* String(e_ID i);
}

and

// AppStrings.cpp

#include <AppStrings.h>
#include <map>

#define ID_STRING(id, str) std::make_pair(id , _T(str))

namespace App {

typedef std::pair<e_ID, const TCHAR*> IdStr;

const IdStr IdStrings[] = {
ID_STRING(ID_THIS, "This"),
ID_STRING(ID_THAT, "That"),
ID_STRING(ID_OTHER, "Other"),
/*etc...*/};

const std::map<e_ID, const TCHAR*> StringMap(IdStrings, IdStrings + sizeof IdStrings / sizeof IdStr);

const TCHAR* String(e_ID i)
{
//const auto it = StringMap.find(i);
const std::map<e_ID, const TCHAR*>::const_iterator it = StringMap.find(i);
return it == StringMap.end() ? NULL : it->second;
}

} // namespace App

any part of the app after #include "AppStrings.h" may call App::String(SOMEID);. You may as well have different namespaces and id enums for different parts of your app. cheers, AR

When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)

modified on Thursday, September 16, 2010 6:15 AM

David Crow

This is what we used to do with DOS and 16-bit Windows.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Man who follows car will be exhausted." - Confucius

Shivanand Gupta

it store data in key value pair. and it work well in windowXP