The D Programming Language
in [C++]
|
From: Andrei Alexandrescu (See Website For Email) on 27 Nov 2006 04:30 James Kanze wrote: > Andrei Alexandrescu (See Website For Email) wrote: >>That's simply wrong. Java does not check thread safety >>statically, yet is able to define behavior of even incorrect >>multithreaded code. > > > Writing to a double while another thread is reading it is > undefined behavior in Java. I've ran a number of searches for that ("java undefined behavior double", "java undefined behavior threads double" etc.), no avail. I'd be glad if you provided a reference. Thanks! Maybe (also) we're using slightly different definitions for undefined behavior? 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 27 Nov 2006 06:41 Peter Dimov wrote: > Andrei Alexandrescu (See Website For Email) wrote: > >>Peter Dimov wrote: >> >>>Andrei Alexandrescu (See Website For Email) wrote: >>> >>> >>>>That's simply wrong. Java does not check thread safety statically, yet >>>>is able to define behavior of even incorrect multithreaded code. >>> >>>It does on a physical level (long and double aside), but not on a >>>logical level. An object invariant can easily be broken by a data race. >>>The behavior from this point onwards is defined but makes no sense. >>>This decision is correct for safety reasons, but doesn't offer many >>>other benefits. >> >>And that contradicts my statement how? > > > Your statement is completely correct if we stick to the formal > definitions of "undefined behavior" as in the C++ standard and > "incorrect MT code" as in the Java memory model. So it doesn't. I was > just pointing out that programs with defined behavior that don't work > aren't necessarily better than programs without defined behavior that > don't work. But remarking that well-defined programs could behave erratically is trite with or without threads out of the picture. The sky is blue, motherhood is good, and defined well-programs fail to keep their higher-level invariants in ways that make them practically impossible to track. Anyhow, on to a more interesting point - what happens to long and double when there are races on them? I thought the worst that could happen is that you have an unpredictable value stored in them. Right? 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 27 Nov 2006 08:19 James Kanze wrote: > Walter Bright wrote: > >>Peter Dimov wrote: >> >>>Walter Bright wrote: >>> >>>>5) better code generation (like for complex, we can (and do) return them >>>>in the FPU registers rather than like a struct) > > >>>If you optimize the general case of struct { X x; Y y; }, where X and Y >>>fit in a register, you get much better ROI. > > >>The C++98 Standard defines many operations on complex as taking an >>argument of type complex&. That means taking a pointer to it, which puts >>the kibosh on enregistering complex. > > > In a naive implementation. > > The C++98 Standard never forbids making the functions of complex > inline, in which case, a compiler should be able to eliminate > not only the call, but also taking the address, and so should be > able to keep all of the values in registers. Yes, I wonder about the same. If (1) a function taking T& can be inlined, and if (2) it doesn't use the address of its parameter, couldn't that code be optimized to put the thing in register(s)? I mean, once you inline the function, any and all of the implemented optimization spring to life. Unaliasing the function's parmeter with its name is a "simple matter of unaliasing". :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 27 Nov 2006 08:25 {Watch that we do not further drift to discussing D rather than what we might do to C++ -mod} Walter Bright wrote: > Andrei Alexandrescu (See Website For Email) wrote: > >> If a new language is to >> become successful, it better comes up not with what's good in other >> languages, but with some good of its own. Otherwise it will always be >> one step behind. > > > Consider the following: > > Language A has features X,Y. > Language B has features S,T. > > X sucks, Y is cool. S sucks, T is cool. So why is a language C that > implements Y,T behind? The combination of Y and T may actually make C a > far more powerful language than A or B, even though it didn't actually > do anything innovative. Ah, if only it all were this simple... :o) The reality is, it's hard to balance good features in a harmonious whole, and it's also hard to remove features that "suck" without impacting "good" ones. > Even so, D has already implemented C++ features that exist only as > proposals, such as contract programming, type inference, unicode > support, modules, etc. It has moved ahead of C++ with things like > tuples, scope guard, function literals, lazy arguments, inline > assembler, etc. Ideally one would find in a new language something entirely original that's unique to that language, and that is clever, interesting, and attractive. > All these things make it easier to develop library code. I don't see how > D is a step behind. I don't understand how strings and arrays as core > types sabotages library development. I meant something different - that robbing user code from facilities available to the core language writer sabotages library development. I don't want to see the D source for adding two ints. But I'd love it if the addition of two integers would be "in the initial symbol table" of D, meaning it's an operation that has equal status to the user-defined ones, and implying (if I assume that integer addition is implemented to be overhead-free) that user-defined code can enjoy similar amenities. Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 27 Nov 2006 08:28
Walter Bright <walter(a)digitalmars-nospamm.com> writes: > Numerical analysis is quite likely something that a mainstream > programmer would never encounter. It doesn't come up when you're writing > guis, databases, compilers, device drivers, web apps, games Whoa, stop right there. Many of today's games contain sophisticated physics simulations that require intense numerical analysis. -- 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! ] |