views:

1450

answers:

6

I have this piece of code (summarized)...

AnsiString working(AnsiString format,...)
{
    va_list argptr;
    AnsiString buff;

    va_start(argptr, format);
    buff.vprintf(format.c_str(), argptr);

    va_end(argptr);
    return buff;
}

And, on the basis that pass by reference is preferred where possible, I changed it thusly.

AnsiString broken(const AnsiString &format,...)
{
... the rest, totally identical ...
}

My calling code is like this:-

AnsiString s1, s2;
    s1 = working("Hello %s", "World");
    s2 = broken("Hello %s", "World");

But, s1 contains "Hello World", while s2 has "Hello (null)". I think this is due to the way va_start works, but I'm not exactly sure what's going on.

+3  A: 

A good analysis why you don't want this is found in N0695

MSalters
+3  A: 

According to C++ Coding Standards (Sutter, Alexandrescu):

varargs should never be used with C++:

They are not type safe and have UNDEFINED behavior for objects of class type, which is likely causing your problem.

lefticus
In this case, it's not the class type issue, since there are only char * types in the va_list. It's the fact that the argument preceding the list is a reference.
Eclipse
I agree with your answer, about the macro expansion, it's a good point and probably the actual problem in this case. However, it's still a bad idea to mix it up in your C++ code, as there is nothing to prevent a user from (trying to) pass a std::string in.
lefticus
Yup, can't wait for variadic template in C++0x!
Eclipse
+16  A: 

If you look at what va_start exapnds out to, you'll see what's happening:

va_start(argptr, format); 

becomes (roughly)

argptr = (va_list) (&format+1);

If format is a value-type, it gets placed on the stack right before all the variadic arguments. If format is a reference type, only the address gets placed on the stack. When you take the address of the reference variable, you get the address or the original variable (in this case of a temporary AnsiString created before calling Broken), not the address of the argument.

If you don't want to pass around full classes, your options are to either pass by pointer, or put in a dummy argument:

AnsiString working_ptr(const AnsiString *format,...)
{
    ASSERT(format != NULL);
    va_list argptr;
    AnsiString buff;

    va_start(argptr, format);
    buff.vprintf(format->c_str(), argptr);

    va_end(argptr);
    return buff;
}

...

AnsiString format = "Hello %s";
s1 = working_ptr(&format, "World");

or

AnsiString working_dummy(const AnsiString &format, int dummy, ...)
{
    va_list argptr;
    AnsiString buff;

    va_start(argptr, dummy);
    buff.vprintf(format.c_str(), argptr);

    va_end(argptr);
    return buff;
}

...

s1 = working_dummy("Hello %s", 0, "World");
Eclipse
Nice explanation of what's going on.
Michael Burr
This is a good example of the proverbial leaky abstraction. va_start seems like some sort of magic, but really it's just a bit of compiler-approved hackery.
Eclipse
+7  A: 

Here's what the C++ standard (18.7 - Other runtime supprort) says about va_start() (emphasis mine) :

The restrictions that ISO C places on the second parameter to the va_start() macro in header <stdarg.h> are different in this International Standard. The parameter parmN is the identifier of the rightmost parameter in the variable parameter list of the function definition (the one just before the ...). If the parameter parmN is declared with a function, array, or reference type, or with a type that is not compatible with the type that results when passing an argument for which there is no parameter, the behavior is undefined.

As others have mentioned, using varargs in C++ is dangerous if you use it with non-straight-C items (and possibly even in other ways).

That said - I still use printf() all the time...

Michael Burr
+1  A: 

Varargs are bad m'kay.

plinth
A: 

Side note:

The behavior for class types as varargs arguments may be undefined, but it's consistent in my experience. The compiler pushes sizeof(class) of the class's memory onto the stack. Ie, in pseudo-code:

alloca(sizeof(class));
memcpy(stack, &instance, sizeof(class);

For a really interesting example of this being utilized in a very creative way, notice that you can pass a CString instance in place of a LPCTSTR to a varargs function directly, and it works, and there's no casting involved. I leave it as an exercise to the reader to figure out how they made that work.

Nick