小编dvd*_*dvd的帖子

GCC和clang对此代码持不同意见.

#include <type_traits>

template <typename T, template <typename...> typename Tpl> 
struct storage {
    using type_t = T;

    template <typename... Args>
    using storage_tpl = Tpl<Args...>;
};

template <typename T, template <typename...> typename>
struct F{
    constexpr static int x = 1;
};

template <typename T >
struct F<T, std::void_t>{
    constexpr static int x = 2;
};

int f() {
    using S = storage<int, std::void_t>;

    static_assert(F<int, S::storage_tpl>().x == 2);

    return F<int, S::storage_tpl>().x;
}

根据铿锵S::storage_tpl不是std::void_t; 结果,它选择主模板F而不是部分特化,从而选择断言.

乍一看,它看起来像GCC是正确的,因为它知道该嵌套模板仅仅是一个别名std::void_t,但也许是太聪明,该标准要求S::storage_tpl …

在查询中引入ORDER BY子句会增加总时间,因为db必须执行额外的工作才能对结果集进行排序:

• 将生成的元组复制到一些临时内存中
• 排序它们(希望在内存中,否则使用磁盘)
• 将结果传递给客户端

我想念的是为什么只从连接表中添加一列产生如此不同的性能.

查询1

EXPLAIN ANALYZE
SELECT p.*
FROM product_product p
JOIN django_site d ON (p.site_id = d.id)
WHERE (p.active = true  AND p.site_id = 1 )
ORDER BY d.domain, p.ordering, p.name

查询计划

Sort  (cost=3909.83..3952.21 rows=16954 width=1086) (actual time=1120.618..1143.922 rows=16946 loops=1)
   Sort Key: django_site.domain, product_product.ordering, product_product.name
   Sort Method:  quicksort  Memory: 25517kB
   ->  Nested Loop  (cost=0.00..2718.86 rows=16954 width=1086) (actual time=0.053..87.396 rows=16946 loops=1)
         ->  Seq Scan on django_site  (cost=0.00..1.01 rows=1 width=24) (actual time=0.010..0.012 rows=1 loops=1)
               Filter: (id = 1) …

此代码不编译(gcc 5.3.1 + boost 1.60):

#include <boost/spirit/home/x3.hpp>

namespace x3 = boost::spirit::x3;

template <typename T>
void parse(T begin, T end) {
    auto dest = x3::lit('[') >> x3::int_ >> ';' >> x3::int_ >> ']';

    auto on_portal = [&](auto& ctx) {};
    auto portal    = (x3::char_('P') >> -dest)[on_portal];

    auto tiles = +portal;
    x3::phrase_parse(begin, end, tiles, x3::eol);
}

int main() {
    std::string x;
    parse(x.begin(), x.end());
}

它失败并带有静态断言:

error: static assertion failed: Attribute does not have the expected size.

感谢wandbox我也尝试了boost 1.61和clang,两者都产生了相同的结果.

如果我删除附加的语义动作portal,它编译得很好; 如果我dest …

我正在尝试实现一个 deflate 压缩器，并且必须决定是使用静态霍夫曼代码压缩块还是创建动态压缩器。

与静态代码相关的长度背后的基本原理是什么？

（这是rfc中包含的表格） Lit Value Bits --------- ---- 0 - 143 8 144 - 255 9 256 - 279 7 280 - 287 8 我认为静态代码更偏向于纯ascii文本，相反，它看起来更喜欢rle长度的压缩

决定是否使用静态代码的良好启发式是什么？

我正在考虑根据输入数据的样本构建概率分布，并根据静态代码导出的概率计算距离（也许是 EMD？）。

以下代码无法编译:

#include <boost/variant.hpp>

class A {};
class B {};
class C {};
class D {};

using v1 = boost::variant<A, B>;
using v2 = boost::variant<C, D>;

int f(v1 const&) {
    return 0;
}
int f(v2 const&) {
    return 1;
}
int main() {
    return f(A{});
}

gcc和clang都抱怨:

test1.cpp: In function ‘int main()’:
test1.cpp:18:17: error: call of overloaded ‘f(A)’ is ambiguous
     return f(A{});
                 ^
test1.cpp:18:17: note: candidates are:
test1.cpp:11:5: note: int f(const v1&)
 int f(v1 const&) {
     ^
test1.cpp:14:5: note: int f(const …

请检查此缩减示例(增强1.68):

#include <boost/smart_ptr/shared_ptr.hpp>
#include <boost/range.hpp>
#include <vector>

void f(std::vector<boost::shared_ptr<int>>& c) {
    using std::advance;
    auto it = c.begin();
    advance(it, 1);
}

这段代码无法在gcc-8和clang-6上编译同样的错误,对advance()的调用是不明确的.

这两个候选人:

candidate: ‘constexpr void std::advance(_InputIterator&, _Distance)
[with _InputIterator =
__gnu_cxx::__normal_iterator<boost::shared_ptr<int>*, std::vector<boost::shared_ptr<int> > >; _Distance = int]’
     advance(_InputIterator& __i, _Distance __n)
candidate: ‘constexpr void boost::iterators::advance_adl_barrier::advance(InputIterator&, Distance) [with InputIterator =
__gnu_cxx::__normal_iterator<boost::shared_ptr<int>*, std::vector<boost::shared_ptr<int> > >; Distance = int]’
         advance(InputIterator& it, Distance n)

第二个候选是由boost :: range引入的,不幸的是我不能简单地删除它,因为它被另一个依赖项(boost :: geometry)包含.

非限定调用由另一个库(范围-v3)执行,并且它是为了利用ADL而故意制作的

这显然是一个与ADL相关的问题,但我想念为什么编译器找到了第二个候选者,因为没有涉及boost :: range类型.