Mail Archives: djgpp/2000/05/18/09:35:00
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 -