subroutine in C

Hi pals, I tried to implement my code from FORTRAN to C, but I found a problem, how can I call a subroutine in C, I saw that I could use the command VOID but Im not sure, could you explain me this please
thx

It has been long since I have written fortran, and I never was really advanced in it...
But I guess subroutines were close to functions in C (or close to using 'goto' statement - which is not good way in C - it makes larger codes a mess).

But I doubt no one will give you detailed description about functions in C. I suggest you'll google some really basic C tutorial, and experiment with creating functions. You should also pay attention to "pass by reference" Vs. "pass by value" issues in C.

You can then come back, and ask a bit more specific questions if needed.

A fortran subroutine is, in C, a function with no return value, which is a "void" function.

--
Mats

So I can use VOID in C as I use subroutine in Fortran right

Yes, but C is case-sensitive, so "VOID" is not the same as "void".

--
Mats

well some problem trying to implement my code from fortran to C with void somebody could help me

Code:

---

        void contour (float f[][],float x[],float y[],int jmax, int imax)
        {
        for(j=1;j<=jmax;j++)
        {
                f[1][j]=ui*x[1];
                f[imax][j]=ui*x[imax];
        }
        for(i=1;i<=imax;i++)
        {
                f[i][jmax]=ui*x[i];
                if((i>=il) && (i<=it))
                f[i][1]=f[i][2]-0.1*(y[2]-y[1])*(1.0-2*x[i]);
                else
                f[i][1]=f[i][2];
        }// end contour ()

---

Ok, so in C, you have to SPECIFY the size of all but the right-most array size - or use a single-dimension array.

You also must start array indices at 0, not 1. So array[imax] will not work, probably.

--
Mats

even in void as in the main I need to specify the size of the array?

Quote:

---

Originally Posted by vikingcarioca

even in void as in the main I need to specify the size of the array?

---

Yes.

The way C works is that every array [no matter how many dimensions] is implemented as a simple one-dimension array. The compiler will then calculate the respective postion by multiplying the first index times it's size + second index.

--
Mats

Quote:

---

Originally Posted by vikingcarioca

even in void as in the main I need to specify the size of the array?

---

'void' in C is used a couple of ways:

1 - To indicate that the function will not return a value.

Code:

---

void fun1( int x )
{
  printf( "x + 1 is %d\n", x + 1 );
}

---

2 - To indicate that a function takes no arguments (is passed nothing).

Code:

---

int fun2( void )
{
    printf( "This function takes no parameters, but returns something!\n" );
    return 0;
}

---

3 - To declare a "universal" datatype.

Code:

---

void *vptr;
int x;
char c;
vptr = &x;
...
vptr = &c;

---

You can assign any type to a void pointer, and it will keep tabs on it for you. But to get back what you're pointing at, you need to reference that type implicitly.

You can also use it as a cast to disregard return values, but you usually don't need to do that.


Quzah.

Quote:

---

Originally Posted by quzah

2 - To indicate that a function takes no arguments (is passed nothing).

Code:

---

int fun2( void )
{
    printf( "This function takes no parameters, but returns something!\n" );
    return 0;
}

---

---

Only in prototypes, though.
The compiler couldn't care less about the actual definition.

Quote:

---

Originally Posted by Elysia

Only in prototypes, though.
The compiler could care less about the actual definition.

---

The phrase is "couldn't care less". Could care less means that it does care, and it could care less than it currently does, but doesn't for some reason...

For the record, I don't care as much what the compiler thinks, as much as I care what the language defines. Anyway, I'm clear on what it is you're trying to say. If you're saying that when you call a function which takes no parameters, you don't have to specify void:

Code:

---

void fun( void )
{
  ...
}

...

fun( );

---

Then I agree. When you call a function which takes no arguments, you do not have to provide arguments. That's sort of the whole point. ;)


Quzah.

Quote:

---

Originally Posted by quzah

For the record, I don't care as much what the compiler thinks, as much as I care what the language defines. Anyway, I'm clear on what it is you're trying to say. If you're saying that when you call a function which takes no parameters, you don't have to specify void:

Code:

---

void fun( void )
{
  ...
}

...

fun( );

---

Then I agree. When you call a function which takes no arguments, you do not have to provide arguments. That's sort of the whole point. ;)


Quzah.

---

The point is / was that this...

Code:

---

void fun(void);
void fun()
{
    // blah
}

---

The "void" must be in the prototype to tell the compiler that function takes no arguments. Sure, if you only provide a definition, then you must use void in the parameter list.
This trickery allows this sort of stuff to compile:

Code:

---

void fun(); // Unspecified number of args
void fun(int arg1, int arg2)
{
    // blah
}

---

Void specifies that there are no arguments. Empty specifies that there are an unspecified number of arguments. There's a difference. And since I wasn't talking about having an unspecified number of arguments, it's not relevant to the discussion of void really. Again, void is specifically saying that there will be no arguments.


Quzah.

I merely want to make it clear that this works:

Code:

---

void foo(void);
void foo()
{

}

int main()
{
        foo();
}

---

This works:

Code:

---

void foo(void);
void foo(void)
{

}

int main()
{
        foo();
}

---

And this works:

Code:

---

void foo(void)
{

}

int main()
{
        foo();
}

---

In all of them, foo takes no arguments and the compiler will complain if you try.

Quote:

---

Originally Posted by Elysia

Sure, if you only provide a definition, then you must use void in the parameter list.

---

Not so. In a definition, an unnamed void argument, and an empty argument list both mean the same thing.

So this will not compile with a "too many arguments" error:

Code:

---

int func(){
  return 0;
}

int main(){
  func(1);
}

---

Quote:

---

Originally Posted by King Mir

Not so. In a definition, an unnamed void argument, and an empty argument list both mean the same thing.

So this will not compile with a "too many arguments" error:

---

Not in VS2005

Quote:

---

Originally Posted by vart

Not in VS2005

---

Are you sure you did not compile as C++? It works for me when compiling as C.

EDIT:
Wait a minute, I assumed that King Mir meant 'this will not (compile with a "too many arguments" error)' (which does not really make sense, I suppose), but maybe King Mir meant 'this will (not compile) with a "too many arguments" error', in which case the reason why this is not so is that the definition is also a declaration.

EDIT #2:
hmm... but the language of C99 seems to indicate otherwise:

Quote:

---

Originally Posted by Section 6.7.5.3, Paragraph 14

An identifier list declares only the identifiers of the parameters of the function. An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters. The empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied.

---

The wording "not part of a definition" seems to say that although a definition is a declaration, the fact that it is a definition trumps the fact that it is a declaration for the interpretation of an empty parameter list. If this is so (and also in C90), then gcc and MSVC are both non-conformant in this area.

I compiled it as C

VS2005 gives no errors
gcc port used in CodeBlocks - gives the error specified by King Mir

Quote:

---

Originally Posted by vart

gcc port used in CodeBlocks - gives the error specified by King Mir

---

What is the version of gcc? The MinGW port of gcc 3.4.5 did not emit such an error for both C90 and C99 mode with -Wall and -pedantic tacked on.

Quote:

---

Originally Posted by laserlight

What is the version of gcc? The MinGW port of gcc 3.4.5 did not emit such an error for both C90 and C99 mode with -Wall and -pedantic tacked on.

---

ok I played a little with the CodeBlocks installation to see exactly which gcc is configured, what switches are set, and finally - what command line it uses to compile a file.


Here is it:
1. gcc is 3.4.5 and it does not show the error. (I have running it from command prompt)
2. CodeBlocks on some reason starts g++ to compile the c-file


So - about the second - how do I tell to CodeBlocks that *.c files should be compiled as C and not C++?

Quote:

---

Originally Posted by vart

So - about the second - how do I tell to CodeBlocks that *.c files should be compiled as C and not C++?

---

I think this might work: click on the .c file and select "Properties...". Click on the "Advanced" tab and change "CPP" to "CC" for the "Compiler variable" setting.

EDIT:
No, Code::Blocks does not seem smart enough to use gcc instead of g++ in that case.

Quote:

---

Originally Posted by laserlight

The wording "not part of a definition" seems to say that although a definition is a declaration, the fact that it is a definition trumps the fact that it is a declaration for the interpretation of an empty parameter list. If this is so (and also in C90), then gcc and MSVC are both non-conformant in this area.

---

My take on the whole was:

Code:

---

void fun(void); // No parameters
void fun(); // No parameter information (infinite parameters)
void fun(void) { } // No parameters
void fun () { } // No parameters

---

I could be wrong, though.
Although VS would let the last example compile.