On 09/19/2010 02:37 PM, Rodrigo Rivas wrote:
Maybe Rodrigo would be interested in collaborating on this work?
Sure I am! Please, let me a couple of days to re-read the C++ draft,
and check this patch.
Also, take in account that I'm in no way a GCC expert... but I'll do my best.
Also I have a little patch on my own that might use some help... But
this is for another post.
Regards.
--
Rodrigo
I would be delighted to collaborate.
I got over my initial hump using a more generic lookup (like the
standard says). I'll make another patch over the next day or two
.
I can parse strings: "sluggo"_xyz, u"facebeef"_LL, etc.
I can parse the various char types: 'x'_foo etc.
I'm looking at (besides input on what I've got currently):
1. A warning or error if a user chooses a suffix that gcc uses. I was
surprised that 'w', 'q', 'i', 'j' and several others were used by gcc
for floats. I won't be the only one. The standard is clear that
implementations get first crack at these but it shouldn't be a mystery
or a surprise when things don't work as expected.
2. Should we at least pedwarn about user not starting a suffix with an
underscore? Probably. Non-underscore suffixen are reserved to the
implementation but I think a user should be able to use one if it's not
used by gcc though the user risks non-portability and potential but
unlikely future breakage.
3. The big one: Getting the integer(long long) and float(long double)
suffixes that are not used by gcc out of the preprocessor. Then we can
build the calls.
4. If, for long long and long double the usual signature is not found,
first look for a: _suffix(char*) and failing that: template<char...>
_suffix(). So we'll need to make the lookup of these two signatures
more complex.
