The D Programming Language
in [C++]
|
From: Peter Dimov on 26 Nov 2006 21:43 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. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Dimov on 26 Nov 2006 21:44 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. This is an interesting point. The easy response is that this (and the fact that complex<T> has no defined layout) is a defect in the standard and can be fixed without making complex a fundamental type. But it's true that operators on fundamental types don't have to specify a particular signature or calling convention and offer more freedom. (You still have to specify the signature of functions, though.) On the other hand, if only complex is optimized because it's part of the core language, pair<int, int> and point2<double> won't be enregistered even when passed by value. So users of complex win, but everyone else loses. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Dimov on 26 Nov 2006 21:46 Walter Bright wrote: > For another imponderable, why do reusable Java libraries sprout > everywhere you look, but reusable C++ libraries seem to follow a more > tortured path? Is there something about C++ that makes it difficult to > write libraries? The main reason, IMO, is that if you need a Java library for something, you have to write it. You can't take one written in C (or even Fortran) and just call it, as you do in C++. There is one something in C++ that makes it difficult to write libraries, and it's the lack of an ownership convention. In Java you just return a reference to the object and that's it. Most C++ libraries have to start by defining their own convention. Or had to, before shared_ptr. There's also the fact that Java is effectively C++ with a built-in strict coding standard. This takes away programmer freedom and power, but facilitates reusability. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Steven E. Harris on 27 Nov 2006 00:55 James Kanze <james.kanze(a)gmail.com> writes: > The little I've seen of Lisp and Scheme do as well, or at least, > I've not seen how the behavior is defined. Common Lisp has "implementation-dependent" behavior�, which sounds a lot like "undefined behavior" in C++. As for how easy it is to wander into such territory, though, or the severity of the consequences one might encounter remains another question. Footnotes: � http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_i.htm#implementation-dependent -- Steven E. Harris [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mirek Fidler on 27 Nov 2006 00:57
> I think there is huge > opportunity in the programming language area for a language as > performance oriented as C++ but with the productivity capabilities of > Python/Ruby. Interesting. This is why I use C++ - I have the productivity of Python/Ruby, with C/C++ performance. Such a combo is hard to beat. Admittedly, there is a catch.... We had the comfort of enough time to use just the core language and to develop, over years, "the right set" of libraries and development tools. Now I have solution that is optimal for the problem domain I am working in (SQL/GUI applications) plus in other areas (e.g. development tools) as well. I dare to say that my current C++ coding easily beats, in terms of productivity of my problem domains, anything else out there. (But of course, I am biased ;) The moral of the story is that C++ is way too flexible to justify another similar language - even if C++ has some some features that make seasoned compiler writer cry :) Mirek -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |