template won't compile - C2975

[Amn]

Why doesn't Microsoft Visual C++ 7.0 want to compile this template:

template<char* p> class A
{
public:

char* f() { return p; }
};

A<"helo"> obj;


I get compiler error C2975 which briefly states that template needs a constant parameter for instantiation. Now, isnt "helo" a const design-time evaluated entity ?

I consider this another one of the "yet unimplemented" template features...sucks

has any of you come across c2975 before ?

Thanks,
Amn.

[Yves M]

This is a very strange use of templates... You use them for classes or types, but not for constant strings...

What you are trying to do is better done with a non-templated class that has a constructor that takes a char *...

[Amn]

Well, this is just an example which points out that MSVC++ 7.0 doesnt treat "helo" as a constant, or gives C2975 error nevertheless.

If you need a justfiyment for the use of constant strings for templates here is one:

template<LPCTSTR strClassName>
class win32window
{
public:

HWND create(...)
{ return ::CreateWindow(strClassName, ...); }
};

Like that, simple wrapper for system defined window classes.

BUt no, MSVC++ wont compile this..

Thanks for reply anyway... do you know if the error is a bug or what ?

[Graham]

You can't use a string literal as the argument to a char* template parameter. Sorry, but that's the standard.

char hi[] = "hello";

A<hi> obj;

should work, IIRC.

[Graham]

Just seen your reply to Yves. You can't blame Micro$oft, this time, I'm afraid - the complier is correct to reject your code.

[Amn]

Hmm, any is this because of the stack placement in case of "helo" and data segment placement in case of hi[] ? Otherwise i dont know why i can use the constant hi[] and cannot use constant "helo". Can you please refer me to a standard article pointing the issue out ?

Thanks,

[PaulWendt]

Your question was already answered a few days ago:

http://www.codeguru.com/forum/showth...hreadid=210848

Edit: I guess a few people replied before me. I also want to point
out that Paul McKenzie quoted some relevant material from the
standard.

--Paul

[Amn]

Thanks A LOT everyone. a true help is given to me

Reading the standard now... guess this is exactly because stack unwinding of literals prevents correct template class operation...

[Yves M]

If you need a justfiyment for the use of constant strings for templates here is one:

template<LPCTSTR strClassName>
class win32window

Interesting, I'll go to bed less stupid today

[Amn]

Why do you think it is a stupid approach ? =]

* Just speaking between us two (and the rest of the community)*

[Graham]

Originally posted by PaulWendt
Your question was already answered a few days ago:

http://www.codeguru.com/forum/showth...hreadid=210848

Edit: I guess a few people replied before me. I also want to point
out that Paul McKenzie quoted some relevant material from the
standard.

--Paul

I would have sworn that I read that thread on comp.lang.c++.moderated, or I'd have looked for and quoted it myself. Thanks, Paul.

[Yves M]

Originally posted by Amn
Why do you think it is a stupid approach ? =]

* Just speaking between us two (and the rest of the community)*

No no, what I meant was that this seems like a valid use of templates

Although I'm still not quite sure that it's really useful to put constants into template parameters. I mean, writing a template based class is not the nicest thing as you can't program with .cpp files and have to implement everything in the .h file (with current compilers). If all I had to use were a constant as template parameter, I would prefer to use a constructor with a parameter instead.

The most compelling reason for me to avoid uneccessary templates is that intellisense for VC doesn't work in h files :/

[Amn]

OMG, i read your comment as "i ll go to BE less stupid today", something that made me go questionmarks funny, i read it again only now and realised it...OMG OMG OMG OMG

sorry man

Well of course nobody would use templates if a constructor parameter option is available instead hihi...it was a dumb example of me LOL

But i guess it could be useful to use window class templates to describe already defined WNDCLASSEX structures, which are stored in internal Windows registries. I mean

window<"EDIT">
window<"MDIClient">
window<"TREE">
window<"RICHEDIT">

etc.

Because since GUI is advancing so fast these days, and new controls appear all the time, it is a better thing to do then having to create a new class derived from window just to change classname parameter in constructor/create routine.


Thanks for your help once again,
and thanks everybody else on the message board who helped me out with the template thingie

[Yves M]

what I meant is that you would use
pwindow = new window("EDIT");
pwindow = new window("RICHEDIT");

etc... instead of the template parameter

[Amn]

Yes i considered that an option.

If you are willing to discuss this topic further before we are closed, i can say following:

It is a part of my framework which is supposed to be very thin layer over win32. And i earlier discarded that option "pWindow = new window("EDIT")", not because it is bad or something, in fact it is very straightforward, but the goal is to somehow blend win32 naked API and C++ OO design. It is a tough thing to do, since win32 suggests window classes ARE objects (run-time memory structures), and C++ does treat classes as objects only when a programmer designs them, and only basic RTTI is available. Again, Win32 allows individual windows to branch off their class behavior by means of SUBCLASSING, something that a C++ class would strongly object
since class member are not properties of its objects but simply functions which take a "this" pointer under the hood.

So basically i will break my head little longer than expected, but in the end if the idea of blending C++ and Win32 turns out to be NUTS, i will go for the constructor style approach as you suggested.

Yves, please note that I specifically write this framework to blend Win32 and C++, because this will allow developers to think native language OO design, and less handles and subclassing (which in C++ is inheritance). I do not say "forget Win32 API", but since we are programming in C++, which saves time, this whole thing might be good to do.

Anyway, i know i am a blabbermouth, but i hope someone will benefit from this.