2
$\begingroup$
int *numPtr;
double num;
numPtr = #

This code shows an error as pointer points to data of different datatype. But why does it show the error? Why doesn't the compiler typecast the pointer and remove the error?

Just like a character becomes an integer as it is implicitly typecasted. (int a = 'a';) It should do similarly and remove the error.

$\endgroup$
3
  • 1
    $\begingroup$ Among other probable reasons, in numPtr = &num, you are trying to point to a RHS type that is typically four bytes wider than the type on the LHS. $\endgroup$
    – Noah
    Aug 6 '21 at 21:31
  • 2
    $\begingroup$ "Why" questions are usually considered opinion-based. By the way, language-specific quesitions are more appropriate on StackOverflow. $\endgroup$
    – xskxzr
    Aug 7 '21 at 4:22
  • $\begingroup$ BTW. A "typecast" is an explicit command to convert an object in your source code, like (int) 'a'. What you are talking about is a "conversion" or "value conversion". $\endgroup$
    – gnasher729
    Aug 17 '21 at 9:25
2
$\begingroup$
Why doesn't the compiler typecast the pointer and remove the error?

What's allowed is not dictated by the compiler but by the C++ standard and implicit conversions from a "pointer to double" to a "pointer to int" are not allowed by the standard. See, e.g., section 7.11 here.

There is nothing, in principle, that prevents you from coming up with a C++-like language where the above program is well-formed, once you specify what the semantics of the above assignment is.

As it is, I don't see any obvious meaning of what you are trying to write and I believe that if you try to formally specify what your expected behavior is, you'll run into problems.

Notice that there is no object of type int. What would be the reasonable thing to do? Should the compiler create one new int for you, initialize it with the result of a cast from double to int, and then assign the address to numPtr? Should that be allocated on the stack or on the heap? If it's on the stack, should using the pointer outside the current scope be illegal? If it's on the heap, who's responsible for free-ing the allocated memory? How should changes on num reflect on *numPtr? Even worse, numPtr is not a pointer to a constant int, so how should changes to *numPtr reflect on num? What if a new pointer, say of type short, is initialized to numPtr?

If no new object is created, how do you reconcile the fact that two pointers of different (and incompatible) types point to the same memory address? (Recall that you can do numPtr = reinterpret_cast<int*>(&num); but dereferencing numPtr violates aliasing rules).

$\endgroup$
0
$\begingroup$

This is because casting from char to int is up-casting, since an int is "an extension" of a char (in C, it is the same "thing" except for that it has a larger storage size). You can think of it as the same as casting from int to long. Basically, we use char also for alphabet letters because its size is convenient, but it actually just represents a number with less storage.

However, casting a double to int * is doing a totally different thing, since you are asking to convert a number into a pointer. A number and a pointer are inherently two different things, and as such there is no "natural" conversion between them. Therefore, in order to avoid weird mistakes (since most likely you won't want to convert a number to a pointer), the compiler complains that it cannot cast it. However, you can tell the compiler you specifically meant for this cast to happen by explicitly writing a type cast, with the syntax: (<type>) <variable name> to convert the variable <variable name> into the specified type <type>.

$\endgroup$
0
$\begingroup$

The code indicates that the programmer made a mistake. It's easy for the compiler to change the code in a way so that it compiles. But it is impossible for the compiler to know what your mistake was.

I would usually assume that if I assign num = 7.0 then *numPtr == 7. That won't be the case with your suggestion, so the compiler would produce something that is fundamentally broken without any warning.

The statements as written are plainly wrong. If you as a programmer fixed the compiler error by adding the cast I would worry about you. That fix would be utterly stupid. The real fix would be either changing the type of num to int, or the type of numPtr to double*, or to think about the situation and maybe coming to the conclusion that what you are trying to do just doesn't work. Not something you would leave to a compiler.

After a year or so of programming, you will likely turn on all reasonable warnings in your compiler so that it will warn you if you do something suspicious. You don't want a compiler that takes everything without thought. You definitely don't want a compiler that makes ill-judged attempts at fixing your mistakes.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.