8000 Conversion problem from boost to std [Windows] · Issue #229 · vrpn/vrpn · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Conversion problem from boost to std [Windows] #229

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.

Sign up for GitHub

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

Jump to bottom
Open
mattandria opened this issue May 29, 2019 · 9 comments
Open

Conversion problem from boost to std [Windows] #229

mattandria opened this issue May 29, 2019 · 9 comments

Comments

@mattandria
Copy link

Hello guys,

I'm now working with a Falcon haptic device for a project. And I would like to use VRPN (on Windows) to communicate with it.
However, I have some issues when I build the solution on Visual Studio (2017).

Impossible to convert from boost::array<double,3> to std::array<double,3U>

I have linked Boost (1.69) correctly to my project, so I don't know why I get this error.
Is there another library I have to install to make this conversion?

Thanks in advance!
@russell-taylor
Copy link
Contributor

Fascinating. The Falcon driver uses the std::array completely internally to do some of its calculations and does not expose that through a header or include anything that might include boost when it is compiling.

Does this happen when you are compiling VRPN itself, or when you are compiling your program and trying to link it to your program? Also, can you include the lines leading up to the error above so I can see what stage of the compilation/linking and what line on what file the error happens?

"Don't use standard libraries" is one of the rules for VRPN code, to avoid this and conflicts between the two early versions of the standard library, but sometimes the rule is broken. It doesn't often get us into trouble, but when it does it can be subtle.

@russell-taylor
Copy link
Contributor
russell-taylor commented May 29, 2019 •
edited
Loading

It could be that the new falcon libraries are including boost's array and that is causing conflicts...

@mattandria
Copy link
Author

It happens when I compile VRPN separately. And it is caused by this line in the file vrpn_Tracker_NovintFalcon.c:

d_vector pos = m_falconDevice->getPosition();

The type d_vector is a typedef which corresponds to std::array<double,3U> . And getPosition() returns a boost::array<double,3>.

@russell-taylor
Copy link
Contributor

So the problem is that the two types are now incompatible. Try removing the #include and change the definition of d_vector to boost::array<double,3> and let me know if that solves the problem. If so, please do a pull request so we can get this change into master.

Thanks!

@russell-taylor
Copy link
Contributor

Did changing the definition to boost::array work for you?

@mattandria
Copy link
Author

Sorry for the late response.

So, I tried what you said, I changed the definition of d_vector to boost::array. The error above dissapeared but another one appeared after that. When I'm trying to build vrpndll I get that:

vrpn_Tracker_NovintFalcon.obj : error LNK2019: unresolved external symbol "public: bool __thiscall libnifalcon::FalconFirmware::loadFirmware(bool,unsigned int const &,unsigned char *)" (?loadFirmware@FalconFirmware@libnifalcon@@QAE_N_NABIPAE@Z) referenced in function "public: bool __thiscall vrpn_NovintFalcon_Device::init(void)" (?init@vrpn_NovintFalcon_Device@@QAE_NXZ)

However, I have already linked libnifalcon and boost to vrpndll (headers and library files) . And I have the same error when I try to build vrpn_server. What can cause this?

@russell-taylor
Copy link
Contributor

This is a different issue from boost usage.

The DLL compilation path is not as well maintained as the static-library path. The first thing I would try is static linkage.

This looks like a standard library-linking problem. If you're compiling on Linux, my guess is that the falcon libraries are included in the linking command line before the VRPN ones that reference them. In any architecture, I'd check to make sure that the falcon library that defines that symbol is on the link line (there may be multiple libraries).

@rpavlik
Copy link
Member
rpavlik commented Nov 1, 2019

yeah this is entirely a library maintenance issue on the libnifalcon side - don't drag the defenseless standard libraries into it :) Presumably at some point they switched the type they exposed in their API?

The libnifalcon readme says dynamic linking isn't supported due to missing declspec annotations.

@rpavlik
Copy link
Member
rpavlik commented Nov 1, 2019

(To be fair, they changed from boost::array to std::array back in 2014 - std::array is at least standard and not requiring an external dep - if you're going to return an array of fixed size, that's a decent way to do it. libnifalcon/libnifalcon@817c71c#diff-bb06f8197ccad2bed811e7d1c6bd30f2 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rpavlik @russell-taylor @mattandria
0