delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/05/18/09:35:00

From: "Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: C++, complex, etc
Date: Thu, 18 May 2000 13:51:45 +0400
Organization: MTU-Intel ISP
Lines: 64
Message-ID: <3923BD31.D1033050@mtu-net.ru>
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>
NNTP-Posting-Host: ppp108-214.dialup.mtu-net.ru
Mime-Version: 1.0
X-Trace: gavrilo.mtu.ru 958643713 53129 212.188.108.214 (18 May 2000 09:55:13 GMT)
X-Complaints-To: usenet-abuse AT mtu DOT ru
NNTP-Posting-Date: 18 May 2000 09:55:13 GMT
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: ru,en
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Hans-Bernhard Broeker wrote:

[snip]

> > Is standard or is <being> standartized? Why so long?
> 
> As someone else in this thread so nicely put it: it *is* standardized,
> but so far only on paper, not in the form of compilers and libraries,
> yet. And of course, there's still the issue of old versions of
> compilers, and outdated books, that won't vanish from the surface of
> the earth just because they are no longer up to date.

OK. Where can I have the specs on C++ library standard?
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"?

> [... and now for something completely different ...]
> 
> >> > size_t is not a problem. Btw, what so I need size_t for, if both size_t and
> >> > int equal the same machine word?
> >>
> >> *If*. But how on earth is a program supposed to know if that condition
> >> holds, on the compiler it's being put through?
> 
> > I don't understand your phrase. Please tell it in other words, if possible.
> 
> 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() :)

> Your acceptance problem with size_t, as far as I can see, is that you
> don't see any difference between it and the common 'int'. But there
> most certainly is one. You claimed that size_t had something to do
> with the 'machine word' size. That's simply not true. Size_t is the
> type to express sizes of objects in. That's why malloc()'s argument is
> of type size_t, to give just one example. How large it has to be to
> support that usage is impossible to know, for your program.
> 
> You seem to believe that it's somehow "obvious" that for a 16bit
> compiler, size_t would be a 16bit int, and for a 32bit compiler, it
> would have to be a 32bit int. Wake up to reality, will you?  Fact is
> 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. This implies
> that for some uses, even if you don't use any of the Standard C
> Library function, you still have to know what size_t is.

OKay, how many compilers assume different sizes of size_t due to memory
model or *something else*? 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))?
What is that *something else*?

bye.
Alexei A. Frounze
-----------------------------------------
Homepage: http://alexfru.chat.ru
Mirror:   http://members.xoom.com/alexfru


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019