What does volatile guarantee?
in [Java Help]
|
Prev: 64-bit JNI
Next: Problem with interface implementation
From: Mike Schilling on 17 Feb 2010 03:19 EJP wrote: > On 16/02/2010 9:48 AM, Arne Vajh�j wrote: >> I know, but the ++something is better than something++ >> because it is faster is rooted in C++ classes I believe. > > It is rooted in the PDP-11 and Vax architectures, which had > pre-increment and post-decrement instructions, but not vice versa. No, that's not even remotely true.
From: Lars Enderin on 17 Feb 2010 04:39 Roedy Green wrote: > On Mon, 15 Feb 2010 09:35:27 +0100, Lars Enderin > <lars.enderin(a)telia.com> wrote, quoted or indirectly quoted someone > who said : > >> No, the text is not thin, it's just faint, with low contrast, but >> readable. It looks almost transparent, which is what you asked about >> initially. > > Could you please email me a screen shot. Also run > http://mindprod.com/applet/fontshower.html Sorry, but you are asking too much from me. I am sorry I commented at all. The fontshower applet alone is enough to turn me off. I says: Sorry, you need Java 1.5+ to run this Applet. I have Java 1.6! > And send me the list of fonts you have installed. > > or if you are feeling brave, fiddle with mindprod.css and jdisplay.css > till you figure out just what in them in causing the strange > rendering. Don't worry. Your page is readable.
From: Andreas Leitgeb on 17 Feb 2010 08:36 Robert Klemme <shortcutter(a)googlemail.com> wrote: > On 02/15/2010 10:32 AM, Andreas Leitgeb wrote: >> Lew <noone(a)lewscanon.com> wrote: >>> The matter of the existence or not of a shorthand combining operator >>> is a red herring. >> Java programming must really stink to you, with all those red herrings. That wasn't meant seriously, of course :-) I'd still dare to bet, that when red herrings are mentioned in any particular argument here, then in almost all(*) of the cases it's Lew who brought them in. :-) > Whenever I look, there is almost certainly a profound posting by him > in c.l.j - although I would concede that some might have to adjust to > his style of writing. :-) Btw., he was right on that point, too, because, as op='s are defined, they're just impossible to be atomical - because the old value of left side must be obtained before the right side is even begun to be evaluated. That just cannot be compatibly redefined. *: "almost all": all, but a finite number...
From: Joshua Cranmer on 17 Feb 2010 09:02 On 02/17/2010 08:36 AM, Andreas Leitgeb wrote: > *: "almost all": all, but a finite number... Warning: do not try pulling this definition on a math professor... -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Eric Sosman on 17 Feb 2010 10:34
On 2/17/2010 1:59 AM, EJP wrote: > On 16/02/2010 9:48 AM, Arne Vajhøj wrote: >> I know, but the ++something is better than something++ >> because it is faster is rooted in C++ classes I believe. > > It is rooted in the PDP-11 and Vax architectures, which had > pre-increment and post-decrement instructions, but not vice versa. "[...] People often guess that [++ and --] were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. [...]" - Dennis M. Ritchie, "The Development of the C Language" http://cm.bell-labs.com/cm/cs/who/dmr/chist.html -- Eric Sosman esosman(a)ieee-dot-org.invalid |