Like Tree7Likes
  • 2 Post By smokeyangel
  • 5 Post By grumpy

Different behavior of gcc 3.x and 4.x

This is a discussion on Different behavior of gcc 3.x and 4.x within the C++ Programming forums, part of the General Programming Boards category; Hello, has this happened to anyone? I have an old program that would compile under gcc 3.x. When I compiled ...

  1. #1
    Registered User
    Join Date
    Dec 2011
    Location
    Chicago
    Posts
    7

    Different behavior of gcc 3.x and 4.x

    Hello, has this happened to anyone? I have an old program that would compile under gcc 3.x. When I compiled it under gcc 4.x, but it stopped with a bunch 'was not declared in this scope' errors. The errors were members of a class declared in a header file shared by all compilation units. So, I simply placed an extern declaration for the member functions in the header file, which stopped the errors.
    My question is, I thought all members not declared static were extern by default, so why do I need to declare it extern again?

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,420
    Can you post a short example class header file, class implementation file and a file using the class (nothing complicated, one private member var, one public member method ought to do it).
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Registered User
    Join Date
    Dec 2011
    Location
    Chicago
    Posts
    7
    Quote Originally Posted by Salem View Post
    Can you post a short example class header file, class implementation file and a file using the class (nothing complicated, one private member var, one public member method ought to do it).
    This compiles under MingW gcc 3.x , Dev-Cpp but not under MingW 4.x, Code::Blocks or Orwell fork of Dev-Cpp, also gcc 4.x
    Attached Files Attached Files

  4. #4
    Registered User
    Join Date
    Dec 2011
    Location
    Chicago
    Posts
    7
    Code:
    // MAIN FILE
    #include "header.hpp"
    #include <iostream>
    #include <cstdlib>
    using namespace std;
    int main()
    {
        {
            if (var(1,1,1)==FALSE) cout << "FALSE\n";
            else cout << "TRUE\n";
        }
        system("PAUSE(0)");
        return(0);
    }

    Code:
    // Separate unit
    #include "header.hpp"
    using namespace std;
    bool var(short p1, short p2, short p3)
    {
        if (p1==1&&p2==1&&p3==1) return TRUE;
        return FALSE;
    }
    Code:
    // HEADER FILE
    #define TRUE true
    #define FALSE false
    class object
    {
    private:
        short *ptr; // Not in used in example
    public:
        friend bool var(short,short,short);
        object() {}
        ~object() {}
    };

  5. #5
    Registered User
    Join Date
    Aug 2003
    Posts
    1,197
    You have defined the var function in data.cpp, but no declaration of it in main.cpp so when the compiler tries to compile main.cpp it has no clue what var is supposed to be. Adding the following before main in main.cpp fixes the issue:

    bool var(short, short, short);

    Normally function declarations goes into header files that you then include in the cpp files that needs them.

  6. #6
    Registered User
    Join Date
    Dec 2011
    Location
    Chicago
    Posts
    7
    Good explanation. I am assuming gcc 3.x was not as strict in this regard compared to gcc 4.x. Thanks

  7. #7
    ZuK
    ZuK is offline
    Registered User
    Join Date
    Aug 2005
    Location
    Austria
    Posts
    1,990
    Quote Originally Posted by Sean M View Post
    This compiles under MingW gcc 3.x , Dev-Cpp but not under MingW 4.x, Code::Blocks or Orwell fork of Dev-Cpp, also gcc 4.x
    I can only say that this shouldn't compile.
    The function var is not declared when compiling main.cpp.
    to fix it put
    Code:
    bool var(short p1, short p2, short p3);
    into Header.h

    I cannot imagine that gcc3.x compiled this without error.

    Kurt

  8. #8
    Registered User
    Join Date
    Mar 2010
    Posts
    535
    I think the documentation for the -ffriend-injection option explains this. With GCC 3x the compiler would have gotten the declaration of var from the friend declaration in the header file.

    I haven't been personally hit by this problem, but from general personal experience I think GCC gets a bit stricter with every release -- though usually it's just a massive new spew of warnings to sort out.

    From C++ Dialect Options - Using the GNU Compiler Collection (GCC)
    -ffriend-injection
    Inject friend functions into the enclosing namespace, so that they are visible outside the scope of the class in which they are declared. Friend functions were documented to work this way in the old Annotated C++ Reference Manual, and versions of G++ before 4.1 always worked that way. However, in ISO C++ a friend function which is not declared in an enclosing scope can only be found using argument dependent lookup. This option causes friends to be injected as they were in earlier releases.
    This option is for compatibility, and may be removed in a future release of G++.
    ZuK and Salem like this.

  9. #9
    ZuK
    ZuK is offline
    Registered User
    Join Date
    Aug 2005
    Location
    Austria
    Posts
    1,990
    That's it. when using -ffriend-injection it compiles with g++ (GCC) 4.6.3

    Kurt

  10. #10
    Registered User
    Join Date
    Dec 2011
    Location
    Chicago
    Posts
    7
    Yes, it works for me too. That saves me a lot of time as it is a huge program

  11. #11
    Registered User
    Join Date
    Jun 2005
    Posts
    6,169
    This option may save you time now, but will probably cause you (or, if you move on, your successor) a waste of time later.

    If the -ffriend-injection option is removed from gcc (and the documentation strongly suggests it will be) or a decision is made to use another compiler, then a real fix to the problem will be needed.


    The fix is trivial: add a declaration of the affected functions to the header files. That will work in both old and new versions of gcc. Doing otherwise might be expedient in the short term but, frankly, is false economy.
    Right 98% of the time, and don't care about the other 3%.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Undefined behavior from VC6 to 2k5
    By m37h0d in forum C++ Programming
    Replies: 10
    Last Post: 06-22-2011, 07:56 PM
  2. Odd printf behavior?
    By tallen387 in forum C Programming
    Replies: 1
    Last Post: 04-07-2011, 07:03 AM
  3. fork behavior
    By jlotty in forum C Programming
    Replies: 2
    Last Post: 12-13-2009, 09:50 PM
  4. Odd resizing behavior in MFC
    By VirtualAce in forum Windows Programming
    Replies: 6
    Last Post: 01-10-2006, 07:31 PM
  5. strange behavior
    By agarwaga in forum C Programming
    Replies: 1
    Last Post: 10-17-2005, 12:03 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21