There is no macro expansion problem, the OBJARRAY is just used wrong which the old macros allowed but the new macros not and your patch enables the wrong usage again :o). This is a prime example why macros are dangerous and evil.
OBJARRAY uses pointers internally but uses them value-wise, it takes care of the lifetime of the objects by deleting them and creating copies of them when necessary. The affected code however uses these arrays pointer-wise, it takes care of the lifetime of these objects itself. In the old wxWidgets versions the code got away with this by creating pointer-of-pointer arrays which the new macros prevent, but since they are macros your typedef trick allows the creation of these pointer-of-pointer arrays again.
The correct solution is to use the proper array type for "unmanaged" pointers, see the attached patch.
I applied your patch and then compilation fails. I quoted the full list of errors in my previous post, but it's awaiting moderation. The first error was in line 58 of wxFlatNotebook.h:
Apply objarray.patch only if it is needed against what killerbot uses to build night builds or if it is needed with wx-master. I have no opinion on the second dynarray.patch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to clarify, both patches are mutually exclusive and achieve the same, getting CodeBlocks to compile against newer/with disabled compatibility wxWidgets versions, they are just using a different approach.
objarray.patch gets the broken code to compile again, dynarray.patch fixes the broken code (couldn't test this though).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it is still broken, but the wxWidgets folks made broken code to compile again, just for the sake of compatibility. See the explanation here https://github.com/wxWidgets/wxWidgets/commit/02ffdd16f6664a3b81e24ced192fbeccaa4393ef. So i'm still sure my patch fixes the code, too bad i still don't know what to do that these code locations are getting executed so that i can verfiy that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
P.S. This error occurs also for GCC versions older than GCC 8, including 7.1 to 7.3.
There is no macro expansion problem, the OBJARRAY is just used wrong which the old macros allowed but the new macros not and your patch enables the wrong usage again :o). This is a prime example why macros are dangerous and evil.
OBJARRAY uses pointers internally but uses them value-wise, it takes care of the lifetime of the objects by deleting them and creating copies of them when necessary. The affected code however uses these arrays pointer-wise, it takes care of the lifetime of these objects itself. In the old wxWidgets versions the code got away with this by creating pointer-of-pointer arrays which the new macros prevent, but since they are macros your typedef trick allows the creation of these pointer-of-pointer arrays again.
The correct solution is to use the proper array type for "unmanaged" pointers, see the attached patch.
I have removed my patch and applied yours, but compilation fails:
I applied your patch and then compilation fails. I quoted the full list of errors in my previous post, but it's awaiting moderation. The first error was in line 58 of wxFlatNotebook.h:
Do a full rebuild and make sure you got rid of all precompiled headers
OK, it compiles now
Does anything speaks against this patch?
I have to resetup my environment to be able to test this...
Apply objarray.patch only if it is needed against what killerbot uses to build night builds or if it is needed with wx-master. I have no opinion on the second dynarray.patch.
Just to clarify, both patches are mutually exclusive and achieve the same, getting CodeBlocks to compile against newer/with disabled compatibility wxWidgets versions, they are just using a different approach.
objarray.patch gets the broken code to compile again, dynarray.patch fixes the broken code (couldn't test this though).
Is this still broken? C::B seems to build fine with wx-master...
Yes, it is still broken, but the wxWidgets folks made broken code to compile again, just for the sake of compatibility. See the explanation here https://github.com/wxWidgets/wxWidgets/commit/02ffdd16f6664a3b81e24ced192fbeccaa4393ef. So i'm still sure my patch fixes the code, too bad i still don't know what to do that these code locations are getting executed so that i can verfiy that.