Mail Archives: djgpp/2000/05/18/09:37:03
Alexei A. Frounze <alex DOT fru AT mtu-net DOT ru> wrote:
> Hans-Bernhard Broeker wrote:
>> Alexei A. Frounze <alex DOT fru AT mtu-net DOT ru> wrote:
[...]
>> Sorry, Alexei, but I think you must have misunderstood a fundamental
>> detail about what high-level programming languages are meant for. And
>> C++ is just about as high-level as it gets.
> Nope. :) I simply flame because C++ library implementations are different in
> different compilers. That's the main problem that makes me angry. I don't
> understand why C++ library is standartized so long.
That's life. Standardization is a lengthy process. It usually takes at
least several years from the idea that a standard is needed to the
final ratification of a new standard by the international
organizations. That's because many external forces --- implementors,
users, sometimes even computer science theoreticians --- will try to
have their opinions accounted for, and lots of such opinions will be
contradictory. Sorting that out is a time-consuming process for a
committee that, lacking the normative power of a government agency,
has to rely on at least some level of consensus to get their work
accepted.
Now, in comes competition among compiler makers. In these days,
optimization quality has become so hard to measure that the compiler
makers, in search for a better marketing buzzword, find that it is a
good selling point if you can claim that your compiler supports *all*
of the latest features going to be be in the forthcoming ISO C++
Standard.
What this 'latest, hottest ANSI/ISO C++ features' thing does not
account for is that such features may as easily be removed from the
working draft of the standard, or substantially changed, as they're
being added. I.e. what was correct yesterday may be deprecated
tomorrow, and outright wrong next week. It *is* a work-in-progress,
after all.
'complex' is an example of that happening. The standardization
committe originally had one kind of implementing complex datatypes in
mind, so some compile makers jumped onto that bandwagon and
implemented that particular method, and authors wrote into their books
that this was 'the' method of using complex numbers in C++. Later, the
committee found compelling reason to choose another, strongly
different way of implementing it, so they changed their mind, and the
draft standard.
At that point in time, a responsible reaction by compiler makers and
publishers would have been to *call back* all their products, to
replace the now broken implementation and description by the new one.
But of course, this world not being an ideal one, they didn't do that,
letting unsuspecting programmers and book readers sort out the issue
on their own.
> Seems people started inventing it w/o thinking of portability and
> standards so standard is released after C++ is out. Or the standard
> changes all the time itself. :(
'The standard' didn't change, yet. There simply *was* no true standard
before the ISO committee finished their work. Until then, the usual
reference was either the latest book by the inventor of the language,
Mr. Stroustrup, or the latest 'reference implementation' by AT&T.
>> > So why should I use C++ library, if it's not standartized?
>>
>> It *is* standardized. But most of the compilers haven't implemented
>> all of that standard, yet.
> 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.
This is where the confusion really comes from: books describing such a
volatile thing as 'the current draft ISO C++ language/library' would
need a BIG timestamp on them, telling what 'current' actually means.
That way, readers would be warned that this particular book is well
beyond its time of useability, and not rely on the accuracy of it any
more than is advisable.
[... 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.
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.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -