The D Programming Language
in [C++]
|
From: Gabriel Dos Reis on 21 Nov 2006 05:47 Walter Bright <walter(a)digitalmars-nospamm.com> writes: [...] | 2) std::complex has no way to produce a complex literal. My understanding is that there is a general solution on the table. [...] | So, why isn't there much of any outcry about these problems with | std::complex? My theory is that few use C++ for serious numerical | computing, derived from the observation that popular and widely used C++ | compilers have dropped support for extended doubles (80 bit floating | point) without pushback from the users. Let me see if I get it right. You have observed (from data you collected) that widely used C++ compilers have dropped support for extended doubles (80 bit floating point) without pushback from the users. Therefore it logically follows that few use C++ for serious numerical computing. -- 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: AJ on 21 Nov 2006 05:45 Hi there, James Kanze wrote: <snip> > That depends. Library support isn't as good as core support > when it isn't as good. The fact that it is library and not core > isn't a disadvantage per se---I'd say that almost the opposite > is true. But you do have to compare the level of support; there > are some things that simply cannot be supported in a library > alone. I think I agree, though I also think we need a clear definition of a "library" and of "core-language" support. It is unclear at this point whether a library can be "magic" in the sense that it does things a regular user couldn't. It is also unclear what is meant by C++ any more. Is C++ simply the language, or does it include the STL? I don't think I would include the STL into the definition of the "core" C++ language. >> Here's one example: Multi-threading and thread safety. > > And this is one of them: you definitly have to specify at the > language level when it is safe to access objects, and when not. > >> For 1: In D, this is achieved in a super-clean and succinct manner: >> Adding a synchronized keyword. > > That, on the other hand, is a serious defect, at least if it is > done as in Java. It forces locking to obey scope rules. How is this a serious defect? It merely follows RAII, which is among C++'s strengths (say, vs. C#/Java). This seems very orthogonal to me. >> In C++, one must add error-prone boilerplate for critical >> sections (or mutexes, or locks) and in general the syntax is >> verbose and a hassle. > > I've never noticed this. My experience in Java is that the > synchronized keyword is a major problem; it's much easier to > write effective, correct code in C++ (using e.g. boost::mutex). I'm not very familiar with Java's synchronized, unfortunately. I'll try to read up on it. >> For 2: In D, synchronized is built-in. No need to download or >> install anything else. No need to check additional >> documentation on library usage. > > I'm not sure I understand this point: if the functionality is > part of the standard library, there's also no need to download > or install anything else, and what's the difference between > having to check library documentation, and having to check > language documentation? The standard library IS part of the > language. Well, this is a tricky semantically (what is what), as I mentioned above. The point is that, as it stands, I believe there is _no_ C++ support for synchronized of any sort, without relying on an external library. >> In C++, one must install and add a dependency to boost >> (non-trivial) or pthreads (still non-trivial), or sacrifice >> platform-independence and go Win32. > > Pthreads is delivered pre-installed on all of my platformes:-). > But that's not the point. At present, there is no support for > threading in (official) C++. Library or language. That is a > weakness. A weakness currently being addressed by the > committee. The final solution will doubtlessly contain both > library elements and language elements---the library cannot > possibly define what sequence points mean in a multi-threaded > environment, and it would be completely silly to not use > functions and classes to create new threads, mutexes, etc. > (Note that Java uses the synchronized keyword principally > because it doesn't have destructors, and has no other way of > ensuring that a lock is released in case of an exception. One > weakness leads to another.) Right. >> On the other hand, D isn't available by default almost anywhere, whereas >> C++ is, so that's one disadvantage. > > A pretty serious one. For me, the absence of a compiler for > Sparc under Solaris means that it's not even worth my time to > find out more. Give it some time, I guess :). Although I've always thought Walter should allow more outside help with D development. Also, I believe there is a D front-end with a GCC backend. So that's one means of cross-platform support (not sure if it works on Solaris though). >> However, wasn't this the case with >> C++ vs. C too, at some point? > > I'm not sure. The earliest C++ compiler used C as an > intermediate language, so could easily be ported to any machine > on which C ran. Good point. >> One other serious legacy flaw in D (inherited from C/C++) is that it >> doesn't do away with undefined behavior. It's close, I think, but it's >> unfortunate that the holes aren't closed entirely. > > No language manages to completely do away with undefined > behavior. Although C++ could surely do better in this regard; > there's a lot of unnecessary undefined behavior. I have doubts about that first assertion. Surely there are academic languages out there that do. Moreover, I wasn't aware that fully-managed (e.g. no unsafe/PInvoke), CLS-compliant C# contained any UB. Does it? I also think pure ECMAScript is safe in that regard. >>> However, what is important is whether a programmer can do his/her task >>> efficiently with the language and the associated tools, not whether it >>> is done by the core language or by the standard library or by a >>> third-party library. Whether a language facilitates good libraries or it >>> hinders good development tools, much of the credit/blame is to the language. > >> 'Efficiently' is the key. Adding certain things to the core language can >> improve efficiency by an order of magnitude. "Can be done at all" isn't >> the same as "can be done simply and easily." :) > > Formally, if it is part of the standard library, the compiler > can know about it, and do whatever is necessary. This is often > the case for standard library functions (like memcpy) in C. To > date, it's not become the case for anything in C++, at least to > my knowledge, although the standard certainly allows it. I > think, however, that part of the goal is to design things so > that the compiler can do the job well, not just for standard > components, but for any user defined class. I think this is what Walter disagrees with. If you're gonna make a special case for some part of the "standard" library, then why not make that feature part of the "core" language in the first place? You get the advantage of nicer syntax and semantics with the advantage of clean, intrinsic compiler support without having to "cheat" with a "magic" library (which is what he called the worst of both worlds). Cheers, -Al.
From: Andrei Alexandrescu (See Website For Email) on 21 Nov 2006 05:55 Frederick Gotham wrote: > Walter Bright: > >> I agree with the need for getting rid of undefined behavior as much as >> possible, but in a systems oriented language it's hard to see how it can >> be gotten rid of completely. > > > My opinion is the total opposite: Leave behaviour as undefined all over the > place giving plenty of freedom to the implementation. Ouch. Unless this is a joke, I can only be happy that your opinion isn't shared by many :o). Why would you think undefined (I think you really meant "unspecified") behavior is a good thing? 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 21 Nov 2006 05:54 Walter Bright wrote: >> But... From that point of view, the fact that some things can be >> effectively relegated to the library, rather than be implemented >> in the core langage, would be a symptom of an advantage in the >> language. (Supposing, of course, that the functionality in the >> two cases was equivalent.) > > The problem is, the functionality is not equivalent. If it was, why are > there proposals to, for example, add new basic types to core C++ to > support UTF strings? I think it would be goofy to limit comparison to core features. Otherwise a language with configurable syntax that allows things like custom statements, user-defined literals etc. will come last as they have a very small core. Comparing how a library implementation fares versus a core language approach towards the same feature is more to the point. But let's not forget one important detail. The disadvantage of core implementation is the absolute dictatorship of the entity that defines the language. I view that as a major drawback. The obvious disadvantages of library-side implementations (less natural syntax, less opportunities for optimization etc.) should be considered in balance with the democracy advantage they enjoy. Therefore, I'm personally way more enthused by languages that offer their user access to (meta)liguistic tools, rather than languages that are closely bounded by the view, limits, creativity, bias, preferences of their creator. Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 21 Nov 2006 07:03
AJ wrote: > Frederick Gotham wrote: > > Walter Bright: > >> I agree with the need for getting rid of undefined behavior as much as > >> possible, but in a systems oriented language it's hard to see how it can > >> be gotten rid of completely. > > My opinion is the total opposite: Leave behaviour as undefined all over the > > place giving plenty of freedom to the implementation. > My knowledge of C++ compiler internals is not very extensive. However, I > still find this "wild-west" mentality kind of detrimental for the end-user. Very. There are a lot of cases where the undefined behavior really isn't necessary. Java doesn't allow any freedom whatsoever with regards to order of initialization, for example, and yet Java regularly beats C++ in terms of speed when dealing strictly with basic types. > Can someone with a C++ implementation background actually confirm that > the great hassle that is UB significantly benefits the implementation? Well, if multithreading is taken into account... The current C++ standard doesn't address the issue, but I would expect that modifying a variable from two different threads will be undefined behavior. Giving it a defined meaning would almost mean putting a lock around each access, which is really not acceptable, and for the compiler to detect which variables cannot be accessed from more than one thread at a time is far beyond any known compiler technology today. Not the implementation, of course, but as Walter has pointed out, there are also cases where the purpose of undefined behavior is to let the implementation define something sensible for the environment where it runs. You couldn't do memory mapped IO, for example, without exploiting undefined behavior that the implementation has "defined". > That is to say, that the benefit outweighs its cost? I think that a lot > of UB doesn't actually help anyone and is just there out of > carelessness, or laziness. Mainly historical reasons, I think. When C was first being developped, using Sethi-Ulmann numbers were state of the art optimizing, and they imply being able to reorder exceptions. Today, of course, opimization techniques have evolved immensely, and in practice, I don't think that this freedom really buys the implementation much. > Perhaps just for C compat? If so, this simply > passes the buck to C. > It'd also be interesting to hear from people familiar with the upcoming > C++ standard about whether UB is being mitigated in any way. We're adding to it:-). We can't avoid adding to it, since we are adding support for threading---and thus, a whole new realm of possible undefined behaviors. It would be nice if we did define things like the order of evaluation, but there doesn't seem to be a consensus to do so. -- 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! ] |