This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Sat, Nov 5, 2011 at 2:30 PM, David BrownA 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?
int8_t multShortFract(int8_t a, int8_t b) { int16_t c = (int16_t) a * b; return (c >> 7); }
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |