তথ্যের ধরণ

এই বিভাগে HIDL ডেটা প্রকারগুলি বর্ণনা করে৷ বাস্তবায়নের বিবরণের জন্য, HIDL C++ (C++ বাস্তবায়নের জন্য) অথবা HIDL Java (জাভা বাস্তবায়নের জন্য) দেখুন।

C++ এর সাথে মিল রয়েছে:

• structs C++ সিনট্যাক্স ব্যবহার করে; unions ডিফল্টরূপে C++ সিনট্যাক্স সমর্থন করে। উভয়ের নাম দিতে হবে; বেনামী structs এবং ইউনিয়ন সমর্থিত নয়.
• HIDL-এ Typedefs অনুমোদিত (যেমন সেগুলি C++ এ রয়েছে)।
• C++-শৈলী মন্তব্য অনুমোদিত এবং জেনারেট করা হেডার ফাইলে কপি করা হয়।

জাভা এর সাথে মিল রয়েছে:

• প্রতিটি ফাইলের জন্য, HIDL একটি জাভা-স্টাইল নামস্থান সংজ্ঞায়িত করে যা অবশ্যই android.hardware. . জেনারেট করা C++ নামস্থান হল ::android::hardware::… .
• ফাইলের সমস্ত সংজ্ঞা একটি জাভা-স্টাইল interface মোড়কের মধ্যে রয়েছে।
• HIDL অ্যারে ঘোষণা জাভা স্টাইল অনুসরণ করে, C++ স্টাইল নয়। উদাহরণ:

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

• মন্তব্য javadoc বিন্যাস অনুরূপ.

তথ্য উপস্থাপনা

স্ট্যান্ডার্ড-লেআউট (সাধারণ-পুরাতন-ডেটা প্রকারের প্রয়োজনীয়তার একটি উপসেট) দ্বারা গঠিত একটি struct বা union জেনারেট করা C++ কোডে একটি সামঞ্জস্যপূর্ণ মেমরি বিন্যাস থাকে, যা struct এবং union সদস্যদের উপর স্পষ্ট প্রান্তিককরণ বৈশিষ্ট্যের সাথে প্রয়োগ করা হয়।

আদিম HIDL প্রকারগুলি, সেইসাথে enum এবং bitfield প্রকারগুলি (যা সর্বদা আদিম প্রকারগুলি থেকে উদ্ভূত হয়), স্ট্যান্ডার্ড C++ প্রকারের মানচিত্র যেমন std::uint32_t থেকে cstdint ।

যেহেতু জাভা স্বাক্ষরবিহীন প্রকারগুলিকে সমর্থন করে না, তাই স্বাক্ষরবিহীন HIDL প্রকারগুলি সংশ্লিষ্ট স্বাক্ষরিত জাভা প্রকারের সাথে ম্যাপ করা হয়৷ জাভা ক্লাসে মানচিত্র গঠন করে ; অ্যারে ম্যাপ জাভা অ্যারেতে; ইউনিয়নগুলি বর্তমানে জাভাতে সমর্থিত নয়। স্ট্রিংগুলি অভ্যন্তরীণভাবে UTF8 হিসাবে সংরক্ষণ করা হয়। যেহেতু জাভা শুধুমাত্র UTF16 স্ট্রিংগুলিকে সমর্থন করে, তাই জাভা বাস্তবায়নে বা থেকে পাঠানো স্ট্রিং মানগুলি অনুবাদ করা হয় এবং পুনরায় অনুবাদে অভিন্ন নাও হতে পারে কারণ অক্ষর সেটগুলি সর্বদা মসৃণভাবে ম্যাপ করে না।

C++-এ IPC-এর উপর প্রাপ্ত ডেটা const চিহ্নিত এবং শুধুমাত্র পঠনযোগ্য মেমরিতে থাকে যা শুধুমাত্র ফাংশন কলের সময়কালের জন্য স্থায়ী হয়। জাভাতে IPC-এর উপর প্রাপ্ত ডেটা ইতিমধ্যেই জাভা অবজেক্টে অনুলিপি করা হয়েছে, তাই এটি অতিরিক্ত অনুলিপি ছাড়াই ধরে রাখা যেতে পারে (এবং সংশোধন করা যেতে পারে)।

টীকা

জাভা-স্টাইল টীকা টাইপ ঘোষণা যোগ করা যেতে পারে. টীকাগুলি HIDL কম্পাইলারের ভেন্ডর টেস্ট স্যুট (VTS) ব্যাকএন্ড দ্বারা পার্স করা হয় কিন্তু এই ধরনের পার্সকৃত টীকাগুলির কোনোটিই HIDL কম্পাইলার দ্বারা বোঝা যায় না। পরিবর্তে, পার্স করা VTS টীকা VTS কম্পাইলার (VTSC) দ্বারা পরিচালিত হয়।

টীকাগুলি জাভা সিনট্যাক্স ব্যবহার করে: @annotation বা @annotation(value) বা @annotation(id=value, id=value…) যেখানে মান হয় একটি ধ্রুবক অভিব্যক্তি, একটি স্ট্রিং, বা {} এর ভিতরে মানগুলির একটি তালিকা হতে পারে, ঠিক যেমন জাভা। একই নামের একাধিক টীকা একই আইটেমের সাথে সংযুক্ত করা যেতে পারে।

ফরোয়ার্ড ঘোষণা

HIDL-এ, স্ট্রাকটগুলি ফরওয়ার্ড-ঘোষিত নাও হতে পারে, যা ব্যবহারকারী-সংজ্ঞায়িত, স্ব-রেফারেন্সিয়াল ডেটা প্রকারগুলিকে অসম্ভব করে তোলে (উদাহরণস্বরূপ, আপনি HIDL-এ লিঙ্কযুক্ত তালিকা বা গাছের বর্ণনা দিতে পারবেন না)। বেশিরভাগ বিদ্যমান (প্রি-অ্যান্ড্রয়েড 8.x) HAL-এর ফরোয়ার্ড ঘোষণার সীমিত ব্যবহার রয়েছে, যা ডেটা কাঠামো ঘোষণা পুনর্বিন্যাস করে সরানো যেতে পারে।

এই সীমাবদ্ধতা একটি স্ব-রেফারেন্সিয়াল ডেটা স্ট্রাকচারে একাধিকবার ঘটতে পারে এমন পয়েন্টার মানগুলির ট্র্যাক রাখার পরিবর্তে একটি সাধারণ ডিপ-কপির মাধ্যমে ডেটা স্ট্রাকচারগুলিকে কপি করার অনুমতি দেয়। যদি একই ডেটা দু'বার পাস করা হয়, যেমন দুটি পদ্ধতির প্যারামিটার বা vec<T> s যা একই ডেটা নির্দেশ করে, দুটি পৃথক কপি তৈরি করা হয় এবং বিতরণ করা হয়।

নেস্টেড ঘোষণা

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++ কাঁচা পয়েন্টারগুলির সম্পূর্ণ নমনীয়তা সমর্থন করে না। কিভাবে HIDL পয়েন্টার এবং অ্যারে/ভেক্টরকে এনক্যাপসুলেট করে তার বিস্তারিত জানার জন্য, vec<T> টেমপ্লেট দেখুন।

ইন্টারফেস

interface কীওয়ার্ডের দুটি ব্যবহার রয়েছে।

• এটি একটি .hal ফাইলে একটি ইন্টারফেসের সংজ্ঞা খোলে।
• এটি struct/ইউনিয়ন ক্ষেত্র, পদ্ধতি পরামিতি এবং রিটার্নে একটি বিশেষ প্রকার হিসাবে ব্যবহার করা যেতে পারে। এটিকে একটি সাধারণ ইন্টারফেস এবং 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 ইন্টারফেস জুড়ে একটি সিঙ্ক্রোনাইজড বা আনসিঙ্ক্রোনাইজড ফাস্ট মেসেজ কিউ (FMQ) বর্ণনাকারী পাস করে। বিস্তারিত জানার জন্য, HIDL C++ দেখুন (FMQs জাভাতে সমর্থিত নয়)।

মেমরি টাইপ

memory টাইপ HIDL-এ আনম্যাপ করা শেয়ার্ড মেমরি উপস্থাপন করতে ব্যবহৃত হয়। এটি শুধুমাত্র C++ এ সমর্থিত। এই ধরনের একটি মান একটি IMemory অবজেক্ট শুরু করার জন্য প্রাপ্তির প্রান্তে ব্যবহার করা যেতে পারে, মেমরি ম্যাপিং এবং এটি ব্যবহারযোগ্য করে তোলে। বিস্তারিত জানার জন্য, HIDL C++ দেখুন।

সতর্কতা: শেয়ার্ড মেমরিতে রাখা স্ট্রাকচার্ড ডেটা অবশ্যই এমন একটি প্রকার হতে হবে যার ফর্ম্যাট memory পাস করার ইন্টারফেস সংস্করণের আজীবনের জন্য কখনই পরিবর্তন হবে না৷ অন্যথায়, HALs মারাত্মক সামঞ্জস্যের সমস্যায় ভুগতে পারে।

পয়েন্টার টাইপ

pointer টাইপ শুধুমাত্র HIDL অভ্যন্তরীণ ব্যবহারের জন্য।

bitfield<T> টাইপ টেমপ্লেট

bitfield<T> যেখানে T একটি ব্যবহারকারী-সংজ্ঞায়িত enum প্রস্তাব করে যে মানটি T এ সংজ্ঞায়িত enum মানের একটি bitwise-OR। উত্পন্ন কোডে, 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 ব্যবহার করা পাঠককে অতিরিক্ত HAL তথ্য সরবরাহ করে, যারা এখন জানে যে setFlags পতাকার একটি বিটওয়াইজ-OR মান নেয় (অর্থাৎ জানে যে setFlags 16 দিয়ে কল করা অবৈধ)। bitfield ছাড়া, এই তথ্য শুধুমাত্র ডকুমেন্টেশনের মাধ্যমে জানানো হয়। উপরন্তু, VTS প্রকৃতপক্ষে পতাকার মান পতাকার বিটওয়াইজ-OR কিনা তা পরীক্ষা করতে পারে।

আদিম টাইপ হ্যান্ডেল

সতর্কতা: যেকোনো ধরনের ঠিকানা (এমনকি শারীরিক ডিভাইসের ঠিকানা) কখনই নেটিভ হ্যান্ডেলের অংশ হতে হবে না। প্রক্রিয়াগুলির মধ্যে এই তথ্যটি পাস করা বিপজ্জনক এবং তাদের আক্রমণের জন্য সংবেদনশীল করে তোলে। প্রসেসের মধ্যে পাস করা যেকোনো মান অবশ্যই একটি প্রক্রিয়ার মধ্যে বরাদ্দ করা মেমরি খোঁজার জন্য ব্যবহার করার আগে যাচাই করা উচিত। অন্যথায়, খারাপ হ্যান্ডেলগুলি খারাপ মেমরি অ্যাক্সেস বা মেমরি দুর্নীতির কারণ হতে পারে।

HIDL শব্দার্থবিদ্যা কপি-বাই-মান, যা বোঝায় যে প্যারামিটারগুলি অনুলিপি করা হয়েছে। ডেটার যে কোনও বড় টুকরো, বা ডেটা যা প্রক্রিয়াগুলির মধ্যে ভাগ করা দরকার (যেমন একটি সিঙ্ক বেড়া), স্থায়ী বস্তুর দিকে নির্দেশ করে ফাইল বর্ণনাকারীর চারপাশে পাস ashmem পরিচালনা করা হয়: শেয়ার করা মেমরি, প্রকৃত ফাইল বা অন্য কিছু যা পিছনে লুকিয়ে রাখতে পারে একটি ফাইল বর্ণনাকারী। বাইন্ডার ড্রাইভার অন্য প্রক্রিয়ায় ফাইল বর্ণনাকারীর নকল করে।

নেটিভ_হ্যান্ডেল_টি

অ্যান্ড্রয়েড 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 এবং ফাইল বর্ণনাকারীর একটি সংগ্রহ যা মান দ্বারা পাস করা হয়। একটি একক ফাইল বর্ণনাকারী একটি নেটিভ হ্যান্ডেলে কোনো ints এবং একটি একক ফাইল বর্ণনাকারী ছাড়াই সংরক্ষণ করা যেতে পারে। handle আদিম টাইপের সাথে এনক্যাপসুলেটেড নেটিভ হ্যান্ডেলগুলি ব্যবহার করে হ্যান্ডলগুলি পাস করা নিশ্চিত করে যে নেটিভ হ্যান্ডেলগুলি সরাসরি HIDL-এ অন্তর্ভুক্ত রয়েছে।

যেহেতু একটি native_handle_t পরিবর্তনশীল আকার রয়েছে, এটি সরাসরি একটি কাঠামোতে অন্তর্ভুক্ত করা যায় না। একটি হ্যান্ডেল ক্ষেত্র আলাদাভাবে বরাদ্দ করা native_handle_t তে একটি পয়েন্টার তৈরি করে।

অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলিতে, লিবকুটিলে উপস্থিত একই ফাংশনগুলি ব্যবহার করে নেটিভ হ্যান্ডেলগুলি তৈরি করা হয়েছিল। Android 8.0 এবং উচ্চতর সংস্করণে, এই ফাংশনগুলি এখন android::hardware::hidl নামস্থানে অনুলিপি করা হয়েছে বা NDK-এ সরানো হয়েছে। HIDL অটোজেনারেটেড কোড ব্যবহারকারী-লিখিত কোড থেকে জড়িত ছাড়াই এই ফাংশনগুলিকে স্বয়ংক্রিয়ভাবে সিরিয়ালাইজ এবং ডিসিরিয়ালাইজ করে।

হ্যান্ডেল এবং ফাইল বর্ণনাকারী মালিকানা

আপনি যখন একটি HIDL ইন্টারফেস পদ্ধতিকে কল করেন যা একটি hidl_handle অবজেক্ট পাস করে (বা ফেরত দেয়) (হয় শীর্ষ-স্তরের বা একটি যৌগিক প্রকারের অংশ), এতে থাকা ফাইল বর্ণনাকারীদের মালিকানা নিম্নরূপ:

• কলকারী একটি আর্গুমেন্ট হিসাবে একটি hidl_handle অবজেক্ট পাস করছে যা native_handle_t মোড়ানো ফাইলের বর্ণনাকারীর মালিকানা ধরে রাখে; কলারকে অবশ্যই এই ফাইল বর্ণনাকারীগুলি বন্ধ করতে হবে যখন এটি তাদের সাথে করা হয়।
• একটি hidl_handle অবজেক্ট ফেরত দেওয়ার প্রক্রিয়া (এটিকে একটি _cb ফাংশনে পাস করে) অবজেক্ট দ্বারা মোড়ানো native_handle_t তে থাকা ফাইল বর্ণনাকারীর মালিকানা বজায় রাখে; প্রক্রিয়াটি অবশ্যই এই ফাইল বর্ণনাকারীগুলিকে বন্ধ করতে হবে যখন এটি তাদের সাথে সম্পন্ন হয়।
• একটি ট্রান্সপোর্ট যা একটি hidl_handle গ্রহণ করে তার কাছে বস্তু দ্বারা আবৃত native_handle_t এর ভিতরে ফাইল বর্ণনাকারীর মালিকানা থাকে; লেনদেন কলব্যাকের সময় রিসিভার এই ফাইল বর্ণনাকারীগুলি ব্যবহার করতে পারে, তবে কলব্যাকের বাইরে ফাইল বর্ণনাকারীগুলি ব্যবহার করার জন্য নেটিভ হ্যান্ডেল ক্লোন করতে হবে। লেনদেন সম্পন্ন হলে ট্রান্সপোর্ট স্বয়ংক্রিয়ভাবে ফাইল বর্ণনাকারী close() হয়ে যাবে।

HIDL জাভাতে হ্যান্ডলগুলি সমর্থন করে না (যেহেতু জাভা হ্যান্ডেলগুলিকে সমর্থন করে না)।

আকারের অ্যারে

HIDL স্ট্রাকটে আকারের অ্যারেগুলির জন্য, তাদের উপাদানগুলি যে কোনও ধরণের হতে পারে একটি স্ট্রাকটে থাকতে পারে:

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

স্ট্রিংস

স্ট্রিংগুলি C++ এবং জাভাতে ভিন্নভাবে দেখা যায়, কিন্তু অন্তর্নিহিত পরিবহন স্টোরেজের ধরন হল একটি C++ কাঠামো। বিস্তারিত জানার জন্য, HIDL C++ ডেটা টাইপস বা HIDL Java ডেটা টাইপস দেখুন।

দ্রষ্টব্য: HIDL ইন্টারফেসের (জাভা থেকে জাভা সহ) মাধ্যমে জাভা থেকে বা জাভা থেকে একটি স্ট্রিং পাস করার ফলে অক্ষর সেট রূপান্তর ঘটবে যা আসল এনকোডিং ঠিকভাবে সংরক্ষণ করতে পারে না।

vec<T> টাইপ টেমপ্লেট

vec<T> টেমপ্লেট T এর দৃষ্টান্ত ধারণকারী একটি পরিবর্তনশীল-আকারের বাফার প্রতিনিধিত্ব করে।

T নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:

• আদিম প্রকার (যেমন uint32_t)
• স্ট্রিংস
• ব্যবহারকারী-সংজ্ঞায়িত enums
• ব্যবহারকারী-সংজ্ঞায়িত কাঠামো
• ইন্টারফেস, বা interface কীওয়ার্ড ( vec<IFoo> , vec<interface> শুধুমাত্র একটি শীর্ষ-স্তরের প্যারামিটার হিসাবে সমর্থিত)
• হ্যান্ডেল
• বিটফিল্ড<U>
• vec<U>, যেখানে ইউ ইন্টারফেস ছাড়া এই তালিকায় রয়েছে (যেমন vec<vec<IFoo>> সমর্থিত নয়)
• U[] (U এর আকারের অ্যারে), যেখানে ইউ ইন্টারফেস ছাড়া এই তালিকায় রয়েছে

ব্যবহারকারী-সংজ্ঞায়িত প্রকার

এই বিভাগে ব্যবহারকারী-সংজ্ঞায়িত প্রকার বর্ণনা করে।

এনাম

HIDL বেনামী enums সমর্থন করে না. অন্যথায়, HIDL-এর enums C++11-এর অনুরূপ:

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

HIDL-এর পূর্ণসংখ্যার ধরনগুলির মধ্যে একটির পরিপ্রেক্ষিতে একটি বেস enum সংজ্ঞায়িত করা হয়। যদি একটি পূর্ণসংখ্যার প্রকারের উপর ভিত্তি করে একটি enum-এর প্রথম গণনাকারীর জন্য কোনো মান নির্দিষ্ট করা না থাকে, তাহলে মানটি ডিফল্ট 0 হয়ে যায়। যদি পরবর্তী গণনাকারীর জন্য কোনো মান নির্দিষ্ট না করা হয়, তাহলে মানটি পূর্ববর্তী মান প্লাস ওয়ানের সাথে ডিফল্ট হয়। উদাহরণ স্বরূপ:

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

একটি enum পূর্বে সংজ্ঞায়িত enum থেকেও উত্তরাধিকার সূত্রে প্রাপ্ত হতে পারে। যদি একটি শিশু enum-এর প্রথম গণনাকারীর জন্য কোনো মান নির্দিষ্ট করা না থাকে (এই ক্ষেত্রে FullSpectrumColor ), এটি প্যারেন্ট enum প্লাস ওয়ানের শেষ গণনাকারীর মানকে ডিফল্ট করে। উদাহরণ স্বরূপ:

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

সতর্কতা: Enum উত্তরাধিকার বেশিরভাগ অন্যান্য ধরনের উত্তরাধিকার থেকে পিছনে কাজ করে। একটি শিশু enum মান একটি অভিভাবক enum মান হিসাবে ব্যবহার করা যাবে না. এটি কারণ একটি শিশু enum পিতামাতার চেয়ে বেশি মান অন্তর্ভুক্ত করে। যাইহোক, একটি প্যারেন্ট এনাম মান নিরাপদে চাইল্ড এনাম মান হিসাবে ব্যবহার করা যেতে পারে কারণ চাইল্ড এনাম মানগুলি সংজ্ঞা অনুসারে প্যারেন্ট এনাম মানগুলির একটি সুপারসেট। ইন্টারফেস ডিজাইন করার সময় এটি মনে রাখবেন কারণ এর অর্থ হল প্যারেন্ট enums উল্লেখ করা প্রকারগুলি আপনার ইন্টারফেসের পরবর্তী পুনরাবৃত্তিতে চাইল্ড enums উল্লেখ করতে পারে না।

এনামগুলির মানগুলি কোলন সিনট্যাক্সের সাথে উল্লেখ করা হয় (নেস্টেড প্রকার হিসাবে ডট সিনট্যাক্স নয়)। সিনট্যাক্স হল Type:VALUE_NAME । মানটি একই enum টাইপ বা চাইল্ড টাইপের ক্ষেত্রে উল্লেখ করা হলে টাইপ নির্দিষ্ট করার দরকার নেই। উদাহরণ:

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

অ্যান্ড্রয়েড 10 থেকে শুরু করে, enums-এর একটি len বৈশিষ্ট্য রয়েছে যা ধ্রুবক অভিব্যক্তিতে ব্যবহার করা যেতে পারে। MyEnum::len হল সেই গণনার মোট এন্ট্রির সংখ্যা। এটি মোট মানের থেকে আলাদা, যা মানগুলি সদৃশ হলে ছোট হতে পারে।

গঠন

HIDL বেনামী স্ট্রাকট সমর্থন করে না। অন্যথায়, এইচআইডিএল-এর স্ট্রাকটগুলি সি-এর মতো।

HIDL সম্পূর্ণরূপে একটি কাঠামোর মধ্যে থাকা পরিবর্তনশীল-দৈর্ঘ্যের ডেটা স্ট্রাকচারকে সমর্থন করে না। এর মধ্যে রয়েছে অনির্দিষ্ট-দৈর্ঘ্যের অ্যারে যা কখনও কখনও C/C++ এ একটি স্ট্রাকটের শেষ ক্ষেত্র হিসাবে ব্যবহৃত হয় (কখনও কখনও [0] এর আকারের সাথে দেখা যায়)। HIDL vec<T> একটি পৃথক বাফারে সংরক্ষিত ডেটা সহ গতিশীল আকারের অ্যারেগুলিকে উপস্থাপন করে; এই ধরনের উদাহরণগুলিকে struct এ vec<T> এর একটি উদাহরণ দিয়ে উপস্থাপন করা হয়।

একইভাবে, string একটি struct থাকতে পারে (সম্পর্কিত বাফারগুলি আলাদা)। জেনারেট করা C++-এ, HIDL হ্যান্ডেল টাইপের দৃষ্টান্তগুলি একটি পয়েন্টারের মাধ্যমে প্রকৃত নেটিভ হ্যান্ডেলে উপস্থাপন করা হয় কারণ অন্তর্নিহিত ডেটা টাইপের উদাহরণগুলি পরিবর্তনশীল-দৈর্ঘ্য।

মিলন

HIDL বেনামী ইউনিয়ন সমর্থন করে না। অন্যথায়, ইউনিয়নগুলি সি এর মতো।

ইউনিয়নে ফিক্স-আপ প্রকার (পয়েন্টার, ফাইল বর্ণনাকারী, বাইন্ডার অবজেক্ট ইত্যাদি) থাকতে পারে না। তাদের বিশেষ ক্ষেত্র বা সংশ্লিষ্ট প্রকারের প্রয়োজন নেই এবং শুধুমাত্র 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
  }