David Brown writes:
> If the compiler can generate fractional arithmetic code directly
> from such expressions, then it is indeed a good step towards
> implementing such types as a pure C++ class without needing to use
> compiler extensions.
...
> I am not saying the compiler couldn't generate opt
On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote:
> > Making something involving new types - and so ABI impact - universal
> > without actually agreeing the ABI for each target with appropriate ABI
> > maintainers or interest groups for that target is not a good idea. It
> > leads to ABI incompatibil
On Tue, 8 Nov 2011, Joseph S. Myers wrote:
> On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote:
>
> > (yes, that's you cue. :) For acceptance, IMHO better get it
> > working universally by open-coding the implementation without
> > requiring --enable-* options.
>
> Making something involving new types
On Tue, 8 Nov 2011, Hans-Peter Nilsson wrote:
> (yes, that's you cue. :) For acceptance, IMHO better get it
> working universally by open-coding the implementation without
> requiring --enable-* options.
Making something involving new types - and so ABI impact - universal
without actually agree
On Tue, 8 Nov 2011, David Brown wrote:
> The guts of gcc already know about types like "signed short _Fract", and can
> handle them well (at least for some targets). It is always easier for the
Actually, I'd say they are handled badly. The approach of separate
machine modes for them going righ
On 08/11/2011 15:24, Hans-Peter Nilsson wrote:
(Not CC:ing the quoted newsgroup, sorry.)
On Tue, 8 Nov 2011, David Brown wrote:
If the compiler can generate fractional arithmetic code directly from such
expressions, then it is indeed a good step towards implementing such types as
a pure C++ cla
(Not CC:ing the quoted newsgroup, sorry.)
On Tue, 8 Nov 2011, David Brown wrote:
> If the compiler can generate fractional arithmetic code directly from such
> expressions, then it is indeed a good step towards implementing such types as
> a pure C++ class without needing to use compiler extension
On 08/11/2011 05:27, Hans-Peter Nilsson wrote:
On Sun, 6 Nov 2011, Joern Rennecke wrote:
Quoting David Brown:
Take an example using a processor I know well, the AVR (it is an 8-bit
device, which is a little unusual for gcc). It has an instruction will
multiply two "1.7" signed 8-bit integers
On Sun, 6 Nov 2011, Joern Rennecke wrote:
> Quoting David Brown :
>
> > Take an example using a processor I know well, the AVR (it is an 8-bit
> > device, which is a little unusual for gcc). It has an instruction will
> > multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
> > 16
On Sun, Nov 6, 2011 at 10:07 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> I think it would be very possible to have a general template library for C++
> that would handle a range of sizes and granularities. There would be a few
> combinations that would correspond to the C types. These wou
Quoting David Brown :
Take an example using a processor I know well, the AVR (it is an 8-bit
device, which is a little unusual for gcc). It has an instruction will
multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
16-bit integer - basically combining an 8-bit x 8-bit to 16-bi
On 6 November 2011 16:10, David Brown wrote:
> Perhaps I have been getting too worked up about small things here, and
> missing out on the major points, such as the efforts made to keep things
> consistent through the use of header files. I still find it odd that
> features are added in different
On Sun, 6 Nov 2011, David Brown wrote:
My original concern in this thread was that if the "r" and "k" _Fract
suffixes were freed for general use in C++, it would be difficult to use
them later.
The C++ standard already reserves all the suffixes that don't start with
an underscore for future
On 06/11/11 16:40, Jonathan Wakely wrote:
On 6 November 2011 15:03, David Brown wrote:
Obviously C++ is going to get features that C does not - that's fair
enough. But it is seldom that there is a good reason for C++ not supporting
the additions to C standards.
Some of the differences are ju
On 11/06/2011 10:40 AM, Jonathan Wakely wrote:
On 6 November 2011 15:03, David Brown wrote:
What usually happens is that if C has claimed a new keyword already
C++ will reuse it. When C++ has added a new keyword such as
static_assert the C committee has preferred to add keywords in the
reserve
On 6 November 2011 15:40, Jonathan Wakely wrote:
>
> I think a better example is atomics support in C++11 and C11, where
> std::atomic aka std::atomic_int can be exactly the same
> representation as _Atomic int and are compatible, but the C++ library
> solution also allows std::atomic which C doesn
On 6 November 2011 15:03, David Brown wrote:
> Obviously C++ is going to get features that C does not - that's fair
> enough. But it is seldom that there is a good reason for C++ not supporting
> the additions to C standards.
>
> Some of the differences are just mind-boggling - C1x has got a
> "_
On Sun, 6 Nov 2011, David Brown wrote:
> Some of the differences are just mind-boggling - C1x has got a
> "_Static_assert" addition, while C++11 has "static_assert". They do the same
> thing, but have a different keyword. Don't these people /talk/ to each other?
> Do they make differences like t
On 05/11/11 21:43, Gabriel Dos Reis wrote:
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 witho
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 ta
On 05/11/11 18:29, Ed Smith-Rowland wrote:
On 11/05/2011 08:36 AM, David Brown wrote:
On 04/11/11 20:35, 3dw...@verizon.net wrote:
Greetings,
Now that C++11 user-defined literals are in trunk I was thinking
about reclaiming some of the numeric suffixes that are currently
recognized by gcc in t
On 11/05/2011 08:36 AM, David Brown wrote:
On 04/11/11 20:35, 3dw...@verizon.net wrote:
Greetings,
Now that C++11 user-defined literals are in trunk I was thinking
about reclaiming some of the numeric suffixes that are currently
recognized by gcc in the preprocessor. The C++11 spec stipulates
On 04/11/11 20:35, 3dw...@verizon.net wrote:
Greetings,
Now that C++11 user-defined literals are in trunk I was thinking
about reclaiming some of the numeric suffixes that are currently
recognized by gcc in the preprocessor. The C++11 spec stipulates
that any suffix that is recognized by the im
23 matches
Mail list logo
