Why is new juce::image giving so high pointers?

General JUCE discussion
1

Not quite sure if this is the right forum or such and it is kind of more of general c++ question, but here it goes.

I was trying to find some issues I have in my synth so I made some checks on some pointer values.

.... snippet

        textImage = new Image(Image::ARGB, getWidth(), getHeight(), true);
        void* p = malloc(1024*1024);
        char* c = new char[1024*1024];
        
        printf("%p %p %p\n", textImage, p, c);
        printf("%i, %i", getWidth(), getHeight());

...end snippet

printf gives the following

0x618001410450 0x12c163000 0x12d0f7000
225, 90

As you can see, new "new Image" gives a pointer value waaaay higher than "malloc" and "new char".

The code works as expected though but it got me curious.

>>> x = 0x618001410450
>>> x/(1024*1024*1024)
99840

What fundemental thing am I missing if I interpret that as a pointer 99840 gigabytes in to the ram!? :)

Please be kind ;)

 

 

2

I would guess that's just how it happens to go in your test case for whatever reason...This is from a 64 bit build, right...? Did you run the test multiple times? Debug or release build?

Incidentally, you probably shouldn't even be "new":ing Juce::Images, they are themselves internally wrappers to shared heap allocated data already, so why add yet another level of indirection in your code...?

3

Is textImage a pointer?

4

Would some compiler actually allow writing something like Image img=new Image... ? 

I would actually suspect it's just the printf formatting of the pointer values doing something weird here. 

5 
Image img = new Image();

No since that would be Java or C# syntax, and any decent C++ compiler would spit an error.

I wouldn't be surprised if printf() is broken somehow. A cast to a valid integer type to represent the address (e.g.: juce::pointer_sized_int) would confirm if that's true.

6

TextImage could be a smart pointer.

7

Yup it's a 64 bit build, debug. I have run it several times and it is the same every time.

I doubt it is just printf is giving wrong numbers. When I run it in xcode and stop with the debugger I see the same values.

 

About having it as a pointer.. You might just well be correct that it is unnecessary indirection. It is however working code.

8

textImage is a normal old school pointer.

9

Casting to a big integer type is how I first found it.

I made a small function to check pointer.... a bit of warning.. this is hackish ;)

In a normal Release build this will be just a null-check but in Debug some more where I set breakpoints and stuff.

 

//this is by no means watertight or even close but might catch a few percent of potential pointer bugs.
bool okPointer(void* p) {
    if(p != nullptr) {
#ifdef DEBUG_BUILD
        uint64_t address = reinterpret_cast<uint64_t>(p);
//                     0x610000c00570
        if(address > 0x400000000) {
            DBUG(("WARNING, strangely large pointer value %p", p));
            return false;
        }
        if(address < 0x000001000) {
            DBUG(("WARNING, strangely small pointer value %p", p));
            return false;
        }
#endif
        return true;
    }
    return false;
}

10

Helpful advice:

1. Never create a new Image! it's a by-value class, you never need to allocate it on the heap.

2. Never worry about the physical numbers that your pointers have! It doesn't matter, let the compiler worry about this. On 64-bit systems allocators use all kinds of tricks to place blocks of memory, but it's not your problem.

11

(3.) And if you are really concerned by what's hap IMHO the only way is to look inside the assembly generated by your compiler.

12

Ok, then I suppose the big lesson here is that the addresses are not human readable what so ever.