Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Building Code::Blocks on Win 64
MortenMacFly:
--- Quote from: Biplab on February 21, 2012, 11:55:44 am ---And if you want to maintain compatibility with wx-2.8.x, you should keep cbIntPtr in the code.
--- End quote ---
No, in recent wx2.8 wxIntPtr is defined correctly (see wx/defs.h) - so its no longer a wx2.9.x thing. So you are more safe if you use wxIntPtr meanwhile... that was my point.
stahta01:
--- Quote from: MortenMacFly on February 21, 2012, 12:43:17 pm ---
--- Quote from: Biplab on February 21, 2012, 11:55:44 am ---And if you want to maintain compatibility with wx-2.8.x, you should keep cbIntPtr in the code.
--- End quote ---
No, in recent wx2.8 wxIntPtr is defined correctly (see wx/defs.h) - so its no longer a wx2.9.x thing. So you are more safe if you use wxIntPtr meanwhile... that was my point.
--- End quote ---
Where is it Documented as being in 2.8; I ask because I tried your argument with using wx_str() and it failed even though it has been in every 2.8 release I checked (checked about 4 releases).
Tim S.
Biplab:
--- Quote from: MortenMacFly on February 21, 2012, 12:43:17 pm ---
--- Quote from: Biplab on February 21, 2012, 11:55:44 am ---And if you want to maintain compatibility with wx-2.8.x, you should keep cbIntPtr in the code.
--- End quote ---
No, in recent wx2.8 wxIntPtr is defined correctly (see wx/defs.h) - so its no longer a wx2.9.x thing. So you are more safe if you use wxIntPtr meanwhile... that was my point.
--- End quote ---
My point is to keep things simple. wx-2.8 api is well established. wx-2.9 api is meant for wx-3.0. It may change over time until wx-3.0 is released. Till then I'd use wx-2.8 & wx-2.9 api separately wherever possible.
A couple of #ifdef s here and there wouldn't make any difference to the binary. It's trivial to remove them when we want to drop support of wx-2.8.
If we keep following bleeding edge wx-trunk, we may end up breaking Linux/Mac builds. If I'm not wrong, there are distros which come with older wx packages.
MortenMacFly:
--- Quote from: Biplab on February 21, 2012, 01:58:34 pm ---My point is to keep things simple. wx-2.8 api is well established. wx-2.9 api is meant for wx-3.0. It may change over time until wx-3.0 is released. Till then I'd use wx-2.8 & wx-2.9 api separately wherever possible.
--- End quote ---
Full agreed.
--- Quote from: Biplab on February 21, 2012, 01:58:34 pm ---If we keep following bleeding edge wx-trunk, we may end up breaking Linux/Mac builds. If I'm not wrong, there are distros which come with older wx packages.
--- End quote ---
Most likely I simply don't get it, but why defining an own type (cbIntPtr) if there is a type in both: wx2.8 and wx2.9 that works?
--- Quote from: stahta01 on February 21, 2012, 01:42:34 pm ---Where is it Documented as being in 2.8; I ask because I tried your argument with using wx_str() and it failed even though it has been in every 2.8 release I checked (checked about 4 releases).
--- End quote ---
Its not, I believe its not even documented in wx29... ;-) I just checked, it was introduced by JS himself in r66923, currently they are at r70626. However, I don't get what you mean with wx_str()? We are talking about {cb/wx}IntPtr here. ???
stahta01:
--- Quote from: MortenMacFly on February 21, 2012, 02:25:32 pm ---Its not, I believe its not even documented in wx29... ;-) I just checked, it was introduced by JS himself in r66923, currently they are at r70626. However, I don't get what you mean with wx_str()? We are talking about {cb/wx}IntPtr here. ???
--- End quote ---
I was just showing the example where I was told you could NOT use a 2.9 feature in 2.8 till it is documented in 2.8; This is even true when the feature existed in both 2.6 and 2.8. There is about 100 #ifdef that are not needed in Code::Blocks because of the c_str/wx_str functions where in 2.8 wx_str is defined the same as c_str but I could not use it because it was not documented.
Tim S.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version