小编Ken*_*eth的帖子

这些术语之间存在很多混淆。我想把我的理解发表出来，看看人们是否同意。我在网上看到了相互矛盾和错误的定义。

在我看来，宽列数据库和列族数据库本质上是同一件事。他们是

1. 数据由一组键值对（每个键值对称为列）进行逻辑组织；
2. 由唯一的行键标识；
3. 每行可以有可变的长度或列的定义
4. 一行一行地存储在磁盘上。因此，列族（宽列）表与关系数据库的表相似，因为它们仍然被组织为行。

主要区别是它们没有固定的列模式，并且显然不能进行表连接。

3 行（列族）的示例：每行具有不同的长度和/或列，但在磁盘上rowkey1的整个内容是连续的行，后面跟着类似于关系数据库的其他行

rowkey1 k1-v k2-v k3-v

rowkey2 k1-v k4-v

rowkey3 k2-v k4-v k5-v

另一方面，术语“列式数据库”与“面向列的数据库”相同。它们一次一列存储在磁盘上，而不是一次一行。它非常适合时间序列或任何多序列分析目的。事实上，每列都具有相同类型的数据并且存储在一起，从而可以实现更好的数据压缩，这是一个额外的好处。

一个例子：

在磁盘上：

a:1 b:2 c:3 d:4

10:1 9:2 8:3 7:4

我正在尝试链接协程。Foo2 实际上会异步。一旦 Foo2 恢复，代码应按照“恢复 Foo2”和“恢复 Foo1”的顺序执行（如 2 延续）。有些细节我不太清楚。首先，当 co_await b 挂起时，它是否立即向调用者返回一个 Promise 对象？然后 co_await Foo2() 发生。此时我需要挂起但不想触发线程 t(run)。我认为我需要在 Foo1() 中的 co_await 之前包装 Foo2() 中的承诺/等待者。

void run(std::coroutine_handle<> h)
{
  std::cout<<std::this_thread::get_id()<<" "<<"in Run\n";
  std::this_thread::sleep_for (std::chrono::seconds(5));
  h.resume();
}

template<typename T>
struct task{

  struct promise_type {
    T val_;
    task get_return_object() { return {.h_ = std::coroutine_handle<promise_type>::from_promise(*this)}; }
    std::suspend_never initial_suspend() { return {}; }
    std::suspend_never final_suspend() noexcept { return {}; }
    void return_value(T val) { val_ = val; }
    void unhandled_exception() {}
  };

  bool await_ready() { return …

我在Win10的Node.js命令窗口中运行以下命令.它失败了.有人有想法如何解决它？我正在运行Node.js v7.3.0

C:\Users\haozhang>npm install openssl
C:\Users\haozhang
`-- openssl@1.1.0
  +-- mout@0.11.1
  `-- nyks@2.31.3
    +-- async@2.1.5
    | `-- lodash@4.17.4
    `-- mout@1.0.0

npm WARN enoent ENOENT: no such file or directory, open 'C:\Users\haozhang\package.json'
npm WARN haozhang No description
npm WARN haozhang No repository field.
npm WARN haozhang No README data
npm WARN haozhang No license field.

C:\Users\haozhang>openssl
'openssl' is not recognized as an internal or external command,
operable program or batch file.

在下面的代码中，callee 中的 string_view 值是每个设计的。但是返回给调用者之后，就报错了。这两个地址是不同的，所以似乎 return elision 不起作用。如果没有，我希望至少 string_view copy c'tor 应该可以工作，但也不能。

static string_view my_to_string_view(uint32_t value)
{
  std::array<char, 10> str;
  if (auto [ptr, ec] = std::to_chars(str.data(), str.data() + str.size(), value); ec == std::errc())
  {
    cout << "data:" << str.data() << "\n";
    cout << "length is:" << ptr - str.data()<<"\n";
    auto ret = std::string_view(str.data(), ptr - str.data()); // C++17, uses string_view(ptr, length);
    cout << "return value in func:" << ret << "\n";
    return ret;
  }

  throw std::exception();
}

int main()
{
  std::string_view …

My test shows that using lock-free atomic fetch_add is much slower than using mutex. I am running 10 parallel threads adding 1 million to the shared counter each. I am using relaxed memory order. Did I do the atomic wrong?

output from test:

fetch_add elapsed time: 4.14048 secs
fetch_add elapsed time: 5.37776 secs
fetch_add elapsed time: 5.37771 secs
fetch_add elapsed time: 5.37791 secs
fetch_add elapsed time: 5.37865 secs
fetch_add elapsed time: 7.85113 secs
fetch_add elapsed time: 7.93542 secs
fetch_add elapsed …