Unresolved external symbol error - __WinMainCRTStartup

[CommonTater]

What am I looking for in my code?
I've never used C++, at least not intentionally.

You're looking for stuff C can't do ... Classes, C++ specific includes with no .h extension, operator overoloading, two functions with the same names, etc.

Stephan seems to have nailed it... you've got a C++ program there... 

[megafiddle]

Ok, found part of the problem. I was trying to pass arguments by reference:

void getfield(int &field, int &x, int &y, int &fval);

Thought it was C99.

Part of all the confusion was that Pelles wasn't complaing when compiling
the program with a .cpp extension. Only when making, which gave the error
at the beginning of this topic.

As soon I add all those *'s to my variable names, I'll see what other errors I have.

[Stefan Pendl]

Ok, found part of the problem. I was trying to pass arguments by reference:

void getfield(int &field, int &x, int &y, int &fval);

Thought it was C99.

Yes, this is C99, but only when calling the function. When you are defining/declaring it, you use the asterisk to indicate "by reference" or a pointer to an array.

I wonder if such a problem will be caught, when you place your declarations into a header file?

Declaration

Code: [Select]

void getfield(int *field, int *x, int *y, int *fval);
Usage

Code: [Select]

getfield(&myfield, &myx, &myy, &myfval);

[megafiddle]

Got it working! Just had a couple of missing "voids" in some declarations after fixing the getfield() function.

So the main difference is that C++ allows the passed variables to be accesed without the indirection?

as in:

Code: [Select]

void getfield(int &field, int &x, int &y, int &fval)
{
    fval = 1;
    ....
    ....   
}
vs:

Code: [Select]

void getfield(int *field, int *x, int *y, int *fval)
{
    *fval = 1;
    ....
    ....   
}
(with arguments passed as &variable)

[Stefan Pendl]

Got it working! Just had a couple of missing "voids" in some declarations after fixing the getfield() function.

So the main difference is that C++ allows the passed variables to be accesed without the indirection?

No, I just think that the parser of Borland is too forgiving or too smart and interprets the intent of the user, but not the code itself.

It is defined that one needs to use an asterisk for the declaration, but an ampersand for calling a function.
These are basic concepts of K&R the founders of the C language.

Might be nice to have the PellesC parser catch such problems instead of getting confused.

I still would try to place the same declarations into a header file and see if the error will be caught there, since &var should not be allowed there, I think.

[CommonTater]

Ok, found part of the problem. I was trying to pass arguments by reference:

void getfield(int &field, int &x, int &y, int &fval);

Thought it was C99.

Go into your Project->Project Options->Compiler tab and set the warning level to 2...

C++ turns many things on their heads... In C++ you can hand a function a variable name and the function itself will turn it into an address... hense "pass by reference" ... C-99 can't do that. 

In C-99 you pass by value, always.  That is you pass in the value of a pointer... The pointer value is copied and made available inside your function.  If in this case you want to pass in the address of a variable you use the & operator when calling the function as Stephan has shown you.

It would seem your original linker error came from not having any compileable files in your project.

[megafiddle]

Do you mean that the Borland shouldn't have allowed this even as C++ code?

Code: [Select]

{
    ...
    ...
    getfield(int &field, int &x, int &y, int &fval);
    ...   
}

void getfield(int &field, int &x, int &y, int &fval)
{
    fval = 1;
    ....
    ....   
}
Or that it should allow it as C++ but not as C99?

I realize now that it isn't C99

[CommonTater]

It should work in C++ .... but it cannot work in C-99. 

C and C++ despite many apparent commonalities are actually 2 completely different languages.  Which brings us to one of my long time beefs with Borland... They use the same compiler for both, it's all C++ as far as they're concerned, leading to situations just like this one.

[megafiddle]

Ok. Thanks to all for the help.

The SetDCPenColor and SetDCBrushColor are also working with Pelles.
Borland 4.52 wouldn't recognize them.

[CommonTater]

Ok. Thanks to all for the help.

The SetDCPenColor and SetDCBrushColor are also working with Pelles.
Borland 4.52 wouldn't recognize them.

Well, the Borland compilers are years out of date... but Windows marches on...

We should all thank Pelle for his hard work keeping this compiler and libraries right up to date!