On Sat, Nov 5, 2011 at 2:30 PM, David Brown > A C++ template class for "_Fract" support would be straightforward to write, > and could easily support the formats in N1169. But it would be very hard to > do so in a way that generates small and fast code without resorting to > inline assembly for targets that have hardware support for such features.
is this some sort of "here an outlanding statement and you would have to prove a negative to prove me right" or do you have more factual evidence to back your statement? > As you say, it is possible that both could be supported - using a template > class to provide a generic solution, and using the C "_Fract" types for > specialized classes. The first step to that, however, is to allow the > standard C "_Fract" types to work in C++ as a gcc extension. > > The same principle applies to the decimal types and extended float types > supported by C. that is one possibility. However there is a difference between restricted "extension" and full fledged extensions. I can see how a restricted version would work in C++ as an extension, but I doubt that is what you want. I can also see how unrestricted extension (which you seemed to advocate) brings more headache where a library solution is seamless. Keeping adding builtin type specifiers to a language is not a sustainable and responsible way to grow a large language for the real world. I appreciate we may disagree on that point.
