0

Is there an easy way in C++ to have a message lookup table that allows the use of variables.

For example in C you can have something like this:

const char* transaction_messages[] = {
"UNAUTHORIZED",
"UNKNOWN_ORDER",
"UNKNOWN_DEALER",
"UNKNOWN_COMMODITY",
"INVALID_MESSAGE",
"BOUGHT %d %s @ %f.1 FROM %s", //amount, commodity, price, dealer
"SOLD %d %s @ %f.1 FROM %s", //amount, commodity, price, dealer
"%d HAS BEEN FILLED", //order id
"%d HAS BEEN REVOKED", //order id
"%d %s %s %s %d %f.1 HAS BEEN POSTED", //order id, dealer, side, commodity, amount, price
"%d %s %s %s %d %f.1" //order id, dealer, side, commodity, amount, price
};

and then use it in a function like thislike this:

void myfunction(int amount, char* commodity, double price, char* dealer){

    char *msg = transaction_message[6];
    printf(msg, amount, commodity, price, dealer);
}

I want to be able to do the same with an ostream instead of having to do something with the << operator where the same thing would look like:

ostream << "BOUGHT" << amount << " " << commodity << " @ " << price << " FROM " << dealer;

the only way I can think of doing this right now would be to have a bunch of inline functions that return strings and instead of having a char* table instead have a function table that looks up the inline functions. There must be an easier way tho.

kelab
  • 41
  • 6
  • the question is: why? what problem are you trying to solve with it? knowing that maybe there is a different solution to that problem. – PlasmaHH May 15 '12 at 15:32
  • You do notice the disadvantage of the `printf` version, that a small typo like `transaction_message[6]` instead of `[5]` changes from *BOUGHT* to *SOLD*? You wouldn't do that mistake in the second version. – Bo Persson May 15 '12 at 15:37
  • @BoPersson While I agree that `printf` is too error prone to be used in production code, an error in the index is an error in the index, regardless of whether the array contains `printf` format strings or pointers to functions. – James Kanze May 15 '12 at 15:50

3 Answers3

1

What you are doing is very similar to Localization (AKA L10N).

There are a couple of questions on this: Best way to design for localization of strings

But there are several packages that already deal with this.
These are basically designed to take all the strings from your application and package them in a separate resource (the correct resource (depending usually on locale) is selected at runtime). But they usually use the "English" (or should I say original text for non English programers) as the look-up text to find the correct resource string (thus the code is still readable to the developer) and the user gets a language specific string displayed.

Of course boost also has one

But there are others (A quick google finds)

Othere resources:

But getting the correct string is only half the battle. Then you need to correctly swap run-time values with place holders in the string. Personally this is where I think boost::format really shines.

Example:

sprintf("The time is %s in %s.", time, country);

The trouble is the order of nouns and verbs differ across languages. For example if we translate

"The time is 12:00 in Germany."

into Azerbaijani

"Saat Almaniya saat 12:00 deyil."

You will notice that the word for "Germany" (Almaniya) swaps places with the time. Thus the simple task of replacing items in a specific order does not work. What you need are indexed placeholders. (boost::format to the rescue).

std::cout << boost::formt("The time is %1 in %2.") << time << country;
// Notice the place holders are number '%1' means the first bound argument
// But the format string allows you to place them in any order in the string
// So your localized resource will look like this:

std::cout << boost::formt("Saat %2 saat %1 deyil.") % time % country;

Or more likely:

std::cout << boost::formt(I10N.get("The time is %1 in %2.")) % time % country;
Community
  • 1
  • 1
Martin York
  • 257,169
  • 86
  • 333
  • 562
  • It doesn't look like localization to me. (In practice, for anything dealing with real native language messages, localization means a different DLL per language, in order to handle things like plurals, gender, etc. correctly.) – James Kanze May 15 '12 at 15:48
  • @JamesKanze: Looks like localization to me: `transaction_messages[]`. Where the displayed text varies at run-time but the look-up index is a compile time constant. But yes. When dealing with localization the string need to be packaged into their own resources (DLL in your terms). If on the other hand the OP is just trying for a more compact way to format his output (I could read it this way) the second half of my answer covers that. – Martin York May 15 '12 at 16:00
  • I don't see any different languages, which would be typical of internationalization. Nor anything dealing with gender, number or any of the other issues you encounter in internationalization. It looks to me like he's generating a message according to a transaction type. – James Kanze May 15 '12 at 16:14
  • @JamesKanze: `L10N` not `I18N`. Sure I could be wrong. Then me answer is over-complex but the second half applies to message formatting which he can apply. – Martin York May 15 '12 at 16:16
0

In C++ boost::format can be used as a type-safe sprintf().

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
0

How about:

ostream& ToString(ostream&O, int amount, char* commodity, double price, char* dealer)
{
  char buf[80];

  char *msg = transaction_message[6];
  sprintf(msg, amount, commodity, price, dealer);

  return O << buf;
}
Neil
  • 11,059
  • 3
  • 31
  • 56