The D Programming Language
in [C++]
|
From: PeteK on 4 Dec 2006 13:18 Andrei Alexandrescu (See Website For Email) wrote: > David Abrahams wrote: > > "Andrei Alexandrescu (See Website For Email)" > >>But in a memory-safe program you don't even need Purify to tell you that > >>the program did something wrong. A logging module would suffice, and the > >>proof is in the trace. > > > > > > a. I don't see how the logging module can do that > > b. Anyway, that's often far too late to actually debug the problem. > > Am I not getting a joke? Logs are the _best_ way to debug a program. > There is NO "best" way to debug a program. There are lots of different tools you can use, of which logs are just one. -- [ 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 15:23 Al wrote: > Hi, > James Kanze wrote: > > Mirek Fidler wrote: > >> Walter Bright wrote: > >>> Nevin :-] Liber wrote: > >>>> So what is it about C++ that is stopping you from applying the > >>>> optimization you use for the intrinsic complex to std::complex (and > >>>> then, in general, to objects that have a similar form to std::complex)? > >>> Having constructors causes problems for it. Even though indirection can > >>> often be removed by the optimizer, the decisions about how returns are > >>> done are made in the parsing stage, because it affects how constructors > >>> are set up to get the return type built on the caller's stack. The > >>> optimizer/code generator really only see the C-like result of all that. > >> Just to keep things clear, we are here speaking about non-inlined > >> functions, are we? > > 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). > 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? It's a hint. It also allows (and requires) providing the definition in each compilation unit. While this doesn't make a difference to the best compilers, such compiler technology is still far from universal. > Why not just let the compiler deal > entirely with the efficiency of inlining by itself? Because getting it right is at the very limit of current technology, and most compilers aren't that advanced. Think about register. When I was learning C, we made extensive use of register, as soon as we had information from the profiler as to where it was needed. Most compilers back then weren't good enough to allocate registers optimally themselves. Today, the technology has evolved, and nobody uses register anymore---it's often counter productive, because even the most everyday compiler can do a better job. I expect that in ten or fifteen years, the same will be said of inline, but we're very far from being there yet. > 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. It's a hint. And you never use it until the profiler says you must, so for most people, it's pratically as if the language didn't have it. -- 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: James Kanze on 4 Dec 2006 15:21 Andrei Alexandrescu (See Website For Email) wrote: > David Abrahams wrote: > > Meaning that in Java, all writes of "references" (a.k.a. pointers) are > > synchronized? > That is correct. They are guaranteed to be atomic; there is no invalid > reference in Java, ever, period. For a particular definition of "invalid". As Jean-Marc pointed out, you can very easily end up with pointers to invalid objects. I think you and I basically agree here (based at least partially on earlier discussions concerning garbage collection). There is an enhanced degree of safety in Java in this regard. But I don't like statements like "there is no invalid reference" or "you cannot leak memory" (which one often hears)---they give a false sense of security. It's much easier to protect against accidentally using an invalid object, since the memory containing the object cannot be used for any other use as long as there is a pointer to it, but the object may still be invalid. In a very real sense, the problem with C++ here isn't that you cannot have a pointer to an invalid object, it's that a pointer can suddenly end up pointing to some totally unrelated object---the memory for a dead object can be recycled while there are still pointers to it in existance. And that you can have pointers to non-objects, but in practice, that's less of a problem, because using such pointers generally results in a core dump very quickly. -- 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 4 Dec 2006 15:26 Walter Bright <walter(a)digitalmars-nospamm.com> writes: [...] | 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); What about std::tr1::array? -- 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: Peter Dimov on 4 Dec 2006 15:25
Al wrote: > 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? It allows the function definition to appear in multiple translation units. In practice, this means that you can place it in a header file. This makes the definition visible wherever the function is used, making inlining easier even when the compiler operates on a single translation unit at a time. In "whole program optimization" mode this makes no difference as the compiler sees the entire program. Even then, there's usually an option to force it to honor your inline hints. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |