Re: Segmentation faultwhy???
Sebastian Redl wrote:
Cristian wrote:
#include <vector>
#include <iostream>
#include <cmath>
#include <string>
#include <time.h>
Why not <ctime>?
Probably because there is no conformant version available. (To
my knowledge, no compiler today comes with a conformant <ctime>.
Or a conformant <canythingelse>.) At least with <time.h>, you
know pretty much what you are getting.
The real question is why <cmath>, instead of <math.h>?
And why no "#include <ostream>", which the standard would also
require for his code.
using namespace std;
int main( ) {
long i, j ;
long dim1=10000, dim2=1000 ;
double m[dim1][dim2];
Declaring an array with non-const bounds is invalid and does
not compile. In addition, if it did compile, the array would
be (assuming an 8-byte double, as is typical) 80 megabytes
large, and allocated on the stack. Many operating systems will
not allow this, including Windows and, I think, Linux.
Every Unix I've ever worked on allows it. If you ask nicely --
usually, when the stack gets this big, it's a bug, so by
default, the system will limit the stack to some user defined
amount (by default, 8 MB on Solaris, 10 MB on the Linux
installed here). But the user can change this. (I would not
recommend changing it globally, but starting the program which
needs it from a shell script which changes it just for that one
program.)
Of course, I'm not saying it's a good idea to allocate things of
this size on the stack.
for ( i=0,n=0 ; i < dim1 ; i++ ) {
n is not declared. It's not used, either.
for ( j=0 ; j < dim2 ; j++) {
m[i][j] = (double) ( (j+1) + 3.0 *1/(j+1)*(j+1)*(j+1)*(j+1) + 50*
(i+1) );
No need for the cast (and it should be a static_cast anyway),
That's really a question of style. A lot of people prefer
explicit conversions over implicit -- if you know there is a
conversion, why hide it from the reader. And I know of almost
no one who uses static_cast systematically. Function style cast
seems to be preferred when converting to a class type, for
example. And I find that arithmetic types are conceptually
similar: I'm really creating a new object of the type. So I
don't (always) use static_cast for them, either.
but you should really think about operator precedence and
types within the expression here. In particular, the entire
middle expression will always yield 0.
I don't think so, although I'm not sure that it will do what he
wants. Inserting all the parentheses, we get:
(((((3.0 *1) /(j+1)) *(j+1)) *(j+1)) *(j+1))
He first multiplies 3.0 by 1 -- presumably, the compiler will
simply ignore this. He then divides the results (a double) by
(j+1) (resulting in a double), then immediately multiplies them
by (j+1). Which is a pretty useless thing to do, but I don't
think that the compiler can ignore it, since the results will
not always be exactly 3.0, given the way machine floating point
works. He then multiplies this result twice by (j+1) -- as far
as I can see, these are the only operations which will have an
effect on the results, except for the rounding errors introduced
by the first division and multiplication.
In sum, the expression is (almost) the same as the much simpler:
3.0 * (j+1) * (j+1 )
and the fact that he didn't write it this was suggests that it
isn't actually the expression he wanted. I vaguely suspect that
what he was looking for was something like:
3.0 / pow( j+1, 4 )
But I'm not really sure -- that's so much simpler than what he
wrote as well, it's surprising that he wouldn't use it.
--
James Kanze GABI Software
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! ]