Jump to page: 1 2
Thread overview
typeinfo[] construction
Nov 14, 2005
Kris
Nov 14, 2005
pragma
Nov 14, 2005
Kris
Nov 14, 2005
Sean Kelly
Nov 15, 2005
Kris
Nov 15, 2005
Sean Kelly
Nov 15, 2005
Kris
Nov 15, 2005
Sean Kelly
Nov 15, 2005
Georg Wrede
Nov 15, 2005
kris
Nov 15, 2005
Sean Kelly
November 14, 2005
How does one construct & expose a typeinfo array, plus the corresponding arg array, without actually calling a function? Is there a neat template trick to do this? Without allocating from the heap? Appreciate any suggestions.


November 14, 2005
In article <dlat7b$cpr$1@digitaldaemon.com>, Kris says...
>
>How does one construct & expose a typeinfo array, plus the corresponding arg array, without actually calling a function? Is there a neat template trick to do this? Without allocating from the heap? Appreciate any suggestions.

Well, nothing that qualifies as 'neat' anyway (you've probably been down this road before).  You could roll a set of templates that accomodate up to n types:

> template TypeinfoList(T1, T2, T3){
> 		static const TypeInfo[] TypeinfoList =[
> 			typeid(T1),
> 			typeid(T2),
> 			typeid(T3)
> 		];
> }

(BTW, anybody willing to draft up a template-vararg specification?)

So yea, the above template keeps the data off of the heap and works great.  As for "the corresponding arg array", I'm don't know what you're after.  Maybe you could hit me with some pseudocode or a use-case?

- EricAnderton at yahoo
November 14, 2005
Thanks Eric;

What I'm looking for is an inline version of the _arguments & _argptr pair that one has access to within a variadic-parameter function. That is, to construct the equivalent of _arguments & _argptr on the fly.

What you illustrate below is partway there. In a similar vein, is it possible to do /something/ like this:

template TypeInfoList()
{
  TypeInfo[] TypeInfoList (...) {return _arguments;}
}

auto ti = TypeInfoList!(7, 3.14159, "foo", x, y, z);



"pragma" <pragma_member@pathlink.com> wrote in message news:dlb435$17i0$1@digitaldaemon.com...
> In article <dlat7b$cpr$1@digitaldaemon.com>, Kris says...
>>
>>How does one construct & expose a typeinfo array, plus the corresponding
>>arg
>>array, without actually calling a function? Is there a neat template trick
>>to do this? Without allocating from the heap? Appreciate any suggestions.
>
> Well, nothing that qualifies as 'neat' anyway (you've probably been down
> this
> road before).  You could roll a set of templates that accomodate up to n
> types:
>
>> template TypeinfoList(T1, T2, T3){
>> static const TypeInfo[] TypeinfoList =[
>> typeid(T1),
>> typeid(T2),
>> typeid(T3)
>> ];
>> }
>
> (BTW, anybody willing to draft up a template-vararg specification?)
>
> So yea, the above template keeps the data off of the heap and works great.
> As
> for "the corresponding arg array", I'm don't know what you're after.
> Maybe you
> could hit me with some pseudocode or a use-case?
>
> - EricAnderton at yahoo


November 14, 2005
Kris wrote:
> How does one construct & expose a typeinfo array, plus the corresponding arg array, without actually calling a function? Is there a neat template trick to do this? Without allocating from the heap? Appreciate any suggestions. 

Possible, I think, but likely somewhat messy.  One of the problems I ran into while playing with this is that template specialization fails if you try to operate solely on parameter type.  ie.

	template TI(int v) { ... }
	template TI(char v) { ... }

	TI!('a');

is ambiguous.  As is:

	TI!(cast(char)'a');

You could get around this by building your parameter list like so:

	alias TI!(int,1, TI!(char,'a', Empty)) TwoParams;

Which I suppose could be simplified to:

	alias MakeParams!(int,1, char,'a') TwoParams;

But this still feels a tad clunky.  It's worth noting that this doesn't manage to resolve the ambiguity either:

	struct Set1
	{
	    const int  p1 = 1;
	    const char p2 = 'a';

	    alias MakeParams!(p1,p2) Params;
	}

However, Don's approach does, at the risk of being even more verbose:

	template p1() { const int p1 = 1;    }
	template p2() { const char p2 = 'a'; }

	alias MakeParams(p1,p2) Params;

Note that in this last example, the template parameters for MakeParams must be aliases, ie.

	template MakeParams(alias p1, alias p2) {...}

What problem are you trying to solve? :-)  I think this could be worked into something usable, but it may be easier with a specific goal in mind.


Sean
November 15, 2005
Thanks, Sean.

Looking at it more closely, I'm not sure if it's really possible. Here's a rough, but compilable, example of what I getting at:

struct S {TypeInfo[] ti; void* args;}

template Foo(T = S)
{
        S Foo(...)
        {
                S s;
                s.ti = _arguments;
                s.args = _argptr;
                return s;
        }
}

void main()
{
        auto list = Foo!()(1, 2, 3, 4);

        // do something with list.args & list.ti
}

But that leaves pointers into potentially invalid stack space. Any further ideas?





"Sean Kelly" <sean@f4.ca> wrote in message news:dlb5f1$1c1p$1@digitaldaemon.com...
> Kris wrote:
>> How does one construct & expose a typeinfo array, plus the corresponding arg array, without actually calling a function? Is there a neat template trick to do this? Without allocating from the heap? Appreciate any suggestions.
>
> Possible, I think, but likely somewhat messy.  One of the problems I ran into while playing with this is that template specialization fails if you try to operate solely on parameter type.  ie.
>
> template TI(int v) { ... }
> template TI(char v) { ... }
>
> TI!('a');
>
> is ambiguous.  As is:
>
> TI!(cast(char)'a');
>
> You could get around this by building your parameter list like so:
>
> alias TI!(int,1, TI!(char,'a', Empty)) TwoParams;
>
> Which I suppose could be simplified to:
>
> alias MakeParams!(int,1, char,'a') TwoParams;
>
> But this still feels a tad clunky.  It's worth noting that this doesn't manage to resolve the ambiguity either:
>
> struct Set1
> {
>     const int  p1 = 1;
>     const char p2 = 'a';
>
>     alias MakeParams!(p1,p2) Params;
> }
>
> However, Don's approach does, at the risk of being even more verbose:
>
> template p1() { const int p1 = 1;    }
> template p2() { const char p2 = 'a'; }
>
> alias MakeParams(p1,p2) Params;
>
> Note that in this last example, the template parameters for MakeParams must be aliases, ie.
>
> template MakeParams(alias p1, alias p2) {...}
>
> What problem are you trying to solve? :-)  I think this could be worked into something usable, but it may be easier with a specific goal in mind.
>
>
> Sean


November 15, 2005
Kris wrote:
> Thanks, Sean.
> 
> Looking at it more closely, I'm not sure if it's really possible. Here's a rough, but compilable, example of what I getting at:
> 
> struct S {TypeInfo[] ti; void* args;}
> 
> template Foo(T = S)
> {
>         S Foo(...)
>         {
>                 S s;
>                 s.ti = _arguments;
>                 s.args = _argptr;
>                 return s;
>         }
> }
> 
> void main()
> {
>         auto list = Foo!()(1, 2, 3, 4);
> 
>         // do something with list.args & list.ti
> }
> 
> But that leaves pointers into potentially invalid stack space. Any further ideas?

The templates in your example really aren't necessary, given what the code is doing, so assuming it's okay for this stuff to be sorted out at run-time, perhaps you should simply focus on copying the _arguments array and _argptr data to the heap.  Here's a quick go at it that seems to work:

import std.c.stdio;
import std.c.string;

struct ParamList
{
    TypeInfo[]  info;
    void*       args;
}

ParamList getParamList( ... )
{
    ParamList   list;
    size_t      size = 0;

    list.info = _arguments.dup;
    foreach( TypeInfo t; _arguments )
        size += t.tsize();
    list.args = new ubyte[size];
    memcpy( list.args, _argptr, size );
    return list;

}

void main()
{
    ParamList list = getParamList( 1, 2, 3 );
    for( int i = 0; i < 3; ++i )
        printf( "%i\n", cast(int) (cast(int*)list.args)[i] );
}
November 15, 2005
Thanks again, Sean.

Was hoping to construct the list at compile time, and avoid the heap allocation. D apparently cannot populate non-static arrays of any type, let alone variable type. Seems I was hoping for too much :-(




"Sean Kelly" <sean@f4.ca> wrote in message news:dlbmt8$2k0i$1@digitaldaemon.com...
> Kris wrote:
>> Thanks, Sean.
>>
>> Looking at it more closely, I'm not sure if it's really possible. Here's a rough, but compilable, example of what I getting at:
>>
>> struct S {TypeInfo[] ti; void* args;}
>>
>> template Foo(T = S)
>> {
>>         S Foo(...)
>>         {
>>                 S s;
>>                 s.ti = _arguments;
>>                 s.args = _argptr;
>>                 return s;
>>         }
>> }
>>
>> void main()
>> {
>>         auto list = Foo!()(1, 2, 3, 4);
>>
>>         // do something with list.args & list.ti
>> }
>>
>> But that leaves pointers into potentially invalid stack space. Any further ideas?
>
> The templates in your example really aren't necessary, given what the code is doing, so assuming it's okay for this stuff to be sorted out at run-time, perhaps you should simply focus on copying the _arguments array and _argptr data to the heap.  Here's a quick go at it that seems to work:
>
> import std.c.stdio;
> import std.c.string;
>
> struct ParamList
> {
>     TypeInfo[]  info;
>     void*       args;
> }
>
> ParamList getParamList( ... )
> {
>     ParamList   list;
>     size_t      size = 0;
>
>     list.info = _arguments.dup;
>     foreach( TypeInfo t; _arguments )
>         size += t.tsize();
>     list.args = new ubyte[size];
>     memcpy( list.args, _argptr, size );
>     return list;
>
> }
>
> void main()
> {
>     ParamList list = getParamList( 1, 2, 3 );
>     for( int i = 0; i < 3; ++i )
>         printf( "%i\n", cast(int) (cast(int*)list.args)[i] );
> }


November 15, 2005
Kris wrote:
> Thanks again, Sean.
> 
> Was hoping to construct the list at compile time, and avoid the heap allocation. D apparently cannot populate non-static arrays of any type, let alone variable type. Seems I was hoping for too much :-(

I still think this might be possible, but doing so seems nontrivial.  I foresee some char string voodoo ala Don's itoa example to build the _argptr data segment, and the syntax to construct the list wouldn't be quite as painless.  Unless there's a pressing reason to do this at compile-time it's probably not worth the trouble :-)  You can always initialize this stuff on module load anyway.


Sean
November 15, 2005
Kris wrote:
> D apparently cannot populate non-static arrays of any
> type, let alone variable type. Seems I was hoping for too much :-(

I'm not sure, but I'd be thoroughly amazed if that was possible, even in theory.

Non-static in itself implies runtime, right?

That in turn implies heap allocation, right?

And at compile time we don't even have that heap, right?
November 15, 2005
Georg Wrede wrote:
> Kris wrote:
> 
>> D apparently cannot populate non-static arrays of any
>> type, let alone variable type. Seems I was hoping for too much :-(
> 
> 
> I'm not sure, but I'd be thoroughly amazed if that was possible, even in theory.
> 
> Non-static in itself implies runtime, right?

Yes and no. Theoretically, the space required can be allocated upon the stack. Optionally the TypeInfo[] noted can be constructed and populated at compile time also. What's left is the population of the _arptr value array: that would be done at runtime; but inline.

> 
> That in turn implies heap allocation, right?

In this case, I was looking for a way to get these on the stack.

> 
> And at compile time we don't even have that heap, right?

« First   ‹ Prev
1 2