From: Walter Bright on
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 for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Gabriel Dos Reis on
Walter Bright <walter(a)> 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

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
David Abrahams wrote:
> Walter Bright <walter(a)> 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 for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Peter Dimov on
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 for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Peter Dimov on
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 for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]