The D Programming Language
in [C++]
|
From: Mirek Fidler on 4 Dec 2006 10:33 James Kanze wrote: > I'm not sure it makes an important difference, since a compiler > is free to inline any function it likes (and some compilers do > inline functions not declared inline, if the profiler says they > should). Of course, I am speaking about THIS kind of inlining... The reason why I want to be sure is that if I understand Walter well, his description of 'why we need complex fundamental type to store it in the register' deals with returning of values from non-inlined functions, with ABI used by DMC++ /x86-32. Therefore it is practically irrelevant for complex type in most C++ implementations which will be inlined in most cases. Mirek -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 4 Dec 2006 10:30 Vidar Hasfjord wrote: >> People simply /expect/ an array to automatically know its size. > > Actually, an array in C++ knows its size --- its part of the type. In > native C++, i.e. without using library features, the above is expressed > as: > > int a [] = {1, 2, 3, 42, 666}; > cout << sizeof a / sizeof a [0] << endl; // 5 > > Of course the native array has static size, and some may argue that's > not very useful. Personally, I consider the static array the most > fundamental building block of a system programming language, because it > is so closely related to the von Neumann addressable memory model. In > fact, references/proxies, pointers, dynamic arrays and strings can be > built in terms of the static array. > > Unfortunately, the irregular treatment of the native array in C++ is > IMHO the most fundamental and ugliest wart of the language. The way its > type decays when passed around is simply traitorous. In C++, core arrays have one subset of needed array features, and std::vector has the other subset of needed array features. The problem is the two don't combine with each other to create full featured arrays. BTW, the array example in D would be: int[] a = [1, 2, 3, 42, 66]; writefln(a.length); -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jean-Marc Bourguet on 4 Dec 2006 13:15 David Abrahams <dave(a)boost-consulting.com> writes: > Jean-Marc Bourguet <jm(a)bourguet.org> writes: > > > "Andrei Alexandrescu (See Website For Email)" > > <SeeWebsiteForEmail(a)erdani.org> writes: > > > >> Well the only thing I can add is that in my limited experience, > >> debugging Java programs is much easier because there's never the case > >> that a dangling pointer misteriously overwrites some object it wasn't > >> supposed to. > > > > Instead you are writing to an object which was supposed to be out of > > existence for a long time. In my experience, that give you the same kind > > of elusive bugs. Excepted that purify can't help you > > I want to emphasize that point: when nothing is truly illegal (like > those things that C++ says cause undefined behavior), there's no way a > tool like Purify can tell you that the program did something wrong. > > > and that random behaviour including crashes are replaced by > > deterministic, often plausible but wrong results. > > Of course that can happen in a system with undefined behavior, too. > That said, it looks like a wash to me: incorrect programs have > different characteristics under the two systems but neither one wins > in terms of debuggability. Detection of the problem is easier when the behavior is non deterministic: at worse it is the same as the deterministic one, at best it is a very visible crash or detected by some tools. Debuggability is helped by tools; but more by the fact that you had to design in another way. With GC being sold by some as the solution to all memory management, most people don't think as much about the problem, and very few put in place the infrastructure you have to put in place when doing manual management. Security is better for more specified langages... some problems stay the same, but it is less easy to abuse some bugs. Yours -- Jean-Marc [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: PeteK on 4 Dec 2006 13:17 Al wrote: > Hi, > > I'm kind of curious about the inline keyword. If the compiler is allowed to: > > a) Ignore it when it appears (i.e. not inline). > b) Ignore its omission when it doesn't appear (i.e. force inline). > > Then what exactly is the point of it? Why not just let the compiler deal > entirely with the efficiency of inlining by itself? Clearly, from the > points above, the programmer has zero control over what actual inlining > goes on, so why pretend that they do via a bogus keyword? It seems like > it just needlessly complicates the function specifier set. > > Thanks. > -Al. > It allows you to define the same function in multiple translation units. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 4 Dec 2006 13:16
David Abrahams wrote: > "James Kanze" <james.kanze(a)gmail.com> writes: > > I'd even go further and say that I prefer the Java > > solution of consistently doing the wrong thing to that of C++, > > which results in inconsistent and untestable behavior. > I agree that the behavior is often inconsistent. I disagree that it's > untestable in practice. One of my points is that labelling some > behavior undefined can improve testability, because the system can > then things observably outside the realm of defined behavior. If the system defines the behavior to do the right thing, that's obviously even better than consistently doing the wrong thing. I think Andrei's point is that 1) C++ doesn't require this of the system, and 2) most systems don't really make too many additional guarantees in this regard. In particular, there's no guarantee that an invalid pointer will crash the program---my experience has been that most invalid pointers are a result of using already freed memory, and without Purify, it's pretty much guaranteed (at least under Solaris and Linux) that using such a pointer won't crash the system immediately. > It's > true that it's a crapshoot whether the behavior of most running C++ > programs will be observably undefined, but that is technically > speaking an implementation artifact, for efficiency. There's no > reason in principle that a C++ system couldn't be written that > immediately detects way, _way_ more of the errors that lead to > undefined behavior and invokes a debugger immediately. Every pointer > dereference could be fully checked, for example. More or less what Purify does, in other words. Or (I think) CenterLine used to do. Regretfully, very few implementations do this, and none that I know combine it with intermodule optimization, which would allow suppression of the checks when the compiler could prove that they would succeed. (I seem to recall reading a study on bounds checking in Pascal that found that the compiler could eliminate 80% of the checks, including almost all in tight loops. Which means that full runtime checking is affordable, if the compilers want to do it.) > > Undefined behavior is bad, > I don't think that's been demonstrated, and I challenge it as an > axiom. I don't see too much where it's challengeable. You certainly aren't arguing for inconsistent and untestable behavior. If I understand you correctly, you're arguing for implementations to define the behavior which the standard leaves undefined. When I say that undefined behavior is bad, I mean truly undefined behavior, defined neither by the language nor by the implementation. > Whether undefined behavior is badly expressed in today's running C++ > programs is another matter. I think that Andrei's point was that as soon as you start restricting how it is expressed, it's no longer totally undefined. I'm not sure that I completely agree with him, but as a practical matter today, there's far too much undefined behavior in C++, and the implementations aren't exploiting it to produce more robust applications. -- 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! ] |