Fix name conflict & Support cmake install

[xiaozhuai]

See also microsoft/vcpkg#50329

Support following cmake usage

find_package(atomic_queue CONFIG REQUIRED)
target_link_libraries(main PRIVATE atomic_queue::atomic_queue)

[max0x7ba]

I defer reviewing this PR to original author of CMake files @RedSkittleFox , please.

[RedSkittleFox]

@max0x7ba
Changing the name from max0x7ba::atomic_queue to atomic_queue::atomic_queue is somewhat of a breaking change. Perhaps it would be sensible to make a new release because of that?

[xiaozhuai]

I agree, we need make a new release after merge this.
I changed the namespace because namespaces sharing the same name as the project are more common.
For example glm::glm, nanobench::nanobench, minifb::minifb, yoga::yogacore and etc.
Since this project previously did not export CMake config, this is an ideal opportunity to change the namespace.

[xiaozhuai]

And also, after make a new release, I will submit a new pr to add cmake usage about FetchContent.

[RedSkittleFox]

I've looked at both this MR and microsoft/vcpkg#50329 and tested this one locally. Both look good.

I've left two comments for the consideration. Otherwise this is ready to be merged.

If you decide to implement further changes per my suggestions I'll rereview this again.

[RedSkittleFox]

This name is very generic and might potentially conflict with some other package in the vcpkg ecosystem, perhaps it might be a good time to change this internal library name from atomic_queue to something like max0x7ba_atomic_queue and then alias that to either max0x7ba::atomic_queue or atomic_queue::atomic_queue?

[xiaozhuai]

IMO changing the port name of vcpkg is not a good idea, as it would break downstream. As for naming conflicts, that is an issue future ports should consider, I would like to keep the current port name.

[max0x7ba]

I've looked at both this MR and microsoft/vcpkg#50329 and tested this one locally. Both look good.

I've left two comments for the consideration. Otherwise this is ready to be merged.

If you decide to implement further changes per my suggestions I'll rereview this again.

Well, I read a CMake book more than a decade ago, but never wrote a line of CMake since then.

If you could review changes to CMake code you authored, dear @RedSkittleFox, I would click the merge button for you when you are happy with the changes 🤷🏼‍♂️💯😁

[xiaozhuai]

@max0x7ba I found that when I use this in a mm file, it has name conflict with nil. And I update this PR and solve this.

[max0x7ba]

@max0x7ba I found that when I use this in a mm file, it has name conflict with nil. And I update this PR and solve this.

Hmm, what is mm file and why does it break nil?

[xiaozhuai]

what is mm file

Objective-C++ (ObjC++) is an extension of the Objective-C programming language that allows seamless integration of C++ code and features within Objective-C programs. Objective-C is a core language for Apple platforms (like iOS and macOS), built on C with object-oriented extensions. ObjC++ further extends it to incorporate C++ elements.

[max0x7ba]

Well, this library adheres to and complies with the C++14 language standard.

In C++, nil is not a reserved keyword, and is available for use as an identifier of a class, function or object, in all namespaces without restrictions.

It could also be a preprocessor macro, breaking nil identifiers in any and all namespaces. Just like Microsoft's C headers define macros min and max, breaking std::min and std::max. That's the error of Microsoft's C header files defining macros with names reserved for user code, and, hence, breaking any perfectly well-formed C++ code by the misfortune of having to include Windows C headers. Microsoft NOMINMAX macro was introduced for Windows C headers to comply with the C++ standard by stopping breaking std::min and std::max.

In your case, the well-formed C++ standard compliant headers get broken when used by applications incompatible with the C++ standard.

If you'd like to use C++ headers in incompatible with C++ standard applications and environments, that's a problem of your own making. You cannot possibly ask of 3rd-party libraries to bend over and adjust to arbitrary constraints and limitations of yours or anyone else's incompatible environments. And without associated unit-tests your changes will be broken by some later change without anyone noticing.

You should rather adjust your environment and tools to comply with the language of libraries you'd like to use. That's what standard compliance exists for.

Objective-C++ ... allows seamless integration of C++ code and features within Objective-C programs...

Objective-C++ fails to deliver its "seamless integration of C++ code and features" feature, in this particular case. You should file a bug report against proprietary Objective-C++ tool breaking C++ header files.

Does that sound reasonable to you?

[xiaozhuai]

Objective-C++ fails to deliver its "seamless integration of C++ code and features" feature, in this particular case. You should file a bug report against proprietary Objective-C++ tool breaking C++ header files.
Does that sound reasonable to you?

IMO, it is not. nil is a predefined macro ( defined as (void*)0 just like NULL) in Objective-C and Objective-C++ and we cannot ask Apple to change it, It can only be a third-party library that provides compatibility for it.
Since objc++ is widely used on Apple platforms, I believe compatibility with it is essential. Not my own envirment, but Apple's.

I understand the min/max example you mentioned, but the situation here is indeed different. I am well aware that nil is not a reserved name in the C++ standard, but we can support objc++ with just a small modification and objc++ can be part of the cross-platform support puzzle for atomic-queue. All we need is a small modification.

Therefore, I still recommend changing nil to another name. If nil_value doesn't meet your requirements, I can update this PR.

[max0x7ba]

Objective-C++ fails to deliver its "seamless integration of C++ code and features" feature, in this particular case. You should file a bug report against proprietary Objective-C++ tool breaking C++ header files.
Does that sound reasonable to you?

IMO, it is not. nil is a predefined macro ( defined as (void*)0 just like NULL) in Objective-C and Objective-C++ and we cannot ask Apple to change it, It can only be a third-party library that provides compatibility for it. Since objc++ is widely used on Apple platforms,

This library is designed for C++ language.

Objective-C++ is not C++, is that right?

I believe compatibility with it is essential.

Compatibility of Apple's proprietary Objective-C++ with the C++ standard could be essential for Apple.

C++ not being compatible with Objective-C++ is Objective-C++'s problem. Is it not?

Not my own envirment, but Apple's.

And what does this C++ library have to do with your Apple's Objective-C++ environment?

I understand the min/max example you mentioned, but the situation here is indeed different. I am well aware that nil is not a reserved name in the C++ standard, but we can support objc++ with just a small modification and objc++ can be part of the cross-platform support puzzle for atomic-queue.

We cannot support Apple's objc++ because:

• Apple's Objective-C++ is incompatible with C++.
• Apple's compilers and tools aren't available for use free of charge.
• Apple's software documentation is not freely available.
• The licensing of artefacts produced by Apple's software is incompatible with open-source licences. You need a lawyer to comply with Apple's licensing to avoid getting sued.
• Apple's environment and tools aren't available in Github actions environments running the CI unit-tests. Because of all the above.

All we need is a small modification.

nil macro breaks C++ libraries.

Undefine nil macro with one line in your codebase prior to including C++ headers.

That is as small modification as it ever gets.

Therefore, I still recommend changing nil to another name. If nil_value doesn't meet your requirements, I can update this PR.

Are you going to recommend renaming to every C++ library that Apple's Objective-C++ breaks?

[RedSkittleFox]

@xiaozhuai the cmake and vcpkg changes were still valid contributions

[max0x7ba]

If nil_value doesn't meet your requirements, I can update this PR.

PRs with one change are the best practice. Easy to review, assess and accept.

PRs with more than one change are normally rejected. They must be split into multiple one-change PRs in order to be considered review-worthy.

Piling more changes into one PR while it is being reviewed is a little bit worse than submitting a PR with more than one change.

[xiaozhuai]

I have no interest in debating the naming conflict surrounding nil. However, I personally believe that insisting on abandoning compatibility with Objective-C++ is stubborn.

Are you going to recommend renaming to every C++ library that Apple's Objective-C++ breaks?

The answer is NO. But we could have done this. In fact, I've used a large number of C++ libraries in objc++, and they typically don't have similar issues.

[xiaozhuai]

PRs with one change are the best practice. Easy to review, assess and accept.

I agree : )

[xiaozhuai]

• Apple's Objective-C++ is incompatible with C++.
• Apple's compilers and tools aren't available for use free of charge.
• Apple's software documentation is not freely available.
• The licensing of artefacts produced by Apple's software is incompatible with open-source licences. You need a lawyer to comply with Apple's licensing to avoid getting sued.
• Apple's environment and tools aren't available in Github actions environments running the CI unit-tests. Because of all the above.

And these are not true as I know.

[xiaozhuai]

Finally, nil is a function located within the details namespace, and I don't think change it would cause any side effects.

I'd like to give another example: QT. If there's a naming conflict between this library and QT, what should we do? As we all know, QT is actually a superset of C++, and objc++ is likewise a superset of C++.

[RedSkittleFox]

Finally, nil is a function located within the details namespace, and I don't think change it would cause any side effects.

It's actually located in the namespace atomic_queue::details, it should not cause conflicts with any other library.

I have no interest in debating the naming conflict surrounding nil. However, I personally believe that insisting on abandoning compatibility with Objective-C++ is stubborn.

It's not really abandoning, this was never designed to work with it in the first place. AFAIK you could create a thin wrapper, compile it and then use that in objective-c++. This way you wouldn't be exposing the nil identifier to objective-c++ sources. I don't think changing the name from nil to something else is a big issue but it should be done in another MR.

[max0x7ba]

I have no interest in debating the naming conflict surrounding nil.

Me neither.

That's Apple's Objective-C++ problem to solve for its users, who pay Apple for the privilege of using Apple's Objective-C++.

However, I personally believe that insisting on abandoning compatibility with Objective-C++ is stubborn.

This library was never intended to be compatible with anything else than C++14.

It never had Objective-C++ compatibility to abandon now, to begin with.

Apple's Objective-C++ is what abandons C++ compatibility, making its users suffer.

---

Having said that, your CMake changes are most welcome.

Your CMake changes don't need to suffer because of Apple's Objective-C++ abandoning compatibility with the C++ standard.

[xiaozhuai]

AFAIK you could create a thin wrapper, compile it and then use that in objective-c++. This way you wouldn't be exposing the nil identifier to objective-c++ sources.

I know that, we all know there are many workarounds.

I don't think changing the name from nil to something else is a big issue but

I completely agree. Then why not?

it should be done in another MR.

Sure, I should have done that. But I cut corners. If the author requests it, I'm willing to do it.

[xiaozhuai]

Apple's Objective-C++ abandoning compatibility with the C++ standard.

This is not true. It's a superset of c++.

You also cited the example of min/max in msvc. It's common for our code to fail on certain platforms or in specific environments. We patch it to make it work on more platforms—we call this porting, am I right?

If only we could ensure that all environments were consistent, the world would be perfect.
MSVC is compatible with C++14, so why do we need #define NOMINMAX?
You cannot claim that msvc is incompatible with the C++14 standard simply because such a naming conflict exists.

[max0x7ba]

it should be done in another MR.

Sure, I should have done that. But I cut corners. If the author requests it, I'm willing to do it.

Dear Weihang Ding,

Would you be so kind as disentangle your uncontroversially valuable and most desirable CMake changes from any other changes, in order to have your CMake changes merged and, hence, let other people benefit from the fruits of your labour as soon as possible, please?

You can submit any other changes of yours as separate PRs, so that we can bicker out disagreements on a per-change basis without blocking any other changes of yours?

If you decide otherwise, I won't get offended. And you're welcome to change your mind any time.

Maxim

[xiaozhuai]

it should be done in another MR.

Sure, I should have done that. But I cut corners. If the author requests it, I'm willing to do it.

Dear Weihang Ding,

Would you be so kind as disentangle your uncontroversially valuable and most desirable CMake changes from any other changes, in order to have your CMake changes merged and, hence, letting other people benefit from the fruits of your labour as soon as possible, please?

You can submit any other changes of yours as separate PRs, so that we can bicker out disagreements on a per-change basis without blocking any other changes of yours?

If you decide otherwise, I won't get offended. And you're welcome to change your mind any time.

Maxim

Dear Maxim,

My pleasure. Let's set aside our differences for now. Have a nice day.

Weihang

[max0x7ba]

No complaints from me any more, I am happy.

@RedSkittleFox Give me green light to merge, when you are happy with the changes, please.