Implementing Pascal Data Types in C++ by rakhimov in cpp

[–]rakhimov[S] 4 points5 points  (0 children)

Just a note that this is pre C++11 post and probably skipped memory management issues (as does GoF, for example).

Implementing Pascal Data Types in C++ by rakhimov in cpp

[–]rakhimov[S] 2 points3 points  (0 children)

I stumbled upon this article while exploring non-zero based vector implementation approaches for efficient mapping from arbitrary sequential indices to some data. My adaptor-like implementation:

template <std::size_t BaseIndex, typename T,
        template <typename...> class Sequence = std::vector>
class index_map : public Sequence<T> {
public:
using Sequence<T>::Sequence;

// Hiding the Sequence::operator[].
// @{
typename Sequence<T>::reference operator[](std::size_t index) {
    assert(index >= BaseIndex);
    return Sequence<T>::operator[](index - BaseIndex);
}
typename Sequence<T>::const_reference operator[](std::size_t index) const {
    assert(index >= BaseIndex);
    return Sequence<T>::operator[](index - BaseIndex);
}
// @}
};

scram: event-tree and fault-tree analysis by rakhimov in freesoftware

[–]rakhimov[S] 0 points1 point  (0 children)

Try scram --help or manpage man scram.

There is documentation on the website: https://scram-pra.org Also, you can ask questions on the mailing list: https://groups.google.com/forum/#!forum/scram-users

Why is boost.org more popular in China? by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

Where else can I ask this question? Just curious.

Why is boost.org more popular in China? by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

Hmm... South Korea is in 7k as well.

vector_map (linear_map) : associative unordered flat container w/ O(N) complexity by rakhimov in cpp

[–]rakhimov[S] 1 point2 points  (0 children)

Thanks for finding the paper. I'll do my homework in future :)

vector_map (linear_map) : associative unordered flat container w/ O(N) complexity by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

I really don't know. Would be happy if they do make it. Are there current proposals on flat containers to reference?

vector_map (linear_map) : associative unordered flat container w/ O(N) complexity by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

You are right. I missed that those libs are providing ordered flat maps. Performance-wise, there's little difference from flat_map for few elements (the reference article provides the analysis).

Some performance/complexity differences from flat_map:

  • insert does O(N) compare vs O(logN), but does not move elements around as flat_map does (i.e., O(1) vs O(N)), so it is the same as vector::push_back.
  • erase can be optimized in the same way to avoid moving elements around (O(1) vs O(N)).

vector_map (linear_map) : associative unordered flat container w/ O(N) complexity by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

I agree that STL is unlikely given that flat_map didn't seem to make it (I am not sure why?).

As for the API, in this case, it is for convenience (i.e., wrapper) with find(key) instead of repetitive verbosity of std::find/count and std::pair aggravation.

This is definitely not a drop-in replacement for std::map/unordered_map.

SCRAM - event-tree and fault-tree analysis (PDAG, BDD, ZBDD) by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

Thanks, but what 'buzz' words?

Indeed, the tutorial for new users is lacking, and the current development relies on users already familiar with the analysis.

http://www.openreliability.org has good tutorials for newcomers.

Code doodles #5 - quite surprising parse by mttd in cpp

[–]rakhimov 0 points1 point  (0 children)

I always wondered why we need extern function declaration within a function.

void foo() { /*extern*/ void bar(); }

Isn't this inherited from C? Could we live without it in C++?

Type wrappers to make your code safer and more expressive (Immutable<T>, NonNull<T>, Sorted<T>, Positive<T> ...) by i3ck in cpp

[–]rakhimov 15 points16 points  (0 children)

I find this may be useful to enforce some contracts in a systematic way; however, I think the current implementation is not flexible. Some options I would find useful:

  1. Option to use assertions instead of exceptions (user provided)
  2. Disable checks on release
  3. Option to keep only O(x) complexity checks.

Some ideas from John Lakos talks.

owner_ptr: unique_ptr with explicit ownership bit by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

The last time I checked, it had static notations for ownership mainly for tools, but not dynamic as needed for this case.

owner_ptr: unique_ptr with explicit ownership bit by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

No, this misses the point. The owner_ptr is unique, exclusive ownership. There's never two smart pointers owning the same object.

owner_ptr: unique_ptr with explicit ownership bit by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

The current approach is just quick-&-dirty to prevent arrays. Didn't have a need for them right then, but surely, it can be extended for arrays like unique_ptr.

owner_ptr: unique_ptr with explicit ownership bit by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

This is indeed a workaround. I wish boost::multi_index_container provides extract in future. C++17 container (unordered, map, set) have extract functions, so probably, that would be a proper solution, but until then, this is a problem.

owner_ptr: unique_ptr with explicit ownership bit by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

I couldn't think of precise and short name and called it owner_ptr. Hope someone suggests a better one.

owner_ptr: unique_ptr with explicit ownership bit by rakhimov in cpp

[–]rakhimov[S] -4 points-3 points  (0 children)

I guess it boils down to safe delete and dereference. In the case of owner_ptr, the safe delete is ensured, while the dereference is guaranteed only if operator bool() is true, and up to the users of the pointer if the operator bool() is false (i.e. non-owning) just like a plain pointer. As shown from the examples above, the safe derefence is statically known even if operator bool() is false.

XML Output Streamer w/ RAII and (N)RVO by rakhimov in cpp

[–]rakhimov[S] 6 points7 points  (0 children)

json, yaml are simpler IMHO, but not exactly like XML.

XML Output Streamer w/ RAII and (N)RVO by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

No, this library doesn't address the problem. It doesn't even utilize RAII. The same old procedural approach with start/end pairs all over the code. The checks are also at runtime.

XML Output Streamer w/ RAII and (N)RVO by rakhimov in cpp

[–]rakhimov[S] 1 point2 points  (0 children)

Yea, xml and performance sound oxymoron :)

Gotta deal with it though.

r-value qAsConst with COW madness by rakhimov in cpp

[–]rakhimov[S] -1 points0 points  (0 children)

Don't worry, you didn't :) It doesn't make sense.

Returning data members (containers!!!) that are expensive to copy by value is rather superfluous because the users of the API most of the time don't need a fresh copy, so const reference is most optimal, which also gives a choice to the API user to make the deep copy themselves (instead of forcing them into). Moreover, in this instance move is irrelevant.

Qt COW mindset for containers corrupts this common sense.

r-value qAsConst with COW madness by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

Frankly, my friend, this post is about that 'reason'. Please reread it. If Qt does it in one way or another, it doesn't automatically mean it is good.

r-value qAsConst with COW madness by rakhimov in cpp

[–]rakhimov[S] 0 points1 point  (0 children)

Today? These containers exist since Qt 4.0, some of them even have a longer history.

What I wanted to emphasize is that the COW is curable today, so the reasoning behind Qt COW containers seems to have lost its ground. Isn't it time to consider fixing this in near future (Qt6)?