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.

http://docwiki.embarcadero.com/RADStudio/XE4/en/C%2B%2B11_Language_Features_Compliance_Status

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!

Share This | Email this page to a friend

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.

http://www.macincloud.com/pricing/special-plans/embarcadero-powered-plans

So, go check it out.

Share This | Email this page to a friend

Share This | Email this page to a friend

Share This | Email this page to a friend

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.

You will hear us talk about True Native in this XE4 release (and beyond) to remind software developers of the value of compiled code and to help them understand the real meaning of this term that has been grossly and disingenuously overloaded.  True Native re-captures the meaning of what ‘Native’ use to mean, compiling your code to a ‘native’ binary for that device. In comparison to other languages and solutions there is a clear difference. Scripting solutions, like those that use JavaScript, require a runtime language interpreter to convert the source code into machine code. Same goes for Virtual Machines (VM) like those that support the Java and/or C# languages.

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!

Share This | Email this page to a friend

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?

~/jt

P.S. For those of you not understanding the reference in the title check out this scene from the classic 1942 movie, Casablanca.

Share This | Email this page to a friend

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.

Share This | Email this page to a friend

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.

Share This | Email this page to a friend

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.\

Share This | Email this page to a friend

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.

Each major OS vendor provides several languages and frameworks for building applications and many have turned to languages like HTML/JavaScript and Java in attempts to make it easier for a wider developer audience. But I have found it very interesting that C++ as an application development language is very well supported on ALL of these operating systems.

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.
~/jt

Share This | Email this page to a friend