Re: Generating Gaussian distributed random variable using C++

On 4 Aug, 16:03, Richard Dobson <richarddob...@xxxxxxxxxxxxxxxx>
wrote:
Rune Allnor wrote:

..



It seems that the credo in the C++ community is 'fast but
safe,' whereas in the C community it is 'as fast as possible.'

That seems a little too cynical to me. I am sure both C and C++
programmers want their programs to be both safe and as fast as possible.
The difference between them is, as I see it, that C programmers
recognize that the language is very "close to the hardware", so that the
sizes of int, long, char etc are system-dependent, and they code
accordingly.

I believe C99 defines data types with specified binary
formats, like 8 or 16-bit integers. There is no such thing
in C++. Yet. So it is impossible to write standards-complying
portable code for accessing binary files.

Something like defining M_PI is not really intended to be
portable (though it is ~most~ of the time), but to fit the platform. For
a long time now we have got accustomed to 32bit ints and longs; now we
have 8byte longs and 16byte long doubles to deal with.

Sure. And that creates all sorts of problems now that
64-bit platforms become more availble. Which is the
reason for using template libraries:

1) Who know the most details about any particular platform?
The compiler writers for that platform.
2) Whose repsonsibility is it to ensure that libraries
work at as many platform as possible? Library writers.

The problem occurs when other people than those who
know the hardware try to write portale, generally usable
libraries. Templates are 'just' a way to marry the
detailed knowledge of the compiler writers with the
problem-domain knowledge of the library writers.

I as library writer don't need to know any specific
details, as long as I know that the variable

std::numeric_limits<float>::epsilon()

is defined on all systems to which my code will be
ported. I leave it to the compiler vendors - who
need to know the system in excrutiating detail to
be able to do their job - to fill in the exact
numbers.

Specifically, I do not know on which platforms the
code I write today might be run in 10 or 20 years.
All I *need* to know is what details the standard
tells me will be available, and how to use them.

*I* don't care if the numerical accuracy is 1e-15
or 1e-38. All I need to know is how to use the
knowledge of that parameter for any given system
where the code is compiled.

The _compiler_writer_ needs to know all those details.
He passes that knoweldge on to C++ programmers through
the standard functions.

And possibly
fixed-point extensions too. There are programmers still living who
remember (if I have remembered them correctly!) nine-bit bytes, 36bit
integers and all manner of other oddities.

Sure. And there is no reason why I as programmer should
need to know about any of that. A standards-compying
compiler should releave the programmer from needing
to know any of that.

The C++ community in contrast (well the template gurus at least) seem to
be working very hard to get as much done by the compiler as possible, so
that the ideal executable program comprises little nothing more than
printing a result. Which will undoubtedly be fast!

If taken to the extreme - yes.

However, the dominating idea behind templates is that one
should write *one* piece of source code for any operation,
as opposed to many versions of the same algorithm, where
only data types change. If done correctly, this will make
the code safer and easier to maintain. If one find bugs,
one corrects the code in *one* location, and leaves the
compiler to correct all the specific instances where
the source code is used.

It removes quite a burden from the programmer.

And if C++ may have
been in its early days  reasonably "close to the hardware", it surely is
not now.

It is, but the general trend is to hide all those details
from the users. The idea is that programmers should need
to know as little as possible about the soecific details
of the system where the program is to be compiled and run.

But those details are only one template specialization
away from the user.

Rune
.

Relevant Pages

  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... what experienced programmers do, ... optimization, ... Thugs" ad nauseum fits that a lot more closely than discussing compiler ... be modified outside a loop, and guessing ...
    (comp.programming)
  • Re: Statement on Schildt submitted to wikipedia today
    ... to working programmers and more with being "right all the time, ... so that compiler developers could be shed ... The major corporate interests were compiler developers, ... processors, committed to standard division semantics, and otherwise ...
    (comp.lang.c.moderated)
  • Re: Interesting article by Randall Hyde
    ... as you are the compiler optimization "expert". ... of the work that has gone into creating optimizing compilers. ... > Compilers generate better code than *most* programmers all of the ... learn without needing to know anything about assembly language. ...
    (comp.lang.asm.x86)
  • Re: FC4 good new tech, bad legacy support
    ... Often programmers abuse weaknesses in the strictness of how a ... >compiler implements a programming language. ... because an older compiler version seems to accept source code ... >which it should not accept according to programming language standards. ...
    (Fedora)
  • Re: Integer types in embedded systems
    ... Notice the integer type I've used, ... compilers for 8-bit micros have an option for telling the compiler not ... Most C programmers these days are woefully ignorant, ... At least as important as portability, ...
    (comp.lang.c)