0
#include <iostream>
#include <string>
#include <cmath>
using namespace std;
int main() {
    int a = 5;
    int b = &a;
}

Why doesn't this work? If I make b a pointer like int *b = &a then that'll work but if a memory address is just an integer in hexadecimal then why is this not okay?

ShadowRanger
  • 143,180
  • 12
  • 188
  • 271
  • 2
    One reason is `int` may be smaller than a pointer. This is the case on 64 bit msvc where int is 32 bits and pointers are 64 bits. – drescherjm Aug 27 '21 at 17:26
  • 1
    Because an `int` isn't a pointer. Why do you want to store a pointer in a integer? – NathanOliver Aug 27 '21 at 17:26
  • 7
    Because that is what type safety is for. They're both integers but semantically different (and might take up different sizes of memory). In fact, float, double, int, string, etc. are all just binary numbers. But we give them a type to tell the compiler **how** we want to use them. Then the compiler warn us if we try to use them differently than we have declared. – Ted Klein Bergman Aug 27 '21 at 17:26
  • `int` may not be large enough to store a pointer. If you want an integer type that's large enough to store a pointer, use [`std::intptr_t`](https://en.cppreference.com/w/cpp/types/integer). – Brian61354270 Aug 27 '21 at 17:27
  • Well I don't wanna store a pointer in an integer I wanna store the address of a variable in an integer –  Aug 27 '21 at 17:32
  • 1
    A pointer **is** the address. It just has a funky spelling and type. – StoryTeller - Unslander Monica Aug 27 '21 at 17:35
  • 2
    _"a memory address is just an integer in hexadecimal"_. "Hexadecimal" is a _writing style_. It's a way to **print** a number. No count or quantity of anything is intrinsically _hexidecimal_. – Drew Dormann Aug 27 '21 at 17:48
  • You can make it work: `int main() { int memory[1024]{}; int& a = memory[10]; a = 5; int b = static_cast(&a - memory); }` And a will be 5, and b will be 10. Where 10 is the offset into `memory` array where `a` is bound. If you want, you can even have b be bound to another cell in `memory`, there are still 1023 unused cells. – Eljay Aug 27 '21 at 18:17

2 Answers2

6

Well, first off, the sizes may not match; most general purpose computers nowadays use 64 bit addressing, but most compilers provide 32 bit ints (historically, some early 32 bit computers had 32 bit pointers but still provided 16 bit ints; this isn't a new problem).

It's also discouraged because it's usually an error (someone forgot to declare a variable as a pointer).

If you want a variable that is guaranteed to be able to fit a pointer, but acts like an integer, you can use intptr_t or uintptr_t, you just need to cast it to say "yep, I really meant to use this pointer as an integer".

ShadowRanger
  • 143,180
  • 12
  • 188
  • 271
0

It's not an integer in hexadecimal.

First of all, hexadezimal is just a possible output encoding, and the very same variable is also suitable for any other encoding, be it octal, decimal or binary. The native representation is binary in any case.

Next up, pointers and integral values are differentiated in the language design by choice, as a mix-up usually has bad consequences. Pointer also use pointer-arithmetic, which differs from integer arithmetic. E.g. (int*)(0) + 1 == (int*)( 0 + sizeof(int)).

Finally, that int is only 32bit, while the pointer, depending on the target architecture, requires 64bit, so this won't even fit, even if the compiler did allow that cast.

Ext3h
  • 5,713
  • 17
  • 43
  • We don't know that the `int` mentioned is 32-bits and I see no mention of address representation as text (maybe question changed). Your answer just seems slightly off. – Michael Dorgan Aug 27 '21 at 17:38