Re: Template parameter visibility in specialization
On 2012-02-15 02:22, Vidar Hasfjord wrote:
On Feb 12, 12:33 am, Daniel Kr?gler<daniel.krueg...@googlemail.com>
wrote:
I would find it *very* astonishing and problematic, if renaming
the parameter name of a primary template would have impact on a
specialization where this parameter would be somehow implied.
That is a good point. Although it is just stating a maintenance hazard
the other way around, I agree that this is worse.
A solution to both problems would be to allow an optional parameter
name in the specialization. For example:
template<int MessageId>
struct TDispatch;
template<> struct TDispatch<MessageId = 42> // Proposed feature.
{
enum {Id = MessageId}; // Id is 42.
};
int main()
{return TDispatch<42>::Id;}
Except for possible syntax and parsing problems, do you see any
problem with this solution?
Not immediately, but there could be a quite a lot of wording needed for
little advantage (see below for an alternative solution with current
means). If your suggestion should be realized, the solution should be
more general, not just applicable to explicit specializations. E.g. it
would be great to have this combined with a similar proposal
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2881.html
The specialization TDispatch<42> is a class type, no class template anymore,
so why bother about names in a completely unrelated type family?
Sorry, I don't follow the logic of this in the context of the DRY
problem I stated.
My question was pointing to the fact, that a specialization is
independent from the primary template and there is no "name-sharing" to
be expected from the primary template at all. In other words: Your
original suggestion did conflict with all name lookup principles in C++
and would probably cause a lot of surprises and pitfalls as described in
my earlier reply.
Further, this mapping would very much depend on the kind of declaration
that the specialization sees [...]
Again, good point. My feature proposal above would deal with this
also.
Correct. On the other hand I have the feeling that your id registry is
actually inherently flawed, because it is *designed* to be redundant:
The problem is that you require user-code to register X with the value
X. This should not be necessary, IMO. The following shows an alternative
mechanism - also free of macros compared to my previous reply - that
solves your problems without any language extension:
template<int MessageId>
struct DispatchEnabler;
template <int MessageId>
struct TDispatch : DispatchEnabler<MessageId>
{
enum {Id = MessageId};
};
// DRY-free approach for registration:
template <> struct DispatchEnabler<42> {};
TDispatch<42> di1; // OK
TDispatch<43> di2; // Error, not registered
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]