BGL:如何有效地存储edge_descriptors和vertex_descriptors?
因此,在解决了 BGL 的循环依赖问题之后,我遇到了另一个障碍。
我目前正在使用邻接列表来对我的图进行建模。应用节点和边的捆绑属性来存储图中的一些信息。所以我有这样的事情:
class Node {
int x, int y // position
};
class Edge {
float length;
};
boost::adjacency_list<boost::listS, boost::listS, boost::directedS, Node, Edge>
当我想在代码中的其他地方存储特定节点和边缘的快捷方式时(例如,对于有多个车道的街道),问题就出现了。我的第一个方法是将 edge_descriptors 和 vertex_descriptors 保存在我需要的地方。但我想知道这样的描述符有多大(以字节为单位)。也许有更好的解决方案,例如仅存储一小部分信息即可获得相同的结果。
有谁知道用于这种类型的向量的内存量:
std::vector<edge_descriptor> ?
我已经考虑过只存储指向 edge_descriptors 的指针,但我不知道这是否以及如何工作。
/////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////// ////////////////
编辑:既然我的第一个问题已经得到彻底回答,我仍然想知道一件事。我想为我的图形类构建某种接口。该接口应将图类详细信息与其他类分开,其他类不得了解图的详细信息。因此,其他类最好将节点和边识别为数字。 所以我想出了两个想法:
- 我使用 hash_map
std::tr1::unordered_map
能够将数字转换为描述符,然后再次将其用作我的图表的索引-目的。这可能是一步太多 - 也许哈希值的计算会花费太多时间 是否有足够的节点和边需要计算。这就是为什么我有第二个想法。 - 图本身应在内部将这些数字转换为边和节点。我知道内部属性和属性映射可以用来实现我的想法。然后,您只需键入以下内容即可访问节点:
boost::property_map
::type index = get(my_prop(), G);
但是有没有办法将此类属性映射与我的捆绑属性结合起来?
或者你还有其他我没有想到的想法吗?
So after my circular dependency problem with the BGL was solved I've come to another obstacle.
I'm currently using an adjacency-list to model my graph. Bundled properties for both nodes and edges are applied to store some information in the graph. So I have something like this:
class Node {
int x, int y // position
};
class Edge {
float length;
};
boost::adjacency_list<boost::listS, boost::listS, boost::directedS, Node, Edge>
The problem arises when I want to store shortcuts to specific nodes and edges somewhere else in my code (e.g. for a street that has several lanes). My first approach was to save edge_descriptors and vertex_descriptors where I needed them. But I'm wondering how big (in terms of bytes) such descriptors would be. Maybe there is a better solution such as to store just a fraction of information to get the same results.
Does anybody know the amount of memory that is used for a vector of this type:
std::vector<edge_descriptor> ?
I already thought about just storing pointers to edge_descriptors but I don't know if and how that would work.
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
EDIT: Now that my first question has been thorougly answered I am still wondering one thing. I want to build some kind of interface for my graph class. This interface shall seperate the graph class details from other classes which must not be aware of the details of the graph. Thus other classes should preferably recognize nodes and edges as numbers.
So I came up with two ideas:
- I use a hash_map
std::tr1::unordered_map<int, edge_descriptor>
to be able to translate the numbers to descriptors which again are then used as indices to my graph-object. This might be one step to much - maybe the calculation of the hash values will take too much time
if there are enough nodes and edges to be calculated. That's why I had a second idea. - The graph itself shall internally convert these numbers to edges and nodes. I know that internal properties together with property maps can be used to realize my idea. You can then access a node by just typing something like:
boost::property_map<My_Graph, my_prop>::type index = get(my_prop(), G);
But is there a way to combine such property maps with my bundled properties?
Or do you have another idea which I didn't hit on, yet?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
顶点和边描述符的尺寸非常小。
顶点描述符是数字。
边描述符是一个小结构,包含源顶点描述符和目标顶点描述符,以及指向附加到边描述符的内部数据的指针。
因此,你的问题的答案是你可以在向量中使用它们。不会构成内存问题。
Vertex and edge descriptors take a very small size.
Vertex descriptors are numbers.
Edge descriptors are a small structure containing source and target vertex descriptors, and a pointer to internal data attached to edge descriptors.
Therefore the answer to your question is that you can use them in vectors. It won't constitue a memory issue.