• Matthew (23/23) May 07 2004 template Thing(T)
• J Anderson (13/36) May 08 2004 If I understand you correctly, you want to get the string type from the
• Matthew (12/52) May 08 2004 member
• J Anderson (4/84) May 08 2004 Parhaps a recursive template is the answer.
• Andy Friesen (21/49) May 08 2004 You can get pretty close with templates:
• Ivan Senji (26/75) May 08 2004 member

"Matthew" <matthew.hat stlsoft.dot.org> writes:

template Thing(T)
{
    class Thing
    {
    private:
        const char[] sm_componentName = "Thing";

    }
}

This means that I can use the componentName in mixins, member templates, member
functions (virtual or static), etc. for the construction of meaningful exception
reports.

However, it occured to me that it might also be desirable to get hold of a
stringized form of the parameterisation. Naturally, this could not be a manual
thing any longer, so what do we all think about some compile time function
stringize(T) where T is a type, rather than a value. It would look like the
following:

    const char[] stringize(T)

The return value would be a slice onto the same string literal inserted into the
link-unit (dyn lib / exe) by the linker. We'd have to live with it being
link-unit-local, as there's no practical way to make it be constant across
link-units. (At least non that I can think of.) But that's not really a problem,
as I can't think of any reason to want to use this for determining type
identity,
not when we have the typeof keyword.

J Anderson <REMOVEanderson badmama.com.au> writes:

Matthew wrote:

template Thing(T)
{
    class Thing
    {
    private:
        const char[] sm_componentName = "Thing";

    }
}

This means that I can use the componentName in mixins, member templates, member
functions (virtual or static), etc. for the construction of meaningful exception
reports.

However, it occured to me that it might also be desirable to get hold of a
stringized form of the parameterisation. Naturally, this could not be a manual
thing any longer, so what do we all think about some compile time function
stringize(T) where T is a type, rather than a value. It would look like the
following:

    const char[] stringize(T)

The return value would be a slice onto the same string literal inserted into the
link-unit (dyn lib / exe) by the linker. We'd have to live with it being
link-unit-local, as there's no practical way to make it be constant across
link-units. (At least non that I can think of.) But that's not really a problem,
as I can't think of any reason to want to use this for determining type
identity,
not when we have the typeof keyword.

If I understand you correctly, you want to get the string type from the 
type.  You can already do something like this using templates.

template stringize(T : bit) { char [] name() { return "bit"; } }
template stringize(T : byte) { char [] name() { return "byte"; } }

//Of course then you've got array types ect... but it could all be put 
into a standard lib.

use:
char [] name = stringize!(T).name();

You probably already knew that, I'm probably talking about something 
completely different.  Why did I say anything <g>

-- 
-Anderson: http://badmama.com.au/~anderson/

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c7i671$e8q$1 digitaldaemon.com...
 Matthew wrote:

template Thing(T)
{
    class Thing
    {
    private:
        const char[] sm_componentName = "Thing";

    }
}

This means that I can use the componentName in mixins, member templates,


member
functions (virtual or static), etc. for the construction of meaningful


exception
reports.

However, it occured to me that it might also be desirable to get hold of a
stringized form of the parameterisation. Naturally, this could not be a manual
thing any longer, so what do we all think about some compile time function
stringize(T) where T is a type, rather than a value. It would look like the
following:

    const char[] stringize(T)

The return value would be a slice onto the same string literal inserted into


the
link-unit (dyn lib / exe) by the linker. We'd have to live with it being
link-unit-local, as there's no practical way to make it be constant across
link-units. (At least non that I can think of.) But that's not really a


problem,
as I can't think of any reason to want to use this for determining type


identity,
not when we have the typeof keyword.

 If I understand you correctly, you want to get the string type from the
 type.  You can already do something like this using templates.

 template stringize(T : bit) { char [] name() { return "bit"; } }
 template stringize(T : byte) { char [] name() { return "byte"; } }

 //Of course then you've got array types ect... but it could all be put
 into a standard lib.

 use:
 char [] name = stringize!(T).name();

 You probably already knew that, I'm probably talking about something
 completely different.  Why did I say anything <g>

:)

It's easy, although tedious, to specialise templates for known types, but a
template can, in principle, have an infinite number of specialisations. Hence,
specialisation cannot be the answer. I need something only the language/compiler
can provide.

J Anderson <REMOVEanderson badmama.com.au> writes:

Matthew wrote:

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c7i671$e8q$1 digitaldaemon.com...
  

Matthew wrote:

    

template Thing(T)
{
   class Thing
   {
   private:
       const char[] sm_componentName = "Thing";

   }
}

This means that I can use the componentName in mixins, member templates,
      


member
  

functions (virtual or static), etc. for the construction of meaningful
      


exception
  

reports.

However, it occured to me that it might also be desirable to get hold of a
stringized form of the parameterisation. Naturally, this could not be a manual
thing any longer, so what do we all think about some compile time function
stringize(T) where T is a type, rather than a value. It would look like the
following:

   const char[] stringize(T)

The return value would be a slice onto the same string literal inserted into
      


the
  

link-unit (dyn lib / exe) by the linker. We'd have to live with it being
link-unit-local, as there's no practical way to make it be constant across
link-units. (At least non that I can think of.) But that's not really a
      


problem,
  

as I can't think of any reason to want to use this for determining type
      


identity,
  

not when we have the typeof keyword.

      

If I understand you correctly, you want to get the string type from the
type.  You can already do something like this using templates.

template stringize(T : bit) { char [] name() { return "bit"; } }
template stringize(T : byte) { char [] name() { return "byte"; } }

//Of course then you've got array types ect... but it could all be put
into a standard lib.

use:
char [] name = stringize!(T).name();

You probably already knew that, I'm probably talking about something
completely different.  Why did I say anything <g>
    

:)

It's easy, although tedious, to specialise templates for known types, but a
template can, in principle, have an infinite number of specialisations. Hence,
specialisation cannot be the answer. I need something only the language/compiler
can provide.
  

Parhaps a recursive template is the answer.

-- 
-Anderson: http://badmama.com.au/~anderson/

Andy Friesen <andy ikagames.com> writes:

Matthew wrote:

 template Thing(T)
 {
     class Thing
     {
     private:
         const char[] sm_componentName = "Thing";
 
     }
 }
 
 This means that I can use the componentName in mixins, member templates, member
 functions (virtual or static), etc. for the construction of meaningful
exception
 reports.
 
 However, it occured to me that it might also be desirable to get hold of a
 stringized form of the parameterisation. Naturally, this could not be a manual
 thing any longer, so what do we all think about some compile time function
 stringize(T) where T is a type, rather than a value. It would look like the
 following:
 
     const char[] stringize(T)
 
 The return value would be a slice onto the same string literal inserted into
the
 link-unit (dyn lib / exe) by the linker. We'd have to live with it being
 link-unit-local, as there's no practical way to make it be constant across
 link-units. (At least non that I can think of.) But that's not really a
problem,
 as I can't think of any reason to want to use this for determining type
identity,
 not when we have the typeof keyword.

You can get pretty close with templates:

template stringize(T : bit)
{ char[] stringize() { return "bit"; } }
// yadda yadda for all primitive types

template stringize(T : Object)
{ char[] stringize() { return T.classinfo.name; } }
template stringize(T : T[])
{ char[] stringize() { return .stringize!(T) ~ "[]"; } }
template stringize(T, U : T[U]) // is this syntax correct?
{ char[] stringize() { return
     .stringize!(T)() ~ "[" ~ .stringize!(U) ~ "]";
} }

// if it doesn't match anything above, it must be a struct
template stringize(T) {
     char[] stringize() { return "some struct I dunno"; }
}

(excuse the horrid use of whitespace)

That last bit suggests that it's not quite right, but it's pretty close! 
  A 'name' property on structs would seal it.

  -- andy

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Andy Friesen" <andy ikagames.com> wrote in message
news:c7j26i$1lvi$1 digitaldaemon.com...
 Matthew wrote:

 template Thing(T)
 {
     class Thing
     {
     private:
         const char[] sm_componentName = "Thing";

     }
 }

 This means that I can use the componentName in mixins, member templates,


member
 functions (virtual or static), etc. for the construction of meaningful


exception
 reports.

 However, it occured to me that it might also be desirable to get hold of


a
 stringized form of the parameterisation. Naturally, this could not be a


manual
 thing any longer, so what do we all think about some compile time


function
 stringize(T) where T is a type, rather than a value. It would look like


the
 following:

     const char[] stringize(T)

 The return value would be a slice onto the same string literal inserted


into the
 link-unit (dyn lib / exe) by the linker. We'd have to live with it being
 link-unit-local, as there's no practical way to make it be constant


across
 link-units. (At least non that I can think of.) But that's not really a


problem,
 as I can't think of any reason to want to use this for determining type


identity,
 not when we have the typeof keyword.

 You can get pretty close with templates:

 template stringize(T : bit)
 { char[] stringize() { return "bit"; } }
 // yadda yadda for all primitive types

 template stringize(T : Object)
 { char[] stringize() { return T.classinfo.name; } }
 template stringize(T : T[])
 { char[] stringize() { return .stringize!(T) ~ "[]"; } }
 template stringize(T, U : T[U]) // is this syntax correct?

i was just wondering how to do that because i'm trying
to write a IsAssociativeArray template and this syntax is compiled
but it doesn't work.
I have
template IsAssociativeArray (T,U : T[U])
{
    bit IsAssociativeArray = true;
}
template IsAssociativeArray (T)
{
    bit IsAssociativeArray = false;
}

but what ever type i pass to this template the result is allways false.
Maybe a bug?

 { char[] stringize() { return
      .stringize!(T)() ~ "[" ~ .stringize!(U) ~ "]";
 } }

 // if it doesn't match anything above, it must be a struct
 template stringize(T) {
      char[] stringize() { return "some struct I dunno"; }
 }

 (excuse the horrid use of whitespace)

 That last bit suggests that it's not quite right, but it's pretty close!
   A 'name' property on structs would seal it.

   -- andy