The D Programming Language
in [C++]
|
From: Binglong X on 5 Dec 2006 18:27 Mirek Fidler wrote: > Binglong X wrote: > > But a compiler would be free to use SSE2 registers as well to store a > > complex if complex is introduced as a fundamental type into a language? > > Using a nonportable library to supplement the current language is a > > good plus, why is it more fruitful than supporting that in the core of > > another language? > > Right, BUT this way I can use SSE2 to build optimized library for > anything else beyond complex datatype. > > It is quite easy to maintain (e.g. using #ifdefs) optimized parts that > compile on relevant platforms. > For anything else beyond complex data type, that's another topic. 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++. And it is not necessarily so for a new language to prevent its libraries from using SSE2 registers to get the same fruitfulness that C++ libraries enjoy. -- [ 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 5 Dec 2006 18:49 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. > 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. > 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. Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alf P. Steinbach on 6 Dec 2006 01:09 * James Kanze: > Andrei Alexandrescu (See Website For Email) wrote: > >> "Invalid pointer" = typed pointer pointing to a region of memory that >> the program does not assume is of that type. > > I'm having trouble parsing that last statement. > > Be it Java or C++, you can end up with a pointer to a destructed > object. Raw memory, in sum. In C++, that's called an invalid > pointer. In C++, of course, there are also other ways of > getting invalid pointers---just forget to initialize one, for > example, and the problem is made worse by the fact that the > system may reuse that raw memory for some other object, perhaps > of a completely different type. But in the end, saying that a > pointer is valid when it points to an object that has ceased to > live, and is no longer usable is just playing word games. Sorry, I have to disagree, very strongly: there are levels of being invalid, and saying that these levels are the same is IMO a word game. Andrei is right, there is a huge difference. Because there are no wild pointers in e.g. Java, the high-level invalid Java object -- what we call a zombie object (this explanation for Andrei, whom I agree with, but he asked about what that meant somewhere else-thread) -- can be detected as such, with a guarantee, by setting a boolean in the object. In C++ there's no guarantee that that boolean will continue to have its set value, because the program might write all over memory, and does. On the other hand, zombie objects are Bad. Not as bad as C++ UB, but still very Bad. On the third hand, although they can't be totally avoided, even in C++, a language that supported C++-like RAII combined with reference counting could in principle give the Java guarantees, without the need for zombie objects -- multi-level class invariants -- all over the place, and perhaps, I don't know, D is such a language. That said, a few months ago I worked on a project where, to reach the part of the app I was working on via the GUI (and it couldn't be reached otherwise), one had to click through a number of dialogs that exhibited C++ Undefined Behavior, with at least one assert kicking in -- just press "Continue", the project leader cheerily informed me, and don't fix any errors, we'll do that later. So this part had to be developed in a system exhibiting, very visibly, C++ Undefined Behavior, where that C++ Undefined Behavior was in at least one case use of an uninitialized pointer to a class type object. It was possible to develop in this situation, but I now think what I thought was a joke at the interview, "we'll just turn off assertions in the release", was actuality... -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 6 Dec 2006 01:15 "James Kanze" <james.kanze(a)gmail.com> writes: >> True memory isolation is very nice, but I don't see how it helps make >> bugs modular in practice. > > Sure it helps. A lot, even, if you want it to. But it isn't a > panacea, or a silver bullet. It's just one more tool. It can > reduce the number of places where you have to look, even if it > won't tell you exactly what's wrong. > > Why all the extremist positions? You're saying it won't help; No, I was saying "show me, because I don't see it." > Andrei says it eliminates all forms of undefined behavior. IIRC, he was saying it makes the bugs _more_ modular. > 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: peter koch larsen on 6 Dec 2006 01:22
Al skrev: > Hi, > > James Kanze wrote: > <snip> > > One of Java's faults is that it doesn't allow you to do anything > > reasonable (like crashing) when you've detected the problem. > > All you can do is log the error and throw an exception, hoping > > that 1) nobody silently swallows the exception (except that > > major standard library components do silently swallow > > exceptions), and 2) someone reads the log, and notices what went > > wrong. > > That's an interesting problem that honestly I hadn't considered. I guess > it is kind of creepy to know that whoever is calling you might basically > ignore whatever errors you pop up. > > On the other hand, from the other point of view (the caller) that's > exactly what is required. It's the very basis of exception safety. > No. Exception safety is entirely unrelated to exception signatures (or whatever they're called). A process that is concerned about what is thrown at you is fragile and bound to have a bad fate at one time or another. > Look instead at C++'s throw(). Seems completely bogus to me. Why? > Because in truth, it guarantees absolutely nothing, unlike Java. > 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. > Moreover, I'm not terribly familiar with the Java APIs, but from a quick > search, this showed up: > > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html > > Of note is: > > static public void System.exit(int); > > Which seems to do exactly what you want (i.e., elevate the error all the > way up the hierarchy to make sure it gets paid attention). What more do > you want? What is wanted is to stop the program without doing anything. In particular, destructors should not be run. The best would be to have a core dump, of course so that you can examine what happened in detail in your nice cosy office chair. /Peter [snip] -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |