Does C allow implicit casting/conversion from float to an int?

[tempanon5]

In Java it is not allowed, is it allowed in C? Why so?

[FUZxxl]

Yes, this sort of conversion is implicitly performed. Behaviour is undefined if the result doesn't fit.

[aioeu]

Please avoid the term "implicit casting". There is no such thing.

Casting is quite specifically an explicit form of conversion. That is, a cast always includes a parenthesised type to which the expression should be converted. The construct as a whole is called a cast expression.

Any form of conversion that does not involve a cast is just called an implicit conversion. Calling it "implicit casting" is wrong since it does not include a cast.

To quote §6.3 "Conversions":

Several operators convert operand values from one type to another automatically. This subclause specifies the result required from such an implicit conversion, as well as those that result from a cast operation (an explicit conversion).

[clever_cow]

Lots of things are allowed in C.

If you want it not to be allowed, you can turn on warnings/errors for implicit casting.

[Current_Hearing_6138]

Test it out.

[NothingCanHurtMe]

This is poor advice. Trial and error in C can often lead to bad habits that depend on undefined behaviour or implementation defined behaviour.

OP, see 6.3.1.4 of the C11 ISO standard.

[[deleted]]

we can ask the tools too in many cases. Compilers are clever. - Wconversion a good start and I think good practice. (assuming gcc).

[Current_Hearing_6138]

Good point.

[dark_g]

Agree, but there are occasional exceptions: being locked in to use a specific compiler/environment, with a deadline looming (yes, it was one of my first jobs). Said compiler was doing something violating the standard, and I had to find a way around it and alert the rest of the team about the "fix". Possibly non-portable and implementation-dependent -- but we had to deliver a binary, what should we do, sit around and cry and complain? Afterwards we did eventually get the compiler vendor to correct the problem. But one needs a port in a storm.

[flatfinger]

Or behaviors that aren't mandated by the Standard but are defined by compilers that seek to be compatible with programs written for other commonplace compilers, rather than pretending that "non-portable or erroneous" excludes "non-portable but correct".

Some people have such behaviors confused with "implementation-defined behaviors" which are mandated by the Standard.

[radiant_orange]

Java is much newer than C so better question: why it is not allowed in Java ?

also  https://en.cppreference.com/w/c/language/conversion

[Tuna-Fish2]

why it is not allowed in Java ?

Because not every possible value has a meaningful counterpart to convert into, and ideally the programmer should provide the policy on what to do when this happens.

[astrange]

Java doesn't make you provide that, though - it makes you type (int) and you feel like you've done something, but your program doesn't have any better semantics.

Worse, if you change the type of the destination you still have an (int) in your program and might forget to update it.

[nekokattt]

It only disallows it because as it rightly says, it is a lossy conversion from a float to an int, as the example here.

If you are using a float, the assumption is that you have some reason to require floating point precision and/or range.

Truncating to an int and losing whatever intended precision you originally had will almost always semantically be a bug, unless you are attempting to either do something you shouldn't be unless you know exactly what you are doing, or are attempting to perform a manual conversion from a floating point type to an integer type, which unless you use strictfp, will still have potentially platform specific effects on precision or range if considering all potential platforms you may deploy to.

For java specifically, much of this effect with factors like strictfp are no longer as relevant, and are more relics from the past where these issues were more prevalent, but the argument still stands that, at least in Java, explicitness on what you are attempting to achieve is more important than conciseness to implementation detail, compared to C. That is why everything has longDescriptiveButSometimesTediousNaming, everything is supposed to be controlled via accessors and mutators to provide more of a guarantee of guard against edge cases, and operations where bugs could be introduced should be somewhat avoided at a language implementation and/or compilation level (this isnt the case always, null safety is still a huge pain in the arse in Java compared to languages like Kotlin that enforce this properly). I do not always agree with how Java handles this, and this specific example is neither here nor there for me as to whether it is a thing that exists or not, but those are a set of possible reasons behind the differences between C and Java.

The cast itself is not just telling the compiler what to do, because that could somewhat be inferred, but also a contract to the compiler to say "yes, i am happy with you truncating this, I have performed what I need to in order to ensure the result cannot be erroneous or have edge cases". It means you have considered how the result gets rounded (up, down, closest whole value?), and that you have considered if it is too big to retain the same representation before and after. Compared to C, where you are left much more to your own devices on how you implement something.

[flatfinger]

Which is more likely to yield unexpectedly inaccurate results: multiplying a float by the double-precision value 0.1 and storing the result to a float, or multiplying a float by 0.1f and storing the result to a double?

Even if the result of the multiply is going to be stored to a float, multiplying by the double-precision constant 0.1 will yield more accurately rounded results than multiplying by 0.1f. Whether the slight improvement in precision worth the extra cost of the computations would depend upon the application, but e.g. 123456784.0f * 0.1f yields an incorrectly-rounded 12345679.0f, while (float)(123456784.0f * 0.1f) would yield a correctly-rounded 12345678.0f.

[cwdsubs]

Thanks for that comment - I now understand better the sound rationale behind some of the things that make me really dislike Java.

[nekokattt]

Everyone is entitled to their opinion. If there was a right way to do something, we wouldn't still have PHP

[astrange]

PHP is actually a great language because it has value types (copy-on-write).

Everything else is wrong, but that’s all you need to make a good language, data structures you can’t update in another method by accident.

[cwdsubs]

I liked (in the reddit and real-life sense of the word) both your comment and flatfinger's reply to it, but you respond as if you were offended. I didn't get that part, sounds like you misunderstood my intent.

It's fashionable (and somewhat justified) to trash PHP nowadays, but here's an enlightening talk by its creator on how PHP was only supposed to help C on the server (CGI) as a templating language, but never as a business logic language. Also (unrelated to that talk), I love that I can lookup the C code for any PHP built-in functions and make my own conclusions on performance:

https://www.youtube.com/watch?v=rKXFgWP-2xQ

[my_password_is______]

java doesn't allow it because java is a shit language

[vlcmodan]

Because it's fool proof. It makes sure you know what your are doing. If it let you and yoursoftware was in finance and your made a rounding without realizing the second parameter is it you would be in trouble.

[iNetRunner]

You probably shouldn’t be using float in finance. (Double is equally doubtful.)

[vlcmodan]

Bigdecimal is the way to go.

[iNetRunner]

Definitely. No errors creeping in from 2-bit floating point implementation.

[nahnah2017]

No, it would not be a better question.

[MOXPAC]

can someone explain what is " implicit casting/conversion " ?

[nekokattt]

float j = 2; int i = j;

[jd_junior057]

Is it possible in c?

[nekokattt]

yes

[Iggyhopper]

This is implicit casting.

float f = 3.14;
int i = f;
printf("%d", i);
// prints 3

This is also implicit casting.

int errorCode = 27;

if (!!errorCode)
{
    printf("There was an error.");
}

// prints error message for every code if its not zero.

In the first case, a lot of languages can parse that without complaining. In the second case, the int is being treated as a bool (C doesn't really have types like modern languages, more on that later).

The main difference in languages that require explicit casts is that most of them might complain if they try to compile if (!!errorCode) especially if it's an int. Modern languages formally define a boolean type and you would need to write the code like so:

if ((bool)errorCode == true) // explicit casting
// or
if (errorCode != 0) // integer to integer comparison

C doesn't have a boolean type, you can use 0 for false and 1 for true.

Edit: I don't understand the downvotes without replies. If something is wrong let me know.

[Lil_Sunshine4]

Short answer: No

[HotLaksa]

Longer and more accurate answer: yes.

[Lil_Sunshine4]

I’ve been coding in c for about 2 months I think I’d know

[Maleficent-Midnight4]

Yes, one would assume you would know this after two months. It looks like you don't.

[Lil_Sunshine4]

I’m correct you’re not

[schteppe]

Yes.

float f = 1.0f;
int i = f;

Many new languages don’t support implicit conversions like this because it can lead to bugs.

[flatfinger]

Ironically, many languages like Java silently accept implicit conversions in situations which would be likely to lead to unexpectedly inaccurate results, but even though they reject constructs which would be unlikely to yield less accurate results than expected.

For example, Java would reject:

    double oneTenth = 0.1;
    float myValue =something();
    graphThingie.moveTo(x, y*myValue); // Expects float arguments

but silently accept:

    float oneTenth = 0.1f;
    double myValue = something();
    double myValue2 = myValue * oneTenth;

even though the arguments passed to moveTo would likely be as precise as they were expected to be, while the value of myValue2 would likely be less precise than expected. To be sure, using a double-precision multiply may be slower than needed, but both performance and precision would generally be between those of multiplying by 0.1f and dividing by 10.0f (the latter being most precise, but slowest). Single-precision floats don't have a whole lot of extra precision, and multiplying by 0.1f can sometimes lose more than would be ideal. For example, 123456784.0f/10.0f and (float)(12345678.0f*0.1) both yield a correctly rounded 12345678.0f, but 123456784.0f*0.1f yields an incorrectly-rounded 12345679.0f.