Go Back   ZeroC Forums > Bug Reports

Reply
 
LinkBack Thread Tools Rate Thread Display Modes
  #1 (permalink)  
Old 05-27-2004
Jonathan Dzoba Jonathan Dzoba is offline
Registered User
 
 
Join Date: May 2004
Posts: 3
Question Application.h compiler error on int main(int, char*[], const char* = 0);

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
__________________
Jonathan Dzoba
Senior Software Engineer
Texas Instruments Incorporated
Stafford, Texas 77477
(281)274-4021
j-dzoba1@ti.com
Reply With Quote
  #2 (permalink)  
Old 05-27-2004
bernard's Avatar
bernard bernard is offline
ZeroC Staff
 
Name: Bernard Normier
Organization: ZeroC, Inc.
Project: Ice
 
Join Date: Feb 2003
Location: Palm Beach Gardens, FL
Posts: 813
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
Reply With Quote
  #3 (permalink)  
Old 05-27-2004
Jonathan Dzoba Jonathan Dzoba is offline
Registered User
 
 
Join Date: May 2004
Posts: 3
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
Senior Software Engineer
Texas Instruments Incorporated
Stafford, Texas 77477
(281)274-4021
j-dzoba1@ti.com
Reply With Quote
  #4 (permalink)  
Old 05-27-2004
Jonathan Dzoba Jonathan Dzoba is offline
Registered User
 
 
Join Date: May 2004
Posts: 3
#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
__________________
Jonathan Dzoba
Senior Software Engineer
Texas Instruments Incorporated
Stafford, Texas 77477
(281)274-4021
j-dzoba1@ti.com
Reply With Quote
  #5 (permalink)  
Old 05-28-2004
michi's Avatar
michi michi is offline
ZeroC Staff
 
Name: Michi Henning
Organization: ZeroC
Project: Ice
 
Join Date: Feb 2003
Location: Brisbane, Australia
Posts: 909
Re: #include order

Quote:
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.
Reply With Quote
Reply



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
problem with char ':' in identity.name xdm Help Center 4 06-20-2006 05:12 AM
Casting char* to std::string inmmat Help Center 5 06-10-2006 02:43 PM
Is this a bug? (Wide char) while(1){} Help Center 4 01-05-2006 08:27 AM
I need char pointers (char *) catalin Help Center 5 08-16-2004 05:33 PM
Using Char* with SLICE amrufon Help Center 2 08-01-2003 10:58 AM


All times are GMT -4. The time now is 08:45 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.0.0
(c) 2008 ZeroC, Inc.