louischarlesc / safe Goto Github PK

In readme.md it states:
"Most cmake code comes from this repo: https://github.com/bsamseth/cpp-project and Craig Scott's CppCon 2019 talk: Deep CMake for Library Authors. Many thanks to the authors!"
Is this just autogenerated from there? Or is there actual code by third parties?
I need to know that because I am packaging safe for debian and the copyright needs to be strict.

1. A method to replace the protected variable :

safe::Safe<int> m_count{0};
m_count = 20; // equivalent to *m_count.access() = 20;

2. A method to get a copy of the protected variable :

safe::Safe<int> m_count{0};
auto count_copy = m_count.getCopy(); // equivalent to auto copy = *m_count.access();

reason: https://wiki.sei.cmu.edu/confluence/display/cplusplus/DCL59-CPP.+Do+not+define+an+unnamed+namespace+in+a+header+file

Consider playing with the names a little bit, to make them more reminiscent of the standard-library-only idiom, and/or more "narratively intuitive".

My main peeve here is with the names WriteAccess (from the overview) and its sibling ReadAccess. Those don't sound like class names; and the instantiation is about gaining write access, it's not that the instance is the write access.

Why not make it a little more like in the standard library, e.g.:

using safe_string = safe::safe<std::string>;
safe_string foo; 
safe_string bar;
std::string baz;
{
        safe::lock_guard lock(foo); 
	*foo = "Hello, World!";
}
std::cout << bar.unsafe() << std::endl; 

or maybe:

{
        auto lock = safe::lock_guard(foo);
	*foo = "Hello, World!";
}

The safe::Safe class template and specialization have an operator=() member function for assignment, but the semantics do not feel right:

safe::Safe<int> val;
val = val = 42;

does not compile because the operator=() accepts types that can be converted to int. The "val = 42" part is ok, but the "val = val" does not compile as safe::Safe is not convertible to int.

Two solutions:

1. remove the return value of the operator=(). This does not feel right either as every other operator=() out there returns a reference to the assigned object.
2. use a function like "set()" or "assign()" rather than operator=().

I prefer option # 2, and I prefer the name "set()". Any thoughts ?

Most commonly-used C++ libraries, AFAIK - including, of course, the standard library - use this_kind_of_names, not camel case (ThisKindOfNames). Consider switching. safe::access_traits::is_read_only seems nicer.

Hi, I'm currently trying out safe and I wonder how you could implement an upgradable safe::Access with the shared_mutex/shared_lock.

Hi - struggling with this feature. The readme reference a file /src/traits.h but I don't see this in my clone. I tried the example but hit error 'error: ‘AccessTraits’ is not a class template' .. Have I missed something?

I would like to create accessors with a helper. This will not work because Access class is not movable

template <typename T, typename... AccessArgs> auto read(safe::Lockable<T> const& obj, AccessArgs&&... accessArgs) { return std::move(safe::ReadAccess<safe::Lockable<T>>{obj, std::forward<AccessArgs> accessArgs)...}); }

Is there any particular reason not to have this?

Is it possible to upgrade CMake to a more recent version (v3.x)? This would enable many improvements.

CMake >= 3.12 would make sense, as it's the version shipped on Travis CI.

Hi,

I have some questions:

• This library work on raspberry pi (armv7)?
• This library work on iOS (x86, x86_64, armv8, armv8e)?
• This library work on Android (x86, x86_64, armv7, arm64)?
• It support iterator? I want use with std::map<std::string, MyStruct> and std::map<std::string, MyClass>.

Thanks.

I would suggest to have the standard dir packaging:

• ./include/safe/safe.h
• In the CMakeLists.txt, add :

install(DIRECTORY include/safe DESTINATION include)

• In the documentation and tests : #include <safe/safe.h>

For a couple of times while using this (very nice!) library I found myself in a little predicament when I want to use exit-on-error idiom, like so:

auto devices = devices_.readAcces();

auto dev = devices->find("somehow");
if( dev == devices->end() ) {
  connect("somehow");
  return;
}

if( dev->connected() == false ) {
  connect("somehow");
  return;
}

Since connect requires writeAccess to the same devices_ - it gets stuck, because ReadAccess object is still alive even though not needed inside either of if's.

Can you please give me any advice on what can be done in such case to keep everything clean?

(In this particular example I can extract both checks to a lambda but this, to me at least, looks a bit like hoop-jumping)

Hello,

you added a remote code download for your testing package doctest.

According to the Debian Free Software Guidelines this restricts us to update your application from v1.0.1 to v1.1.0. It wouldn't be in good spirit to the Desert Island Test which is a popular way to assert Free Software.

If you are still interested to be updated within the Debian ecosystem please consider checking for a local doctest then download it instead of FetchContent in your tests/CMakeLists.txt file so your application is again within Debian policy limits.

You can reply me here to trigger the update process again.

Greets Ernst

Using safe library c978f80, the attached program will output
Mutex constructed Value constructed
when compiled under VS2017, but only
Value constructed
when compiled under VS2015.

ConstructionTest.cpp.txt

Hi,

It isn't working in my sample:

https://github.com/prsolucoes/cpp-thread-safe-container

Your library is inside "02-fluentcpp" and the output is on README file.

Thanks for any help.

In the spirit of simplifying everything, I would challenge the following points:

• The real use of the doxygen file : I dont think anyone using this lib would build it and run it. They'd rather open the readme on the website.
• The use of gmock+gtest vs headeronly libs (catch2+fakeit) --> Using header-only libs would make the travis simpler and the project self-contained
• Have an examples folder with real-world cases : tests are hard to read, simple tests add code to compile.
• Are tests really necessary in this repo ?
• Can we remove everything and just keep safe headers + readme (and put the tests in a different repos) ? That would increase readability++.

Please comment this :)