yes, we have static functions that can be invoked from the watch window of the debugger:

// These functions are to be used from the debugger Watch Window to 
// convert symbols to strings and vice versa while debugging.
// Use the following syntax in Microsoft Visual Studio:
//
//  {,,Debug.Core.Kernel.dll}SymbolToString(1146)
//  {,,Debug.Core.Kernel.dll}StringToSymbol(L"DiskFileSystem")
//@{
extern "C" NS_CORE_KERNEL_API const NsChar* NsSymbolToString(NsSize id);
extern "C" NS_CORE_KERNEL_API NsSize NsStringToSymbol(const NsChar* str);
//@}

we try to avoid statics in our architecture. That way, we have under control the init order of the different subsystems (for example, the symbol system depends on the log system and memory system).

If you do not have that restriction, your solution seems to be right.

My Symbol class has a string field and a constructor requiring the string, that are only visible when the _DEBUG symbol is defined:

class Symbol
{
public:
#if _DEBUG
Symbol(size_t id, char* str)
{
_id=id;
_str = str;
}

std::string getStr()
{
return _str;
}
#else
Symbol(size_t id) { _id=id; }
#endif
size_t getID() { return _id; }

private:
#if _DEBUG
const char* _str;
#endif
size_t _id;
};

so you could use:
…
return Symbol(sym, #id); /
…

I’ve just realized that a cleaner approach could be leaving that constructor and field available for all configurations, but saving the string only in debug, something like this:
Symbol::Symbol(u32 sym, char * str)
{
_sym = sym;
#if _DEBUG
_str = str;
#else
_str = 0;
#endif
}

const char * Symbol::getStr()
{
if (!_str) return “”;
return _str;
}

typedef size_t Symbol;

#define DECLARE_SYMBOL(id)\
static Symbol SYMBOL_##id = GetIdFromString(#id);

#define S(id) SYMBOL_##id

That way you don’t have to worry about making GetIdFromString thread-safe because it will only be called from the C runtime static initializer, which is guaranteed to be single threaded, and all the cost associated with it will be removed from the runtime. Is there any downside to this approach?