[QUOTE=CRGreathouse;287972]What about random numbers, time/date, and other things that will change without regard to the source?[/QUOTE]

I believe the distinction y'all are circling around is "deterministic or not." This same distinction is a key parameter for RNGs (random number generators). Sometimes one needs genuinely unpredictable numbers (or initial seeds); but in many cases one needs "deterministically random" numbers for e.g. software QA purposes.

Reading from an uninitialized memory location (in the lingo, a UMR - uninitialized memory read) is clearly nondeterministic - sure, you may get the same result over multiple runs of the program, if those re-use the same memory space and nothing else writes the memloc in question in the interim. (Often when trying to track down a crash or other bug which eventually proves due to a UMR, one in fact relies on that near-term-repeatability aspect over multiple debugger runs). But there's a good reason there are dedicated code tools (e.g. Purify, valgrind) designed to ferret out nasties such as UMRs.

[QUOTE=ewmayer;289177]Reading from an uninitialized memory location (in the lingo, a UMR - uninitialized memory read) is clearly nondeterministic - sure, you may get the same result over multiple runs of the program, if those re-use the same memory space and nothing else writes the memloc in question in the interim. (Often when trying to track down a crash or other bug which eventually proves due to a UMR, one in fact relies on that near-term-repeatability aspect over multiple debugger runs). But there's a good reason there are dedicated code tools (e.g. Purify, valgrind) designed to ferret out nasties such as UMRs.[/QUOTE]
Uninitialized memory reads and valgrind: That reminds me of the Debian OpenSSL incident...

[code]
while((c = getc(stdin)) != EOF){
if(cp == &in_line[LINELNG-1] || c == '\n'){
/*
stuff to end string*/
}
else
[b][u]*cp++ = c;[/b][/u]
}[/code]
Oh, after seeing that the first time, it really feels dirty, but at the same time, it's oh-such-a-beautiful line of code. :smile:

[QUOTE=Dubslow;289175]I guess for printing then, I just need to specify more than 6 significant digits.

Now, though we are agreed that %lf is a double for scanf, why does 3.141592653589 get truncated to 3.141593, even though the former should fit inside a double?[/QUOTE]

:furious: Nothing is getting truncated excepted for the printed output!!!! And you know why _that_ is happening.

[QUOTE=axn;289234]:furious: Nothing is getting truncated excepted for the printed output!!!! And you know why _that_ is happening.[/QUOTE]

There are reasons why teachers must have much patience....

(Or, at least, the good ones. :smile:)

[QUOTE=axn;289234]:furious: Nothing is getting truncated excepted for the printed output!!!! And you know why _that_ is happening.[/QUOTE]

I'm sorry, I do sometimes do smart things!!! I swear!

:razz:

[QUOTE=Dubslow;289241]I'm sorry, I do sometimes do smart things!!! I swear!

:razz:[/QUOTE]

I believe ya. :smile:

As for that pointer business, I know understand why what I did was no different from just using standard array notation. As such, I rewrote the LL program, by which I mean I made better use of actual pointers.

[url]http://dubslow.tk/random/ll.txt[/url]

On the other hand, I think I also went a bit overboard with the pointer arithmetic. One went from one extreme to the other...

Edit: I think the old one is faster...

[QUOTE=Dubslow;289534]On the other hand, I think I also went a bit overboard with the pointer arithmetic. One went from one extreme to the other...[/QUOTE]

[CODE]/* This would definitely be better with indices than pointers. */[/CODE]
I agree. That loop is the worst loop in the whole program to be chosen for pointer arithmetic.

Two typos in one quote. I am a boss.

*Went from one extreme to the other....

*with indices rather than (with) pointers.

It's also worth noting that there is the D programming language which might be of interest if you want something similar to C++ but with some features of C# and Java. [url]http://en.wikipedia.org/wiki/D_(programming_language[/url])