Has anyone been able to use Boost in a windows mobile 6.x app? More specifically I want to use Thunk32 for creating a callback to a Non-static Member Function. But it uses some complicated Boost casting methods that will not compile under mobile projects.
Windows Mobile has a crippled implementation of the standard library. You will have to use a more complete version. I personally use STLPort. Using that, most of Boost will work fine. I do still have trouble using some of the libraries that are not header-only, though.
Also, that Thunk32 library you pointed to will probably need to be modified for ARM. The assembly code used is x86.
-PaulH
Related
I need to distribute a closed-source library (in the form of a dynamic .framework) which uses C++ internally and exposes an Objective-C API at the module boundary. The library will be used by numerous clients in their apps.
As I understand, by default the C++ runtime is linked dynamically via libc++.dylib. So the question is: is the runtime compatible between iOS releases / compiler versions? Can my clients run into binary compatibility issues when using my library (e.g. OS is shipped with a different runtime version, producing subtle bugs in my library)?
Sidenote (as to where this question is coming from): On Windows, you would usually want to link the C++ runtime statically if you want to ensure that the binary works on all systems without the need to ship the specific version runtime component. So I wonder if the same problem existent on iOS.
Only Apple knows if or when some C++ library is no longer supported. My guess would be that apps depending on a no longer supported runtime would stop working completely or would not build with your library in the first place. I have found this info here (Xcode 10 (iOS 12) does not contain libstdc++6.0.9) indicating that, over the years, support for older runtimes may be dropped and then you'd need to build another library.
Speaking from past experience, we had an app - I know, not quite the same as a library - in the App store with a C++ core and Objective-C shim and did not care about C++ runtime compatibility. That never became an issue. Instead, from time to time (over several years and iOS iterations) there were slight user interface quirks that needed to be ironed out (I think with iOS7 - ok, you may not have an UI) then the forced move to 64-bit, then some API change where Apple wanted things that way or another... When there as an issue then we did a build with the latest XCode and that would have helped keeping things running, but the old version kept on working.
The upshot is, you'll need to be prepared to maintain your library and maybe something else 'gives' before the C++ runtime becomes a problem and then you'll just have to do another build for your customers.
If you are using libc++.dylib which is system wide library, then any application can also use it.
So by definition whoever delivers this library (Apple), is responsible for maintaining backward binary compatibility of this library.
If compatibility would have been broken, thousands of application would be corrupted.
On other hand if you are using some custom version of this library then it should be shipped with *.framework. In this case there is no risk of breaking compatibility since it is shipped with framework.
So basically there is no reason for you to worry about that.
If something is gets broken then lots of applications will be broken.
In the past new iOS versions have provided excellent compatibility with existing apps. If an app was built for an old iOS version, it would also run on new iOS versions. It seems that Apple simulates old iOS versions - including their visual style and quirks. If you run an app built for iOS 6 or earlier, it will still have the grayish look and not the new style introduced with iOS 7.
Once an app is updated, the story is different: you will need to use the latest Xcode, new rules apply and many old features will have been decommissioned. As part of this, Apple might remove APIs, switch to a new C++ compiler, change the standard C and C++ library etc.
So:
A released app in the App Store should continue to work for many years with your C++ library.
However, for the development of new apps or new version of an existing app, you will need to check the compatibility of your library regularly and possibly provide updated versions.
I would like to make c++ that will work both on Linux and windows as I understand if I use the win32 template in visual studio then it will only work on windows is there something built into c++ like java's jframe that I can use. Also I would like to use any external library at this time.
Here are some cross platform alternatives QT, wxWidgets, Ultimate++. I have used QT, it is intuitive with a huge collection of tools to use in your code. The others are also popular but I have never used them.
I make used of wxWidgets due to it's cross platform and even cross architecture, native look on the OS where it appear. Binary application yields by wxWidgets is small enough thus make it possible to linking statically as portable application. Qt produce huge binary if linked statically (and may be violate qt licensing scheme).
Another reason are licensing flexibly, well documentation and supported by huge community arround the world. wx is considered as mature framework since it first release about 20yrs ago. It's use standard C++ syntax and preprocessor that will make you easily switch from plain C or C++. Complete library are available ranging from appeal window GUI, string, network, stream, webview, xml, and wx is playing very well with 3rd party library as such database SOCI, Asio, etc ....
You may try start to code with wxWidgets easily using Eclipse-IDE and wxFormBuilder as GUI designer. Plese check my experience for ease setup it's IDE+Toolchain. This wx installer can be used do develop, test and run wx application on Linux desktop, and then deploy the binary on Raspberry Pi is available for another board target beside Linux x86_64.
http://yasriady.blogspot.co.id/2016/01/raspberry-pi-toolchain.html
There is a cross-platform application & UI development framework called Qt. I think it meets your requirements. Click here for more info.
There is a long list of both active and dead cross-platform C++ UI libraries here: https://philippegroarke.com/posts/2018/c++_ui_solutions/
I want to use this library for cross platform networking.
http://lacewing-project.org/
It works with OSX, Linux, Windows and has specific code for Android. What I do not know is if it will work (as a client) on iOS. (meaning I will not host a server on iOS)
Since it uses POSIX sockets internally does that make it compatible with iOS?
Thanks
Without trying it, my guess would be that it would work. You will need to write your UI in Objective-C, but you should be able to use Objective-C++ to bind your libraries to the UI. Before you start into the Objective-C++ path be aware of the limitations (see: How well is Objective-C++ supported?).
I would try using the objective-c library AFNetworking first, from the creators of gowalla.
You can get it here:
https://github.com/AFNetworking/AFNetworking
On the topic of lacewing, it should work fine, as long as it relies upon the BSD sockets API, as I can confirm that it exists on iOS.
If it's only written in C/C++ then no, unless you got a C/C++ SDK for iOS (which AFAIK does not exist publicly). iOS SDK is for Objective-C.
I have a C++ eclipse project that I would like to easily compile In Windows and OSX.
The project is currently using an automatically generated makefile.
The libraries that I need vary depending on the platform.
In osx I'm using the CoreMidi, CoreAudio, and CoreFoundation frameworks.
In Windows I'm using the winmm.lib and multithreaded libraries.
What's the simplest way to link different libraries/frameworks depending on the current platform?
I'm currently using the gcc toolchain on OSX. Should I start using the cross compile toolchain?
Should I have two projects. One for working in windows, and one for osx, checking them both in to version control?
Should I write a custom makefile instead of using the automatically generated option that has different g++ arguments depending on the platform?
I personally had the same goal for a project and came to the conclusion the Qt framework was the best thing for me. It handles multiple languages, unicode strings, XML, network communications, native looking user interfaces, console applications: it can do an AWFUL lot.
However, as Paul pointed out, you really have to plan it from the start.
Qt does a good job of abstracting the platform away (in a module called QtCore) allowing you to write vanilla C++ code, or you can chose to include some Qt C++ language extensions which a Qt helper application called the moc (meta object compiler) creates vanilla C++ from, which can then be compiled by most common C++ compilers.
It also has a nifty cross-platform makefile generator called qmake which works on project files to create normal make files for the platform its running on.
Off the top of my head at least Windows XP & 7, OSX 10.4, 10.5, 10.6 are supported currently. But note that OSX Lion is (as of writing) not officially supported but I suspect it will be in the next release.
Based on your description, I am not sure you can easily make it cross-platform. Even without using third-party library, you have to provide separate code for osx and windows. Most of time, they design the system as cross-platform first. It's really hard to make an existing project on single-platform to cross-one. If you have the cross-platform requirement, you'd better design in that way first and rewrite from scratch.
Even though Eclipse can run fine on both OS X and Windows, it is not designed to be used in this way.
The best way to do it is to use separate IDE projects for each platform. This this is the easiest way to have unique compilation settings for multiple platforms.
Yes, you can use two eclipse projects. Alternatively, it's not unusual to have a X-Code project for OSX, and a Visual Studio Project for MS Windows.
How to run c++ applications in android using cygwin. Any tutorial in this regard is appreciated..
You cannot directly run C++ applications in Android.
Android can run only applications written using the Android SDK, but yes you can re-use your native(C/C++) libraries for Android.
You will have to recompile all the native libraries specifically for Android. And you do need the source code for all 3rd party native libs you plan to use simply because Usually when we compile and link these libraries outside Android they are linked to glibc but unfortunately Android doesn't use glibc due to liscence and performance issues. Android uses a watered down version of glibc called libc. It has matching symbol names to glibc for most of the usual functionalities. But as far as i know the libc doesn't have some functionality related to Strings and it definitely doesnt have some posix support. If your native libraries are using any of the deprecated functionality you will have to find workaround for those by using alternative functionality supported by libc and coding your libs accordingly.
Also, you will have to use the NDK to interface Java(Android app/fwk) to native world(C++). And then write a Android application on top of that.
Though this sounds pretty simple in my experience compiling native libraries on Android(Android porting) has traditionally been very time consuming with no guarantee of sucesses.
You will want the Java Native Interface, or "JNI".
See: "Java Native Interface Wiki" "Android JNI Tips" and links therein. It is some work to get this going and to get used to how it goes. I managed it from the references given here with C and it will work out after some time and faith without further help if you follow all the steps.