Function overloading and base types

Discussion in 'C++' started by Gordon Schumacher, Aug 25, 2006.

  1. I'm working with a class with a set of functions that need to be able
    to process any unsigned integer value, and I need this code to compile
    on multiple platforms, so I have something similar to:

    class A
    {
    uint8_t myFunc(uint8_t val);
    uint16_t myFunc(uint16_t val);
    uint32_t myFunc(uint32_t val);
    uint64_t myFunc(uint64_t val);
    };

    This should, I would think, cover all my bases.
    Elsewhere in the code, I have:

    size_t foo, bar;
    bar = myFunc(foo);

    I am currently compiling on three platforms: MSVC++ 7.1, GCC 4.1.0 for
    DOS (DJGPP), and GCC 4.0.2 for Linux. On the first two, this code
    works fine; on Linux, though, I get an ambiguous overload error.

    Looking at the preprocessor output, I found the difference: MSVC++ 7.1
    and DJGPP both expand size_t to "unsigned int", and Linux expands it to
    "long unsigned int". The uint32_t is typedef'ed to "unsigned int" on
    all three platforms - thus matching size_t on all but Linux. If, as a
    test, I change my function declarations to:

    class A
    {
    unsigned char myFunc(unsigned char val);
    unsigned short myFunc(unsigned short val);
    unsigned int myFunc(unsigned int val);
    unsigned long myFunc(unsigned long val);
    unsigned long long myFunc(unsigned long long val);
    };

    that is to say, include definitions for all three of short, int, and
    long... then all three platforms are happy.

    As it happens, on all three of these platforms, "unsigned int" and
    "unsigned long" are the same size. This leads to difficulties when the
    implementations of those functions are dependent on the parameter's
    size (in this case, I'm doing byte-swapping!)

    I also can't safely just add an additional definition for a "size_t"
    type to the first implementation, because then the *other* two
    platforms have duplicate definitions of "unsigned int"!

    There must be a solution for this, but I'll be darned if I can figure
    out what it is. Help?
     
    Gordon Schumacher, Aug 25, 2006
    #1
    1. Advertising

  2. Gordon Schumacher wrote:
    > I'm working with a class with a set of functions that need to be able
    > to process any unsigned integer value, and I need this code to compile
    > on multiple platforms, so I have something similar to:
    >
    > class A
    > {
    > uint8_t myFunc(uint8_t val);
    > uint16_t myFunc(uint16_t val);
    > uint32_t myFunc(uint32_t val);
    > uint64_t myFunc(uint64_t val);
    > };
    >
    > This should, I would think, cover all my bases.
    > Elsewhere in the code, I have:
    >
    > size_t foo, bar;
    > bar = myFunc(foo);
    >
    > I am currently compiling on three platforms: MSVC++ 7.1, GCC 4.1.0 for
    > DOS (DJGPP), and GCC 4.0.2 for Linux. On the first two, this code
    > works fine; on Linux, though, I get an ambiguous overload error.
    >
    > Looking at the preprocessor output, I found the difference: MSVC++ 7.1
    > and DJGPP both expand size_t to "unsigned int", and Linux expands it
    > to "long unsigned int". The uint32_t is typedef'ed to "unsigned int"
    > on all three platforms - thus matching size_t on all but Linux. If,
    > as a test, I change my function declarations to:
    >
    > class A
    > {
    > unsigned char myFunc(unsigned char val);
    > unsigned short myFunc(unsigned short val);
    > unsigned int myFunc(unsigned int val);
    > unsigned long myFunc(unsigned long val);
    > unsigned long long myFunc(unsigned long long val);
    > };
    >
    > that is to say, include definitions for all three of short, int, and
    > long... then all three platforms are happy.
    >
    > As it happens, on all three of these platforms, "unsigned int" and
    > "unsigned long" are the same size. This leads to difficulties when
    > the implementations of those functions are dependent on the
    > parameter's size (in this case, I'm doing byte-swapping!)
    >
    > I also can't safely just add an additional definition for a "size_t"
    > type to the first implementation, because then the *other* two
    > platforms have duplicate definitions of "unsigned int"!
    >
    > There must be a solution for this, but I'll be darned if I can figure
    > out what it is. Help?


    OK, I'll let you in on a secret. When doing multi-platform development,
    you cannot escape having to do some #ifdef'ing:

    class A
    {
    unsigned char ...
    #if defined ( LINUX ) // or whatever your compiler defines
    unsigned somesuch myFunc( ...
    #elif defined ( WIN32 ) || defined ( MSDOS )
    unsigned otherthing myFunc( ...
    #endif
    ..
    };

    That should make your compilers happier.

    Now, if you want to do platform-independent programming (which you
    probably don't), you need to consider that 'unsigned char', 'unsigned
    short', 'unsigned int', and 'unsigned long' can all be the same size.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Aug 25, 2006
    #2
    1. Advertising

  3. Gordon Schumacher

    Bo Persson Guest

    "Victor Bazarov" <> skrev i meddelandet
    news:ecltkf$jlb$...
    > Gordon Schumacher wrote:
    >> I'm working with a class with a set of functions that need to be
    >> able
    >> to process any unsigned integer value, and I need this code to
    >> compile
    >> on multiple platforms, so I have something similar to:
    >>
    >> class A
    >> {
    >> uint8_t myFunc(uint8_t val);
    >> uint16_t myFunc(uint16_t val);
    >> uint32_t myFunc(uint32_t val);
    >> uint64_t myFunc(uint64_t val);
    >> };
    >>
    >> There must be a solution for this, but I'll be darned if I can
    >> figure
    >> out what it is. Help?

    >
    > OK, I'll let you in on a secret. When doing multi-platform
    > development,
    > you cannot escape having to do some #ifdef'ing:
    >
    > class A
    > {
    > unsigned char ...
    > #if defined ( LINUX ) // or whatever your compiler defines
    > unsigned somesuch myFunc( ...
    > #elif defined ( WIN32 ) || defined ( MSDOS )
    > unsigned otherthing myFunc( ...
    > #endif
    > ..
    > };
    >
    > That should make your compilers happier.


    The other way is to have different implementations for each supported
    platform, in separate directories. You can then set the proper include
    path for each compiler.

    >
    > Now, if you want to do platform-independent programming (which you
    > probably don't), you need to consider that 'unsigned char',
    > 'unsigned
    > short', 'unsigned int', and 'unsigned long' can all be the same
    > size.
    >


    And when doing byte swapping, we have to consider all the byte orders.
    There are way more than two!


    Bo Persson
     
    Bo Persson, Aug 25, 2006
    #3
  4. Gordon Schumacher posted:

    > I'm working with a class with a set of functions that need to be able
    > to process any unsigned integer value, and I need this code to compile
    > on multiple platforms, so I have something similar to:



    Here's how I'd do it. First, I'd start with a method of performing a
    compile-time assert:

    template <int i>
    struct VerifyType {
    unsigned bit_field_cant_be_negative : i;
    };

    #define COMPASS(expr) \
    int (*VerifyFuncDecl()) [ \
    ((void)sizeof(VerifyType<(expr) ? 1 : -1 >), 2) \
    ]

    Then I'd use it as follows:

    #include <limits>

    template<class T>
    T MyFunc(T const arg)
    {
    typedef std::numeric_limits<T> Lim;

    COMPASS(Lim::is_integer);
    COMPASS(!Lim::is_signed);

    /* Now it's safe to proceed... */
    }

    For some reason, it won't compile with g++, I get a gibberish error.

    --

    Frederick Gotham
     
    Frederick Gotham, Aug 25, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Iyer, Prasad C

    Overloading __init__ & Function overloading

    Iyer, Prasad C, Sep 30, 2005, in forum: Python
    Replies:
    3
    Views:
    6,449
    Fredrik Lundh
    Sep 30, 2005
  2. Fredrik Lundh
    Replies:
    0
    Views:
    470
    Fredrik Lundh
    Sep 30, 2005
  3. Steve Holden
    Replies:
    0
    Views:
    452
    Steve Holden
    Sep 30, 2005
  4. Replies:
    0
    Views:
    409
  5. Gordon Schumacher

    SOLVED: Function overloading and base types

    Gordon Schumacher, Aug 26, 2006, in forum: C++
    Replies:
    0
    Views:
    328
    Gordon Schumacher
    Aug 26, 2006
Loading...

Share This Page