Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Link failures when defined private/protected to public
QtWS25 Last Chance

Link failures when defined private/protected to public

Scheduled Pinned Locked Moved General and Desktop
7 Posts 4 Posters 4.7k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F Offline
    F Offline
    fifth
    wrote on last edited by
    #1

    In my unit test project, I got following linkage failures,

    bq.
    Error 4 error LNK2001: unresolved external symbol "public: virtual void __thiscall QObject::timerEvent(class QTimerEvent *)" (?timerEvent@QObject@@UAEXPAVQTimerEvent@@@Z) XEdit.obj
    Error 5 error LNK2001: unresolved external symbol "public: virtual void __thiscall QObject::childEvent(class QChildEvent *)" (?childEvent@QObject@@UAEXPAVQChildEvent@@@Z) XEdit.obj
    Error 6 error LNK2001: unresolved external symbol "public: virtual void __thiscall QObject::customEvent(class QEvent *)" (?customEvent@QObject@@UAEXPAVQEvent@@@Z) XEdit.obj
    Error 7 error LNK2001: unresolved external symbol "public: virtual void __thiscall QObject::connectNotify(char const *)" (?connectNotify@QObject@@UAEXPBD@Z) XEdit.obj
    bq.

    I found it's because I changed the access modifier for unit project by,
    @
    #ifdef UNIT_TEST

    #define private public
    #define protected public

    #endif
    @

    Could anyone give me the reason and the solution?
    Thanks.

    1 Reply Last reply
    0
    • L Offline
      L Offline
      LinusA
      wrote on last edited by
      #2

      Apart from the fact that this define-trick is one of the most dangerous and dirtiest I know of, can't you make sure you add the #define somewhere AFTER external headers? Only apply this trick to your classes, not to the Qt and other code...

      If that's too complicated, I noticed Qt-headers always #define QT_BEGIN_HEADER at the beginning and QT_END_HEADER at the end.

      You could change your macro in such a way that it doesn't touch private and protected between QT_BEGIN_HEADER and QT_END_HEADER.

      You seem to be doing unit tests (#ifdef UNIT_TEST). You should seriously re-evaluate what passed unit tests are worth to you if you have screwed up C++ keywords. I'm guessing you do this kind of trick for your unit-tests to work, but I don't think that counts as valid unit test. Aren't there other ways (like mock objects etc.)?

      1 Reply Last reply
      0
      • D Offline
        D Offline
        dangelog
        wrote on last edited by
        #3

        You can't do that define trick with MSVC.

        Name mangling done by that compiler include the access qualifiers inside the mangled name, therefore your linker will be looking for the wrong symbols inside the library.

        Software Engineer
        KDAB (UK) Ltd., a KDAB Group company

        1 Reply Last reply
        0
        • F Offline
          F Offline
          fifth
          wrote on last edited by
          #4

          @LinusA
          Thanks.

          Fortunately, I fixed it by including all Qt headers before any of my other headers.

          As for the trick, our unit test framework does so to make every protected/private method testable.

          But I'm still confused why the link failed in such way.
          In my view, changing access qualifiers doesn't change anything in symbols, and linkage never depends on access qualifiers but symbols.

          1 Reply Last reply
          0
          • F Offline
            F Offline
            fifth
            wrote on last edited by
            #5

            Thanks, my knowledge about name mangling was wrong.

            I also found some reference,
            http://labs.qt.nokia.com/2009/08/12/some-thoughts-on-binary-compatibility/
            http://en.wikipedia.org/wiki/Microsoft_Visual_C++_Name_Mangling

            [quote author="peppe" date="1311311115"]You can't do that define trick with MSVC.

            Name mangling done by that compiler include the access qualifiers inside the mangled name, therefore your linker will be looking for the wrong symbols inside the library.[/quote]

            1 Reply Last reply
            0
            • T Offline
              T Offline
              timoph
              wrote on last edited by
              #6

              [quote author="fifth" date="1311311328"]As for the trick, our unit test framework does so to make every protected/private method testable.
              [/quote]

              To me this just sounds wrong. I wouldn't trust in the results coming from those unit tests since the tested thing will be different than the actual release.

              1 Reply Last reply
              0
              • L Offline
                L Offline
                LinusA
                wrote on last edited by
                #7

                [quote author="timoph" date="1311314706"]
                [quote author="fifth" date="1311311328"]As for the trick, our unit test framework does so to make every protected/private method testable.
                [/quote]
                To me this just sounds wrong. I wouldn't trust in the results coming from those unit tests since the tested thing will be different than the actual release.
                [/quote]
                That's a better phrasing of what I wanted to say, and states my exact concerns!

                1 Reply Last reply
                0

                • Login

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • Users
                • Groups
                • Search
                • Get Qt Extensions
                • Unsolved