3 ms·

> Due to incompatibilities in the compilers, there was a rats nest of dependencies, thousands of #ifdef’s to cover differing OS implementations, and we had to u

> Due to incompatibilities in the compilers, there was a rats nest of dependencies, thousands of #ifdef’s to cover differing OS implementations, and we had to use some of the oldest versions of C++ to be compatible with both XCode and Visual Studio. My current work has me on a single C++ code-base for Linux, Windows and MacOS (not electron though, just native). You can avoid a lot of headaches by avoiding the platform specific tools and instead cross compile using clang with a build system that works on all platforms (eg. ninja + meson).

lstamour 7y ago
+1 for Clang. It integrates with everything. But like most open source options, it plays second fiddle to each company’s primary languages, and so thee’s no one IDE so perfectly integrated into these mobile dev C++ use cases as to make it easy to work with, the way, say, you can be productive on .NET framework with either C# or C++. Google and Apple are both C++ compatible, or have native bindings, but... they target their examples and ease of use at the languages that best integrate with the respective IDEs. (Swift for Xcode, Kotlin for Android Studio) The end result is possible, but it’s like picking Cordova/PhoneGap/Electron for your native app. You’re going to struggle to use native technologies at some point, and there are few examples to follow. Allowing for the realization that 80% of your app code is likely platform-specific even if the UI doesn’t vary much means you can adopt new approaches and native UI conventions faster. It’s like the difference in programming speed when you simply target Chrome for your web development vs when you’re trying to write code that runs on Internet Explorer also. It’s getting to the point where platform functionality diverges so much that writing it but from the same design/spec/data model is faster than trying to maintain compatibility. Especially if you need to support multiple versions of iOS and Android in a backwards compatible way and with different UI conventions in different OS releases. Native is native, nothing else looks or feels like native, when that’s what you need, and there’s more hand-holding for apps when they follow the latest spec from the platform, rather than try to chase it with their custom bindings/implementation... Note re. targeting a platform — often learning and reading some C++ is inescapable. For me, reading Chrome source code makes it easier to work with Puppeteer in JS, or deliver a better web app because I know how things work under the hood and it’s easier to read the C++ than the read the web standards themselves. Similarly, C++ really is portable and fast, so it shows up in many places. But on mobile, the mix of C++ to Swift/Kotlin should be 90%-platform native if your app is a traditional CRUD app that deeply integrates with the platform. If it’s simpler than that, build a website, or if it’s a game engine or some custom UI, use that, sure, but if you want to benefit the most from Apple and Google implementations, native (with shared spec/data models) is the way to go...
softfalcon 7y ago
I agree you can avoid a lot of headaches by not using platform specific tools. Unfortunately, once you get into users wanting OS specific feature support, all that goes out the window. You now are forced to maintain multiple versions of your product that differ greatly per operating system. Pair that with the fact the codebase was almost 20 years old, you get some fun legacy code support issues that a lot of C++ projects naturally have due to the fact that C++ is not a new language.

lstamour 7y ago

+1 for Clang. It integrates with everything. But like most open source options, it plays second fiddle to each company’s primary languages, and so thee’s no one IDE so perfectly integrated into these mobile dev C++ use cases as to make it easy to work with, the way, say, you can be productive on .NET framework with either C# or C++. Google and Apple are both C++ compatible, or have native bindings, but... they target their examples and ease of use at the languages that best integrate with the respective IDEs. (Swift for Xcode, Kotlin for Android Studio) The end result is possible, but it’s like picking Cordova/PhoneGap/Electron for your native app. You’re going to struggle to use native technologies at some point, and there are few examples to follow. Allowing for the realization that 80% of your app code is likely platform-specific even if the UI doesn’t vary much means you can adopt new approaches and native UI conventions faster. It’s like the difference in programming speed when you simply target Chrome for your web development vs when you’re trying to write code that runs on Internet Explorer also. It’s getting to the point where platform functionality diverges so much that writing it but from the same design/spec/data model is faster than trying to maintain compatibility. Especially if you need to support multiple versions of iOS and Android in a backwards compatible way and with different UI conventions in different OS releases. Native is native, nothing else looks or feels like native, when that’s what you need, and there’s more hand-holding for apps when they follow the latest spec from the platform, rather than try to chase it with their custom bindings/implementation... Note re. targeting a platform — often learning and reading some C++ is inescapable. For me, reading Chrome source code makes it easier to work with Puppeteer in JS, or deliver a better web app because I know how things work under the hood and it’s easier to read the C++ than the read the web standards themselves. Similarly, C++ really is portable and fast, so it shows up in many places. But on mobile, the mix of C++ to Swift/Kotlin should be 90%-platform native if your app is a traditional CRUD app that deeply integrates with the platform. If it’s simpler than that, build a website, or if it’s a game engine or some custom UI, use that, sure, but if you want to benefit the most from Apple and Google implementations, native (with shared spec/data models) is the way to go...

softfalcon 7y ago

I agree you can avoid a lot of headaches by not using platform specific tools. Unfortunately, once you get into users wanting OS specific feature support, all that goes out the window. You now are forced to maintain multiple versions of your product that differ greatly per operating system. Pair that with the fact the codebase was almost 20 years old, you get some fun legacy code support issues that a lot of C++ projects naturally have due to the fact that C++ is not a new language.