清泛IT社区App Inventor 2 中文社区

搜索

扫码访问移动社区 移动社区,您的掌上技术专家

关注我,精彩不错过! 关注我,精彩不错过!

扫码安装最新版AI伴侣 最新版AI伴侣v2.72

Aia Store .aia 源码一站式解决方案 发布日志AI2连接测试ai2Starter模拟器

开通会员送SVIPApp Inventor 2 拓展有奖征文 VIP会员享专有教程,免费赠送基础版*技术支持服务! AI2入门必读中文文档中文教程IoT专题

查看: 814|回复: 1
打印 上一主题 下一主题

c++ boost::multi_index composite keys efficiency

  • TA的每日心情
    开心
    2024-02-17 18:16
  • 签到天数: 14 天

    [LV.3]偶尔看看II

    546

    主题

    715

    帖子

    1万

    积分

    管理员

    这里没有广告...

    Rank: 9Rank: 9Rank: 9

    积分
    10709
    QQ
    跳转到指定楼层
    楼主
    发表于 2016-03-15 14:57:14 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

    Long time reader first time poster! I'm playing around with the boost::multi_index container stuff and have a rather in-depth question that hopefully a boost or C++ container expert might know (my knowledge in C++ containers is pretty basic). For reference, the boost documentation on composite keys can be found here: boost::multi_index composite keys.

    When using a composite key, the documentation states that "Composite keys are sorted by lexicographical order, i.e. sorting is performed by the first key, then the second key if the first one is equal, etc". Does this mean that the structure is stored such that a lookup for a specific 2-part composite key will take O(n=1) time, i.e. is the container sorted such that there is a pointer directly to each item, or does the boost container retrieve a list that matches the first part of the composite key and then need to perform a search for items matching the second part of the key and thus is slower?

    For example, if I was to maintain two containers manually using two different indices and wanted to find items that matched a specific 2-part query I would probably filter the first container for all items matching the 1st part of the query, and then filter the result for items that match the 2nd part of the query. So this manual method would effectively involve two searches. Does boost effectively do this or does it improve on efficiency somehow via the use of composite keys?

    Hopefully I've explained myself here but please ask questions and I will try my best to clarify exactly what I mean!


    From:http://stackoverflow.com/questio ... ite-keys-efficiency
    清泛网 - 专注IT技能提升
  • TA的每日心情
    开心
    2024-02-17 18:16
  • 签到天数: 14 天

    [LV.3]偶尔看看II

    546

    主题

    715

    帖子

    1万

    积分

    管理员

    这里没有广告...

    Rank: 9Rank: 9Rank: 9

    积分
    10709
    QQ
    沙发
     楼主| 发表于 2016-03-15 14:57:27 | 只看该作者
    Lookups involving composite keys do not go through any two-stage process as you describe. composite_key-induced orderings are normal orderings, the only special thing about it being its dependence on two or more element keys rather than one.

    Maybe an example will clarify. Consider this use of composite_key:
    1. struct element
    2. {
    3.   int x,y,z;
    4. };

    5. typedef multi_index_container<
    6.   element,
    7.   indexed_by<
    8.     ordered_unique<
    9.       composite_key<
    10.         element,
    11.         member<element,int,&element::x>,
    12.         member<element,int,&element::y>,
    13.         member<element,int,&element::z>
    14.       >
    15.     >
    16.   >
    17. > multi_t;
    复制代码
    The resulting container is in a sense equivalent to this:
    1. struct element_cmp
    2. {
    3.   bool operator()(const element& v1, const element& v2)const
    4.   {
    5.     if(v1.x<v2.x)return true;
    6.     if(v2.x<v1.x)return false;
    7.     if(v1.y<v2.y)return true;
    8.     if(v2.y<v1.y)return false;
    9.     return v1.z<v2.z;
    10.   }
    11. };

    12. typedef std::set<element,element_cmp> set_t;
    复制代码
    composite_key automatically generates equivalent code to that in element_cmp::operator(), and additionally allows for lookup on just the first n keys, but the underlying data structure does not change with respect to the case using std::set.
    清泛网 - 专注IT技能提升
    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    © 2024 tsingfun.com, Inc.  沪ICP备2020034476号-1  沪公网安备31011702000040号

    GMT+8, 2024-11-22 05:37 , Processed in 0.025034 second(s), 39 queries .