On Apr 16, 7:19 am, Daniel Krügler <daniel.krueg...@[EMAIL PROTECTED]
>
wrote:
> On 15 Apr., 05:24, Alberto Ganesh Barbati <AlbertoBarb...@[EMAIL PROTECTED]
>
> wrote:
>
> > I also don't find it compelling to require that the string literal
> > appears as the last argument. Although I understand the intent, I
don't
> > think the requirement provides a true simplification for the
> > implementor, yet it may limit some possibly valid uses. Moreover, if
we
> > find the proper wording, we might even allow string literals to match
> > non-variadic templates. For example, consider a library component
> > implementing a FourCC (http://en.wikipedia.org/wiki/Fourcc):
>
> > template <char A, char B, char C, char D> class FourCC
>
> > FourCC<"RIFF"> riff; // ok: maps to FourCC<'R', 'I', 'F', 'F'>
>
> > isn't that neat? Of course, FourCC<"RIF"> and FourCC<"RIFFF"> would be
> > ill-formed. The key is to simply replace the literal with the sequence
> > of single characters and then apply the "normal" template machinery.
>
> I think that this extension proposal goes to far
> and that there exist an alternative given concepts
> to realize the same thing.
>
> The problem I see is, that this approach might seem
> natural for human tolerant pattern matching, but it
> is not so well-situated for the compiler. It seems
> natural for human beings, because it bases on some
> form of convention: "Just assume that all template
> parameters are non-type parameters and each one has
> the same type and this type must be a character type".
>
I think that is not a problem, am I missing something obvious?
So far i was not able to construct example when proposed aproach would
be overly expensive. It tends to be rather simple tree subsitution.
Compiler logic needed for that is already present
to handle variadic argument pack expansion.
I have made hackish implementation of this, which includes
Alberto Ganesh Barbati extension to proposal, for gcc compiler.
It still needs some `love'. Maybe soon i will find real time to work
on that.
It seems that my orginal proposal is slightly harder to implement (in
gcc), one would have to check just if there is parameter pack in
template parameter list too.
Following example shows status of this patch (and it Works For Me TM):
#include <iostream>
template <char... Chars_>
struct Foo {
static const char chars[sizeof...(Chars_)+1];
};
template <char...Chars_>
const char
Foo<Chars_...>::chars[sizeof...(Chars_)+1] = {Chars_...};
template <char B_, char A_, char R_, char Term_>
struct Bar
{
static const char chars[4];
};
template <char B_, char A_, char R_, char Term_>
const char
Bar<B_, A_, R_, Term_>::chars[4] = {B_, A_, R_, Term_};
int main()
{
std::cout << Foo<"foo", '\0'>::chars << std::endl;
std::cout << Bar<"bar", '\0'>::chars << std::endl;
}
Compile with -std=c++0x -fstring-template-arguments
The know deficiencies are:
- doesn't handle wide literals (should be easy),
and unicode literals (not in gcc yet)
- I should re****t error in case of "" or L""
- definitly needs testing (DejaGNU here I come!)
- and do***entation...
But overall, it should be enough to see how it feels.
I am not sure if default template arguments should be sup****ted ie:
template <char... Chars_ = "Oink!">
struct Foo;
Comments welcome :)
Note that, this was first time i've seen gcc sources...
For brave people, patch against gcc trunk, revision 134411
http://doppler.no-ip.org/~prak/fstring-template-arguments.patch
Piotr Rak
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
