Giving NULL value to non-type template parameter

Hi,

I want to give default value as NULL/0 for non-type template
parameter. I using SunStudio on Linux. I have tried following:

#define non_closer ((int(*)(FILE*))0L)

template<class T, int F(FILE*) = non_closer>

but compiler throws error:

error: '0u' is not a valid template argument for type 'int (*)(FILE*)'
because function '#'integer_cst' not supported by
dump_decl#<declaration error>' has not external linkage

Any idea how can I get this working?

Thanks in advance,
-Neel.

neelsmail@rediffmail.com wrote:The 'F' looks like a function. Perhaps you ought to use (*F) for that?
Just a wild guess...
Try dropping the 'L' after the 0.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Thanks for the reply.

On Jul 21, 7:14*pm, Victor Bazarov <v.Abaza...@comAcast.netwrote:Even with *F, I get the same error: "'0u' is not a valid template
argument for type 'int (*)(FILE*)' because function '#'integer_cst'
not supported by dump_decl#<declaration error>' has not external
linkage". Is there a way to find out whether this is a SunStudio
compiler specific problem?
Yes, that was incorrect; although even without L I get the same
errors.

Thanks for your help,
-Neel.

neelsmail@rediffmail.com wrote:I just tried the following with two compilers, they both accepted it.

#define zero (int(*)(int))0

template<class T, int (*F)(int) = zerostruct foo
{
void bar(T t) { if (F) F(666); }
};

int main() {
foo<intfi;
fi.bar(42);
}

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On Jul 21, 10:41*pm, Victor Bazarov <v.Abaza...@comAcast.netwrote:Thanks again. Even with code you have given I couldn't get compiler to
stop complaining. I found couple of articles that may explain why:

http://gcc.gnu.org/ml/gcc-help/2005-12/msg00069.html
http://www.mail-archive.com/gcc@gcc..../msg15341.html

Finally, I had to rewrite the code:

template<class T, const bool Close = true, int Closer(FILE*) = fclose>
ATemplate {

static int DontClose(FILE*) {
return 0;
}

public:

ATemplate(FILE* fp):shared_ptr<FILE*>(fp, Close? Closer : DontClose)
{}
};

I will try this on MS VC 7/8, let's see if it works there..

Thanks,
-Neel.

On Jul 21, 4:01 pm, neelsm...@rediffmail.com wrote:
Wait for C++0x.

The current version of the standard specifically states that
this is illegal. The committee apparently had a change of
heart, however, and the current draft has been changed to
explicitly allow the case.

In the meantime, you'll have to define a dummy function, and
take its address, e.g.:

int non_closer( FILE* ) {}

template< typename T, int (*F)( FILE* ) = &non_closer >

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 21, 4:14 pm, Victor Bazarov <v.Abaza...@comAcast.netwrote:It would certainly be cleaner. It shouldn't make any
difference, however: "A non-type template-parameter of type
"array of T" or "function returning T" is adjusted to be of type
"pointer to T" or "pointer to function returning T",
respectively."

(Why is it that every time I see such type adjustments, I'm
reminded of a verse by Sir Walter Scott:
Oh what a tangled web we weave
When first we practice to deceive.
.)
What would that change. Both 0 and 0L are legal "integral
constant expressions evaluating to 0", and so null pointer
contants.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 21, 10:20 pm, neelsmail@rediffmail.com wrote:It's illegal according to C++03. Maybe the compilers are
jumping the gun, and have already implemented this feature of
C++0x. (Or maybe the fact that most compilers accepted it was
the motivation for adding it to C++0x.)
I don't see any relationship in them to the problem at hand.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34