Modarnization and Windows multi user fix

[draugvar]

This pull request introduces several updates to modernize the codebase, streamline build and test processes, and improve automation. The most significant changes are upgrading the project to C++20, replacing legacy shell scripts with CMake-based workflows, and adding a comprehensive GitHub Actions CI/CD pipeline for building, testing, and releasing. Below are the most important changes grouped by theme.

Build System Modernization:

• Upgraded the project and test suite to use C++20 instead of C++11, updating CMakeLists.txt, test/CMakeLists.txt, and related compiler flags to ensure compatibility across platforms. [1] [2] [3]
• Removed legacy shell scripts (build.sh, test.sh) and the Node.js package.json file, consolidating build and test commands into CMake targets. [1] [2] [3]
• Added a custom CMake target run_test for running tests, improving integration with CI workflows.

Continuous Integration & Release Automation:

• Introduced a new GitHub Actions workflow (.github/workflows/build_and_test.yml) to automate building, testing, and releasing the library on both Ubuntu and Windows, including dynamic version detection and release note generation.

Documentation Updates:

• Updated README.md to reflect the switch to C++20 and removed outdated build/test instructions, aligning documentation with the new build process. [1] [2]

[kyr0]

WOW! This is a fantastic refactoring!

Thank you @draugvar and @amassuoli

Do you believe this is ready to merge?

With the amount of work you've spent, I'd even go ahead and add you both as project members, so you can work on this project independently.

[draugvar]

Thanks Kyr0!
We’ve already integrated the refactoring into our environment and have been testing it extensively in real-world conditions. So far, it’s working flawlessly across all our multi‑process scenarios, even with different permission levels involved.
From our side, it absolutely looks ready to merge.
And thank you for the proposal — I'd be glad to contribute as project members!

[kyr0]

This sounds amazing, @draugvar - I've added you to the members of the project. I believe that you should be able to see a pending invitation.

With this, I believe, you should be able to even merge this PR. Please tell me, if the Merge button is available to you now (after accepting the invite).

Thanks again for your contributions!

[amassuoli]

Hi,
it's reasonably stable. I wouldn't call it fully production-ready yet, but I think it has just updates to existing code (as far as I can tell, peer reviews are there because of this :D ).

Anyway, thanks for the invite. We firmly believe in open source contributions, so happy to give back.
Let me personally (meaning that I am writing for this specific github account) assess if I can accept, it's a matter of checking what's company stance with open source contributions.

Anyway, for Windows use, the best course of action would be to go through a named file mapping instead of using a file - that's the appointed way to create shared memory there. Not that this way it doesn't work or that watchers aren't good for the job, the current situation can definitely do :)

That's a thing to track for the future, maybe.

Thanks for the kind words, and keep up the good work!

[draugvar]

Hi,

I can confirm that the Merge pull request button is enabled.
If you’d like, I can go ahead and merge it.

[kyr0]

Hi @draugvar and @amassuoli :)

The stage is all yours =) Thank you for your wonderful work!!

Please also feel free to merge on your own in the future. I'd be happy to see this project to be co-created more collaboratively and not to be dependent on me so much.

I still use this project as a peer dependency in my node-libsharedmemory project (that I'll probably update and release once we have this merged; and I might add a bun variant) -- but because with C++ we don't have any automatic 3rd-party dependency version upgrades, I don't see any reason why we wouldn't shouldn't at a higher frequency. Your code quality looks really good to me. Only thing I could with for would be extensive fuzzying tests and benchmarks. Especially also for concurrent mode settings in the very far future. But tbh. this would be too much to ask for, I guess. From the top of my head, there is also only one additional user I know of, who was interested in this.

[kyr0]

p.s.: @amassuoli I've just noticed that your collaborator invitation expired. I've renewed it - just in case the decision will be positive :)

[kyr0]

@amassuoli Regarding named file mapping support, I second this and created issue #7 . However, looking at use cases like #4 - I could imagine that the file/watcher based solution is less architecture specific. Maybe supporting both implementations and having a build flag to activate/deactivate them via preprocessor might be a good idea?