Improve Layout argv handling with gdc

Doesn't compile on x86-64:

<...>/include/d/4.1.3/tango/text/convert/Layout.d:98: Error: cannot have out or ref parameter of type __va_list_tag [1LU]

(gdc (GCC) 4.1.3 20070831 (prerelease gdc 0.25, using dmd 1.021) (Ubuntu 0.25-4.1.2-16ubuntu1))

That "static if (is(typeof(args.ptr)))" was added on my suggestion. On x86-64 GDC typeof(args) is an array type, which is the reason for both that static if and for the error message I pasted above. (See also #1029 and the commits associated with it)

using "ref va_list" instead of "inout va_list" should fix the issue whan va_list is an array. I still strongly suspect that

                            arglist[i] = args.ptr;

is wrong for all but the first argument.

Some previous tests suggests that the static if may be relevant for most 64 bit architectures.

As for the patch, could you please explain the purpose better? Does your usecase work with DMD out of the box?

fawzi: ref and inout are, AFAIK, equivalent in all cases. Either way, the compiler error is exactly the same if I change inout to ref.

And the old code (including arglist[i] = args.ptr;) works fine even for > 1 argument. If you suspect otherwise I suggest you obtain access to an x86_64 machine or emulator and try to prove it.

Indeed the code arglist[i] = args.ptr; is wrong for all arguments but the first (I tested on AMD64), the whole routine works because the code after the if is still executed and overwrites the value.

Here is patch that works on both X86-64 and darwin, the idea is to replace the fixed sizes that where checked in the previous version with a template that checks up to a easy changeable size, now set to 64 bytes.

This way I will be able to print again arrays of the multiarray library that have a size of 32 bytes (the old code accepted just 1,2,4,8,16 as sizes, and the size 16 was wrong depending of the architecture (void[]).sizeof is not 16 on all architectures, it can be also 8.

That version seems to work better. And better struct support is pretty nice. And yes, after some more testing the current svn version does seem to be broken; structs with floating-point values in them don't work properly, for instance. (I guess I didn't notice this earlier because I hardly ever use floats)

However, the same holds for small structs in your version:

import tango.io.Stdout;
import tango.text.convert.Format;

struct T {
    double d = 2;
    char[] toString() {
        return Format.convert("{{{}}", d);
    }
}

void main() {
    T test;
    Stdout.formatln("{}", test.sizeof);
    Stdout.formatln("{}\n{}\n{}", test, test, test);
}

Output (with the new patch):

8
{0.24e-309}
{0.00}
{0.24e-309}

(The problem is that floating-point fields of such structs are passed in xmm* registers)

That said, your code is better for some otherwise unsupported struct types (specifically, > (void[]).sizeof without floating-point values). It's just that GDC varargs are a mess because it uses the C vararg ABI.

P.S.: You may want to reconsider putting your code between Layout and its doc-comment :P.

Depends on http://d.puremagic.com/issues/show_bug.cgi?id=2004

I gave a look at variadic templates, as these don't have the bugs of var_arg. I put my findings here as it might be relevant for some possible future refactorings.

It is easy to create a wrapper that uses variadic templates, with something like this

template Nargs(){
    const int Nargs=0;
}
template Nargs(T,U...){
    const int Nargs=1+Nargs!(U);
}
template mf(U...){
void mf(U args){
    const int nargs=Nargs!(U);
    void *[nargs] aPtrs;
    TypeInfo[nargs] aTis;
    foreach(i,a;args){
        aPtrs[i]=cast(void*)&a;
        aTis[i]=typeid(U[i]);
    }
    return printArgs(aPtrs,aTis);
}
}

This is all stack based, and has no limit on the number of arguments. A convert call can be converted to this. What is more difficult is to have different functions based on the first arguments. Actually using static ifs I managed to handle the different inputs, but not the different return types.

I think that at the moment with the current interface (all public) it isn't possible. The heavy overloading makes it difficult, on should use at least two names: convert and convertSync.

Fawzi

slightly cleaned up patch