I am using a va_list to construct a string that is rendered.
void Text2D::SetText(const char *szText, ...)
This is all fine and good, but now the user has the ability to change the language while the application is running. I need to regenerate all the text strings and re-cache the text bitmaps after initialization. I would like to store the va_list and use it whenever the text needs to be generated.
To give you some more background, this needs to happen in the case where the key string that I'm translating has a dynamic piece of data in it.
"Player Score:%d"
That is the key string I need to translate. I would like to hold the number(s) provided in the va_list for later use (outside the scope of the function that initializes the text) in the case that it needs to be re-translated after initialization. Preferably I would like to hold a copy of the va_list for use with vsnprintf.
I've done some research into doing this and have found a few ways. Some of which I question whether it is a appropriate method (in terms of being stable and portable).
You can use
va_copy()
, here is an example:Storing the
va_list
itself is not a great idea; the standard only requires that theva_list
argument work withva_start()
,va_arg()
andva_end()
. As far as I can tell, theva_list
is not guaranteed to be copy constructable.But you don't need to store the
va_list
. Copy the supplied arguments into another data structure, such as a vector (of void*, probably), and retrieve them later in the usual way. You'll need to be careful about the types, but that's always the case for printf-style functions in C++.This question has really piqued my interest. Also I will be facing a similar problem in my own work, so the solution devised here may help me, too.
In short, I wrote proof-of-concept code which caches variable arguments for later use -- you can find it below.
I was able to get the below code to work correctly on both Windows and intel-based Linux. I compiled with gcc on Linux and MSVC on Windows. There is a twice-repeated warning about abusing va_start() from gcc -- which warning you could disable in your makefile.
I'd love to know if this code works on a Mac compiler. It might take a little tweaking to get it to compile.
I realize this code is:
My use of malloc() and free() was very deliberate, as va_list macros are from the C standard and are not C++ features. I realize your question title mentions C++, but I have attempted to produce a fully C-compatible solution, other than using some C++-style comments.
This code also no doubt has some bugs or non-portabilities in the format string processing. I provide this as a proof of concept which I hacked together in two hours, not a finished code sample ready for professional use.
That disclaimer said, I hope you find the result as delightful as I did! This was a lovely question to hack around in. The sick and twisted nature of the result gives me a deep belly-laugh. ;)
What you describe about "holding the number(s) provided in the va_list" is the way to approach this.
The
va_list
maintains pointers to temporary memory on the stack (so-called "automatic storage" in the C standard). After the function with variable args has returned, this automatic storage is gone and the contents are no longer usable. Because of this, you cannot simply keep a copy of theva_list
itself -- the memory it references will contain unpredictable content.In the example you give, you will need to store two integers that are re-used when re-creating that message. Depending on how many different format strings you have to deal with, your approach might vary.
For a completely general type of approach, you will need to:
cache_arguments()
" function which creates a dynamic-memory buffer of the values found in variable arguments.cache_arguments()
would use theprintf()
-style format string, along with theva_start
,va_arg
,va_end
macros. You will need to retrieve the types according to theprintf()
type-specifiers, becausesizeof(double) != sizeof(int)
.va_arg()
on your platform. (Read yourvarargs.h
file.)vsnprintf()
working with this cached memory buffer instead of a pointer created byva_start()
.The above items are all possible on most platforms, including Linux and Windows.
An item you may wish to consider about translation is the word-order concern. What is written in English as:
Could in some (human) languages only be written fluently with a word order analagous to:
For this reason, the Win32
FormatMessage()
API uses aprintf()
-like format string, with the functional difference that parameters are numbered, as in:(The string type is assumed for each argument, so
%1
is equivalent to%1!s!
)Of course you may not be using the Win32 API, but the functionality of altering the word order of the formatted arguments is what I am attempting to introduce as a concept. You may want to implement this in your software, also.
The way to do it in C is to send a struct of arguments to the function instead. You should pass the struct by reference and then copy (memcpy) the struct to a common location which will allow you to reuse it later. You unravel the struct at the destination in the same manner you sent it. You keep the template of the struct for 'setting and getting'.