From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: C++, complex, etc
Date: 18 May 2000 12:03:15 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 65
Message-ID: <8g0m63$frd$1@nets3.rz.RWTH-Aachen.DE>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000517101641 DOT 4709E-100000 AT is> <39224964 DOT BBFA67CB AT mtu-net DOT ru> <8fu3ke$fd0$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <3922E117 DOT 561584EE AT mtu-net DOT ru> <8g0bq1$b09$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <3923BD31 DOT D1033050 AT mtu-net DOT ru>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 958651395 16237 137.226.32.75 (18 May 2000 12:03:15 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 18 May 2000 12:03:15 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Alexei A. Frounze <alex DOT fru AT mtu-net DOT ru> wrote:
> Hans-Bernhard Broeker wrote:

> OK. Where can I have the specs on C++ library standard?

Straight from the horse's mouth: the ISO (www.iso.ch), or its member
organization for your country, sells the Standard on paper. The cost
is rather high, though. If can do that, the way via the US-American
member organization, ANSI, offers a cheaper way: you can buy the
standard as a PDF file, with a license to print it yourself, for
something like 15 US$.

> Does DJGPP/GCC work that standard way? If so, why there is no backward
> compatibility with "complex"? Is it hard to add one extra "#define" or
> "typedef"?

The problem is that the word 'complex' itself is now used in a
fundamentally incompatible way: it used to be a type name, now it's
the name of a template. You cannot have both at the same time, AFAIK.

[...]
>> I wanted to point out that you were making a totally unjustified
>> assumption.  You say you don't need size_t, if size_t and int are
>> effectively the same thing. The 'if' in that sentence is the crucial
>> part: this 'if' cannot be tested by the program.

> sizeof() :)

Doesn't help you a bit, if you want to ignore size_t altogether. And,
strictly speaking, you cannot deduce *anything* about the range of
acceptable values of a given type, nor about type compatibility, from
sizeof(). Nothing in the language definition forbids the compiler to
introduce garbage bits that serve no useful purpose than to bloat
sizeof().

[...]
>> that the definition of size_t depends on much more subtle
>> parameters. The memory model in 16bit compilers, e.g.: in 'large' or
>> 'huge' model, size_t will have to be a 32bit quantity.

> OKay, how many compilers assume different sizes of size_t due to memory
> model or *something else*? 

It is completely unimportant how many such compilers there are. The
language allows for such compilers to exist, and therefore, you should
not break your code without a good need --- and code using the
assumption that 'size_t' is essentially the same as 'int', without a
very good reason for doing so, is broken, period.

> How may compilers have different memory models
> and what for (nowadays, 32-bit compilers for i386+ don't need something new
> but flat memory model (or as Eli mantioned something like 32-bit .COM))?

The 32bit flat memory model is already stretched close to its
limitations, these days. 4 Gigabytes of address space may have looked
like infinitely much, 5 years ago. These days, you can already buy
high-end PC's with 1 Gigabyte of storage --- there's not much room
left before true 'far' pointers will be needed, even for 32bit
addressing modes. Not even to mention that the era of even the 32bit
variety of x86 systems is reaching its end, these days.


-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.