www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How do I get the string-ized version of a template instantion name

reply "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.
May 07 2004
next sibling parent reply 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/
May 08 2004
parent reply "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.
May 08 2004
parent 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/
May 08 2004
prev sibling parent reply 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
May 08 2004
parent "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
May 08 2004