Xcode 27 and bits

[David Connet]

My system just updated to xcode27 - and it really dislikes ORing bits...

I updated all my sizer related things to use wxSizerFlags. (Kind of
painful, but I've been thinking about that for a while)

How should we handle object creation? For instance, a wxStaticText
object where I'm passing "wxALIGN_CENTRE | wxSTATIC_BORDER"?

David

[Vadim Zeitlin]

On Wed, 23 Sep 2026 17:48:26 -0700 David Connet wrote:

DC> My system just updated to xcode27 - and it really dislikes ORing bits...

I guess this means it uses C++20 by default now.

DC> How should we handle object creation? For instance, a wxStaticText
DC> object where I'm passing "wxALIGN_CENTRE | wxSTATIC_BORDER"?

I'm afraid you're going to need to cast wxSTATIC_BORDER to int explicitly.
What warning exactly does it give for this expression? If it's about
combining an enum with an int, then the only solution is to provide a
global overload of wxBorder with int which is a bit icky. But maybe we'll
have to do this.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
https://www.tt-solutions.com/

[David Connet]

On 9/23/2026 5:54 PM, Vadim Zeitlin wrote:
> On Wed, 23 Sep 2026 17:48:26 -0700 David Connet wrote:
>
> DC> My system just updated to xcode27 - and it really dislikes ORing bits...
>
> I guess this means it uses C++20 by default now.

Hmm - I didn't look at those settings... (tomorrow when I turn the
machine back on) Compiled via makefiles (which specify c++17, I did not
run into those errors)

> DC> How should we handle object creation? For instance, a wxStaticText
> DC> object where I'm passing "wxALIGN_CENTRE | wxSTATIC_BORDER"?
>
> I'm afraid you're going to need to cast wxSTATIC_BORDER to int explicitly.
> What warning exactly does it give for this expression? If it's about
> combining an enum with an int, then the only solution is to provide a
> global overload of wxBorder with int which is a bit icky. But maybe we'll
> have to do this.

If I remember, it was about combining different enums (nothing about
ints) (if I remember right - the machines asleep as I have to run to my
dog training class in just a couple minutes!)

For now, I'm just casting to int. (I didn't know if there was something
similar to wxSizerFlags for the creation flags) Based on what you
mentioned, I guess I'll just leave it that way... thx!

David

[Vadim Zeitlin]

On Wed, 23 Sep 2026 18:08:54 -0700 David Connet wrote:

DC> On 9/23/2026 5:54 PM, Vadim Zeitlin wrote:
DC> > On Wed, 23 Sep 2026 17:48:26 -0700 David Connet wrote:
[...]
DC> > DC> How should we handle object creation? For instance, a wxStaticText
DC> > DC> object where I'm passing "wxALIGN_CENTRE | wxSTATIC_BORDER"?
DC> >
DC> > I'm afraid you're going to need to cast wxSTATIC_BORDER to int explicitly.
DC> > What warning exactly does it give for this expression? If it's about
DC> > combining an enum with an int, then the only solution is to provide a
DC> > global overload of wxBorder with int which is a bit icky. But maybe we'll
DC> > have to do this.
DC>
DC> If I remember, it was about combining different enums (nothing about
DC> ints)

This matters because combining different wx enums should already be
supported by the use of wxALLOW_COMBINING_ENUMS() macro. But
wxSTATIC_BORDER above is an int (well, a #define for an int), not an enum,
which is why I'd like to see the exact warning message.

[David Connet]

On 9/24/2026 5:09 AM, Vadim Zeitlin wrote:
> This matters because combining different wx enums should already be
> supported by the use of wxALLOW_COMBINING_ENUMS() macro. But
> wxSTATIC_BORDER above is an int (well, a #define for an int), not an enum,
> which is why I'd like to see the exact warning message.
>

"Bitwise operation between different enumeration types ('wxAlignment'
and 'wxBorder')"

I did forget to note that I'm using 3.3.3 - in that, wxSTATIC_BORDER is
defined as wxBORDER_STATIC - which is an enum.

David

[Vadim Zeitlin]

On Thu, 24 Sep 2026 07:39:33 -0700 David Connet wrote:

DC> On 9/24/2026 5:09 AM, Vadim Zeitlin wrote:
DC> > This matters because combining different wx enums should already be
DC> > supported by the use of wxALLOW_COMBINING_ENUMS() macro. But
DC> > wxSTATIC_BORDER above is an int (well, a #define for an int), not an enum,
DC> > which is why I'd like to see the exact warning message.
DC> >
DC> "Bitwise operation between different enumeration types ('wxAlignment'
DC> and 'wxBorder')"
DC>
DC> I did forget to note that I'm using 3.3.3 - in that, wxSTATIC_BORDER is
DC> defined as wxBORDER_STATIC - which is an enum.

Oops, sorry, I was confused, I had seen that wxSTATIC_BORDER was an enum
but didn't follow it through. So you do have exactly the situation which
wxALLOW_COMBINING_ENUMS(wxAlignment, wxBorder) is supposed to help with and
now I don't understand why it doesn't.

This macro only takes effect in C++20 builds, but you did get these
warnings with C++20, didn't you? Or do you somehow get C++20 warnings in
C++17 builds?

[David Connet]

Another note: Just scrolled thru the options, C++17 is specified.

David

[Vadim Zeitlin]

On Thu, 24 Sep 2026 07:57:06 -0700 David Connet wrote:

DC> Another note: Just scrolled thru the options, C++17 is specified.

OK, this explains it... I don't know if we have a way of identifying this
particular compiler in C++17 mode, but if we do/anybody can provide it, we
could change the `#if wxCHECK_CXX_STD(202002L)` check before the definition
of wxALLOW_COMBINING_ENUMS_IMPL to take into account and then this should
fix the warnings (you can test it by making the check unconditional).

Alternatively, switching to C++20 should make the warnings disappear as
well, but be warned that C++20 can silently make the existing code work
differently, so it's not a trivial change.

[David Connet]

On 9/24/2026 8:08 AM, David Connet wrote:

> Ah - I switched to c++20 and it now builds. Looks like I'm getting
> that error (not warning) in c++17 mode.
>
> David

But only in xcode - when built via makefiles that does not happen.

[Vadim Zeitlin]

On Thu, 24 Sep 2026 08:09:05 -0700 David Connet wrote:

DC> But only in xcode - when built via makefiles that does not happen.

I have no idea how this works, but you need to compare the exact compiler
command lines in both cases. If they use the same compiler, they must be
passing different options to it. Or maybe they use different compilers due
to different platform/SDK selection.

[David Connet]

On 9/24/2026 7:50 AM, Vadim Zeitlin wrote: