The D Programming Language
in [C++]
|
From: Andrei Alexandrescu (See Website For Email) on 6 Dec 2006 14:20 PeteK wrote: > Andrei Alexandrescu (See Website For Email) wrote: > >>Peter Dimov wrote: >> >>>Dave's point, to which I also subscribe, is that when nothing in a >>>programming language is illegal, you have no "legal standing" to >>>declare a program incorrect. So you can't have a tool like Purify that >>>automatically identifies that a program has performed an illegal >>>operation, because there are no illegal operations whatsoever. >> >>That makes of course sense; the logic is iron-strong. Yet I can't see >>how that is an advantage for languages that allow illegal operations. On >>the contrary. >> > > > I was talking to a man from Barrytown about burglaries. He asked how > we dealt with them. [snip] That's a nice story, but a poor analogy. For example, Java does have (truly) private data :o). Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: PeteK on 7 Dec 2006 03:43 Andrei Alexandrescu (See Website For Email) wrote: > PeteK wrote: > > Andrei Alexandrescu (See Website For Email) wrote: > > > >>Peter Dimov wrote: > >> > >>>Dave's point, to which I also subscribe, is that when nothing in a > >>>programming language is illegal, you have no "legal standing" to > >>>declare a program incorrect. So you can't have a tool like Purify that > >>>automatically identifies that a program has performed an illegal > >>>operation, because there are no illegal operations whatsoever. > >> > >>That makes of course sense; the logic is iron-strong. Yet I can't see > >>how that is an advantage for languages that allow illegal operations. On > >>the contrary. > >> > > > > > > I was talking to a man from Barrytown about burglaries. He asked how > > we dealt with them. > [snip] > > That's a nice story, but a poor analogy. For example, Java does have > (truly) private data :o). > No, it's piled outside the front door with a sign saying, "take what you want" ;-) However, we seem to be in danger of rehashing the argument we had about GC vs smart pointers. You can easily get rid of dangling pointers in C++ and turn them into zombies instead by simply using a bolt-on garbage collector. The language doesn't stop you doing that. However in Java you are stuck with the GC system and there's no way to automate the detection of zombies (big assumption here by someone who's never used it). In principle it should be possible to pick up all potential zombies/dangling pointers in C++ by using a sufficiently clever debugging allocator. Admittedly this doesn't stop you assigning duff values to pointers, but that's the price you have to pay for using a system-level language. If I was going to tighten up C++ one of the first things I'd do is insist on a defined order of evaluation of function arguments and I wouldn't be averse to the automatic initialisation of variables (as in D). After all, a compiler could always provide switches to turn these off for performance freaks who know what they're doing. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrei Alexandrescu (See Website For Email) on 7 Dec 2006 03:44 David Abrahams wrote: >>Of course, this means that other threads can see pointers to >>objects which aren't yet constructed. But that's generally true >>in Java, even without threads; just call a virtual function from >>a base class constructor. Worse, other threads can see pointers >>to objects which haven't yet been zero initialized (or >>initialized at all). That is, of course, the undefined behavior >>that Java supposedly doesn't have. (I'm rather surprised that >>Andrei doesn't recognize this. IIRC, he's written on the >>problems of double checked locking in the past, and this problem >>is related.) > > > Wow. I'm out of my element here, but it does sound sticky. It does sound sticky, indeed. As I discussed in my reply to that post, it also turns out to be incorrect. I'd insert some more sarcastic remarks to James about not dispensing information that one is not sure about, unless I wasn't guilty of the same myself... quite a few times :o). Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrei Alexandrescu (See Website For Email) on 7 Dec 2006 05:54 Joe Seigh wrote: > Andrei Alexandrescu (See Website For Email) wrote: >> My understanding is that previous implementations of Java did have the >> threading issues you mention, and that the work on the Java memory model >> made it impossible for a thread to see an uninitialized object. So >> according to my understanding, your representation of the situation is >> perfectly accurate... as of four years ago. >> >> > > The problem was recognised as far back as here. > http://groups.google.com/group/comp.lang.java.programmer/msg/b804ee40f102c68a?hl=en& > > > And the memory model was fixed with JSR-133. > > Java pointers are atomic but they don't have acquire/release semantics > necessary > to make double checked locking work. For that you need volatile which > means > something slightly different in Java than it does in C or C++. Very true, thanks for clarifying. So, the way I understand things is, if you don't use volatile in DCLP with Java, you end up (worst-case scenario) creating multiple Singleton objects, but never accessing an uninitialized or partially-initialized object. Is that correct? Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Niklas Matthies on 7 Dec 2006 09:39
On 2006-12-06 19:20, Andrei Alexandrescu (See Website For Email) wrote: > PeteK wrote: : >> I was talking to a man from Barrytown about burglaries. He asked how >> we dealt with them. > [snip] > > That's a nice story, but a poor analogy. For example, Java does have > (truly) private data :o). It's not as private as one might assume; with default security settings you can access it via reflection. For example it's possible to corrupt a String object by replacing its char[] value. -- Niklas Matthies -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |