The D Programming Language
in [C++]
|
From: hasta_l3 on 27 Nov 2006 17:58 { All posters are encouraged to stay on-topic and keep the postings related to C++. -mod/sk } Walter Bright wrote : > James Kanze wrote: > > As for a million words... I'd say that any language had that > > many, if you count all of the technical words (e.g. names of > > diseases, scientific names of plants and animals, ...). > > I was counting them, and no other language has made such > an accumulation of them. FWIW, the one million figure is IMO an artifact of the way words are counted. Languages like french have official monitoring organisms, that drop obsolete words from the language, are usually very cautious before accepting new words, and often don't include dialects in the official language. By contrast, the one million figure of english most likely comes from the Oxford English Corpus, that collects words from a as many sources as possible, and includes british, american, australian english as well as obsolete words and one-off coinages. The Oxford way of counting words is bound to give a larger figure than the "official" number of words in a more formalized language. At any rate, dictionaries have the same size in english, french and german (roughly 50.000 words) - meaning that these languages have the same number of words for all practical purpose. http://www.askoxford.com/oec/mainpage/oec02/?view=uk -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 27 Nov 2006 18:01 Mirek Fidler wrote: > In reality, I see no reason why good compiler could not optimize out a > reference. In your example, the struct was not placed into a register. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Al on 27 Nov 2006 18:00 Hi, David Abrahams wrote: > 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. While current games do indeed use sophisticated physics, most of this work is relegated to specific libraries (e.g. havok, physx), or engines (e.g. unreal ragdoll physics) or even dedicated cards (i.e. the ageia ppu). Therefore, I doubt that most programmers, even those on game dev teams, directly interact with any numerical analysis code. On that vein, when can we expect #include <physics> to be part of the STL? ;) Cheers, -Al. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 27 Nov 2006 21:18 Peter Dimov wrote: > Walter Bright wrote: >> Peter Dimov wrote: >>> 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. >> Having them 'mostly' work isn't good enough. Searching doesn't work, for >> example. > > I believe that it does. Nope: size_type find (charT c, size_type pos = 0) const; What if c isn't ASCII? Consider this snippet from the Standard: string s1("abc"); string::iterator i = s1.begin(); string s2 = s1; *i = �a�; How is that supposed to work, if 'a' is not ASCII? -- [ 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 27 Nov 2006 21:25
Francis Glassborow wrote: > In article <4569c5cf(a)news.broadpark.no>, Bj�rn Roald <bjorn(a)4roald.org> > writes >> 1. >> It is hard to find existing relevant libraries that could be accepted >> for projects. They are mostly: >> - not standardized > > And how is that different from Java, C# etc. My point is that those usually have plenty of library support shipped with the compiler as e.g. in the JDK, .Net development platforms. >> - not shipped with compiler > Ditto As they are not standardized, as in "come standard with all compilers from all vendors", they tend not to be found or used. >> - not portable or ported to all needed platforms > However languages like Java, C# etc use a VM to circumvent that problem > and generally do not try to provide for embedded systems. Note that were > CLI widely implemented the C++/CLI dialect of C++ would reap the same > benefit. But then it would not be C++, would it. I tend to think mixed code under C++/CLI is good to bridge two worlds - but that is about it. Most people I know selecting .Net as platform prefer other languages. >> - not well known and trusted > Oh? Well I do not trust most of the libraries written for those other > languages. Many of them are simply of inadequate quality for mission > critical programming. Yeh, I tend to agree. I do however think most developers and to a larger extent their management think libraries that comes with the compiler is of a higher quality than most other. I fail to see why that is a bad way of looking at things in general. The point is, it is hard to know which other libraries out there hold similar or better quality. > Another issue is that languages like Python are not portable in time > because the language does not maintain portability of legacy code. Probably true, I am no expert on this. But how is that better for C++ libraries that are not standardized? >> - not part of a community repository like CPAN for Perl > > IIRC their is very little quality control for code available that way. > Boost for C++ sets very high requirements. Perhaps we could do with a > repository with lesser entry requirements. Yes, I think that would be good thing. Maybe not required to be a new home for all libraries that want to enter. But rather a place where one can find and compare candidate libraries for the problem domain. Information that indicate properties like quality, legal issues, license, stability of interfaces, support options, user feed-back, etc. could be organized in a way making things easier for those who search or attempt to get permission from management or legal department. >> 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 > Really, and that is different for other languages? Usually terms for libraries that are shipped with compilers are ok. Well normally you have already been given or paid for the right to use them. Thus, since these languages come with more standard or community libraries, their support for application level features are more accessible. >> b) platform compatibility > See above Well, above you only explain why it is harder to write portable libraries in C++ than WM based languages. That does not explain why many C++ library vendors tend to ignore all but one platform. >> c) known cost > ? What do you mean? Only that if it comes with the compiler it becomes simpler to know. If libraries or their interfaces are standardized as well, and there are competing compiler/library vendors, it becomes harder to get caught in the net of some commercial tie-up scheme. >> d) lack of relevant support > How is that different for Java etc. Good point. I guess I was generalizing to much. There are of case plenty of C++ libraries with excellent support in many shapes and forms. It was not my intention to say otherwise. It is however much harder to secure relevant support for a multitude of 3'rd party libraries in C++, compared to if I could get it all from one vendor. I know for a fact that this often disqualify otherwise excellent libraries. >> e) risk related to future directions, continuation, or cost > Even worse for many of the languages you listed. One high price for C++ > is the requirement for supporting legacy code. Well that may be true, but my point was related to none standardized or community libraries. E.i. third party commercial libraries in particular. >> f) lack of legal entity responsible for intellectual property issues > You are joking aren't you? No, If I have nobody to blame for the stealing. Everybody would look at me. If I use some library which happens, knowingly or not, to have wrongfully used others intellectual property, then I may be liable for those damages. The problem here is actually with some void entities that are carefully crafted to avoid those issued. One example is Boost, you can not make a lawsuit against Boost if some Boost library violates your intellectual property. You could possibly attempt to go after the author, but that is very unlikely to give high returns. The next option is to go after the users. This is a scary scenario for many paranoid legal departments of those potential users. These lawyers tend to be listened to by unwise management of those potential users. More often than they should, such potential users never become more than potentials. The library is not accessible. I use the word unwise here because the actual legal risk related to use of libraries like Boost are extremely small compared to the benefits. This is however a challenge, and anything we can do to make it simpler to adapt the good C++ libraries out there need to be considered. >> g) dependency is not desirable > On what? If a candidate library has dependency to other 3'rd party library which again.... sometimes these never seems to end. If a candidate library has dependency to other 3'rd party library with some legal issue incompatible with our product. If a candidate library has dependency to other 3'rd party library which some other library we use depend on a different version of.... .... and many other scenarios. >> h) dependency issues pushed on customer if project is a library > ? explain Ok, if I make a library. Then it is simpler, much simpler, to depend on libraries I know comes with the compiler of my customer than to force my customer to depend on 3'rd party libraries and the exact version of those picked by me. Note also how I would cause issues in g) above for my customer. For open source libraries that can be configured and build by the user dependency issues like those above can be worked around, but not without a lot of added complexity. >> i) conflicting use of names or versions of 3'rd party libs > And that is different for languages like Java? C++ provides good tools > for avoiding such problems in the first place (namespaces) If I use a library that internally uses Boost 1.32.1 and I want to use Boost 1.34.0. How can I be sure it will work. If I use libraries that are not header-only it will surely not work. If too much is exposed in headers, it may fail for other reasons. Yes proper use of namespaces helps a lot. However better encapsulation of symbols in modules are needed at the language level. I am hopeful for this in upcoming C++0x. --- Bj�rn Roald -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |