BCCIOSARM64
Go Up to Clang-enhanced C++ Compilers
BCCIOSARM64 is the Appmethod C++ compiler for 64-bit iOS.
BCCIOSARM64 is based on Clang 3.3.1. See Clang-enhanced C++ Compilers for information that the BCCIOSARM64 compiler has in common with other Clang-enhanced C++ compilers.
- Notes:
- BCCIOSARM64 does not support the iOS Simulator. The iOS Simulator runs a special, non-ARM version of iOS. Appmethod does not provide any C++ compiler for the iOS Simulator.
- For 32-bit iOS, use BCCIOSARM instead.
Contents
General Information
| Field | Value |
|---|---|
| Calling Conventions | |
| Name Mangling | Itanium (with small differences) |
| Standard Library | LLVM libc++ |
Output Files
| File Type | File Extension | File Format |
|---|---|---|
| Executable | Mach-O | |
| Shared Library | N/A¹ | |
| Static Library | .a
|
ar |
| Compiled Object | .o
|
Mach-O |
- Note: iOS does not support applications containing shared libraries.
Writing C++ Code for BCCIOSARM64
To write C++ code specifically for BCCIOSARM64, use:
#if defined(__APPLE__) && defined(__arm64__) // Your code. #endif
- Note: This is compiler-specific code, and it is not the recommended way to write iOS-specific code. See Creating an iOS App, Writing Code for iOS Only.
For more information, see Clang-enhanced C++ Compilers, Predefined Macros.
Implementation of Some Data Types in BCCIOSARM64
The 64-bit runtime environment on iOS changes the sizes of many built-in data types. This section explains how to use the following Object Pascal data in C++ codes for 64-bit iOS devices:
NativeInt
On iOS64 platform, the Object Pascal type NativeInt is implemented via the long type. This might affect the codes that involve constants. To avoid ambiguity, the code must use the L-suffix as shown in the following code snippet:
NativeInt ni; #if defined(_PLAT_IOS64) if (ni == 99L) #else if (ni == 99) #endif
Note: In the code snippet above, the code that does not use the L-suffix would be ambiguous for iOS64 platform.
TypeInfo
In Object Pascal codes, the TypeInfo function returns a pointer to the RTTI (Run-time Type Information) block that describes a given type. However, this function is not available in Appmethod C++. In C++ codes you should use the __delphirtti keyword instead.
On iOS64, for a long type, the TypeInfo function returns a typeinfo of the System::tkInt64 kind. At the same time, on other platforms, it returns a typeinfo of the System::tkInteger kind. To clarify, consider the following code snippet:
System::Typinfo::PTypeInfo ti; ti = __delphirtti(long); #if defined(_PLAT_IOS64) assert(ti->Kind == System::tkInt64); assert(pData->MinInt64Value == -9223372036854775808L); assert(pData->MaxInt64Value == 9223372036854775807L); #else assert(ti->Kind == System::tkInteger); assert(pData->OrdType == System::Typinfo::otSLong); assert(pData->MinValue == -2147483648); assert(pData->MaxValue == 2147483647); #endif
The Typeinfo differences mentioned above can cause an incompatibility between iOS64 client code interacting with a Server. For example, when you send a long via SOAP, the iOS64 platform will serialize it as an xml long while other platforms will serialize it as a xml int.
For example, the following table shows the XML produced when a long is sent from a Win32 and an iOS64 client:
| iOS64 | WIN32 |
|---|---|
| <V xsi:type="xsd:long">-1000</V> | <V xsi:type="xsd:int">-1000</V> |
Most runtime environments will transparently convert the XML back to the appropriate type upon deserialization. However, due to the differences in the range of an xml:long vs an xml:int, an iOS64 client could send a value that is truncated by a WIN32 receiver.