From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: C++, complex, etc Date: 18 May 2000 09:06:09 GMT Organization: Aachen University of Technology (RWTH) Lines: 120 Message-ID: <8g0bq1$b09$1@nets3.rz.RWTH-Aachen.DE> References: <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> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 958640769 11273 137.226.32.75 (18 May 2000 09:06:09 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 18 May 2000 09:06:09 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 wrote: > Hans-Bernhard Broeker wrote: >> Alexei A. Frounze 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 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.