From: Kevin Ashley Newsgroups: comp.os.msdos.djgpp Subject: Re: LARGE numbers. Date: Fri, 28 Aug 1998 11:53:02 +0100 Organization: Posted via ULCC Internet Services Lines: 35 Message-ID: <35E68C0E.41C6@ulcc.ac.uk> References: <1103_904198596 AT isaacc> <35E56BAA DOT 424BE1B3 AT unb DOT ca> NNTP-Posting-Host: silver.ulcc.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CC: Endlisnis To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk In a message which has reached me by email, but hasn't yet turned up on our news server, Endlisnis wrote: >Kevin Ashley wrote: > >> double dvar; >> dvar = 25834242042; > > This line WILL work, I've already uploaded example code that shows this working. I hadn't seen your example when I posted. However, I think there is still some room for both to be correct. Your example was C++; I don't program in that, but use C exclusively. I'm familiar with the C standard but not with C++. As far as C is concerned, that constant is an integer constant, which is then effectively cast to a double at compilation time. If it's too big to fit in an int, the results are undefined. GCC produces warnings at compilation time that the constant is too big for an integer, and that it will end up being unsigned. I suspect it must internally store the evaluation in a long long int, since it does produce correct results despite the warnings, but this is definitely compiler-specific behaviour and cannot be relied upon in general. I've tried it on another compiler (ANSI-compatible but not GCC) and both the double and the int end up equal to 64438266 (with a similar slew of warnings.) So, it may work, but if the target language is C it isn't right and it isn't portable and sooner or later it may cause you problems. If we're talking C++, I confess ignorance. -------------------------------------------------------------------------- Kevin Ashley K DOT Ashley AT Ulcc DOT ac DOT uk Special Projects Manager http://www.ulcc.ac.uk/staff/Kevin+Ashley ULCC ...ukc!ncdlab!K.Ashley (but probably not any more) This is not a signature