David Brown da...@westcontrol.com 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
On 08/11/2011 05:27, Hans-Peter Nilsson wrote:
On Sun, 6 Nov 2011, Joern Rennecke wrote:
Quoting David Browndavid.br...@hesbynett.no:
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
(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 extensions.
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++
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 right
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
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 - and so
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 incompatibility
On Sun, 6 Nov 2011, Joern Rennecke wrote:
Quoting David Brown david.br...@hesbynett.no:
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
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
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 this
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 6 November 2011 15:40, Jonathan Wakely wrote:
I think a better example is atomics support in C++11 and C11, where
std::atomicint aka std::atomic_int can be exactly the same
representation as _Atomic int and are compatible, but the C++ library
solution also allows std::atomicFooBar which C
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
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
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 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
Quoting David Brown david.br...@hesbynett.no:
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
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 would
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
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 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
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
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 implementation is not allowable as a
24 matches
Mail list logo
