-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support containing any type supported by STL #284
Comments
I'm encountering this issue in a project that I'm working on where I'm using this library. I need the member data of the nodes to be a user defined class, but I get conversion errors in the best_first_search method. |
Can you provide an example of the code that does not work? And the error that you have encountered? |
Hi, thanks for the reply.
|
Ok, I find the error! CXXGraph/include/Graph/Graph.hpp Line 1634 in daf32ed
The error is the static cast to T Type. In fact the priority queue is define here Graph.hhp:1630 : CXXGraph/include/Graph/Graph.hpp Line 1630 in daf32ed
where CXXGraph/include/Graph/Graph.hpp Line 1617 in daf32ed
So the queue accept for first parameter of pair a double and not a T type.
Do you can correct it? And if it works, you can open PullRequest? Thank you in advance |
Sure, I'll get on it right away. |
I've corrected line Graph.hpp:1634 as you said and it seems to work fine. |
I merge the PR, but this issue is still available for a complete check of the initial request for issue |
Hi @nrkramer, I see that you've closed the issue. Then I was adding a few test cases in each test file to make sure that all the algorithms work even for different data types. I'm almost done and I should be able to open another PR in the next ours. If you think it's useful I'll continue. |
Yes I think is useful, in general increasing tests is ever good! |
I Think it's also useful work on mixed type graph (a graph that can contains different type of node or edges). |
Agreed, thanks @sbaldu . This issue only concerns the basic functionality of using non-numeric types as the template parameter, so it's appropriate to close this. For those cases you've mentioned, other issues can be opened. |
The templating of the graph library is a bit wonky. It doesn't allow users to use things like pointers or other custom data types due to static casting to an integer type in some copy operations.
We should audit the code and make sure that we can support any data type, just like STL containers (similarly to how std::vector supports containing any type).
The text was updated successfully, but these errors were encountered: