i have used srand(time(0)) in my program to generate random numbers ,the problem is my compiler shows an error that call of overloaded 'srand(time_t)' is ambiguous.i don't know what have i done wrong.
please help. i wanted to generate random numbers to be used in my minesweeper program , but it is giving this error. normally in any other program where i am simply outputting the value it works okay , but in this case i am initializing the random value to a variable. i don't know what to do
It means you have a non-standard overload of srand declared somewhere for some reason.
Either seek and destroy the rogue overload; or specify std::srand (if your standard library implementation isn't at fault); or convert the argument type to unsigned int to unambiguously choose the standard one.
Also, have a look at the new(ish) C++ random number library: http://en.cppreference.com/w/cpp/numeric/random. It's a bit more complicated, but much more flexible, and without the evil of global state.
Related
Umm I've came across a problem in Fortran where I need to use Equivalence for a variable which is already declared in a module written by someone else(Probably is dead by now, otherwise I would have contacted him/her).
The variable in the module is of REAL type. And I want to store a INTEGER value in it.
If I do so directly, wrong data gets stored in the REAL type.
I have tried to use equivalence in module, But no luck.
Any Help ?
Well, EQUIVALENCE is an old keyword which should be avoided in modern Fortran because it makes the code misleading, but it has not been eliminated from Fortran standard yet, AFAIK.
However, if you have just the need to store the bit-by-bit representation of a integer in a real variable, I'd rather suggest to use the intrinsic function TRANSFER which literally transfers the binary contents of a variable to a variable of another type without any conversion and without raising errors. So, assuming that your real module variable is x and your integer value is i you can simply do:
x = TRANSFER(i,x)
The second argument could be any real variable, not necessarily x itself, it just gives a hint to the compiler that the result is of real type and it should not be an error to assign it to a real variable.
So I'm writing a bit of code that needs to raise a function's return value to a certain power. I recently discovered that using the '^' operator for exponentiation is useless because in C++ it is actually an XOR operator or something like that. Now here's the code I want to write:
int answer = pow(base, raisingTo(power));
Now can anyone tell me if this is right? I'll explain the code. I've declared an int variable answer as you all are aware of, and initialized it to the value of any variable called 'base', raised to the return value of the raisingTo() function acting on any other variable called 'power'. When I do this (and I edit & compile my code in Visual C++ 2010 Express Edition), a red dash appears under the word 'pow' and an error appears saying: "more than one instance of overloaded function 'pow' matches the argument list"Can someone please solve this problem for me? And could you guys also explain to me how this whole pow() function actually works, cos frankly www.cplusplus.com references are a little confusing as I am still only a beginner!
The documentation states it pretty explicitly already:
The pow(int, int) overload is no longer available. If you use this overload, the compiler may emit C2668 [EDIT: That's the error you get]. To avoid this problem, cast the first parameter to double, float, or long double.
Also, to calculate basepower you just write
pow(base, power)
And with above hint:
int result = (int) pow((double)base, power);
The pow() function returns either a double or a float, so the first step would be to change answer to one of those. Second, what is raisingTo() returning. Unless your are doing something that's not evident, you don't need that, but it should still work. Also, both arguments should be doubles, according to this.
Pretty simple question I think but I'm having trouble finding any discussion on it at all anywhere on the web. I've seen the triple-dot's as function parameters multiple times throughout the years and I've always just thought it meant "and whatever you would stick here." Until last night, when I decided to try to compile a function with them. To my surprise, it compiled without warnings or errors on MSVC2010. Or at least, it appeared to. I'm not really sure, so I figured I'd ask here.
They are va_args, or variable number of arguments. See for example The C book
Triple dots means the function is variadic (i.e. accepts a variable number of parameters). However to be used there should be at least a parameter... so having just "..." isn't an usable portable declaration.
Sometimes variadic function declarations are used in C++ template trickery just because of the resolution precedence of overloads (i.e. those functions are declared just to make a certain template instantiation to fail or succeed, the variadic function themselves are not implemented). This technique is named Substitution failure is not an error (SFINAE).
It's called ellipses - basically saying that function accepts any number of arguments of any non-class type.
It means that the types of arguments, and the number of them are unspecified. A concrete example with which you are probably familiar would be something like printf(char *, ...)
If you use printf, you can put whatever you like after the format string, and it is not enforced by the compiler.
e.g. printf("%s:%s",8), gets through the compiler just the same as if the "expected" arguments are provided printf("%s:%s", "stringA", "stringB").
Unless really necessary, it should be avoided, as it creates the potential for a run time error to occur, where it might otherwise have been picked up at compile time. If there is a finite, enumerable variation in the arguments your function can accept, then it is better to enumerate them by overloading.
I have an issue in Fortran 90.
I have a user-defined type, and when I call one of the MPI subroutines the data looks to be passed by value (not address, as I thought it should). The output arguments aren't modified. It seems to be specific to the MPI calls. I tried the same thing in a simple test, and I can change the passed in values in the calling scope. I'm not sure why this is, because I thought Fortran always passes by address. Any idea what could be going on?
Just to be clear, the commented snippet shows how the calls are made. In the first call, c%NSubDomains is an output argument and should be modified in the calling scope, but is not. When I call with an array rather than a member of a user-defined type it works, in the uncommented snippet.
! ! This doesn't work output values aren't modified ??
! call MPI_Dims_create(c%NProcs,c%NDims,c%NSubDomains,iErr)
nsubs(:)=0
call MPI_Dims_create(c%NProcs,c%NDims,nsubs,iErr)
c%NSubDomains=nsubs
The Fortran language standard doesn't say how arguments are passed. Different compilers can implement argument passing in various ways, depending on the type of the argument and the "intent" of the argument (in/out/inout).
How are nsubs versus C%NSubDomains declared? Do you have an interface declaration (probably from a Fortran 90 binding to MPI) to tell the compiler how it is supposed to call MPI_Dims_create?
As #MSB observes the Fortran standards don't mandate how argument passing is to be implemented. I think it's clear, though, that they do mandate that the semantics of argument passing make it look to the programmer as if arguments are passed by reference. So I understand OP's upset that this appears not to be the case for the INTENT(OUT) argument of MPI_DIMS_CREATE.
If your compiler supports the syntax of declarations like this:
!DEC$ ATTRIBUTE
or if you are using a compiler with the C-interoperability features of Fortran 2003 implemented, you might be able to coerce the compiler into passing the component as if by reference. However, if you do, it is highly likely that behind the scenes the compiler is generating code to do what you yourself are doing in your uncommented code -- making a variable which can be passed as if by reference and passing that to the subroutine.
In this situation I'd go with the flow and write the code myself.
In my Fortran code I made the following call to the dnrm2 routine:
d = dnrm2(n, ax, 1)
Just a simple call that would return me a double precision result.
The question is, should I declare the function at the start of my script? I found that if I don't declare it, when I compile the code in 32 bit Windows, then the result is correct.
But if I compile the code in 64 bit Windows, then the result isn't be correct.
Why is this so? Must an external routine always be declared in Fortran?
If you don't correctly describe your subprograms (subroutines and functions) to a calling program, the compiler may not correctly call them. Fortran compiles each unit separately, so the compiler doesn't "know", by default, about the characteristics of other subprograms. There are several ways that you can describe/declare a subprogram in Fortran 90/95/2003.
The easiest and best method is to place your subprograms into a module and then "use" that module in the calling program. This automatically makes the interface known to the compiler and will enable the compiler to check the consistency of actual arguments (in the call) and dummy arguments in the subprogram. It will also make known the return type of a function. The various subprograms in a module have their interfaces known to each other.
You can also write an "interface" containing a subprogram declaration that matches the declarations of the actual subprogram. (This method can be very similar to the style of including header files in C.) This method is more work and prone to error because you have to manually maintain consistency between the actual subprogram and interface whenever changes are made. The interface method is useful when you don't have the code to the subprogram or the subprogram is written in a language other than Fortran.
Or you can simply declare a function name to specify the type-return of the function, but this won't give you any checking of the arguments. In my opinion this method is weaker since having the compiler check argument consistency eliminates a major class of programming mistakes.
I don't do Fortran, but in C, the size of a pointer and the size of a long int varies between 32 and 64 bit OS'es, but the size of an int does not. Perhaps the program is using ints to do pointer arithmetic?