डेटा प्रकार

इस सेक्शन में, एचआईडीएल डेटा टाइप के बारे में बताया गया है. लागू करने से जुड़ी जानकारी के लिए, यहां देखें HIDL C++ (C++ के लिए लागू करना) या HIDL Java (Java को लागू करने के लिए).

C++ की समानताओं में ये शामिल हैं:

• structs C++ सिंटैक्स का इस्तेमाल करता है; unions C++ सिंटैक्स के साथ काम करता है डिफ़ॉल्ट रूप से. दोनों को नाम देना ज़रूरी है; अनाम स्ट्रक्चर और यूनियन का इस्तेमाल नहीं किया जा सकता.
• HIDL में Typedef की अनुमति है (क्योंकि वे C++ में हैं).
• C++-स्टाइल वाली टिप्पणियों की अनुमति है. साथ ही, इन्हें जनरेट की गई हेडर फ़ाइल में कॉपी किया जा सकता है.

Java की समानताओं में ये शामिल हैं:

• हर फ़ाइल के लिए, HIDL एक Java-स्टाइल नेमस्पेस तय करता है जो इससे शुरू होना चाहिए android.hardware.. जनरेट किया गया C++ नेमस्पेस यह है ::android::hardware::….
• फ़ाइल की सभी परिभाषाएं Java-स्टाइल में शामिल हैं interface का रैपर.
• HIDL कलेक्शन का एलान, Java स्टाइल का पालन करता है, न कि C++ स्टाइल. उदाहरणः

  struct Point {
      int32_t x;
      int32_t y;
  };
  Point[3] triangle;   // sized array
  

• टिप्पणियां, javadoc फ़ॉर्मैट से मिलती-जुलती हैं.

डेटा दिखाना

struct या union से मिलकर बना स्टैंडर्ड-लेआउट (सामान्य पुराने डेटा टाइप की ज़रूरी शर्त का सबसेट) में एक जैसी मेमोरी होती है जनरेट किए गए C++ कोड में लेआउट, साफ़ तौर पर अलाइनमेंट एट्रिब्यूट के साथ लागू किया गया struct और union सदस्य.

प्रिमिटिव एचआईडीएल टाइप, enum, और bitfield टाइप (जो हमेशा प्रिमिटिव टाइप से आते हैं), स्टैंडर्ड C++ टाइप से मैप करें जैसे कि std::uint32_t की वेबसाइट cstdint.

Java में साइन इन नहीं किए गए टाइप काम नहीं करते. इसलिए, साइन नहीं किए गए HIDL टाइप को साइन किया गया संबंधित Java का टाइप. स्ट्रक्ट Java क्लास पर मैप; अरे, Java अरे पर मैप; फ़िलहाल, यूनियन काम नहीं कर रहे जावा में. स्ट्रिंग को अंदरूनी तौर पर UTF8 के तौर पर सेव किया जाता है. चूंकि Java का समर्थन करता है सिर्फ़ UTF16 स्ट्रिंग के साथ-साथ, Java को लागू करने के लिए भेजी गई स्ट्रिंग वैल्यू अनुवाद किया गया है और हो सकता है कि यह दोबारा अनुवाद करने पर एक जैसा न हो, क्योंकि इसमें वर्ण सेट नहीं होते हमेशा आसानी से मैप करें.

C++ में आईपीसी के ज़रिए मिले डेटा को const के तौर पर मार्क किया गया है और यह रीड-ओनली मेमोरी, जो सिर्फ़ फ़ंक्शन कॉल के दौरान बनी रहती है. डेटा को Java ऑब्जेक्ट में IPC पर पहले ही कॉपी कर लिया गया है, इसलिए यह अतिरिक्त कॉपी के बिना बनाए रखा जाना चाहिए (और इसमें बदलाव किया जा सकता है).

एनोटेशन

टाइप की जानकारी देने वाले एलान में, जावा-स्टाइल एनोटेशन जोड़े जा सकते हैं. एनोटेशन हैं HIDL कंपाइलर के वेंडर टेस्ट सुइट (VTS) बैकएंड से पार्स किया गया लेकिन इनमें से कोई नहीं ऐसे पार्स किए गए एनोटेशन को असल में HIDL कंपाइलर समझ लेता है. इसके बजाय, पार्स किए गए वीटीएस एनोटेशन को वीटीएस कंपाइलर (वीटीएससी) मैनेज करता है.

एनोटेशन Java सिंटैक्स का इस्तेमाल करते हैं: @annotation या @annotation(value) या @annotation(id=value, id=value…) जहां मान कोई स्थिर व्यंजक, स्ट्रिंग या मानों की सूची हो सकता है {} के अंदर, ठीक वैसे ही जैसे Java में है. एक ही नाम की कई व्याख्याएं उसी आइटम के साथ अटैच किया जा सकता है.

एलान फ़ॉरवर्ड करें

HIDL में, हो सकता है कि स्ट्रक्चर का एलान फ़ॉरवर्ड न किया गया हो, जिससे उपयोगकर्ता को तय किया जाता हो, इस डेटा टाइप को खुद रेफ़र नहीं किया जा सकता. उदाहरण के लिए, लिंक की गई सूची के बारे में पूरी जानकारी नहीं दी जा सकती या HIDL में कोई पेड़). ज़्यादातर मौजूदा (Android 8.x से पहले के वर्शन) एचएएल में फ़ॉरवर्ड एलानों को, डेटा स्ट्रक्चर को फिर से व्यवस्थित करके हटाया जा सकता है एलानों को पूरा करना ज़रूरी है.

इस पाबंदी की मदद से, डेटा स्ट्रक्चर को आसान तरीके से वैल्यू के हिसाब से कॉपी किया जा सकता है डीप-कॉपी करने के बजाय, एक से ज़्यादा बार आने वाले पॉइंटर वैल्यू को ट्रैक करने के बजाय समय तय होता है. अगर एक ही डेटा दो बार पास किया जाता है, उदाहरण के लिए, दो तरीके पैरामीटर या vec<T> एक ही डेटा, दो अलग-अलग कॉपी बनाई और डिलीवर की जाती हैं.

नेस्ट किए गए एलान

HIDL, नेस्ट किए गए एलानों के साथ अपनी ज़रूरत के हिसाब से कई लेवल पर काम करता है. अपवाद नीचे बताया गया है). उदाहरण के लिए:

interface IFoo {
    uint32_t[3][4][5][6] multidimArray;

    vec<vec<vec<int8_t>>> multidimVector;

    vec<bool[4]> arrayVec;

    struct foo {
        struct bar {
            uint32_t val;
        };
        bar b;
    }
    struct baz {
        foo f;
        foo.bar fb; // HIDL uses dots to access nested type names
    }
    …

अपवाद यह है कि इंटरफ़ेस प्रकार केवल vec<T> और सिर्फ़ एक लेवल की गहराई (नहीं vec<vec<IFoo>>).

रॉ पॉइंटर सिंटैक्स

HIDL भाषा * का इस्तेमाल नहीं करती और C/C++ रॉ पॉइंटर की पूरी सुविधा. एचआईडीएल को कैसे इनकैप्सुलेट करता है, इस बारे में जानकारी के लिए पॉइंटर और अरे/वेक्टर, vec<T> देखें टेंप्लेट के बारे में ज़्यादा जानें.

इंटरफ़ेस

interface कीवर्ड को दो बार इस्तेमाल किया गया है.

• यह .hal फ़ाइल में इंटरफ़ेस की परिभाषा खोलता है.
• इसका इस्तेमाल स्ट्रक्चर/यूनियन फ़ील्ड, तरीका पैरामीटर, और वापस कर दें. इसे एक सामान्य इंटरफ़ेस और इसके समानार्थी के रूप में देखा गया है android.hidl.base@1.0::IBase.

उदाहरण के लिए, IServiceManager का यह तरीका इस्तेमाल किया जाता है:

get(string fqName, string name) generates (interface service);

इस तरीके में नाम से कुछ इंटरफ़ेस को खोजने का वादा किया जाता है. यह भी है इंटरफ़ेस को android.hidl.base@1.0::IBase से बदलने के जैसा है.

इंटरफ़ेस को सिर्फ़ दो तरीकों से पास किया जा सकता है: टॉप-लेवल पैरामीटर के तौर पर या vec<IMyInterface> के सदस्य. वे इसके सदस्य नहीं हो सकते नेस्ट किए गए वीक्स, स्ट्रक्ट, अरे या यूनियन.

MQDescriptorSync और MQDescriptorUnsync

MQDescriptorSync और MQDescriptorUnsync टाइप सिंक किए गए या सिंक नहीं किए गए फ़ास्ट मैसेज लिस्ट (एफ़एमक्यू) डिस्क्रिप्टर को पास करें एक HIDL इंटरफ़ेस पर नज़र आ रहा है. जानकारी के लिए, यह देखें HIDL C++ (FMQ ये नहीं हैं Java में उपलब्ध है).

मेमोरी का टाइप

memory टाइप का इस्तेमाल, मैप नहीं की गई शेयर की गई मेमोरी को दिखाने के लिए किया जाता है एचडीएल. यह सिर्फ़ C++ में काम करता है. इस प्रकार के मान का उपयोग IMemory ऑब्जेक्ट को शुरू करने के लिए एंड मिल रहा है और मेमोरी को मैप करना है और उसे उपयोगी बनाना. जानकारी के लिए, यह देखें HIDL C++.

चेतावनी: शेयर की गई जगह पर स्ट्रक्चर्ड डेटा मेमोरी एक ऐसा प्रकार होना चाहिए जिसका प्रारूप कभी भी इंटरफ़ेस वर्शन memory पास कर रहा है. ऐसा न करने पर, एचएएल को नुकसान हो सकता है कोई नुकसान नहीं पहुंचा सकता.

पॉइंटर टाइप

pointer टाइप को सिर्फ़ HIDL इस्तेमाल करने के लिए इस्तेमाल किया जा सकता है.

बिटफ़ील्ड<T> टेंप्लेट टाइप करें

bitfield<T>, जिसमें T, उपयोगकर्ता की तय की गई संख्या से पता चलता है कि वैल्यू, GA4 प्रॉपर्टी के T में तय की गई enum वैल्यू. जनरेट किए गए कोड में, bitfield<T>, दिए गए T के टाइप के तौर पर दिखता है. इसके लिए उदाहरण:

enum Flag : uint8_t {
    HAS_FOO = 1 << 0,
    HAS_BAR = 1 << 1,
    HAS_BAZ = 1 << 2
};
typedef bitfield<Flag> Flags;
setFlags(Flags flags) generates (bool success);

कंपाइलर, फ़्लैग टाइप को uint8_t की तरह ही हैंडल करता है.

इसका इस्तेमाल क्यों न करें (u)int8_t/(u)int16_t/(u)int32_t/(u)int64_t? bitfield का इस्तेमाल करने से, पाठक को एचएएल की ज़्यादा जानकारी मिलती है. जो अब यह जानते हैं कि setFlags फ़्लैग का बिट के अनुसार-OR मान लेता है (यानी को पता है कि 16 के साथ setFlags को कॉल करना अमान्य है). इसके बिना bitfield, यह जानकारी सिर्फ़ दस्तावेज़ के ज़रिए दी जाती है. तय सीमा में इसके अलावा, VTS वाकई में यह जांच कर सकता है कि फ़्लैग की वैल्यू, बिट के हिसाब से या फ़्लैग की है या नहीं.

प्रिमिटिव टाइप के हैंडल

चेतावनी: किसी भी तरह के पते से जुड़ी जानकारी (यहां तक कि ऑफ़िस या ऑफ़िस के पते पर भी) डिवाइस पते) कभी भी नेटिव हैंडल का हिस्सा नहीं होने चाहिए. इसे पास करना एक प्रोसेस के बीच की जानकारी खतरनाक होती है और उस पर हमला होने की आशंका होती है. अलग-अलग प्रोसेस के बीच पास की जाने वाली वैल्यू की पुष्टि करने के बाद ही, उन्हें इन कामों के लिए इस्तेमाल किया जा सकता है किसी प्रोसेस में असाइन की गई मेमोरी को खोजें. ऐसा न करने पर, गलत हैंडल की वजह से मेमोरी ऐक्सेस या मेमोरी खराब हो जाना.

HIDL सिमेंटिक, हर वैल्यू के हिसाब से कॉपी होते हैं यानी कि पैरामीटर कॉपी किए जाते हैं. डेटा का कोई भी बड़ा हिस्सा या ऐसा डेटा जिसे अलग-अलग प्रोसेस के बीच शेयर करने की ज़रूरत होती है (जैसे कि सिंक फ़ेंस), इन्हें निर्देश देने वाले फ़ाइल डिस्क्रिप्टर के पास से पास करके मैनेज किया जाता है स्थायी ऑब्जेक्ट के लिए: ashmem शेयर की गई मेमोरी, वास्तविक फ़ाइलों, या फ़ाइल डिस्क्रिप्टर के पीछे छिपा हो सकने वाली कोई भी अन्य चीज़. बाइंडर ड्राइवर फ़ाइल डिस्क्रिप्टर का डुप्लीकेट किसी अन्य प्रोसेस में बना देता है.

नेटिव_हैंडल_t

Android, native_handle_t पर काम करता है. यह सामान्य हैंडल का सिद्धांत है libcutils में परिभाषित किया गया है.

typedef struct native_handle
{
  int version;        /* sizeof(native_handle_t) */
  int numFds;         /* number of file-descriptors at &data[0] */
  int numInts;        /* number of ints at &data[numFds] */
  int data[0];        /* numFds + numInts ints */
} native_handle_t;

नेटिव हैंडल, पूर्णांकों और फ़ाइल डिस्क्रिप्टर का कलेक्शन होता है, जिन्हें पास किया जाता है का ध्यान रखें. सिंगल फ़ाइल डिस्क्रिप्टर को नेटिव हैंडल में सेव किया जा सकता है कोई ints और एक फ़ाइल डिस्क्रिप्टर नहीं होना चाहिए. नेटिव हैंडल का इस्तेमाल करके पासिंग हैंडल handle प्रिमिटिव टाइप के साथ होने पर, यह पक्का होता है कि नेटिव हैंडल सीधे HIDL में शामिल किए जाते हैं.

native_handle_t का साइज़ अलग-अलग है, इसलिए इसे शामिल नहीं किया जा सकता सीधे किसी निर्देश में. हैंडल फ़ील्ड, एक अलग विंडो में पॉइंटर जनरेट करता है असाइन किए गए native_handle_t.

Android के पुराने वर्शन में, नेटिव हैंडल इसमें मौजूद फ़ंक्शन Libcutils. Android 8.0 और उसके बाद के वर्शन में, ये फ़ंक्शन अब android::hardware::hidl नेमस्पेस या एनडीके (NDK) में ले जाया गया. एचआईडीएल अपने-आप जनरेट होने वाला कोड, इन फ़ंक्शन को अपने-आप क्रम से लगाता है और डीसीरियलाइज़ करता है, इसके लिए, वह उपयोगकर्ता के लिखे हुए कोड को अपने-आप एक्सपोर्ट नहीं कर सकता.

फ़ाइल डिस्क्रिप्टर का मालिकाना हक मैनेज करना और फ़ाइल डिस्क्रिप्टर का मालिकाना हक

जब किसी HIDL इंटरफ़ेस विधि को कॉल किया जाता है, जो एक hidl_handle ऑब्जेक्ट (टॉप लेवल या कंपाउंड टाइप का हिस्सा), उसमें शामिल फ़ाइल डिस्क्रिप्टर का मालिकाना हक इस तरह होगा:

• ऐसा कॉलर जो hidl_handle ऑब्जेक्ट को तर्क, native_handle_t यह खत्म हो गया; कॉलर को ये फ़ाइल बंद करनी होगी जानकारी दी जाएगी, जब यह उनके साथ पूरी हो जाएगी.
• hidl_handle लौटाने वाली प्रक्रिया ऑब्जेक्ट (इसे _cb फ़ंक्शन में पास करने पर) का मालिकाना हक बना रहता है native_handle_t में मौजूद फ़ाइल डिस्क्रिप्टर, जिन्हें ऑब्जेक्ट; यह प्रोसेस पूरी होने पर, इन फ़ाइल डिस्क्रिप्टर को बंद कर दिया जाना चाहिए.
• hidl_handle पाने वाले ट्रांसपोर्ट के पास native_handle_t में फ़ाइल डिस्क्रिप्टर का मालिकाना हक ऑब्जेक्ट के साथ रैप किया हुआ हो; रिसीवर इन फ़ाइल डिस्क्रिप्टर का इस्तेमाल ट्रांज़ैक्शन कॉलबैक, लेकिन फ़ाइल का इस्तेमाल करने के लिए नेटिव हैंडल का क्लोन बनाना ज़रूरी है डिस्क्रिप्टर का इस्तेमाल करना न भूलें. ट्रांसपोर्ट अपने-आप कॉल करता है लेन-देन पूरा होने पर, फ़ाइल की जानकारी देने वाले व्यक्ति के लिए close().

HIDL Java में हैंडल का समर्थन नहीं करता (क्योंकि Java सभी).

साइज़ वाले अरे

HIDL स्ट्रक्चर में साइज़ वाले सरणियों के लिए, उनके एलिमेंट किसी भी तरह के स्ट्रक्चर के हो सकते हैं इसमें ये शामिल हो सकते हैं:

struct foo {
uint32_t[3] x; // array is contained in foo
};

स्ट्रिंग

C++ और Java में स्ट्रिंग अलग-अलग तरह से दिखती हैं, लेकिन इनके ट्रांसपोर्ट में मौजूद मूल ट्रांसपोर्ट स्टोरेज का टाइप C++ है. जानकारी के लिए, यह देखें HIDL C++ डेटा टाइप या HIDL Java डेटा टाइप.

नोट: किसी स्ट्रिंग को HIDL इंटरफ़ेस (जिसमें Java से Java शामिल है) की वजह से वर्ण सेट में कन्वर्ज़न होते हैं जो मूल एन्कोडिंग को सुरक्षित नहीं रख पाते हैं.

वीसी<T> टेंप्लेट टाइप करें

vec<T> टेंप्लेट, वैरिएबल साइज़ का बफ़र दिखाता है T के इंस्टेंस शामिल हैं.

T इनमें से एक हो सकता है:

• प्रिमिटिव टाइप (उदाहरण के लिए, uint32_t)
• स्ट्रिंग
• उपयोगकर्ता की ओर से तय किए गए ईनम
• उपयोगकर्ता के तय किए गए स्ट्रक्चर
• इंटरफ़ेस या interface कीवर्ड (vec<IFoo>, vec<interface> इस्तेमाल किया जा सकता है का इस्तेमाल सिर्फ़ टॉप-लेवल पैरामीटर के तौर पर करें)
• हैंडल
• बिटफ़ील्ड<U>
• vec<U>, जहां U इस सूची में है. इसमें इंटरफ़ेस (जैसे कि vec<vec<IFoo>> का इस्तेमाल नहीं किया जा सकता)
• U[] (U का आकार वाला अरे), जहां इंटरफ़ेस को छोड़कर U इस सूची में है

उपयोगकर्ता के तय किए गए टाइप

इस सेक्शन में बताया गया है कि किस टाइप के उपयोगकर्ताओं को विज्ञापन दिखाए जाते हैं.

इनम

HIDL अनाम enum का समर्थन नहीं करता. अगर ऐसा नहीं है, तो एचआईडीएल में मौजूद ईनम एक जैसे हैं C++11 तक:

enum name : type { enumerator , enumerator = constexpr , …  }

बेस ईनम को HIDL में मौजूद पूर्णांक टाइप में से किसी एक के हिसाब से तय किया जाता है. अगर नहीं पूर्णांक के आधार पर किसी ईनम के पहले एन्यूमरेटर के लिए वैल्यू तय की गई है टाइप करता है, तो वैल्यू डिफ़ॉल्ट रूप से 0 पर सेट हो जाती है. अगर बाद के एन्यूमरेटर के लिए कोई वैल्यू तय नहीं की गई है, वैल्यू डिफ़ॉल्ट रूप से पिछली वैल्यू प्लस वन पर सेट होती है. उदाहरण के लिए:

// RED == 0
// BLUE == 4 (GREEN + 1)
enum Color : uint32_t { RED, GREEN = 3, BLUE }

किसी ईनम को पहले से तय ईनम से भी लिया जा सकता है. अगर कोई मान नहीं है चाइल्ड ईनम के पहले एन्यूमरेटर के लिए तय किया गया है (इस मामले में FullSpectrumColor), तो यह आखिरी की डिफ़ॉल्ट वैल्यू पर सेट होती है पैरंट ईनम प्लस वन का enumerator है. उदाहरण के लिए:

// ULTRAVIOLET == 5 (Color:BLUE + 1)
enum FullSpectrumColor : Color { ULTRAVIOLET }

चेतावनी: Enum इनहेरिटेंस, पीछे की ओर काम करता है इनहेरिटेंस के लिए सबसे ज़्यादा इस्तेमाल किए जाते हैं. चाइल्ड ईनम वैल्यू का इस्तेमाल पैरंट एनम की वैल्यू. ऐसा इसलिए है क्योंकि चाइल्ड enum में पैरंट. हालांकि, पैरंट ईनम वैल्यू का इस्तेमाल, चाइल्ड एनम वैल्यू के तौर पर सुरक्षित तरीके से किया जा सकता है क्योंकि चाइल्ड ईनम वैल्यू, पैरंट ईनम वैल्यू का सुपरसेट हैं. इंटरफ़ेस डिज़ाइन करते समय इसे ध्यान में रखें, क्योंकि इंटरफ़ेस को पैरंट enum इंटरफ़ेस पर कॉपी करने की सुविधा मिलती है.

ईनम के मान को कोलन सिंटैक्स से बताया जाता है (डॉट सिंटैक्स नहीं नेस्ट किए गए टाइप). इसका सिंटैक्स Type:VALUE_NAME है. बताने की ज़रूरत नहीं है टाइप करें, अगर उस वैल्यू का रेफ़रंस एक ही ईनम टाइप या चाइल्ड टाइप में दिया गया है. उदाहरण:

enum Grayscale : uint32_t { BLACK = 0, WHITE = BLACK + 1 };
enum Color : Grayscale { RED = WHITE + 1 };
enum Unrelated : uint32_t { FOO = Color:RED + 1 };

Android 10 की शुरुआत से, enum में len एट्रिब्यूट, जिसका इस्तेमाल कॉन्सटैंट एक्सप्रेशन में किया जा सकता है. MyEnum::len उस गिनती में एंट्री की कुल संख्या है. यह मानों की कुल संख्या से अलग होती है, जो तब छोटी हो सकती है, जब वैल्यू की डुप्लीकेट कॉपी बनाई गई हैं.

स्ट्रक्ट

HIDL अनजान स्ट्रक्चर के साथ काम नहीं करता. नहीं तो, HIDL में निर्देश बहुत सी. से मिलता-जुलता.

HIDL, वैरिएबल-अवधि वाले ऐसे डेटा स्ट्रक्चर के साथ काम नहीं करता जो पूरी तरह से एक संरचना. इसमें अनिश्चित अवधि वाला अरे शामिल है. इसे कभी-कभी इस तरह इस्तेमाल किया जाता है: C/C++ में किसी संरचना का अंतिम फ़ील्ड (कभी-कभी [0]). HIDL vec<T> डाइनैमिक साइज़ दिखाता है ऐसे अरे जिनमें डेटा को अलग बफ़र में सेव किया गया हो; ऐसे मामले दिखाए जाते हैं struct में vec<T> के एक इंस्टेंस के साथ.

इसी तरह, string को struct में शामिल किया जा सकता है (इस डेटा से जुड़े बफ़र अलग-अलग होते हैं). जनरेट किए गए C++ में, HIDL के इंस्टेंस हैंडल टाइप को असल नेटिव हैंडल के पॉइंटर के ज़रिए दिखाया जाता है दिए गए डेटा टाइप के इंस्टेंस, वैरिएबल की लंबाई के होते हैं.

Union

HIDL, अनाम यूनियन का समर्थन नहीं करता. ऐसा नहीं होने पर यूनियन, C की तरह होते हैं.

यूनियन में सुधार करने के तरीके (जैसे कि पॉइंटर, फ़ाइल डिस्क्रिप्टर, बाइंडर) नहीं हो सकते हैं ऑब्जेक्ट). उन्हें किसी खास फ़ील्ड या उससे जुड़े टाइप की ज़रूरत नहीं होती और memcpy() या इसके बराबर के इस्तेमाल से कॉपी किया गया हो. ऐसा हो सकता है कि कोई यूनियन सीधे तौर पर इसमें ऐसा कुछ भी शामिल है (या किसी दूसरे डेटा स्ट्रक्चर का इस्तेमाल किया हुआ है) जिसके लिए सेटिंग की ज़रूरत होती है बाइंडर ऑफ़सेट (यानी कि हैंडल या बाइंडर-इंटरफ़ेस के रेफ़रंस). उदाहरण के लिए:

union UnionType {
uint32_t a;
//  vec<uint32_t> r;  // Error: can't contain a vec<T>
uint8_t b;1
};
fun8(UnionType info); // Legal

यूनियनों को संरचना के अंदर भी घोषित किया जा सकता है. उदाहरण के लिए:

struct MyStruct {
    union MyUnion {
      uint32_t a;
      uint8_t b;
    }; // declares type but not member

    union MyUnion2 {
      uint32_t a;
      uint8_t b;
    } data; // declares type but not member
  }