The problem with string literals extends to variables as well, i
believe. AFAIK, the only things valid for a template's arguments are
type or class names. (not variables, objects, or literals of any type)
This causes some problems for a few of the methods mentioned below,
with the exception of the macro-based one.
Dave
On 6/17/06, Michael D. Adams <[EMAIL PROTECTED]> wrote:
> On 6/17/06, Marten Svanfeldt <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Intresting idea, and it would be nice if it worked. However there are
> > a few problems with it,
> >
> > Quoting "Michael D. Adams" <[EMAIL PROTECTED]>:
> >
> > > template<char* name> class csNullEventHandlerNames0 { ... };
> > > template<char* name, typename T1> class csNullEventHandlerNames1 :
> > > public T1 { ... };
> > >
> > > These would be used as follows.
> > >
> > > class csFoo : public
> > > csNullEventHanderNames0<"crystalspace.module.name"> { ... };
> > > class csBar : public
> > > csNullEventHanderNames1<"crystalspace.module.name"> { ... };
> >
> > Unfortunatly this is not legal C++. You cannot specialize a char*
> > template parameter with a string literal. This is the only reason we
> > still use a macro for SCF_INTERFACE and SCF_FACTORY.
> >
> > Given that this part breaks down I don't see how the rest of the
> > proposal can work properly, unfortunatly.
>
> I hadn't known that about C++, but I did some research and what you
> say is correct.
>
> I've been trying to think of alternatives that achieve the same effect
> with different mechanisms. None of them are great, but I'll present
> them here. Maybe they will spark some ideas or someone can refine
> them.
>
> We could instantiate the template with a string *variable* instead of
> a literal, but that probably wouldn't buy us very much. (The variable
> would need to have external linkage to keep the compiler happy about
> using it as template argument.)
>
> extern const char foo [] = "crystalspace.module.name";
> class csFoo : public csNullEventHandlerNames0<foo> { ... };
>
> We could pass the string as argument to the constructor. This assumes
> that all event handlers are used as instiantiated objects and not as
> static classes. It might also pose a maintinance problem to keep
> multiple constructors in sync.
>
> class csFoo : public csNullEventHandlerNames0 {
> csFoo () : csNullEventHandlerNames0("crystalspace.module.name") { ... }
> ... };
>
> We could reduce the macro down to a type trait that contains the
> string. This would have just as many "magic" places as before though
> the magic would be "smaller magic".
>
> #define CS_EVENT_HANDLER_NAME(x) \
> struct EventHandlerTraits { \
> static const char* GetName() { return x; } \
> }
> class csFoo : public csNullEventHandlerNames0<csFoo> {
> CS_EVENT_HANDLER_NAME("crystalspace.module.name");
> ...
> };
>
> We could pass a csEventID as template argument instead of a string.
> This option is probably impossible as it would require partially
> populating the event name registry object at compile time.
>
> Brainstorming,
> Michael D. Adams
> [EMAIL PROTECTED]
>
>
> _______________________________________________
> Crystal-main mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/crystal-main
> Unsubscribe: mailto:[EMAIL PROTECTED]
>
--
Lead Programmer
G33X Nexus Entertainment
http://games.g33xnexus.com/precursors/
v3sw5/7Hhw5/6ln4pr6Ock3ma7u7+8Lw3/7Tm3l6+7Gi2e4t4Mb7Hen5g8+9ORPa22s6MSr7p6
hackerkey.com
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
