Keeping up to date with Bricks and FNCAS + minor cleanup.

[dkorolev]

No description provided.

[dkorolev]

Uses KnowSheet/fncas#5.

Thanks!
Dima

[dkorolev]

And merged in #13.

@sompylasar : Could you please take a look? Max is busy for the next few days. Thanks!

[sompylasar]

_with_snapshot?

[sompylasar]

@dkorolev LGTM. Minor nits.

[dkorolev]

Fixed the minor things.

The const issue:

1. The entry should be passed as non-const. This is to allowing moving unique_ptr-s out of the caller thread into message queues for other threads. If the design enforces the passed in objects to be mutable, it's easy (just std::move them away), while if the design does not, it's up to the user to clone those objects, which is a pain for polymorphics.
2. A non-const entry can be passed on to a const-accepting method. So this part is solid.
3. Nonetheless, map::operator[] is mutable in C++ (it will create non-existing entries with default values, in order to be able to return references), and to keep using array-style indexing I simply kept one of two Entry-accepting method take a mutable input.

@sompylasar : PTAL. Thanks!

[sompylasar]

Thanks for the thorough explanation!

Which is preferred: having const or not in the Entry method signature? I
saw both around the code, and I've recently copy-pasted the non-const one
into the db/test.
25.03.2015 9:06 пользователь "Dima" [email protected] написал:

Fixed the minor things.

The const issue:

The entry should be passed as non-const. This is to allowing moving
unique_ptr-s out of the caller thread into message queues for other
threads. If the design enforces the passed in objects to be mutable, it's
easy (just std::move them away), while if the design does not, it's up
to the user to clone those objects, which is a pain for polymorphics.
2.

A non-const entry can be passed on to a const-accepting method. So
this part is solid.
3.

Nonetheless, map::operator[] is mutable in C++ (it will create
non-existing entries with default values, in order to be able to return
references), and to keep using array-style indexing I simply kept one of
two Entry-accepting method take a mutable input.

@sompylasar https://github.com/sompylasar : PTAL. Thanks!

—
Reply to this email directly or view it on GitHub
#12 (comment)
.

[dkorolev]

I'd suggest we go with non-const and override (virtual bool Entry(SomeType& entry, size_t, size_t) override { ... }) whenever possible.

Even though currently the dispatching is done via template magic, not virtual functions table, and thus virtual and override are not necessary, I can totally see a lot of usecases for them in the future, and would prefer to be proactively ready for them.

[sompylasar]

@dkorolev Maybe add this suggestion somewhere into the Sherlock docs?

[dkorolev]

👍 KnowSheet/Sherlock#11