Application.h compiler error on int main(int, char*[], const char* = 0);

Jonathan Dzoba

I moved from ICE V1.2 to ICE V1.4 and got the following compile error under Visual Studio .NET 2002.

C:\Ice-1.4.0\include\Ice\Application.h(33) : error C2668: 'Ice::Application::ace_main_i' : ambiguous call to overloaded function
C:\Ice-1.4.0\include\Ice\Application.h(33): could be 'int Ice::Application::ace_main_i(int,char *[],const char *)'
C:\Ice-1.4.0\include\Ice\Application.h(33): or 'int Ice::Application::ace_main_i(int,char *[])'
while trying to match the argument list '(int, char *[])'

V1.2 of Application.h has:

int main(int, char*[], const char*);

V1.4 has:

int main(int, char*[], const char* = 0);

Removing the ' = 0' fixes the compile error and I believe is benign if you're not using what I presume is the environment variable pointer, but I thought I'd check.

Thanks,
Jonathan

bernard

Hi Jonathan,

I don't understand your compilation error. Ice::Application has a function named main (declared at line 33 in Application.h), but no ace_main_i function. And this main function is not virtual -- so you should not attempt to override it.
Could you maybe post a small code sample that shows this compilation error?

Thanks,
Bernard

Jonathan Dzoba

Pared down example

Bernard,

I have a large body of code that I am not very familiar with yet. I just thought if this was something you folks knew about already that there might be a quick solution.
What I suspect and am afraid of is that since the code also uses ACE, that there is some intricate problem at work here. I haven't tried to build the V1.4 ICE example code yet, but I imagine that will work fine. In any case, I will pursue this on my end and if I can pare it down to a reproducable ICE problem in a small example I will send that on to you.
Meanwhile, don't worry about it.

Thanks,
Jonathan

Jonathan Dzoba

#include order

Bernard,

ACE does a #define of 'main' in order to allow for allocation of it's ObjectManager either on the stack of main() or statically. If you're source files that need to include the ACE headers are included before the ICE header Application.h, the ICE::Application function called 'main' gets #defined to be 'ace_main_i'.

The solution is to put all your ICE #includes before your ACE #includes.

Not an easy thing to find. I'm not fond of ACE being so bold as to #define main without some sort of guards around it.

Thanks,
Jonathan

michi

Re: #include order

Originally posted by Jonathan Dzoba
Not an easy thing to find. I'm not fond of ACE being so bold as to #define main without some sort of guards around it.

No. The liberal use of the preprocessor in ACE and TAO are a big problem, IMO. Last time I looked at some TAO CORBA code, it hardly looked like C++ anymore. Writing a #define for main into a header file is near enough criminal, IMO, just one step short of the old stupidity of writing #defines for true and false...

Cheers,

Michi.