Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. #defines in a static library

#defines in a static library

Scheduled Pinned Locked Moved C / C++ / MFC
15 Posts 3 Posters 0 Views 1 Watching
  • 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.
  • A Offline
    A Offline
    Albert Holguin
    wrote on last edited by
    #1

    Seem to be experiencing a bit of weirdness with a static library: I have two #defines inside of the .lib (hex constants):

    #define VAL_ONE 0x14fc
    #define VAL_TWO 0x0050

    Now, if I execute everything from the .lib as inline function from within the executable source (pretty much make it part of that compilation versus a static library), it works fine, but when it executes within the lib, somehow these values aren't getting assigned correctly to the structure that passes these values on to another function.

    MY_STRUCT tmp;
    tmp.value1 = VAL_ONE;
    tmp.value2 = VAL_TWO;
    //Where, value1 and value2 are defined as unsigned short values
    //If I look at this on the debugger, value1 and value2 do not contain what I expect.

    Am I missing/forgetting something?? :doh:

    N L 4 Replies Last reply
    0
    • A Albert Holguin

      Seem to be experiencing a bit of weirdness with a static library: I have two #defines inside of the .lib (hex constants):

      #define VAL_ONE 0x14fc
      #define VAL_TWO 0x0050

      Now, if I execute everything from the .lib as inline function from within the executable source (pretty much make it part of that compilation versus a static library), it works fine, but when it executes within the lib, somehow these values aren't getting assigned correctly to the structure that passes these values on to another function.

      MY_STRUCT tmp;
      tmp.value1 = VAL_ONE;
      tmp.value2 = VAL_TWO;
      //Where, value1 and value2 are defined as unsigned short values
      //If I look at this on the debugger, value1 and value2 do not contain what I expect.

      Am I missing/forgetting something?? :doh:

      N Offline
      N Offline
      Niklas L
      wrote on last edited by
      #2

      Remember that it is all about substitution at compile time. The values you use when compiling the lib will be used there, and the values you use when compiling the exe will be used there. This means you will have to be careful when changing the values between compilations. Are you saying that you have the same values in both projects and still experiencing problems?

      A 1 Reply Last reply
      0
      • A Albert Holguin

        Seem to be experiencing a bit of weirdness with a static library: I have two #defines inside of the .lib (hex constants):

        #define VAL_ONE 0x14fc
        #define VAL_TWO 0x0050

        Now, if I execute everything from the .lib as inline function from within the executable source (pretty much make it part of that compilation versus a static library), it works fine, but when it executes within the lib, somehow these values aren't getting assigned correctly to the structure that passes these values on to another function.

        MY_STRUCT tmp;
        tmp.value1 = VAL_ONE;
        tmp.value2 = VAL_TWO;
        //Where, value1 and value2 are defined as unsigned short values
        //If I look at this on the debugger, value1 and value2 do not contain what I expect.

        Am I missing/forgetting something?? :doh:

        L Offline
        L Offline
        Lost User
        wrote on last edited by
        #3

        I think we need to see a bit more of your code. Take a look at the actual values that are generated within the library build for the MY_STRUCT tmp;.

        Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman

        1 Reply Last reply
        0
        • A Albert Holguin

          Seem to be experiencing a bit of weirdness with a static library: I have two #defines inside of the .lib (hex constants):

          #define VAL_ONE 0x14fc
          #define VAL_TWO 0x0050

          Now, if I execute everything from the .lib as inline function from within the executable source (pretty much make it part of that compilation versus a static library), it works fine, but when it executes within the lib, somehow these values aren't getting assigned correctly to the structure that passes these values on to another function.

          MY_STRUCT tmp;
          tmp.value1 = VAL_ONE;
          tmp.value2 = VAL_TWO;
          //Where, value1 and value2 are defined as unsigned short values
          //If I look at this on the debugger, value1 and value2 do not contain what I expect.

          Am I missing/forgetting something?? :doh:

          L Offline
          L Offline
          Lost User
          wrote on last edited by
          #4

          Do you have the defines in the header you have the funciton deffinition in, and that is included into the exe you are building?

          ============================== Nothing to say.

          A 1 Reply Last reply
          0
          • N Niklas L

            Remember that it is all about substitution at compile time. The values you use when compiling the lib will be used there, and the values you use when compiling the exe will be used there. This means you will have to be careful when changing the values between compilations. Are you saying that you have the same values in both projects and still experiencing problems?

            A Offline
            A Offline
            Albert Holguin
            wrote on last edited by
            #5

            The #defines are in the header that gets used in the exe code for pulling in the functions in the static library... so it should be exactly the same. I've used this static library before and never had this issue before, which is even more odd. The static library is a very plain/small library with only two small functions. There's no MFC, ATL, or anything like that in the static lib.

            L 1 Reply Last reply
            0
            • L Lost User

              Do you have the defines in the header you have the funciton deffinition in, and that is included into the exe you are building?

              ============================== Nothing to say.

              A Offline
              A Offline
              Albert Holguin
              wrote on last edited by
              #6

              See my comment[^] above to Niklas...

              L 1 Reply Last reply
              0
              • A Albert Holguin

                The #defines are in the header that gets used in the exe code for pulling in the functions in the static library... so it should be exactly the same. I've used this static library before and never had this issue before, which is even more odd. The static library is a very plain/small library with only two small functions. There's no MFC, ATL, or anything like that in the static lib.

                L Offline
                L Offline
                Lost User
                wrote on last edited by
                #7

                Albert Holguin wrote:

                The #defines are in the header that gets used in the exe code for pulling in the functions in the static library

                That is not correct, both the include file and the #defines within it are processed by the compiler, there is no reference to them in the exe or lib file. The actual #define directives are seen and converted to their 'real' values by the preprocessor. If you have different versions of the same directives within your project then you can end up with the situation you are seeing. Alternatively you could have a different set of values in the pre-compiled header file which conflict with the ones you are seeing in your .h file. Without seeing a bit more of your source it's difficult to speculate further as to why this is happening.

                Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman

                A 1 Reply Last reply
                0
                • A Albert Holguin

                  See my comment[^] above to Niklas...

                  L Offline
                  L Offline
                  Lost User
                  wrote on last edited by
                  #8

                  If the same header is used to complie the lib as the exe then the defines must be the same.

                  ============================== Nothing to say.

                  A 1 Reply Last reply
                  0
                  • L Lost User

                    Albert Holguin wrote:

                    The #defines are in the header that gets used in the exe code for pulling in the functions in the static library

                    That is not correct, both the include file and the #defines within it are processed by the compiler, there is no reference to them in the exe or lib file. The actual #define directives are seen and converted to their 'real' values by the preprocessor. If you have different versions of the same directives within your project then you can end up with the situation you are seeing. Alternatively you could have a different set of values in the pre-compiled header file which conflict with the ones you are seeing in your .h file. Without seeing a bit more of your source it's difficult to speculate further as to why this is happening.

                    Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman

                    A Offline
                    A Offline
                    Albert Holguin
                    wrote on last edited by
                    #9

                    I was referring to where the defines are located within the projects. The source isn't that expansive and like I said, if I just move the functions into the header and make them inline so they aren't a separate compilation, it works fine, so there's nothing wrong with the source.

                    L 1 Reply Last reply
                    0
                    • L Lost User

                      If the same header is used to complie the lib as the exe then the defines must be the same.

                      ============================== Nothing to say.

                      A Offline
                      A Offline
                      Albert Holguin
                      wrote on last edited by
                      #10

                      Well... Yes.... Of course.

                      L 1 Reply Last reply
                      0
                      • A Albert Holguin

                        Well... Yes.... Of course.

                        L Offline
                        L Offline
                        Lost User
                        wrote on last edited by
                        #11

                        Yeah, so what you have is plain weird. :) I am thinkin it may be a compiler screw up. Rare, but they can happen. Can you try a different compiler?

                        ============================== Nothing to say.

                        A 1 Reply Last reply
                        0
                        • A Albert Holguin

                          I was referring to where the defines are located within the projects. The source isn't that expansive and like I said, if I just move the functions into the header and make them inline so they aren't a separate compilation, it works fine, so there's nothing wrong with the source.

                          L Offline
                          L Offline
                          Lost User
                          wrote on last edited by
                          #12

                          Albert Holguin wrote:

                          there's nothing wrong with the source.

                          There obviously is something wrong with the source otherwise this problem would not exist. However without more details it's not easy to guess what.

                          Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman

                          1 Reply Last reply
                          0
                          • A Albert Holguin

                            Seem to be experiencing a bit of weirdness with a static library: I have two #defines inside of the .lib (hex constants):

                            #define VAL_ONE 0x14fc
                            #define VAL_TWO 0x0050

                            Now, if I execute everything from the .lib as inline function from within the executable source (pretty much make it part of that compilation versus a static library), it works fine, but when it executes within the lib, somehow these values aren't getting assigned correctly to the structure that passes these values on to another function.

                            MY_STRUCT tmp;
                            tmp.value1 = VAL_ONE;
                            tmp.value2 = VAL_TWO;
                            //Where, value1 and value2 are defined as unsigned short values
                            //If I look at this on the debugger, value1 and value2 do not contain what I expect.

                            Am I missing/forgetting something?? :doh:

                            L Offline
                            L Offline
                            Lost User
                            wrote on last edited by
                            #13

                            Albert Holguin wrote:

                            Am I missing/forgetting something?? :doh:

                            Yep you're forgetting that the preprocessor is evil. use... static const uin16_t VAL_ONE = 0x14fc

                            A 1 Reply Last reply
                            0
                            • L Lost User

                              Albert Holguin wrote:

                              Am I missing/forgetting something?? :doh:

                              Yep you're forgetting that the preprocessor is evil. use... static const uin16_t VAL_ONE = 0x14fc

                              A Offline
                              A Offline
                              Albert Holguin
                              wrote on last edited by
                              #14

                              :-D ...I found a few mistakes on the linker inclusions coupled with the fact that I was breaking in the static library with the release version of the library, so think that was probably causing me to see bogus debug numbers (and the inclusion mistakes were causing the malfunctions).

                              1 Reply Last reply
                              0
                              • L Lost User

                                Yeah, so what you have is plain weird. :) I am thinkin it may be a compiler screw up. Rare, but they can happen. Can you try a different compiler?

                                ============================== Nothing to say.

                                A Offline
                                A Offline
                                Albert Holguin
                                wrote on last edited by
                                #15

                                See note below to Josh btw... got it working, think the bogus numbers just came from breaking in the non-debug assembly... not sure why studio let's you break in a non-debug assembly if it's going to provide bogus data anyway... but at least everything is working.

                                1 Reply Last reply
                                0
                                Reply
                                • Reply as topic
                                Log in to reply
                                • Oldest to Newest
                                • Newest to Oldest
                                • Most Votes


                                • Login

                                • Don't have an account? Register

                                • Login or register to search.
                                • First post
                                  Last post
                                0
                                • Categories
                                • Recent
                                • Tags
                                • Popular
                                • World
                                • Users
                                • Groups