The D Programming Language
in [C++]
|
From: James Kanze on 26 Nov 2006 14:18 Andrei Alexandrescu (See Website For Email) wrote: > James Kanze wrote: > > Andrei Alexandrescu (See Website For Email) wrote: > >> James Kanze wrote: > >>> AJ wrote: > >>>> 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. > >> (Late in the thread, but this cannot be let slip away.) Whatever > >> happened to all languages that do manage to completely do away with > >> undefined behavior? > > Name one. I'm unaware of any. > Java, Lisp, Scheme, ML, Haskell, Ocaml. Java definitly has undefined behavior. The little I've seen of Lisp and Scheme do as well, or at least, I've not seen how the behavior is defined. I don't know the others at all, so I cannot comment. > >> I'm asking this again: it would be best if we all refrained from "I'll > >> qualify it on-demand" statements. > > Well, I suppose that if you exclude support for threading, it > > might be possible. > Java has threads and no undefined behavior. Java has undefined behavior. > I don't know Ocaml but I > recall there is a parallel version of it, which probably also doesn't > have undefined behavior. > > But as far as I know, no language even comes > > close. If nothing else, most older languages don't define the > > case of insufficient ressources---some dialects of Lisp, for > > example, say that in case of overflow in integral arithmetic, > > they switch to an extended format, but they don't say what > > happens when the extended format gets too big to fit in memory. > > And most modern languages support threads, and I'm fairly > > convinced that it is currently impossible to support threads > > without undefined behavior---it would mean being able to > > statically diagnose thread-safety. > 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. -- 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! ]
From: Gabriel Dos Reis on 26 Nov 2006 14:15 "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail(a)erdani.org> writes: [...] | > I'd like to get D to the point where analysts can say: "finally, I can | > ditch the old FORTRAN war horse and move on to a modern language that | > actually caters to my needs." For that to happen, complex and vector | > math support has to be top drawer. What's wrong with C++ complex support | > has already been discussed, it isn't all currently fixable using UDT | > techniques. | | Here's exactly where the mistake begins. It isn't all currently fixable | using ___C++'s___ UDT techniques. It would be great if you developed | better UDT techniques. Then instead of saying "look, I can put a complex | in two registers!" you can say "look, I can put any two-floats structure | in two registers!" etc. I would like to inject some facts in this sub-discussion: the idea of putting complex in registers, in current compilers, is more dictated by ABIs than intrinsic C++ linguistic reasons. The are dumb ABIs, say x86, that put them on stack passes their addresses, and there other ABIs, e.g. PowerPC, that use registers. The allegation that if it is UDT it ain't fixable is FUD. -- 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: James Kanze on 26 Nov 2006 14:20 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. -- 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! ]
From: Peter Dimov on 26 Nov 2006 14:19 Walter Bright wrote: > Nemanja Trifunovic wrote: > > Walter Bright wrote: > >> Nemanja Trifunovic wrote: > >>> Walter Bright wrote: > >>>> 1) Extend std::string to support UTF-8. > >>> Ehm: http://utfcpp.sourceforge.net/ > >> The class supports UTF-8, but not by extending std::string. It uses > >> std::vector, for example. > >> > > > > The set of template functions (not a class) is meant to be used with > > sequences of bytes, including char[], std::string or vector<char>. The > > point of my post is that a utf-8 encoded string may be stored into a > > std::string object just fine, and then some of the common string > > operations would require a little help from a library like the above > > mentioned one. > > That doesn't help it work with other libraries that use plain > std::string and depend on it to work as specified. They'll fall over as > soon as they see a UTF-8 encoding. In theory, they ought to fail. In practice, most of them work just fine. That's the beauty of UTF-8. In-place character manipulation doesn't work in general anyway, even for an ordinary single-byte encoding. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bjørn Roald on 26 Nov 2006 21:45
Walter Bright wrote: > Python is a much younger language than C++, yet has the wider variety of > libraries. I think that's a big indicator that the productivity of > Python is not just faster compiles. This seems to apply to the lot of popular newer languages (development environments) - Python, Ruby, Perl, Java, C#(or .Net in general). I have many times wondered why C++ seems to be so unsuccessful in the library area. My assessment is that there are plenty of C++ libraries in most or all areas, but their accessibility and relevance for particular platform and project seems to limit the adaption or usefulness. Traditionally the commercial C++ compilers has been supplied with framework libraries in addition to the C++ standard libraries. Compiler vendors may do this to add features to the development platform, but other goals, less desirable for the larger success of C++ may also be behind such choices. I think C++ lack acceptable relevant libraries for the following reasons: 1. It is hard to find existing relevant libraries that could be accepted for projects. They are mostly: - not standardized - not shipped with compiler - not portable or ported to all needed platforms - not well known and trusted - not part of a community repository like CPAN for Perl 2. If relevant library exist for C++ it can often not be accepted in projects for the following reasons: a) legal concerns related to license terms b) platform compatibility c) known cost d) lack of relevant support e) risk related to future directions, continuation, or cost f) lack of legal entity responsible for intellectual property issues g) dependency is not desirable h) dependency issues pushed on customer if project is a library i) conflicting use of names or versions of 3'rd party libs 3. Most libraries for C++ are developed to earn well deserved money. However the target users are often limited to specific runtime platform or compiler. Some times this is done to limit usefulness of other platforms or a competing compiler. There is little incentive to make library available for every C++ programmer on the planet. C++ programs are usually effective, in addition they are also attractive to commercial projects because they support the closed code model. Java and C# does the same, but they have extensive standardized library support from the primary language/tool vendor. C++ lack similar support from a single entity which effectively define standardized libraries. Users of C++ tend to be pragmatic. They select the tool that get the job done. Often this cause them to favor accessible compiler supplied, but less portable, libraries rather than 3'rd party portable ones. If the portability is not required, projects often selects e.g. MFC or other options supplied with the compiler. Heck, I believe most projects does not even have a deliberate decision as whether this is acceptable. It just seem to be happening because it is there in the IDE when the programmer have a problem to solve. These days C++/CLI is used to bridge C++ projects to .Net libraries for the exact same reason. All this is not good for the future of standardized library support in C++. Things do move in the right direction regarding standardization, however the process is to slow. Some notable projects such as Boost, AGG(up to v2.4), ACE/TAO, Adobe open source, and others, provide accessibility close to that of the standard library. Also many 3'rd party open source and/or commercial libraries are excellent proof of relevant libraries in C++, Qt comes to my mind. However, they can hardly compete with accessibility of libs supplied with the IDE, at least as long as those are not disqualified by project policy. To summarize: C++ does not lack libraries, usually there are too many of them doing the same thing. And none of those are standardized with all compilers and platforms. Most developers of C++ libraries lack the incentive to work for standardization or even making them available, other motives closer to their business competitive edge is controlling their direction. If this could be changed I believe in a much better future for the language. So I think the issue is how this can be changed. One can always hope a large or specially skilled company took charge in the standardization process, but that is not something I will be waiting for. ----- Bj�rn Roald -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |