3 ms·
IMHO there wasn’t any reason to bother fiddling with the definition of BOOL. It was well-understood that Obj-C BOOL and C++ bool are different types. Anybody w
by pavlov 3y ago
IMHO there wasn’t any reason to bother fiddling with the definition of BOOL.
It was well-understood that Obj-C BOOL and C++ bool are different types. Anybody working in Obj-C++ will deal with a ton of these differences, some minor (like BOOL) and some major (e.g. how NSString and std::string are not at all the same thing). Unifying a few bits here and there doesn’t deliver a lot of practical benefit.
- jviotti 3y agoAuthor here! We write Objective-C++ to connect existing Objective-C code (that uses BOOL) to C++ (where we want to just expose `bool`), which got us into this fun rabbit hole :)
- ryandrake 3y agoWhen I did Objective-C applications with C++ business logic, I recall our company's rule was to keep Objective-C code totally separate from the C++ code, in separate files, different headers, even different static libraries if possible--really quarantine them from each other. Then have a single, standalone, hideous Objective-C++ file that served as the smallest possible interface between the two. It's the only way we could keep sane. This was a trauma response from a previous project where no such discipline was maintained, and people just causally intermixed C++, Objective-C, C, and Objective-C++ willy-nilly all over the code, with now predictable results.
- chunkyguy 3y agoThis is the best way for having a objc and c++ in same project.
- plorkyeran 3y agoI work on a decade-old codebase where we freely mix C++, Obj-C++ and Obj-C as it makes sense and I can't say it's ever been an issue. Obj-C++ has some oddities, but on the whole mixing obj-c and c++ features works totally fine and I've never encountered a reason to want to separate them.
- rogueresearch 3y agojviotti, the reason BOOL was not changed to bool sooner was because it would break ABI compatibility. So on Mac for example, they had to wait until the x86_64 to arm64 to finally do it.
- dottrap 3y ago> IMHO there wasn’t any reason to bother fiddling with the definition of BOOL. There were good reasons to change this to a real boolean. I think it was a WWDC, where kind of discussing this topic, one Apple engineer said they did an audit of production Obj-C code and found multiple instances where their BOOL values were values other than 0 or 1 (which was considered surprising and ultimately bugs). This can lead to all sorts of subtle problems. One common one encountered by framework users is where something returns a BOOL and the user explicitly compared against == YES or == NO. If the value is say 2, then this code usually results in wrong decision.
- mulle_nat 3y agoAgreed. BOOL in Apple ObjC is a `char` though. That is a constant thorn in the side, when you are doing slightly more sophisticated stuff with argument passing and return values as you actually have to cast a lot (BOOL (*)(id, SEL, ...)). As the implementer of an Objective-C dialect, I am considering to go the other route and elevate BOOL to NSInteger (sizeof( NSInteger) == sizeof( id) in my case). Conceivably the compiler could (just) for @properties combine all the BOOL fields into a bitfield, so there would be less grousing about wasted space. Maybe or maybe not. * https://developer.apple.com/documentation/objectivec/bool?language=objc https://developer.apple.com/documentation/objectivec/bool?la... * https://github.com/iterate-ch/rococoa/blob/master/ObjcMsgSend.md https://github.com/iterate-ch/rococoa/blob/master/ObjcMsgSen...