Why C has so many different types? [closed]

Answer 1

[N.B. I have almost completely rewritten this answer since I first posted it.]

The answer to your first question is, C has so many types in an attempt to balance the needs of supporting machines of all different word sizes, with reasonable portability. Things get more complicated due to the desire to also support specialized quantities like "sizes of data structures", "offsets in files", and "times in the real world" reasonably portably, and in spite of the fact that sometimes those specialized quantities end up being determined not by the language spec or the compiler but rather by the underlying operating system.

In general, there are two concerns when converting from a large integral type to a floating-point type:

1. the floating-point type might not be able to represent all the significant digits of the integral type accurately

2. the floating-point type might not even be able to handle the range of the integral type

In the case of time_t, there is an additional concern:

3. Type time_t might not be an integer number of seconds that you can meaningfully subtract

(These days, though, the "helpful" compiler warnings in response to these concerns do sometimes seem to border on the nannyish, and I share your concern. It can be hard to understand what obscure situation the compiler is actually worried about, and it can be hard to see how to rewrite the code without warnings, and it can be hard to be sure that any casts you end up having to insert don't end up making the code even less safe.)

If you're not worried about concern #3 (if you're willing to assume that time_t is an integer number of seconds), you can minimize the chances for data loss by doing the subtraction first (and in the integral type), and then converting:

return (sometype)(end->tv_sec - start->tv_sec) +
       (sometype)(end->tv_usec - start->tv_usec) / 1e6;

But of course the big question is, what should sometype be?

I believe your best bet is to cast to double in each of those places. Both the guaranteed range and precision of type double in C are quite large. So unless you're manipulating time differences greater than 1e50 years (and unless someone has implemented type subsec_t to be a 266-bit type or something), your code should be safe even with the warning-suppressing casts, and you can insert a comment to that effect.

If you want to understand how these concerns can actually manifest in practice, it's easy to demonstrate them. Try this:

float f = (float)2000000123L - (float)2000000000L;
printf("%f\n", f);

If you have a 64-bit compiler, you can observe precision loss even with double precision:

double d = (double)9000000000000001234LL - (double)9000000000000000000LL;
printf("%f\n", d);

On my machine, these two fragments print 128 and 1024, respectively.

I'm not sure exactly which of the three concerns your compiler was trying to warn you about. #1 is the likeliest possibility. And you can see how the precision loss disappears if you convert after subtracting, instead of before:

f = 2000000123L - 2000000000L;
d = 9000000000000001234LL - 9000000000000000000LL;

or

f = (float)(2000000123L - 2000000000L);
d = (double)(9000000000000001234LL - 9000000000000000000LL);

Back when all we had was 32-bit longs and 64-bit doubles, this wasn't much of a concern in practice (because IEEE 754 doubles have something like 52 bits of precision). Now that 64-bit types are becoming commonplace, these kinds of warnings are becoming much more widespread. If you're satisfied that type double has enough precision for all your time-subtracting needs, you can use appropriate casts to double to silence the warnings. (And, again, here by "appropriate" we mean "after the subtraction".) If you want to be even safer, you could move to type long double instead. If your compiler supports it, and if it is indeed "longer" than regular double, it can truly reduce the loss-of-precision problem. (Here's the previous example using long double:

long double ld = (long double)9000000000000001234LL - (long double)9000000000000000000LL;
printf("%Lf\n", ld);

On my system this one prints 1234.)

But with all of that said, in this case, if you want to really make your life easier -- and, incidentally, address concern #3 at the same time -- you could and arguably should use a standard function for computing the differences. The standard function for subtracting two time_t values is difftime. (It's difftime's job to worry about all of these things, including the possibility that time_t doesn't represent seconds directly.) So you could write

return difftime(end->tv_sec - start->tv_sec) +
       (double)(end->tv_usec - start->tv_usec) / 1e6;

although of course there's still the problem of the subseconds.

The very best solution would be a prewritten library function to subtract two timeval's, and you might want to spend some time looking for one of those.

Answer 2

To avoid the warnings

double mytimer(struct timeval * start, struct timeval * end) {
    long usec = end->tv_usec - start->tv_usec;
    long sec = end->tv_sec - start->tv_sec;
    return 1.0 * sec + 1e-6 * usec;
}

If you see the datatypes defined in <sys/types.h>, inherently you'll find

typedef long time_t;
...
typedef long suseconds_t;

There are no specific format specifiers for struct timeval but the structure members are of type long. Hope this solves your problem.

Answer 3

The reason is that the built-in types like int are platform-dependent. So on one computer an int might be good enough to store a time value, while on another you would need a long. To allow people to write programs that run on all platforms, types like time_t were introduces, which are often just alias definitions for some primitive type that is suitable on that particular platform. This in fact takes a little more learning effort in the beginning, but this effort will pay large dividends in the long run.

Makes sense, doesn't it?

[EDIT]: As for the strange warnings: The compiler is warning that the conversion of a time_t and suseconds_t to double might lose some information. That is because both types are integer types with more bits than the mantissa part of double. In your case that would apply only to very large time values, so you can simply ignore these warnings. (But how should the compiler know that a time_t value normally fits into a double? So he emits this warning.) There is in fact not much you can do about that without making the code platform-dependent.

Answer 4

Because what time_t etc contains are implementation-defined, there is nothing saying that they should contain a number of seconds as an integer, like the comment in your code implies. The reason is that they want these types to be portable between different systems.

In practice, time.h is indeed rather cumbersome, so most of the time programs end up calling system-specific functions instead.

Answer 5

While these type are generally implemented with standard integral types, you can't assume this for portability. The standard library offers some convenient functions for conversions, etc. For example, if you want to compute the delay in between times you can use difftime which returns a double.

Answer 6

As buttiful butterfly correctly points out, the aim of the c++ language and standard library design is to enforce logical correctness at compile time.

What this means is that we aim for a situation where a program that would do the wrong thing under certain obscure circumstances simply will not compile (or will compile, but will warn you).

This means you can fix these logical errors before your software ever even runs in your test harness, let alone in front of your customers.

The result of this is that correctly written c++ code can be mostly proven to be 'correct' before run-time, meaning you spend a great deal less time tracking down obscure bugs that you otherwise would.

The magic of c++ is that is performs this incredible feat while offering a fantastic of efficiency and code optimisation.

note: by 'correct' I mean that it will reliably do what you think you're telling it to do. It's still up to you to write the correct logic!

as to the questions:

So my question is why does C define so many incompatible types instead of simply using primitive types such as int short ...? It's not user-friendly at all.

They are made incompatible in order to deliberately prevent you from converting them to each other. They represent different concepts, in the same way that velocity and distance are different concepts. There is no direct conversion between them.

And how can I do arithmetic operations on these types?

make the intermediate results of your arithmetic something that these types can safely convert to without losing precision. In this case, tv_sec and tv_usec are integral types, so even though they are incompatible with each other, they are both convertible to double individually.

for example:

double mytimer(struct timeval *start, struct timeval *end)
{
    return double(end->tv_sec - start->tv_sec) + 
           double(end->tv_usec - start->tv_usec) * 1e-6;
}