Results 1 to 5 of 5

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

  1. #1
    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

  2. #2
    bernard's Avatar
    bernard is offline ZeroC Staff
    Name: Bernard Normier
    Organization: ZeroC, Inc.
    Project: Ice
    Join Date
    Feb 2003
    Location
    Palm Beach Gardens, FL
    Posts
    1,294
    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

  3. #3
    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

  4. #4
    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

  5. #5
    michi's Avatar
    michi is offline Registered User
    Name: Michi Henning
    Organization: Triodia Technologies
    Project: I have a passing interest in Ice :-)
    Join Date
    Feb 2003
    Location
    Brisbane, Australia
    Posts
    1,055

    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.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 5
    Last Post: 09-11-2010, 09:47 PM
  2. a missing char in v.3.4 manual
    By n2503v in forum Bug Reports
    Replies: 0
    Last Post: 03-13-2010, 01:31 AM
  3. Is this a bug? (Wide char)
    By while(1){} in forum Help Center
    Replies: 4
    Last Post: 01-05-2006, 07:27 AM
  4. I need char pointers (char *)
    By catalin in forum Help Center
    Replies: 5
    Last Post: 08-16-2004, 04:33 PM
  5. Using Char* with SLICE
    By amrufon in forum Help Center
    Replies: 2
    Last Post: 08-01-2003, 09:58 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •