❓ اگه من نخوام کاری که توسعه‌دهنده می‌خواد رو انجام بدم چی؟
✅ پاسخ: خب، اصلاً لازم نیست تو ایردراپ شرکت کنی :)

❓ اگه شرکت کنم و سریع رمزارزو بفروشم یا عوضش کنم چی؟
✅ پاسخ: آزادی که این کارو بکنی، اما شاید توسعه‌دهنده‌های آینده دیگه بهت ایردراپ ندن چون می‌بینن فقط برای پول اومدی.

❓ یعنی باید رمزارزو نگه دارم و نفروشم؟
✅ پاسخ: نه الزاماً. توسعه‌دهنده‌ها مشخص می‌کنن که انتظار دارن شما چه کاری انجام بدین در ازای ایردراپ. برای هر پروژه متفاوته.

❓ این خیلی کنترل‌گرانه‌ست / مالیاتش دردسره / دنبال یه بهونه‌م که ناراحت بشم!
✅ پاسخ: خب، این کاملاً اختیاریه (opt-in) — اگه دوست نداری، شرکت نکن :)

پیشنهاد، منتظر باشیم و ببینیم اولین ایردراپ هفته بعدی چی هست تا بر مبنای اون بگم چه کار باید کنیم!
باید ببینیم کدوم توسعه‌دهنده‌ها قراره چه ایردراپی به واسطهٔ اون‌ها اختصاص پیدا کنه.

ادعاشون کمی گنگ هست اما به نظر میرسه خبرای خوبی در راهه.

چند تا نکته داره!
باز هم مثل همیشه تأکید می‌کنم، ذهنیت فارم رو بذارید کنار :)

نکتهٔ اصلی اینه هر فعالیت اسپم‌وار رو به شدت شناسایی و از دایرهٔ فعالیت حذفش خواهند کرد.

https://warpcast.com/dwr.eth/0x48b81243

طرف داره جر میده خودشو می‌گه پست‌ها وجزئیات کیفی مهمه برامون نه شرو ور‌هایی که بین خودتون رد و بلد می‌کنید.

اینجا داره تأکید می‌کنه که این توسعه‌دهنده‌ها هستن که مشخص می‌کنن به کی ایردراپ اختصاص داده بشه!

https://warpcast.com/dwr.eth/0x9b57529a

✅ این ایردراپ‌ها از طرف توسعه‌دهنده‌های داخل اکوسیستم هستن (نه یه ایردراپ عمومی برای همه).
✅ این ایردراپ‌ها هدف‌مند (targeted) هستن — یعنی توسعه‌دهنده‌ها خودشون تصمیم می‌گیرن که به چه حساب‌هایی ایردراپ بدن.
✅ در نهایت، تصمیم نهایی با خود توسعه‌دهنده‌ست که به کی ایردراپ بده و به کی نه.

یعنی اگه یه نفر فقط دنبال گرفتن جایزه باشه بدون مشارکت واقعی، ممکنه تو لیست ایردراپ‌های بعدی قرار نگیره. ولی اگه واقعاً مشارکت کنه، شانسش برای دریافت ایردراپ‌های بیشتر بیشتر می‌شه.

اینجا پرسیدن که از این دو فریم داره استفاده می‌کنه، آیا شامل امتیاز میشه؟

اون فریم WC Labels مال منه!

دن پاسخ داده همهٔ فریم‌ها! 😉 من چند‌تا فریم ساختم برای جامعه!؟ کم نیستن! پس همشونو حساب می‌کنیم! اما هنوز برام مبهمه و باید اختصاصی بپرسم شروط محاسباتیش بر چه مبنایی هست! آیا فقط استفاده یا ...

https://warpcast.com/dwr.eth/0x461a24e8

خلاصهٔ این پست تأکیدی

1️⃣ هدف ما اینه که تعداد کیف‌پول‌های موبایلی فعال و دارای موجودی رو افزایش بدیم—اون‌هایی که فقط با چند تا کلیک می‌تونن در فریم‌ها تراکنش انجام بدن.

2️⃣ حدود یک ماه گذشته و الان از مرز ۶۰,۰۰۰ کیف‌پول funded warplet عبور کردیم. به‌علاوه، ده‌ها هزار کیف‌پول موبایلی هم از طریق MWP (Mobile Wallet Provider) متصل شدن.

3️⃣ این یعنی فارکستر جذاب‌تر برای توسعه‌دهنده‌های آن‌چینی شده—چون حالا یه جامعهٔ واقعی وجود داره که می‌تونه از اپ‌های آن‌چین استفاده کنه و تراکنش انجام بده، اونم روی دستگاهی که بیشتر وقت آزادشون رو باهاش می‌گذرونن (ببخشید کاربران وفادار دسکتاپ 😄).

4️⃣ هرچی تعداد کیف‌پول‌های فعال موبایلی بیشتر بشه، فریم‌ها هم بیشتر می‌شن.
بیشتر شدن فریم‌ها یعنی محتوای خاص‌تر برای فارکستر؛ محتوای خاص‌تر یعنی کاربران دلیل بیشتری برای استفاده از فارکستر (علاوه بر سایر شبکه‌ها) دارن.
فریم‌ها + تجربهٔ ساده و خاص آن‌چینی روی موبایل؛ فارکستر مکمل خوبی برای بقیه‌ٔ شبکه‌ها می‌شه.

5️⃣ هرچی افراد بیشتر زمان صرف تست کردن فریم‌های جدید آن‌چینی بکنن، بیشتر احتمال داره که درگیر ویژگی‌های اجتماعی بشن (مثل ارسال cast).

🌾 کاشت، داشت، برداشت! 🌾
روی این جمله خیلی باید فکر کرد، همون جمله‌ایه که تو دوران مدرسه به هممون گفتن.

حالا تو ببین وقتی دنبال ایردراپ هستی توی این سه مرحله مشارکت داری یا نداری یا فقط به دنبال مرحلهٔ آخرشی؟! 😉

آدم سالم نیازی به آزار دیگران ندارد؛ تا وقتی کسی از درون در عذاب نباشد، برای بی‌رحمی کردن در حق دیگران انگیزهٔ کافی ندارد.

GM folks!

https://warpcast.com/compez.eth/0x0205b824

یعنی باید بشینی پشت سیستم و طبق دستورالعمل‌های فارکستر یه Mini-App طراحی کنی.

نیازمندی‌هاش چی هست و چه تخصص‌هایی لازم داره؟

۱) خلاق و بخش منطق مغزت باید خوب باشه.

۲) تخصص کافی و لازم در حوزهٔ نرم‌افزار داشته باشی، باید بدونی یک نرم‌افزار در سطوح و لایه‌های مختلف چطوری کار می‌کنه.

۳) برنامه‌نویس خوبی باشی و به حداقل زبان‌های برنامه‌نویسی JavaScript یا TypeScript تسلط کافی داشته باشی تا بتونی نقشهٔ ذهنیت رو باهاش بکشی! مثل مداد یا خودکار بهش نیاز داری.

۴) اگر همچین خاصیت‌هایی داشتی بعدش می‌تونی طبق این دستور‌العمل در فارکستر شروع کنی برای توسعه و یا ساخت و ساز.

از نظر من سادست؟ نه! امید واهی نمیدم که همه می‌تونن چون واقعاً تخصص لازم داره! من هم اگه می‌سازم بر مبنای سال‌ها تجربه و تخصصی هست که تو حوزهٔ مهندسی کامپیوتر و نرم‌افزار دارم.

اما از بیخ هم نمی‌گم نمیشه! اگه من تونستم خب شما هم می‌تونید، ولی باید توجه کنی که باید یک طراح و مهندس نرم‌افزار باشی. :)

سر نخ‌های پیشنهادی چیه؟
چطور میشه خیلی سریع به موضوعات مهم تخصص نرم‌افزار دسترسی داشت؟

قبلاً در این خصوص یه مقاله نوشته بودم مسائل خیلی بیشتری از این‌ها می‌تونه بهش اضافه بشه.

خلاصه‌ای از ملزومات و نقشهٔ راه ساخت و ساز محصول نرم‌افزاری

از نظر من حداقل مواردی که (به طور خیلی خیلی خلاصه و محدود) نیاز هست تا یک متخصص بتونه پاسخ‌گوی‌ تصمیم‌گیری نقشهٔ توسعهٔ یک محصول برای مشتری در ابعاد مختلف و سطوح متفاوت از حوزه‌های موجود در قالب اصولی باشه به صورت زیر هستند:

۱- آشنا مبانی کامپیوتر که امر طبیعیه (شامل درک و فهم مسائل و نحوهٔ حلشون متناسب با پلتفرم اجرایی محصول)
۲- آشنا به ساختار نوع محصول استاندارد در یک حوزه مثل: وب، آی‌او‌اس، اندروید یا دسکتاپ‌های مختلف مثل لینوکس، مک و ویندوز، اینترنت اشیاء و دیگر موارد.
۳- آشنا به فلسفهٔ بک‌اند و فرانت‌اند یا ترکیبی از این دو به همراه ابزار‌های مناسب.
۴- آشنا به اصول طراحی UI/UX به عنوان یک نیاز و یک فاکتور مهم در ساخت محصولی که وابسته به عملکرد کاربر داره و در حوزهٔ فرانت‌اند مهم و کاربردی هست.
۵- آشنا به اصول SOLID و امثالش مهم هستند.
۶- آشنا اصول برنامه‌ریزی ساخت بانک اطلاعاتی، اینکه از چه بانک اطلاعاتی‌ای استفاده کنی و چرا؟
۷- آشنا به ارتباطات داده‌ای، جداول و ارتباط بین فیلد‌ها، جدوال و روش‌های درست تبادل اطلاعات مابینی داده‌ها.
۸- آشنا و تسلط کافی به یک محیط توسعه و ادغام ابزار‌ها و محیط طراحی برای هدف.
۹- آشنا به معماری ساختار و رابط‌های برنامه‌نویسی (Api)
۱۰- آشنا به استاندارد‌های Http، درک و مدیریت درخواست، پاسخ‌ها و ...
۱۱- آشنا به الگو‌های طراحی برنامه‌نویسی (DP)
۱۲- آشنا به روش‌های نگه‌داری و آزمایش نرم‌افزار و کد‌ها به خصوص درک مبحث Fault tolerance.
۱۳- آشنا به روش‌های اطمینان‌سازی و ایمن‌سازی پردازش‌های داخلی نرم‌افزار برای جلوگیری یا دشوار سازی نفوز و خراب‌کاری
۱۴- آشنا به روش‌ها و معماری‌های احراز هویت و نحوهٔ ادغامش با نرم‌افزار مثل:JWT, OAuth, AWS و غیره...
۱۵- آشنا به نوع پارادایم‌های زبان برنامه‌نویسی، در قالب‌های (دستوری) Imperative و (اعلانی) Declarative مثل OOP، functional و دیگر موارد.
۱۶- آشنا به سبک معماری نرم‌افزاری (Microservice یا مثلاً Monolith) مزایا و معایبشون.
۱۷- آشنا به سبک معماری طراحی مانند MVC در طراحی بدنهٔ محصول.
۱۸- آشنا به سبک و الگو‌های طراحی ساختاری در بک‌اند مانند Builder، Abstract، Factory و غیره.
۱۹- آشنا به ساختار یک زبان (در صورتی که می‌خواین جوابگوی مسائلِ پیش آمده باشید) کالبد‌شکافی زیر‌پوستی و عمیق یک زبان مهمه.
۲۰- آشنا و درک کامپایلر‌ها و مفسر‌ها، تفاوت‌ها و شیوه‌های عملکردیشون نسبت به کد‌های بهینه شده و عادی.
۲۱- آشنا و درک مدل‌های مختلفی از سیستم‌های توزیع شده مثل IaaS، PaaS، SaaS یا FaaS.
۲۲- آشنا به ابزار‌های ساخت و فرآیند کاری اون‌ها مثل CMake، NMake، QMake و غیره.
۲۳- آشنا به روش‌های مدیریت وابستگی‌های نرم‌افزار و ابزار‌های لازم برای بسته‌بندی بهتر خروجی.
۲۴- آشنا به روش‌های کد‌نویسی قابل آزمایش (Unit Test) و استفاده از ابزار‌هایی مثل CTest, GTest, Catch2 و غیره.
۲۵- آشنا به توسعهٔ آزمون محور (Test Driven- Development)
۲۶- آشنا به گام‌ها و شرایط نسخه‌نگاری و مراحل توسعهٔ نرم‌افزار (SDP)
۲۷- آشنا به روش‌های امنیت در کد و توسعه به شیوه‌های بررسی از طریق Fuzz-Test، Sanitizer، آنالیزر‌های پویا و ایستا و غیره...
۲۸-آشنا به قوائد طراحی بر پایهٔ خدمات مبتدی بر معماری ابری برای خدمات پیامی، وب‌سرویس‌ها، پردازش و غیره.
۲۹- در سطوح وب آشنا به مکانیزم شاخص بندی، فاکتور‌های SEO و شیوه‌‌های درست بهبود صفحات وب.
۳۰- آشنا به روش‌های به کار گیری و پیاده‌سازی ثبت کننده‌ٔ وقایع در دل محصول و روش‌های بازخورد برای توسعهٔ بهتر به همراه مانیتورینگ، نظارت و تریسینگ.
۳۱- در شرایط لزوم آشنا به نحوهٔ به کار گیری و دلیل استفاده از فناوری‌هایی مثل Redis، Memcached و غیره.
۳۲- آشنا و درک صحیح از مفاهیم هم‌زمانی (Concurrency) و روش‌های به کار گیری آن نسبت به زبان برنامه‌نویسی و شرایط مناسب استفاده.
۳۳- آشنا به سبک و قوائد و ساختار زبان‌های برنامه‌نویسی و فرآیند ساخت و ترجمه.
۳۴- و تا صد‌ها گزینهٔ دیگه می‌تونم لیست کنم اینجا که اگه انتخابتون زبان‌های نزدیک به سیستم باشه این داستان در ادامهٔ این توضیحات سر به فلک می‌کشه نمونش کامپایلر‌ها خودشون شونصد جور مباحث دارند، پلتفرم‌ها ومعماری‌های پردازنده‌ای هم در این زبان‌ها مهمن و شما حتی تا عمق سیستم‌عامل و رابط‌های اون‌ها و نحوهٔ رفتارشون باید اطلاعات کافی داشته باشید که هر کدوم به نوبهٔ خودشون هزاران صفحه می‌شه راجع بهشون کتاب معرفی کرد.

این لیست چیزی بود که به زبان بسیار بسیار ساده شده و خیلی خلاصه به ذهنم رسید تا بدانید همچین هم الکی نیست ای عزیزانی که فتوا‌های صد من یه غاز میدین و این مسائل رو حل شده می‌دونید!

در ادامه اصل ماجرا خیلی فراتر از این‌ها هم هست که بخوای حساب کتاب کنی می‌بینی باید هفت خان رستم رو فتح کنی تا در تمامی سطوح پاسخگو باشی، این امر شدنی هست اما زمانی که شما محدود به یک موضوع باشید قطعاً درک همهٔ مسائل محدود و ناتوان در اجرای آن خواهید شد.

- وقتی می‌گم آشنا قطعاً در حد حروف الفبا کافی نیست، باید در حد نیاز تسلط و درک کافی ازشون وجود داشته باشه.

- همهٔ این‌ها رو باید در کمترین زمان ممکن نسبت به یک مشتری، محصول و نیاز تشخیص بدین و انتخاب کنید، به این کار می‌گن ارزیابی محصول بر اساس دانسته‌های فنی که تماماً متکی بر دانش و تجربهٔ شماست. (کارشناسی پروژه دقیقاً همین موضوع است).

- برای بهتر شدن و حرفه‌ای تر شدن هم باید فراتر از این‌ها پیش برید و در قالب «مثلث دانش» بهبودش بدهید.

- محصولات معتبر جهانی حاصلِ چنین نقشه‌های پیش‌بردی هستند و اصول تخصصی و مهندسی رو رعایت می‌کنن تا به یک درجهٔ کیفی موفق و زبان زد می‌رسند. شاید این مسائل از نظر یک برنامه‌نویس ساده و نه چندان با تجربه مهم نباشه، اما در سطح کیفی یک محصول نرم‌افزاری همهٔ این مسائل مهم تلقی می‌شوند.

به این تصویر دقت کن.

حالا اینو با دقت بخون...

دانستن این که وسعت و عمق دانشِ ما چقدر است بسیار مهمه، ما طبق همین اصول یک هرم نمایش از سطح دانش و نیاز‌های تکنیکی بر اساس «اصول معماری نرم‌افزار» (Software Architecture Fundamentals) داریم که به سه حالت ساده خلاصه می‌شه:

۱- چیز‌هایی که می‌دانیم.
۲- چیز‌هایی که می‌دانیم وجود دارند و در موردشان شنیده‌ایم، اما دانش عمیقی راجع به آن‌ها نداریم.
۳- چیز‌هایی که نمی‌دانیم که هستند و در موردشان چیزی نمی‌دانیم!

به طور خلاصه مواردی که در گزینهٔ اول هستند، شامل ابزار‌ها، زبان‌های برنامه‌نویسی، فریم‌ورک‌ها، کتابخانه‌های تحت فناوری هست که شما با اون‌ها آشنا هستید و در انجام کار‌های روزمره ازشون هم استفاده می‌کنید خیلی از افراد غیر متخصص همینطور هستند و گروه‌های تلگرامی و افراد بسیاری وجود داره که با ادعای گزینهٔ اول اصلاً در جریان گزینه‌های دوم و سوم قرار نمی‌گیرند و در همین تاریکی خودشون رو کامل می‌بینند و حتی صاحب نظر هم می‌دونن.

در گزینهٔ دوم، مواردی هستند که شما صرفاً در موردشون شنیده‌اید و تجربه‌ای به صورت واقعی و عملی باهاشون ندارید. برای مثال، یک برنامه‌نویس سی++ درسته که با هسته، نحو و کتابخانهٔ پیش‌فرض و شاید با کتابخانه‌های دیگر اون زبان کار می‌کنه، اما احتمال این که در بحث پردازش تصویر کار نکرده باشه وجود داره، اما با این حال در موردشون شنیده و میدونه چیز‌هایی هستند که در موردشون چیزی نمی‌دونه.

گزینهٔ سوم بیشترین دانش مورد نیازی هست که در وسیع‌ترین بخش از «مثلث دانش» مطرح می‌شه که خودش زیر ساخت‌های مربوط به همین زبان‌ها، ابزار‌ها، فریم‌ورک، سیستم‌عامل، سخت‌افزار و غیره هست که داشتن اطلاعات و دانش کافی در این باره به شما اجازه میده تا راه حل‌های بهتری برای حل مسئله پیدا کنید. چون در این سطح شما به بیشترین دانش دسترسی دارید و می‌تونید مسئله رو ارزیابی، راه حل‌ها رو پیشنهاد و اون رو به نتیجه برسونید. اما خب همه در این حد نیستند و حتی نمی‌دونن که همچین سطحی وجود داره و به خیال خودش مهم نیستند یا لازم نیستند.

بهتره بدونید یک توسعه‌دهنده برای اینکه بتونه تخصص، شغل و مهارتش رو حفظ کنه باید در مورد احتمالات، پیش‌بینی‌ها و به‌روز رسانی‌های لازم رو داشته باشه؛ به طور خلاصه اطلاعات و دانش قدیمی در صورتی که به‌روز رسانی نشوند برای نظرات قطعی و کافی بودن در به کار گیری یک شیوهٔ جدید ملاک نیستند و یک توسعه‌دهنده باید سعی کنه در بالاترین سطح از «مثلث دانش» خودش رو به‌روز نگه‌داره که گفتم شامل ابزار‌ها، زبان‌ها، شیوه‌ها و غیره هستند.

داده‌های برچسب‌گذاری فارکستر روی فریم به‌روز رسانی شد.

https://warpcast.com/compez.eth/0xe5adb6e2

ویژگی std::unreachable به عنوان یک ابزار پشتیبانی

قبل از هر چیز بهتر است بدانیم که در برنامه نویسی کامپیوتری، کدِ غیرقابل دسترسی، بخشی از کد منبع یک برنامه است که هرگز نمی‌تواند اجرا شود، زیرا هیچ مسیر کنترلی برای جریان کد از بقیه برنامه وجود ندارد. در سی‌پلاس‌پلاس نیز بعضاً در صورت نقض برخی از قوانین زبان، کل برنامه در مورد آن بخش بی‌معنی می‌شود. بنابراین ابزار std::unreachable که به عنوان گزینه‌ای در سرآیند (هدر) <utility> معرفی شده است وضعیت نامشخص را فرا می‌خواند.

هدف از به کارگیری این ویژگی:
- نشان دادن به کامپایلر که مسیر کد فعلی در شرایط عادی اجرای برنامه غیرقابل دسترس است.
- فعال کردن کامپایلر برای انجام بهینه‌سازی‌ها بر اساس این دانش (به عنوان مثال، حذف کد غیرقابل دسترس در ساخت‌های Release).
- ممکن است برای ابزارهای تحلیل ایستا (Static Analyzer) برای تشخیص خطاهای احتمالی یا کد مرده استفاده شود.
- مزیت این ویژگی برای استفاده در بهبود مدیریت خطا، دستورات سوئیچ و یا حلقه‌هاست.

فرض کنید تابعی داریم که یک عدد صحیح را به عنوان ورودی می‌گیرد و باید آن را بین ۰ و ۱۲۸ بررسی کند. اگر عدد خارج از این محدوده باشد، تابع باید یک خطا را به کاربر گزارش دهد.

import std;

void validateInput(int value)
{
    if (value < 0 || value > 128)
    {
        std::cerr << "Error: Value must be between 0 and 128.\n";
        std::unreachable();
    }
}

auto main() -> int {
    validateInput(128);
    validateInput(-128);
}

- وضوح کد، به وضوح نشان می‌دهد که کد بعد از std::unreachable غیرقابل دسترس است.
- بهینه‌سازی، به کامپایلر اجازه می‌دهد تا کد غیرقابل دسترس را حذف کند.
- تشخیص خطا، در صورت رسیدن به کد بعد از std::unreachable، نشان‌دهنده یک خطای منطقی در برنامه است.


#cpp20 #cpp23 #ub #unreachable #چالش #سی‌روزه #روز_دوازدهم

بخش تخصصی دوم (به‌روز رسانی Solidity) |ساختار (Struct)

در Solidity راهی برای تعریف انواع جدید در قالب ساختار ارائه می‌شود؛ یک ساختار یک نوع سفارشی تعریف شده است که به شما امکان می‌دهد گروهی از متغیرها را تحت یک نام واحد کپسوله کنید. این شبیه به ساختار در زبان های برنامه نویسی دیگر مانند C یا ++C است.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.6.0 <0.9.0;

// Defines a new type with two fields.
// Declaring a struct outside of a contract allows
// it to be shared by multiple contracts.
// Here, this is not really needed.
struct Funder {
    address addr;
    uint amount;
}

contract CrowdFunding {
    // Structs can also be defined inside contracts, which makes them
    // visible only there and in derived contracts.
    struct Campaign {
        address payable beneficiary;
        uint fundingGoal;
        uint numFunders;
        uint amount;
        mapping(uint => Funder) funders;
    }

    uint numCampaigns;
    mapping(uint => Campaign) campaigns;

    function newCampaign(address payable beneficiary, uint goal) public returns (uint campaignID) {
        campaignID = numCampaigns++; // campaignID is return variable
        // We cannot use "campaigns[campaignID] = Campaign(beneficiary, goal, 0, 0)"
        // because the right hand side creates a memory-struct "Campaign" that contains a mapping.
        Campaign storage c = campaigns[campaignID];
        c.beneficiary = beneficiary;
        c.fundingGoal = goal;
    }

    function contribute(uint campaignID) public payable {
        Campaign storage c = campaigns[campaignID];
        // Creates a new temporary memory struct, initialised with the given values
        // and copies it over to storage.
        // Note that you can also use Funder(msg.sender, msg.value) to initialise.
        c.funders[c.numFunders++] = Funder({addr: msg.sender, amount: msg.value});
        c.amount += msg.value;
    }

    function checkGoalReached(uint campaignID) public returns (bool reached) {
        Campaign storage c = campaigns[campaignID];
        if (c.amount < c.fundingGoal)
            return false;
        uint amount = c.amount;
        c.amount = 0;
        c.beneficiary.transfer(amount);
        return true;
    }
}

انواع ساختاری می‌توانند در داخل نگاشت‌ها (mappings) و آرایه‌ها استفاده شوند و خود ممکن است شامل نگاشت‌ها و آرایه‌هایی باشند.

ممکن نیست یک ساختار حاوی یک عضو از نوع خودش باشد، با این حال خود ساختار می‌تواند نوع مقدار عضوی از یک عضو نگاشت باشد یا ممکن است شامل یک آرایه با اندازه پویا از نوع خودش باشد. این محدودیت ضروری است، زیرا اندازهٔ ساختار باید محدود باشد. همچنین در تمام توابع، یک نوع ساختاری به یک متغیر محلی با مکانیت داده ذخیره می‌شود. این کار کپی کردن ساختار را انجام نمی‌دهد بلکه فقط یک مرجع را ذخیره می‌کند، به طوری که نسبت به اعضای متغیر محلی واقعی به وضوح نوشته شود.

البته، می‌توانید نیز به طور مستقیم به اعضای ساختار دسترسی داشته باشید بدون این که آن را به یک متغیر محلی اختصاص دهید، مانند

campaigns[campaignID].amount = 0

#solidity #web3 #update #ether #اتریوم

ابزار کمکی std::to_underlying در C++23

در استاندارد ۲۳، تابع std::to_underlying برای تبدیل مقادیر شمارشی به نوع پایه ای آنها معرفی شده است. این تابع می‌تواند برای تبدیل انواع شمارشی مانند enum و enum class به نوع پایه‌ای آنها مانند int یا unsigned int استفاده شود.

برای مثال، فرض کنید می‌خواهیم مقدار Color::Green در شمارنده را به عنوان یک عدد صحیح ۸ بیتی ذخیره کنیم. در این صورت می‌توانیم از تابع std::to_underlying برای تبدیل Color::Green به نوع std::uint8_t استفاده کنیم:

import std;

enum class Color : std::uint8_t {
    Red = 0,
    Green = 1,
    Blue = 2
};

auto main() -> int {

    std::uint8_t colorIndex = std::to_underlying(Color::Green);
    std::println("Color Index:{}", colorIndex);

}

از مزایای این ویژگی می‌تواند به افزایش خوانایی کد، جلوگیری از خطاهای تبدیل و افزایش کارآیی کد اشاره کرد.

#cpp20 #cpp23 #to_underlying #چالش #سی‌روزه #روز_سیزدهم