I wrote a simple program to convert Roman numbers to Japanese (roomaji).
This program needs to lookup a string using a number (think std::map).
And I'm wondering about the pros/cons of the 3 methods I thought about:
Method 1
I guess the major con here is you need to initialize the data at runtime, keep track of the initialization state, etc.

typedef std::multimap<unsigned long, std::string> UnitMap;
UnitMap Units;
static bool UnitsInitialized = false;
void InitializeUnits()
{
    if (!UnitsInitialized)
    {
        UnitsInitialized = true;
        boost::assign::insert(Units)
            (0, "zero")
            (0, "rei")
            //...
    }
}

Method 2
This is very C to me.

struct Unit
{
    unsigned long Value;
    const std::string Roomaji;
};
const Unit Units[] = 
{
    {0, "zero"},
    {0, "rei"}
    //...
};

Method 3
This is just like the previous method except a std::pair is used.
I'm thinking the std::pair constructor is called for every unit here which is less than optimal.
This 'feels' more C++ to me though.

typedef std::pair<unsigned long, std::string> Unit;
const Unit Units[] =
{
    Unit(0, "zero"),
    Unit(0, "rei")
    //...
};

Are there any other methods (without an external source)?
And what are the pros/cons here?

Recommended Answers

All 5 Replies

Edit limit got me.

I wanted to add:
-The table will actually only have about 20 items.

I don't understand why you consider these three methods equally matched. The 1st method only builds the desired multimap.

I think the std::multimap native interface is not suitable for most of applications (too cumbersome and unclear), so you need your own problem-oriented multimap wrapper class. You may initialize static multimap member in its constructor from method #2 or #3 sources (placed in the wrapper implementation module). Use boolean "initialized" static member to avoid redundant multimap initialization in possible consequent wrapper constructor calls.

The first method inclues the code to build the map because it is required. There's no way to build the map at compile-time that I know of.
The other methods have an advantage in that the data is 'built' at compile-time and needs no explicit initialization at runtime.

I'm thinking multimap is a little too heavy for this since I'll only have around 20 items. But I'm not really sure.

Right now I'm thinking of going with Method 2 (or possibly 1).

In actual fact all three methods construct data in run time because it's impossible to create std::string (and especially std::multimap) in compile time: the C++ compiler know nothing about generic data structures internal representation!

>I'm thinking the std::pair constructor is called for every unit here which is less than optimal
It's of no importance (and not only for std::pair constructor): it's startup flash code only...

I'm not sure that this mini-multimap is a proper data structure at all. But if you have the strong specification (of multimap using) then it seems the best method is to declare multimap<unsigned,const char*> and incapsulate it in a simple wrapper class then initialize it in the class constructor from type#2 data structure...

In actual fact all three methods construct data in run time because it's impossible to create std::string (and especially std::multimap) in compile time: the C++ compiler know nothing about generic data structures internal representation!

Ah! I originally had const char* 's, not std::string 's. But I changed it at some point.

I'm not sure that this mini-multimap is a proper data structure at all. But if you have the strong specification (of multimap using) then it seems the best method is to declare multimap<unsigned,const char*> and incapsulate it in a simple wrapper class then initialize it in the class constructor from type#2 data structure...

I think this is pretty much what I will do. Thanks for your help.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.