cstr unresolved

nickb

Hi
I have just moved from client 6.0.0 to 6.5.3, and converted my code but have run into 1 problem.
I'm sure I'm doing something dumb but can't figure out why I can't link my c++ client using MSVC 2008.
I keep getting unresolved external symbol with cstr() on any JString.
Other JString functions are fine and just removing this one function everything compiles and links.
Any ideas?

Kaiserludi

Hi nickb. For which target platform are you compiling, Win32, I suppose?
Can you copy and paste the exact error-message from VS-output, please?

We switched from char* to wchar_t* for strings with version 6.4.0 for unicode-support. JStrings cstr()-method now is returning a wchar_t* isntead of a char* like in 6.0.0 (also the internal storage switched to wchar_t, so if you pass a char* on creation, it will be automatically converted). Probably this is causing your issue. You can use wchar_t instead of char* for your strings, if you are comfortable with this change to your code. Alternatively you can use the classes ANSIString and UTF8String, which we have introduced with 6.4.0, to access the payload of a JString as a char*. Therefore you can use JStrings methods UTF8Representation() and ANSIRepresentation() (depending on the encoding, the char* should have) and the call the cstr()-method of the returntype, instead of directly calling cstr() on the JString.
So instead of myJString.cstr() you would now call myJString().ANSIRepresentation().cstr() to achieve the 6.0.0 behavior.

nickb

Thanks, your ANSIRepresentation function seems to have done the job, I wasn't aware of that. I did realise you had swapped to wchar_t, and was altering my code to work with that, but looks like I wont have to now.

Here's the link error I still get if I try to use the standard cstr function.

error LNK2019: unresolved external symbol "public: unsigned short const * __thiscall ExitGames::JString::cstr(void)const " (?cstr@JString@ExitGames@@QBEPBGXZ) referenced in function "public: virtual void __thiscall Nearworld::ExitPhotonServerImpl::EventAction(int,class ExitGames::Hashtable const &)" (?EventAction@ExitPhotonServerImpl@Nearworld@@UAEXHABVHashtable@ExitGames@@@Z)

I assume there is a conficting preprocessor directive in a header I am using. I can build your demo application fine.

Kaiserludi

In your project-settings at Configuration Properties -> C/C++ -> Language, what's your setting for "Treat wchar_t as Built-in type"? It should be set to "yes", which also is the default setting. You will get those linker errors for cstr() and other methods, which are having wchar_t in their API (but only if you are calling those methods), if this option is set to "no" on your side, as in that case your application will interpret wchar_t as typedef for unsigned short and the linker will look for a method with unsigned short instead of wchar_t in it's signature (that would explain the "unsigned short" return type in your error message), as your compiler has compiled JString-headers that way, while it has been compiled into the library binaries as an independent type.

nickb

Yeah that makes sense now I've got the -Zc:wchar_t- flag set in my compiler options.
And just as a bit of general advice, I am porting my app to OSX (including your client). Would you recommend using wchar_t or just sticking to the ANSI method?

Kaiserludi

If you are just using your strings internally and do not offer the user any possibility, to input strings, like names, chart-messages, and so on, then it is not so important. wchar_t will still give you a speed-improvement, as you have less encoding-conversions that way, but for normal usage it will not be big enough to be recognized without profiling it.
However, if you are allowing users to input strings, then I would recommend to use wchar_t at least for these strings, especially if you want to offer your game to people from outside of the US and Western Europe, as ANSI is not capable of the very most of the thousands of asian characters.

PS: As you now have upgraded your windows-version to 6.5.3, I guess, you do not need a 6.0.0 osx-build anymore, which you have requested yesterday? However, as far as I know, the osx-build, which we supplied you with, is of version 6.4.2, so you probably want a 6.5.3 build to have same versions for both os'?

nickb

Yeah I'd want a version that I can get for both mac and windows. I haven't got the latest version working in windows yet, and I assume I will need to update the server (thats still on 2.0.4.0). Problem is though we already have a version running out there. If we update the server people on the old version won't be on the same version as the new release. For that reason I wouldnt mind sticking to 6.0.0 if possible. Is there much advantage to the latest version? What do you reckon?

Kaiserludi

1. All 6.x Clients are compatible to all 2.x servers. There are no breaking changes in client-server protocol since 2.0.0 and 6.0.0.RC1
2. You should always integrate a possibility into your game to force people to update, if they want to use multiplayer. Not only because of new libraries, but also for gameplay-, balancing- and other changes in your code, so you can guarantee, that all clients on your server are using the same version and no one has an advantage over his opponent because of using another version than him. The client should send it's game version number to the server directly after connect, typically in authentication, when you also would let the user login with a username and such things. If it is not the newest version or the client is not sending a version number at all, do not let him on the server, until the client has been updated (e
an error message for the user would be nice, of course). So you could easily update your old clients to use new photon versions, but also update al other kind of stuff in your game if you want to.
3. For advantages of the latest version please refer to Common- and Photon-release-history in the new sdk. as you can see, there has been done pretty much, as 6.0.0 is from about a year ago. If you do not find anything fixed or added, which is important for your game, then you could stay with 6.0.0 to save time.

nickb

OK I seem to be rolling quite well with client 6.5.3 now. Can I get that version for the Mac?

Kaiserludi

I just have recognized, that 6.5.3 does not build for osx due to some osx-incompatible-code.
Here is a version 6.5.4 build, which basically is a 6.5.3 + some single-platform changes. Non of these changes has affected win32, so a win32-build of it would be identical to version 6.5.3:
http://dl.dropbox.com/u/4296291/Photon- ... -4_SDK.zip

nickb

Getting some link errors with that.
Building for i386, cpp version with g++

Undefined symbols:
  "_PhotonConnect_closeConnection", referenced from:
      _PhotonPeer_Disconnect in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
      _PhotonPeer_internal_Disconnected in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
      _PhotonPeer_internal_execute in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
      _PhotonPeer_internal_execute in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
  "_PhotonConnect_Release", referenced from:
      _PhotonPeer_Release in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
  "_PhotonConnect_service", referenced from:
      _PhotonPeer_serviceBasic in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
  "_PhotonConnect_CheckRecvUdpPackage", referenced from:
      _PhotonPeer_internal_cbNetConnect in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
  "_PhotonConnect_createConnection", referenced from:
      _PhotonPeer_Connect in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
  "_PhotonConnect_sendUdpPackage", referenced from:
      _PhotonPeer_sendOutgoingCommands in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
  "_PhotonConnect_New", referenced from:
      _PhotonPeer_New in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
  "_PhotonConnect_StopRecvUdpPackage", referenced from:
      _PhotonPeer_Disconnect in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
      _PhotonPeer_internal_execute in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
      _PhotonPeer_internal_execute in libPhoton-cpp_debug_macosx.a(CPhotonPeer.o)
ld: symbol(s) not found

Any ideas much appreciated.

Kaiserludi

Sorry. Seems, a source-file has been missing in osx-config of the lib-project.

I have made a new build for you, fixing this issue:
http://dl.dropbox.com/u/4296291/Photon- ... -4_SDK.zip (yes, replaced the old build at the same link with the new one)

nickb

Woo yeah! Working great, cheers!

nickb

Oh and by the way, also had to remove lines 23-27 of "Photon-c/inc/PhotonPlatformLayer.h". Some unnessecary includes.

Kaiserludi

Oh, actually those lines now should compile with the new build, but I also recognized, that they did not with the old, as a file has been missing in the zip.

However that is only the internal platform-dependentabstraction for encryption implementation and that code is only needed in the header, when compiling Photon, not when compiling an application, which is using Photon.