• "Matthew" <matthew.hat stlsoft.dot.org> May 07 2004
• J Anderson <REMOVEanderson badmama.com.au> May 08 2004
• "Matthew" <matthew.hat stlsoft.dot.org> May 08 2004
• J Anderson <REMOVEanderson badmama.com.au> May 08 2004
• Andy Friesen <andy ikagames.com> May 08 2004
• "Ivan Senji" <ivan.senji public.srce.hr> May 08 2004

"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,




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




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




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




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




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,
      




  

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




  

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
      




  

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
      




  

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




  

not when we have the typeof keyword.

      


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.
  



-- 
-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,




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




 reports.

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




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




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




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




 following:

     const char[] stringize(T)

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




 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




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




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




 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