tags:

views:

546

answers:

6

I'm working on a code base in which we have several configurable types. One of those types is 64 bit integer. When we compile for platforms that have no native 64 bit integer type, we simple represent 64 bit integers using a struct similar to

typedef struct {
    unsigned int hi, lo;
} int64;

In order to make this type useful, all common operations are defined as functions such as

int64 int64_add(int64 x, int64 y);

On platforms where a native 64 bit integer type is available, these operations simply look like

#define int64_add(x, y) ((x) + (y))

Anyway, on to the question. I am implementing some functionality regarding time and I want to represent my time using the 64 bit integer:

typedef int64 mytime;

I also want all the common operations available to the int64 type to be available for my time type as well:

#define mytime_add(x, y) (mytime) int64_add((int64) (x), (int64) (y))

The problem with this is that the casts between the types mytime and int64 isn't allowed in C (as far as I can tell anyhow). Is there any way to do this without having to reimplement all the add, sub, mul, div, etc functions for the mytime type?

One option is of course to never do the mytime typedef and simply use int64 everywhere I need to represent time. The problem with this is that I'm not sure if I always want to represent time as a 64 bit integer. Then there's the issue of readable code as well... :-)

A: 

You could try:

#define mytime int64

Instead of the typedef.

That looks like it will net you both the transparent conversion and the maintainability you're looking for.

Dan Fego
+1  A: 

Take a look at stdint.h header file. It contains int64_t, uint64_t, etc'. This is standard and portable way, and you will avoid the need to implement math functions :).

Drakosha
Doesn't help, because int64_t will only be there if the compiler supports a 64bit type.
Steve Jessop
A: 

Dan Fego: Thanks! That's exactly what I was looking for. Been writing code in C++ for way too long and would never have though of the preprocessor as a place to find the solution... :-)

Drakosha: Unfortunately stdint.h isn't available on all out taget platforms, otherwise I would definately have used it.

vonolsson
+2  A: 

Do you really need the cast? gcc is compiling the following example without any complains:


typedef struct int64 int64;

struct int64
{
    unsigned int hi, lo;
};

typedef int64 mytime;

int64
add_int64(int64 a, int64 b)
{
    int64 c;
    /* I know that is wrong */
    c.hi = a.hi + b.hi;
    c.lo = a.lo + b.lo;

    return c;
}

int
main(void)
{
    mytime a = {1, 2};
    mytime b = {3, 4};
    mytime c;

    c = add_int64(a, b);

    return 0;
}
quinmars
+3  A: 

Because you're using typedef's, you don't need the casts at all. Typedef's in C do not create a distinct type, only an alias to another type. The compiler does not distinguish between them. Just write the mytime_add function as:

#define mytime_add(x, y) int64_add((x), (y))

or if your C compiler is good enough to do inlining:

mytime mytime_add(mytime x, mytime y) { return int64_add(x, y); }
Walter Bright
Why not just `#define mytime_add int64_add` and not worry about macro argument evaluation and also gain the benefit of being able to use `mytime_add` as a function pointer?
Chris Lutz
A: 

Right, so I'm using typedefs and no casting. Works fine. Seems strange though that an explicit cast doesn't compile while an implicit one does. If the implicit cast really isn't a cast at all since the compiler sees the two types as being the same type, one would think the same reasoning would work when doing an explicit cast...

vonolsson