C++Builder XE4: multi-device, true native, on-device rapid prototyping
C++ developers are deep into the mad, mad, mad, mad world of multiple devices. Users inside and outside of enterprises are using desktops, notebooks, netbooks, ultrabooks, smartphones, tablets, servers and clouds as their main and secondary computing devices. Being able to build native apps for Windows and Mac with a single codebase allows you to code once and create a high performance app that runs on PCs and Macs. Using true native C++ gives you more control and your users the best app experience. With C++Builder XE4, you develop your app in C++ with the multi-device FireMonkey FM3 framework, then compile to multiple platforms. If you are worried about application performance, C++Builder lets you create true native apps that run full-speed directly on the device CPU and GPU, not in a script engine or VM, giving you more control, tighter security, and a better user experience.
Multi-Device, True Native C++ Apps
C++ developers are under pressure to deliver apps to their users and customers can use on multiple platforms, but coding and managing these different versions can be costly and time-consuming. Multi-device app development allows you to use one development project, one tool chain, and one codebase to deliver your app natively on multiple platforms (Windows and Mac).
C++ language extensions support on-device rapid prototyping
As I detailed in my December 2012 "Migrating C++Builder Code to 64-bits" blog post, we have used C++'s standard extension syntax to support multi-device, true native C++ and on-device rapid prototyping. You can find the list of extensions in my blog at http://blogs.embarcadero.com/davidi/2012/12/14/42144.
On-device rapid prototyping is facilitated in the FireMonkey business application platform, the IDE's visual designer and the component architecture. Three langauge extensions support the component model and RTL:
Why is C++Builder the best approach for multi-device development?
Most C++ development solutions do not support the creation of apps for Mac, Windows and Windows tablets all from a single codebase. As a result, development teams not using C++Builder often have to support multiple development projects using different tools, programming languages, codebases, and sometimes different teams to deliver their app on multiple devices.
What are “true native” apps, and why should you care?
True native app development lets you deliver script-free, device-native apps that expose the full range of capabilities and performance in the underlying devices – for faster, richer apps that end users love. Many tool vendors are using the term “native” app development to describe web technologies and scripts wrapped into an app package to deliver an app-like user experience. This approach can impose limits on app performance and capabilities.
True native apps in C++Builder are script-free and run directly on hardware CPU and GPU delivering the following advantages:
C++ multi-device, true native and on-device rapid prototyping in action
There are several ways to see the power and productivity of multi-device, true native and on-device rapid prototyping in action.
You are engineering the apps of the future enterprise. C++Builder is the starship that gives you all she's got!
Multi-Device, True Native C++ Apps
C++ developers are under pressure to deliver apps to their users and customers can use on multiple platforms, but coding and managing these different versions can be costly and time-consuming. Multi-device app development allows you to use one development project, one tool chain, and one codebase to deliver your app natively on multiple platforms (Windows and Mac).
C++ language extensions support on-device rapid prototyping
As I detailed in my December 2012 "Migrating C++Builder Code to 64-bits" blog post, we have used C++'s standard extension syntax to support multi-device, true native C++ and on-device rapid prototyping. You can find the list of extensions in my blog at http://blogs.embarcadero.com/davidi/2012/12/14/42144.
On-device rapid prototyping is facilitated in the FireMonkey business application platform, the IDE's visual designer and the component architecture. Three langauge extensions support the component model and RTL:
- __property - The __property keyword was added to support the VCL and FireMonkey (FMX) class properties. The __property keyword declares an attribute of a class. Properties appear to the programmer just like any other attribute (field) of a class. However, like its Object Pascal counterpart, C++ Builder’s __property keyword adds significantly more functionality beyond just examining and changing the value of the attribute. Since property attributes completely control access to the property, there are no restrictions on how you implement the property within the class itself. http://docwiki.embarcadero.com/RADStudio/XE3/en/Property and http://docwiki.embarcadero.com/RADStudio/XE3/en/C%2B%2B_Keyword_Extensions#_property
- __published – The __published keyword was added to support the VCL and FireMonkey (FMX) frameworks. This public member access specifier is similar to the public specifier, but __published has compiler-generated RTTI (run-time type identification) attached. This means the __published properties appear in the IDE’s Object Inspector View at design time. The __published keyword specifies that properties in that section are displayed in the Object Inspector, if the class is on the Component palette. Only classes derived from TObject can have __published sections. The visibility rules for published members are identical to those of public members. The only difference between published and public members is that Object Pascal-style run-time type information (RTTI) is generated for data members and properties declared in a __published section. RTTI enables an application to dynamically query the data members, member functions, and properties of an otherwise unknown class type. http://docwiki.embarcadero.com/RADStudio/XE3/en/Published.
- __closure - There are two kinds of function pointers that can be used in C++. The first is a simple pointer to a global function (not a member of a class). When dealing with class member functions, a simple pointer to a method is not sufficient to make a call. Instead, two pointers are required: one for the originating object and the second for the method address. All VCL and FireMonkey (FMX) component events are declared as closures, in order to allow methods of a class to be called when the event is fired. The following code is an excerpt from the Classes.hpp header, showing the declaration of the TNotifyEvent, used in many events in VCL and FMX (e.g. OnClick). http://docwiki.embarcadero.com/RADStudio/XE3/en/Closure and http://docwiki.embarcadero.com/RADStudio/XE3/en/C%2B%2B_Keyword_Extensions#_closure
Why is C++Builder the best approach for multi-device development?
Most C++ development solutions do not support the creation of apps for Mac, Windows and Windows tablets all from a single codebase. As a result, development teams not using C++Builder often have to support multiple development projects using different tools, programming languages, codebases, and sometimes different teams to deliver their app on multiple devices.
What are “true native” apps, and why should you care?
True native app development lets you deliver script-free, device-native apps that expose the full range of capabilities and performance in the underlying devices – for faster, richer apps that end users love. Many tool vendors are using the term “native” app development to describe web technologies and scripts wrapped into an app package to deliver an app-like user experience. This approach can impose limits on app performance and capabilities.
True native apps in C++Builder are script-free and run directly on hardware CPU and GPU delivering the following advantages:
- Fast – Uncompromised native device performance with full native API and CPU control when you need it, and not limited by or slowed by script interpreters and virtual machines.
- Predictable – Apps run directly on the device CPU, as intended by the device vendors, and are not slowed by additional software layers and processes, such as random garbage collection.
- Better User Experience (UX) – Apps take full advantage of device capabilities and performance.
C++ multi-device, true native and on-device rapid prototyping in action
There are several ways to see the power and productivity of multi-device, true native and on-device rapid prototyping in action.
- Watch my 31 C++ videos at http://www.embarcadero.com/products/cbuilder/how-to-create-software-applications
- Watch the CodeRage 7 C++ virtual conference session replays at http://www.embarcadero.com/coderage/coderage-7-c-sessions
- Watch my on-demand "C++ in the Multi-Device Enterprise" webinar replay at http://forms.embarcadero.com/forms/AMUSCA1303CMulti-deviceWebinar3-26
- Download the C++Builder XE4 free trial at http://www.embarcadero.com/products/cbuilder/downloads
You are engineering the apps of the future enterprise. C++Builder is the starship that gives you all she's got!
Tags:
32-bit
64-bit
C++
C++Builder
Devices
FireMonkey
GPU
GUI
MAC OSX
Programming
RAD Studio
Windows
Comments
-
Monday, 6 May 2013we need C++ iOS target, when will be deployed?
-
Monday, 6 May 2013
xe4 still no ios support
-
Sunday, 23 June 2013
Thanks for the posting when you have the opportunity,Guess i will just bookmark this web site.
-
Sunday, 20 October 2013
Rp prototype factory in china not only to protect your ideas but its process directly to fabricate a tool for a limited volume of prototypes.
-
Please login first in order for you to submit comments
- Page :
- 1
Hello,
multi-device are welcome but we need C++ iOS target, when will be deployed?
And what about C++ Android target and Windows RT target?
Do you will publishing a new roadmap about that?
Kind regards,
Enrico.