5 ms·
> print("hello",who,"answer",answer,'\n'); -- This is cute, ... but what if you need an integer in hex, or a floating-point number to a particular precision, an
by byuu 11y ago
> print("hello",who,"answer",answer,'\n'); -- This is cute, ... but what if you need an integer in hex, or a floating-point number to a particular precision, and so forth?
Then you can use a helper function to convert them to string objects first.
print("A:", hex(r.a, 4), " X:", hex(r.x, 4), " C:", integer(c, -10, ' '), "\n");
If your string class is smart enough to do small-string optimization (SSO), then this won't even need heap allocation, so the overhead is really very minimal.
This is basically what I do for my string library. But I also have a special format mode for things like UI localization:
print(tr("{1} is the value of {0}\n"), format{name, value});
//tr returns "{0}の値は{1}です\n" for Japanese locale
This goes further than printf by allowing you to very easily reorder the arguments. (omitting the indexes and using just {} makes them sequential.) [I've heard printf can do this too, but I don't know if that's standardized. I've never seen anyone do it in the wild.]
The format{} builds a list of values [I convert them to strings but you could use an any type if you wanted), and when print() gets a const format& as a type, it applies the list to the current string before it. It would be a trivial exercise to extend the token syntax to support formatting rules, eg "{0,-4h}" or what not.
Further, adapters can be added outside the library. So for SQL, one can have bindings via:
database.execute("select * from user where name=? and age >= ?",
escape{name, minimumAge});
Still, I'll freely confess that this isn't in the spirit of the C++ standard library: you pay a tiny bit of performance overhead in return for niceness. But unless your application is I/O bound to string formatting, I strongly believe it's worth the (minimal) cost.
String interpolation would make C++ print statements even nicer, but that's unlikely to ever arrive.
- Wyverald 11y agore your first point, the author did point out that this would pollute the namespace with names like hex, integer, etc.
- Someone 11y ago"I've heard printf can do this too, but I don't know if that's standardized" It is in POSIX. http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/pr...: "Conversions can be applied to the nth argument after the format in the argument list, rather than to the next unused argument. In this case, the conversion specifier character % (see below) is replaced by the sequence "%n$", where n is a decimal integer in the range [1,{NL_ARGMAX}], giving the position of the argument in the argument list. This feature provides for the definition of format strings that select arguments in an order appropriate to specific languages"
- TeMPOraL 11y agoHow the implementation of tr() looks like? It's another time when I see translating functions indexing text by... text itself, instead of some kind of numeric ID. Since we're talking about performance, I wonder why people write it this way.
- byuu 11y agoJust a simple hash table, or if you prefer, a red-black tree. The index where the string was found would be the same between the native list and locale string file. I like this style because a) if the locale file is deleted you don't end up with no text in your app, b) you don't need a gigantic pool of cryptic IDs, c) it's more intuitive what you're trying to print in the source code. print(tr("Warning: changing the video driver requires a restart to take effect")); //vs print(tr(TR_WARN_VIDEO_DRIVER_CHANGE_RESTART)); You'll create the English locale file anyway for others to translate for you, and you can even use that. The two major downsides are a) sometimes the same sentence is used in two areas and has the same translation in one language, but different translations in another (very rare), and b) if you change the text wording later, you have to edit it in the source code instead of in a separate English locale file. > Since we're talking about performance, I wonder why people write it this way. You're doing something horrendously wrong if your application spends even 0.1% of its time looking up strings to put into GUI windows.
- TeMPOraL 11y ago> a) sometimes the same sentence is used in two areas and has the same translation in one language I suspect it's not that rare of a thing, it would explain at least some of the bad translation cases I've seen, that are the reason I never use software in my native language if I can avoid it. > b) if you change the text wording later, you have to edit it in the source code instead of in a separate English locale file. And, if I understand correctly, in every other locale file too. This tingles my DRY sense in a bad way. > You're doing something horrendously wrong if your application spends even 0.1% of its time looking up strings to put into GUI windows. True. Though you can use this reasoning for pretty much every single thing in the source code, and this way lies Java and XML. Premature optimization may be bad, but I still try to always pick the faster option when it doesn't require too much work :).