The D Programming Language
in [C++]
|
From: PeteK on 6 Dec 2006 02:05 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. "Well", I said, "we've got a bunch of policemen who patrol the neighbourhood. Whenever they see a burglary taking place they nick the burglar and lock him up". "That's all very well", he said, "but surely some burglars get away, and what about the mess they make breaking into your house?" "Well yes, they can make a mess sometimes. But we generally catch them quite quickly and some people install silent alarms, which means we can nick them as soon as they break in. It may take a little time, but we get them all in the end. Anyway, how do you deal with your burglaries?" "Oh, we abolished them" he said. "How did you do that?" I asked, somewhat intrigued. "Well we simply place all our valuables outside the front door with a sign saying 'take what you want'. That way taking stuff is not illegal, so there's no need for policemen." "But surely people take your stuff anyway?" "Yes, but at least they don't make a mess breaking in." "Do you ever find out who did it?" "Not unless we happen to catch them in the act, but that doesn't often happen." "So people still keep taking your stuff and no-one ever stops them. Isn't that somewhat annoying when you want something and find that someone's simply taken it?" "Oh yes! It's really infuriating. But hey! At least we've stopped of all those damned burglaries!" --------------------- I'm not one to look behind I know that times must change But over there in Barrytown they do things very strange - Steel Dan -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Joe Seigh on 6 Dec 2006 02:09 Andrei Alexandrescu (See Website For Email) wrote: > James Kanze wrote: >> 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.) > > > 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++. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gabriel Dos Reis on 6 Dec 2006 02:04 "Binglong X" <binglongx(a)gmail.com> writes: [...] | The point is, that supporting the complex data type in the core of a new | language is not necessarily less fruitful than supporting it in a | library to supplement C++. There are too many negatives that make it very difficult for me to attain an acceptable degree of semantic analysis. Could you detail? -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gerhard Menzl on 6 Dec 2006 04:34 peter koch larsen wrote: > Wrong again. C++ throw() guarantees that the function will not throw > anything, An empty Java throw specification on the contrary guarantees > nothing of that kind. Surely you mean to say that C++ throw() guarantees that std::unexpected() will be called in case that the function throws in spite of having promised not to. -- Gerhard Menzl Non-spammers may respond to my email address, which is composed of my full name, separated by a dot, followed by at, followed by "fwz", followed by a dot, followed by "aero". [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 6 Dec 2006 06:35
Andrei Alexandrescu (See Website For Email) wrote: > James Kanze wrote: > > I get the feeling that Andrei is confusing atomic and > > synchronized. Writes to pointers in Java are guaranteed to be > > atomic; they're not "synchronized", neither in the usual sense, > > nor in the Java language sense. > No, I just used synchronized in lieu of atomic (as the effect is the > same), as I clarified in a different post. I thought it was just an accidental misuse of the word---"confusing" was a poor choice of words on my part, because I didn't think that there was any confusion in your head. On the other hand, given the parentheses above, I'm no longer certain. Atomic and synchronized are definitly different concepts, and have very different effects here. Synchronized would guarantee defined behavior (but slow the execution up by a factor of maybe 5). All Java guarantees (unless there's something I've missed---always possible) is atomic. > > 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. > This is defined behavior - I'd agree not the best choice, but defined. > It's not worth discussing it further. Agreed. > > 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.) > 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. Possibly. I've not kept up to date with Java, as I don't normally use it. But the runtime cost would be extreme, if they do guarantee it. I've just checked the latest version of the specification, and they do seem to have special wording to cover this: # The write of the default value (zero, false or null) to each variable synchronizes-with the first action in every thread. Although it may seem a little strange to write a default value to a variable before the object containing the variable is allocated, conceptually every object is created at the start of the program with its default initialized values. I'm not too sure how to interpret it, but the second sentence seems to suggest that default initialization of an object created after the thread has started must appear to have occured before the start of the thread (or conceptually appears before the start of the thread). I would be very curious to see how this is actually implemented, because it seems like it would be very, very expensive; it pratically means that every pointer dereference must be surrounded by fences. Do implementations really do this in practice? Or are there optimization techniques which allow eliminating enough of the fences so that the effect on performance is not important? (I'm not very up to date with regards to optimization in a multi-threaded context.) Or (what I suspect) do most implementations just ignore the issue, hoping that there will be enough intervening accesses involved in returning from the allocator and the delays involving the garbage collector that no older values will accidentally remained pipelined? (Or maybe there are tricks that can be used with the garbage collector. I'll have to think about this.) -- James Kanze (GABI Software) email:james.kanze(a)gmail.com Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |