C++ is a multiple platform language and always has been. It’s predecessor, C, can be found on virtually every single device ever created because C is the foundation of every operating system kernel and runtime library. As such, you will find a C/C++ compiler toolchain on every single device as well. So, why is it so challenging to have a single C/C++ source code base for your application across all platforms?
One of the bigger considerations is binary compatibility. By that, I mean the binary format created and used by the actual compiler, linker, and debugger. The short of it is, every single compiler and linker out there use a different binary format from one another. Therefore, it is difficult (and many times impossible) to share object files or libraries created from a different compiler. And just as difficult to have a common debugger although there is seems to be more industry standardization on debug formats these days. This isn’t an easy problem to solve.
But that’s OK if you have all the source code you need, right? Well, sort of. Just like binary formats there can be differences between all of the various compilers such as standards language compliance, library compliance, and finally language extensions. With the ratification of C++11, most compiler vendors, including Embarcadero, are shooting towards full compliance with this new language standard and library standard. This is a good thing and improves source compatibility, however not every compiler front end is at the same level of compliance with all of the same features. And the same is true of standard library support (the other half of the "language").
The majority of our standards compliance efforts will be geared around the recently release BCC64 architecture and this is the same toolchain we will be brining to mobile and eventually back to 32-bit Windows (and any other supported platform). In the meantime, to help you manage your source code across both platforms more effectively we have published the following language compliance table between the two.
We will be doing the same for library compliance and Boost over the coming months. Additionally, I will be discussing more Critical C++ Toolchain Considerations during a webinar this Wednesday, June 5th. Come join us!Posted by J T on June 3rd, 2013 under Uncategorized | 1 Comment »
The macincloud.com hosting service is now pre-installing Platform Assistant Server on all of its user accounts so you can get up and running with it that much quicker. macincloud.com is a great service that complements RAD Studio so that you can build, simulate, debug, and Appstore deploy iOS applications, and build, debug and deploy Mac applications without having a Mac onsite. You can find your PAServer in the top center of the 3rd page of the LaunchPad. Double click on it and off you go.
Then grab the IP in another terminal window with the ifconfig command.
Finally, create a connection in RAD Studio and deploy.
Additionally, we’ve partnered with macincloud to provide a special offer for trial users – if you are currently or about to evaluate RAD Studio with the trial, you can get a special trial period of 24 hours during your 30-day RAD Studio trial. The macincloud trial expires after 24 hours of login time or 30 days, whichever comes first, then you can cancel or kick in to your special priced Embarcadero RAD Studio developer exclusive subscription.
So, go check it out.Uncategorized | 1 Comment »
Uncategorized | 1 Comment »
I found a great resource for those of you trying out iOS support in XE4. macincloud.com offers rental time of Mac hardware online. Yesterday, I setup an account. Installed Platform Assistant into my account (actually I had to ask them to install it for me via the .pkg we make available online). Once it was installed, I ran PA Server, grabbed my IP address of that machine, setup a connection in RAD Studio, built and deployed a Simulator targeted app, and voila! Very cool service.Uncategorized | 4 Comments »
One would think the meaning of a simple term like ‘native’ with regard to software applications would be obvious. This term has had a specific meaning since the dawn of software development. Those of us who have been developing software for a while inherently understand this to mean compiled source code that produces a binary to run directly on the CPU; When the OS loads your app, there is nothing between your app and the machine. As such, there are well understood benefits from all software developers around native apps, namely the best performance possible on a device.
However, over the last year or so, I’ve been noticing the term ‘native’ thrown around much more loosely when describing all kinds of mobile apps. To some, an app has been described as native if it can simply be downloaded from an app store and launched with an app icon even it consists of just web content. To others, an app has been described as native if it binds a scripting language to some of the OS SDK APIs. I’ve even seen some describe an app as native if it only calls on the OS to render the user interface controls. While some of these features are characteristics of a native application they all fail to deliver on the true meaning of a native application - ultimate performance with nothing between your app and the device.
The use of a scripting language or VM, in the simplest terms, introduce another layer of software to convert your sources into machine code (typically at runtime) and this presents several compromises for a developer. Some of these compromises include limited tunability and lack of predictability. This hurts your ability as a developer to have full control over the performance of your application and ultimately gets in the way of delivering the best user experience possible on the device. That user experience, judged by end users largely by the performance of the app, has become a paramount concern for most app developers because it is a critical to an app’s success. We’re not the only ones that believe this.
Facebook came to this conclusion several months back.
“The biggest mistake we made as a company was betting too much on HTML5 as opposed to native."
Mark Zuckerberg - Facebook CEO
"One of the biggest advantages we’ve gained from building on native iOS has been the ability to make the app fast.
Jonathan Dann – Facebook 2012
And the trend continues:
“The lesson we’ve learnt over the last 12 months has been that the cost in time, effort and testing to bring an HTML5 application to a native level of performance seems to be far greater than if the application was built with native technologies from the get-go.”
Matt Vickers - Xero
“In most cases you really do need a native experience. The feedback we’ve gotten is that customers want to enhance that (mobile) experience from a native perspective. Therefore, the company found it needed to invest more heavily in native apps, which could provide a better and richer user experience.”
Albert Lai – BrightCove
With RAD Studio XE4, developers can be sure they are getting the best performance possible to deliver the ultimate user experiences on iOS devices, PCs, and Macs, with True Native compiled code and as announced for later this year True Native for Android, too!Posted by J T on April 18th, 2013 under Uncategorized | 4 Comments »
If there is one thing that Enterprises need to do today - they need to deliver functionality and data onto mobile devices. Although there are plenty of technology options for remoting and moving data around the cloud and/or to a client, a clear, emerging, leader here is the use of REST technology.
Basically, for those who are not aware, REST presents a lightweight remoting protocol that can also move data around with JSON, a lightweight data interchange format. Since many Enterprise applications are written in C++, how can you take advantage of it. For those of you using VCL or FireMonkey you can use provided components but there is a new and very interesting project that deserves a further look. Recently, Microsoft released a new C++ REST SDK, called Casablanca, as an open source project. Even though it comes form Microsoft, it is not Windows specific.
Here is how it is described on the Casablanca codeplex project site:
This library is an effort to support cloud-based client-server communication in native code using a modern asynchronous C++ API design.
The C++ REST SDK (codename "Casablanca") is a project to start exploring how to best support C++ developers who want to take advantage of the radical shift in software architecture that cloud computing represents.
What is most interesting about this SDK, to me, is that it takes advantage of new C++11 features, particularly around asynchronous operations. Here is how the project creators describe their goals in that regard.
This library also gives you a convenient model for composing asynchronous operations. Whether your application is compute-intensive or I/O-driven, its scalability is likely to require careful resource utilization. Asynchronous APIs are great for scalability, but can be very hard to use when all you have is C-level functionality. Fortunately, C++ 11 offers a whole new set of capabilities that can make dealing with asynchronous operations easy, and the library takes advantage of that throughout.
I agree! C++11 does offer a whole new set of capabilities to improve asynchronous operations. Now that we have a highly compliant C++11, I plan to work on building this with our BCC64 compiler and reporting back. Anyone interested in working on that with me?
P.S. For those of you not understanding the reference in the title check out this scene from the classic 1942 movie, Casablanca.Posted by J T on March 20th, 2013 under Uncategorized | 4 Comments »
If any of you are interested in the C++ standard, the current Working Group 21 is tweeting paper submissions as they come in.
Check out @isocpp.
Some recent notables for me:
A Parallel Algorithms Library
Proposal for Assorted Extensions to Lambda Expressions—Faisal Vali et al.
Proposal for Generic (Polymorphic) Lambda Expressions (Rev. 2)—F. Vali et al.
I’ve recently decided my PlayMyDrums iOS app is best suited for the iPad and more specifically landscape mode (rotated 90 degrees). Take a look at the app in Portrait mode - it doesn’t provide enough playing area since it shrinks the image to fit. Additionally, the FireMonkey ellipses I used to specify the hit area need to be aligned to work in portrait mode.
Since I’ve decided to make it work in Portrait mode only, I am not going to worry about realining for this orientation. Rather I am going to lock this application to not display in Portrait. With RAD Studio and FireMonkey on iOS this will be very easy - I simply set this as a project option and the Application properties (and plist.info) get updated for me automatically.
Now, the app loads in landscape mode (even the splash screen) and the user cannot rotate it into portrait mode.Delphi, FireMonkey, iOS | Comment now »
FireMonkey has a new feature in XE3 to detect if your Mac OS X or iOS device has a retinal display. If it does detect your application running on a Retina device, FireMonkey will load high resolution assets automatically to take advantage of the additional pixels. For my Play My Drums app, which will be a tablet only application, I want to make sure it looks as good as it can.
Doing this with a FireMonkey TImage is extremely easy. Basically, there is a new property added to TImage called BitmapHiRes.
So, for PlayMyDrums app, I provide two sets of images that are scaled and layed out to the exact resolutions for a Retina (2048×1536) and non-Retina (1024×768) iPad. The same package gets deployed and installed on to each seperate device but at runtime FireMonkey selects the correct asset for me.\
As a follow on to David I’s blog post about C++ being everywhere, I thought I would share some of my own observations.
In the mid 2000s, I was working at an local embedded Linux company. We were convinced Linux would take over the world and we were partly right (Android with it’s Linux kernel pretty much has ). Our Linux was being used in many types of embedded devices from telecoms, to medical, to military, to consumer game systems and I was very interested in enabling our customers application developers to be successful. The primary language used for kernel development was C but for application development, it was C++.
Now, the world has evolved quite a bit since then and embedded devices are now everywhere with smart phones, tablets, wearable computing, infotainment systems, etc. But even more compelling is that all of these devices are app ready.
For instance, here is an upcoming book on "Pro" C++ using the Android NDK:
BlackBerry has made C++ central to their future platform:
So, has Microsoft for WinRT, where C++ is already dominant for the desktop:
Finally, although Apple talks about Objective-C, C++ actually gets equal billing on their developer site:
Seems pretty obvious to me that C++ is not only everywhere but is as mainstream as it ever has been, in no small part, thanks to the meteoric rise of embedded devices in all of our lives.