Board index » cppbuilder » Re: vote for a native 64-bit compiler

2005-02-12 04:03:03 AM
cppbuilder72
Sean Hoffman < XXXX@XXXXX.COM >writes:
--
Chris (TeamB);
 

"Will DeWitt Jr." < XXXX@XXXXX.COM >writes:
--
Chris (TeamB);
 

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote in
program is also a valid C++ program?
mr_organic
 

{smallsort}

"mr_organic" < XXXX@XXXXX.COM >writes:
language will not affect C++ unless the C++ committee adopts those
changes too. (And the C++ committee will probably try to accomodate
many of the changes, but some simply do not make sense for C++.) You
can read about this in the normative references in the C++ standard,
section 1.2. They refer specifically to the version of C specified in
ISO/IEC 9989:1990.
--
Chris (TeamB);
 

mr_organic wrote:
technical corrigendum. The C++ standard was ratified in 1998, the
revised C stanard was the following year. How can the 1998 standard
include concepts that official did not exist when it was published? <g>
You could argue for forward-compatibility automatically including all C
revisions, but that does not work when C is steered by a different
committee that does not regard C++ concerns as limitting on their own,
separate language.
Of course improved compatibility with C99 is a goal of the C++
committee. You will see the C99 standard library incorporated in
Library TR1, the preprocessor is being actively looked at, 'long long'
is pretty much a done deal (although integer promotion and function
overloading make this a little more interesting for C++, especially
when figuring out the type of a literal - should MAXINT + 1 be unsigned
int or long long?)
On the other hand, 'restrict' and VLAs are a long way off, and I have
not heard many calls for the different floating point types...
AlisdairM(TeamB)
 

"Alisdair Meredith" <alisdair.meredith@ XXXX@XXXXX.COM >
wrote in news:420d295e$ XXXX@XXXXX.COM :
Windows market now? I am unaware of any vendor that sells a "pure C"
compiler, and AFAIK GCC is not fully C99 compliant yet. If Microsoft is
tracking the ISO C++ standard, then it too will not compile C99-based C
code.
Am I missing something obvious here? If I want to write pure, C99-
compliant C code targetting a WIN32 platform, what toolset can I use?
mr_organic
 

"mr_organic" < XXXX@XXXXX.COM >writes:
is no implementation for the full spec, although all vendors cover the
most "interesting" features.
BTW, gcc, VC++, Borland, Intel and most compiler vendors provide a C++
compiler *and* a C compiler, even if they share a large part of the
infrastructure. GCC has the C and C++ front ends on separate
executables, while most other vendors has both frontend on the same
executable, but this is just a implementation detail. So you have
plenty of options for pure C development.
--
Oscar
 

mr_organic wrote:
[big snip]
.a
 

"Alex Bakaev [TeamB]" < XXXX@XXXXX.COM >writes:
info is outdated: they mention C++'s "export" as not supported, but it
is supported since a long time ago.
--
Oscar
 

mr_organic wrote:
for existing implementations. Note that C99 replaces the existing C89
standard, so if your 'C' vendor does not implement C99, they do not
implement a conforming C compiler.
One of the problems of the C++ standard is that it
includes-by-reference a standard that is no longer available - try
buying an out of date standard from ISO and you will see what I mean!
There are also certain 'blended' implementations that support elements
of C99 as a conforming extension to C++. For instance, _Pragma sits in
the list of identifiers reserved to the implementation, so a vendor can
choose to implement this feature as specified in C99 as a conforming
C++ extension. While you cannot implement the entire standard this way
(new keywords are awkward for a start!) you can certainly make some
progress.
with their efforts on straight C++. Last I heard they had no intention
of implementing a fully conforming C++ compiler, the export keyword and
2-phase looking for templates being the two most notable omissions.
Dinkumware have the library, so it should be possible to put out a C99
toolset. It has not bothered me significantly enough to seek one out
though, and as Alex says - the parallels with finding a conforming C++
compiler are scary <g>
Off the record, I suspect the most controversial parts of C++0x to
implement will continue to be holdovers from C++98. The language is
already large and complex enough without adding the kitchen sink, so
additions will be carefully chosen and almost certainly have at least
one implementation before being accepted. That said, we'll see what
sneaks under the wire as the process comes to an end - at some point
you have to stop, write the words and ship!
AlisdairM(TeamB)
 

Sean Hoffman in <420cde2c$ XXXX@XXXXX.COM >:
those 'visible' to the user and they use register renaming to map
specific registers to specific roles for processing particular
instructions. Combined with instruction reordering / out-of-order
execution this can have the same effect as a bigger official register set
(depending on the instruction dependencies in the actual code).
More importantly, certain local memory accesses are almost as fast as
register access (and certainly faster than access to a stalled register)
and these reads/writes can be handled completely within the CPU chip;
some of the writes may never go into external caches/memory. Intel had a
special name for that but I have forgotten it - I haven't done serious
assembly programming for a couple of years. <g>
So the benefit of the bigger register set may actually not be as big as
the difference to the tiny 'nominal' x86 register set makes it seem.
--
Sherlog [Personenkennzahl 250866413515 / Stefan Otto / SO1801-RIPE]
 

Will DeWitt Jr. in <420cfea7$ XXXX@XXXXX.COM >:
compilers, of course).
The type names in C99 are int32_t, uint32_t and so on - just look into
<stdint.h>, which BCB also has had since at least version 6. But this has
nothing to do with what the language says about char, int, long and so
on. According to the *language* definition a long must be at least 32
bits and a char must not be longer - but it could be just as long as a
long. In fact, a couple of years I worked with a system where
sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long) ==
sizeof(void*). This certainly simplified a lot of things. ;-)
--
Sherlog [Personenkennzahl 250866413515 / Stefan Otto / SO1801-RIPE]
 

"Sean Hoffman" < XXXX@XXXXX.COM >schrieb im Newsbeitrag news:420cf082$ XXXX@XXXXX.COM ...
Regarding the MSDN documentation all integral datatypes will have the same size
on a 64-bit Windows operating system as they had on the current 32-bit
Windows operating systems.
Quote from the MSDN documentation
"
An int and a long are 32-bit values on 64-bit Windows operating systems.
size_t, time_t, and ptrdiff_t are 64-bit values on 64-bit Windows operating systems.
"
I hadn´t time to install 64 Bit XP yet, so i can only refer to the MSDN documentation.
 

Sherlog wrote:
Will
--
Want native support in Delphi for AMD64/EM64T? Vote here--
qc.borland.com/wc/qcmain.aspx
 

Sherlog < XXXX@XXXXX.COM >writes:
[snip]
false for the later.
BTW, the int size used on compilers for the x86 64bit architectures
seems in conflict with the C++ standard (3.9.1/2):
"... Plain ints have the natural size suggested by the architecture of
the executing environment^(39). ..."
The footnote 39 says:
"That is, large enough to contain any value in the range of INT_MIN
and INT_MAX, as defined in the header <climits>."
which is a cyclic definition, but the intent is clear: an int in a 64
bit processor should be 64 bits wide. This would cause some problems
for using 32 bit and 16 bit types: `short int' for 32 bits and
`short short int' for 16 bits?
[snip]
--
Oscar