From: Walter Bright on 27 Nov 2006 17:49 werasm wrote: > Does D, BTW. support other paradigms (I'm not > counting concurrent programming as a paradigm, since I've been using > C++ to do that for some time now)? From the little I've seen it does > seem to support TMP better, but I'm not the one to debate that - others > are more qualified. In some way I do think, wrt. the TMP paradigm, D > stands towards C++ as C++ stood towards C in the OOP paradigm. One can > program in OOP fashion using C, but it is not natural. One can do TMP > with C++ but with D, is it more natural? I have not found C++ > templates that unnatural for the cause, though. The problem with TMP in C++ is it was discovered, not designed. When templates were designed for C++, nobody realized that it could actually be used as a compile time functional programming language itself. Now that we know what TMP is, and what people are trying to do with it, it opens the door wide to a redesign of templates to make TMP much easier to do. >> Finally we should be careful about comparing like with like. The >> interesting features of languages like Ruby and Python is that the come >> from a very different ancestry (that of scripting languages) > I don't disagree. Eventually the advantages/disadvantages of ancestry > may be compared, and certain descendents may disappear altogether. Examination of the strengths of other languages enables thinking outside of the box. Otherwise, you're restricted to thinking about only incremental improvements. -- [ 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 27 Nov 2006 17:46 Walter Bright <walter(a)digitalmars-nospamm.com> writes: [...] | > 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. | | Inlining a function doesn't necessarily imply replacing a reference type | with a value type. most certainly, and there are incompetent compilers that cannot see that a reference type is not need after inlining. Fortunately, more capable compilers are around, and they just ditch the references when and where appropriate for their taste. -- 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: Walter Bright on 27 Nov 2006 17:50 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. They don't have to get the right answer, though. And that's what makes game numerics different, and not *serious* numerical analysis. Game numerics is all about speed, not accuracy. That's why there are vector float instructions now in the x86. Serious numerical analysts have to pay attention to creeping roundoff error, gradual underflow, etc. After all, like I said before, you don't want your Mars lander retro rockets to be programmed to fire 10 feet below the surface after traveling 100000000000 miles. With a game, who cares? I was playing the "Simpsons" game the other day, and you could easily get into situations where things were clipped halfway through a wall, where Homer is driving his car but is drawn offset from it, and even one where the elements of the scenes were flipped in a crazy manner (looks like some sort of sign error in the calcs). Like I said, who cares? But when your airplane elevator servo mechanism goes unstable at 30,000 feet and tears itself to pieces because your numerical integration program calculated the wrong value for the spring rate, you better believe people care. And when languages are dumbed down to the lowest common floating point denominator, they aren't going to be used by those who must care about it. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Dimov on 27 Nov 2006 17:56 Walter Bright wrote: > James Kanze wrote: > > Walter Bright wrote: > >> 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. > > That would include 100% of current implementations. #include <complex> inline std::complex<double> f( int x ) { return std::complex<double>( x, 0 ); } int main() { return ( f( 1 ) + f( 2 ) ).real(); } Compiler output: (MSVC 8) _main PROC ; 10 : return ( f( 1 ) + f( 2 ) ).real(); mov eax, 3 ; 11 : } ret 0 _main ENDP If I make it int main() { return ( f( 1 ) + f( rand() ) ).real(); } the result is less convincing: _main PROC ; 10 : { push ecx ; 11 : return ( f( 1 ) + f( rand() ) ).real(); call _rand mov DWORD PTR tv147[esp+4], eax fild DWORD PTR tv147[esp+4] fadd QWORD PTR __real(a)3ff0000000000000 ; 12 : } add esp, 4 ; 11 : return ( f( 1 ) + f( rand() ) ).real(); jmp __ftol2_sse _main ENDP but still no complex<> in sight. One must make sure to use the static runtime, though; the DLL runtime has complex<>::operator+ as an exported function, which is an odd decision. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Dimov on 27 Nov 2006 17:55
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. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |