在使用地图以分层方式组织数据时,我习惯了Python的开发思维。这很简单,语法便宜。虽然在C ++中并不是非常困难,但嵌套的地图/集合使组织变得困难。我不认为我正在考虑这个问题。
例如,我正在使用以下组织:
typedef set<Motif> Motifs;
typedef map<Motif, Motifs> LinkedMotifs;
struct Candidates {
Motifs deadend;
Motifs intralinked;
LinkedMotifs interlinked;
};
typedef map<Linker::shp, Candidates> LinkedCandidates;
出于性能原因,我正在使用boost的flat_map / set实现。 Motif是一对std ::结构。 Linker :: shp是一个SharedPtr。
此地图是搜索功能的结果。搜索完成后,我对结果进行评分,并在单独的函数中将结果写入文件。我在设计项目时考虑了函数式编程,最初的尝试是将候选结构和得分结构分开。然而,这会产生问题,因为我基本上最终会重新创建内存中的所有地图结构。当所有内容写入磁盘时,结构很重要。
我可以将分数链接到地图和集合中的迭代器,但老实说看起来我做的事情太难了。
谢谢!
*编辑以使我的最终目标更有意义。
答案 0 :(得分:3)
请注意,代码的大部分冗长都来自于所有名称中“序列和配置对”的重复使用。这表明您需要一个术语来解决这个问题。最好是使用在问题域俚语中使用的相同术语来命名它。人类很懒惰。让我们把它称为motif
,一切都变得简单了:
typedef set<Motif> Motifs;
typedef map<Motif, Motifs> LinkedMotifs;
struct Candidates {
Motifs deadend;
Motifs intralinked;
LinkedMotifs interlinked;
};
typedef map<Linker::shp, Candidates> LinkersCandidates;
IOW ...使用短名称。始终将每个名称都放在C ++中的命名空间中。 C ++通常用于 写相当大的产品(百万行是平均值),这有助于 避免名称冲突。
如果您需要重复使用该组织,则可以使用模板:
template<typename T>
struct Handler {
typedef set<T> Ts;
typedef map<T, Ts> LinkedTs;
struct Candidates {
Ts deadend;
Ts intralinked;
LinkedTs interlinked;
};
typedef map<Linker::shp, Candidates> LinkersCandidates;
};
typedef Handler<Motif>::LinkersCandidates LinkersMotifCandidates;
typedef Handler<Other>::LinkersCandidates LinkersOtherCandidates;
如果您使用的副本应该使用引用或指针,或者您没有选择正确的容器,则可能会出现性能问题。例如,当set
和map
不够复杂时,Boost.MultiIndex或Boost.Graph会提供更复杂的容器。另一方面,当map
或set
大部分时间保持不变时,则排序vector
对(而非map
)或排序vector
(而不是set
std::lower_bound
)和set
可能会提供更好的效果。复制map
和vector
比复制{{1}}要贵得多。