در استاندارد جدید ۲۳ گزینهٔ std::expected معرفی شده ‌است که اجازه می‌دهد خطاها را بهتر مدیریت کنیم.

مدیریت خطا در سی‌پلاس‌پلاس به وسیلهٔ بیانیه‌های try، catch و throw انجام می‌شود. این ویژگی به برنامه‌نویس این امکان را می‌دهد که خطاها را شناسایی کرده و به دسته‌بندی کرده و سپس به شکل مناسبی برخورد کند.
همچنین کلاس‌هایی مانند std::exception یک کلاس پایه در سی‌پلاس‌پلاس است که برای نمایش استثناء‌ها (خطاها) در هنگام اجرای برنامه استفاده می‌شود. این کلاس یک رابط عمومی به نام what دارد که متنی که توضیح خطا را حاوی می‌شود، به عنوان یک رشته C-style (const char*) باز می‌گرداند.

۱) این نوع داده به شما این امکان را می‌دهد که یک عدد بازگشتی معمولی (نتیجه موفقیت‌آمیز) یا یک کد خطا (نتیجه ناموفق) را با هم در یک متغیر ذخیره کنید.
۲) برای برنامه نویسانی که از این نوع داده استفاده می‌کنند، کد برنامه خواناتر و قابل‌فهم‌تر است.
۳) استفاده از std::expected معمولاً در جاهایی مناسب است که خطاها قابل پیش‌بینی و مدیریت شوند.

import <print>;
import <expected>;
 
enum class ErrorType { InvalidName, NotFound, OtherError };
 
auto getName(std::string name) -> std::expected<std::string, ErrorType>
{
    if (name != "Kambiz") {
        return std::unexpected(ErrorType::InvalidName);
    }
    return name;
}
 
auto main() -> int {
 
    auto result = getName("Compez");
 
    if (result.has_value()) {
        std::println("Result: {}", result.value());
    } else {
        ErrorType error = result.error();
        switch (error) {
        case ErrorType::InvalidName:
            std::println("Error: Invalid Name!");
            break;
        case ErrorType::NotFound:
            std::println("Error: Not Found!");
            break;
        case ErrorType::OtherError:
            std::println("Error: Other Error!");
            break;
        }
    }
 
    return 0;
}

در اینجا، یک تابع به نام getName تعریف شده است که یک نام به عنوان ورودی دریافت می‌کند و یک std::expected را باز می‌گرداند. اگر نام "Kambiz" نباشد، یک std::unexpected با ErrorType::InvalidName ایجاد می‌شود و اگر نام معتبر باشد، خود نام به عنوان مقدار بازگشتی استفاده می‌شود.

سپس در تابع main، ما از تابع getName برای دریافت نتیجه استفاده می‌کنیم. اگر نتیجه دارای مقدار باشد (با فراخوانی()has_value)، آن مقدار با استفاده از ()value چاپ می‌شود. اگر نتیجه دارای خطا باشد، ما با استفاده از ()error نوع خطا را دریافت کرده و با استفاده از یک switch به تصمیمات مرتبط با نوع خطا می‌رسیم و پیام مناسب چاپ می‌شود. توجه داشته باشید که در دسترسی به()error، ممکن است بعضی از پیاده‌سازی‌های expected به جای ()error از ()value برای دسترسی به خطا استفاده کنند.

به نظر می‌رسد این ویژگی می‌تواند به صورت چشم‌گیری روش مدیریت خطاها را بهبود سازد.

#cpp20 #cpp23 #expected #چالش #سی‌روزه #رمضان #روز_بیست_و_چهارم

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

تابع Fallback یک قابلیت مهم در قراردادهای هوشمند سالیدیتی است. هر قرارداد می‌تواند حداکثر یک تابع Fallback داشته باشد. این تابع با استفاده از کلیدواژه‌های ()fallback یا fallback(bytes calldata input) external [payable] تعریف می‌شود (هر دو بدون کلیدواژه function). این تابع باید دارای سطح دسترسی external باشد.

تابع Fallback در دو حالت اجرا می‌شود:
۱) عدم تطابق با سایر توابع: هنگامی که فراخوانی به قرارداد ارسال می‌شود اما هیچ یک از توابع دیگر با امضای تابع فراخوانی مطابقت ندارند، تابع Fallback اجرا می‌شود.
۲) عدم وجود داده: اگر اصلاً داده‌ای با تراکنش ارسال نشود و هیچ تابع receive Ether وجود نداشته باشد، تابع Fallback اجرا می‌شود.

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

contract Test {
    uint x;
    // This function is called for all messages sent to
    // this contract (there is no other function).
    // Sending Ether to this contract will cause an exception,
    // because the fallback function does not have the `payable`
    // modifier.
    fallback() external { x = 1; }
}

contract TestPayable {
    uint x;
    uint y;
    // This function is called for all messages sent to
    // this contract, except plain Ether transfers
    // (there is no other function except the receive function).
    // Any call with non-empty calldata to this contract will execute
    // the fallback function (even if Ether is sent along with the call).
    fallback() external payable { x = 1; y = msg.value; }

    // This function is called for plain Ether transfers, i.e.
    // for every call with empty calldata.
    receive() external payable { x = 2; y = msg.value; }
}

contract Caller {
    function callTest(Test test) public returns (bool) {
        (bool success,) = address(test).call(abi.encodeWithSignature("nonExistingFunction()"));
        require(success);
        // results in test.x becoming == 1.

        // address(test) will not allow to call ``send`` directly, since ``test`` has no payable
        // fallback function.
        // It has to be converted to the ``address payable`` type to even allow calling ``send`` on it.
        address payable testPayable = payable(address(test));

        // If someone sends Ether to that contract,
        // the transfer will fail, i.e. this returns false here.
        return testPayable.send(2 ether);
    }

    function callTestPayable(TestPayable test) public returns (bool) {
        (bool success,) = address(test).call(abi.encodeWithSignature("nonExistingFunction()"));
        require(success);
        // results in test.x becoming == 1 and test.y becoming 0.
        (success,) = address(test).call{value: 1}(abi.encodeWithSignature("nonExistingFunction()"));
        require(success);
        // results in test.x becoming == 1 and test.y becoming 1.

        // If someone sends Ether to that contract, the receive function in TestPayable will be called.
        // Since that function writes to storage, it takes more gas than is available with a
        // simple ``send`` or ``transfer``. Because of that, we have to use a low-level call.
        (success,) = address(test).call{value: 2 ether}("");
        require(success);
        // results in test.x becoming == 2 and test.y becoming 2 ether.

        return true;
    }
}

- یک تابع Fallback همیشه داده دریافت می‌کند، اما برای دریافت اتر (ETH) باید با payable علامت‌گذاری شود.
- در صورت استفاده از نسخه با پارامترها، input حاوی تمام داده‌های ارسال شده به قرارداد (معادل msg.data) خواهد بود و می‌تواند داده‌ای را در output برگرداند. داده برگشتی به صورت ABI رمزگذاری نخواهد شد.
- در بدترین حالت، اگر از یک تابع Fallback با قابلیت دریافت اتر (payable) به جای تابع receive استفاده شود، تنها می‌تواند روی ۲۳۰۰ واحد Gas تکیه کند.
- همانند هر تابع دیگری، تابع Fallback می‌تواند عملیات پیچیده‌ای را انجام دهد، به شرطی که Gas کافی برای آن تامین شود.

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

توی این مملکت به هیچ یک از تجاوز‌هایی که به مال و جان و زندگی و معیشت و در کل حق مردم میشه، واکنشی نمیدن! لام تا کام، کور و کر و لال هستن؛ اما نصف شب به زبان عِبری واکنش نشون میدن به اون سر مرز‌ها برای محو متجاوزین!!!

در همین حد همه چیز شفاف هست! 😉

سوأل این‌که کدوم زبان رو برای وب ۳ یاد بگیرم؟! قبلاً هم گفتم برای بک‌اند و زیر ساخت‌ها زبان‌های زیر:

- قطعاً ++C و Rust و Go

۱) بین این‌ها ++C از همشون مطمئن‌تر و خفن‌تره! مثال واقعی؟ پادشاه‌ ارز‌های دیجیتال سلطان بزرگ بیت‌کوین!
۲) خروجی واقعی از Go مثال بزنم؟ ملکهٔ ارز‌ها، اتریوم!
۳) در مورد راست مثال بزنم؟ شبکهٔ لایه L2 از اتریوم و زیرساخت‌های NFT!

برای لایه‌های بالاتر زبان‌های زیر:

- JavaScript/TypeScript

برای قرارداد‌نویسی بر روی بستر EVM:

- زبان برنامه‌نویسی سالیدیتی Solidity

زبان‌های دیگه هم کاربرد دارند، قبلاً هم گفتم SDK برای همشون وجود داره. اما پر کاربرد‌ترینشون همین‌ها هستن اما رابط‌های رسمی براشون وجود نداره مگر اینکه بشینی از صفر خودت یه چیزی سر هم کنی که بتونی یک نسخه از محصول dApp رو باهاش سازگار کنی.

پیشنهاد من چیه؟ حتی اگه هیچی نتونی یاد بگیری، JavaScript رو باید تو جعبه ابزارت داشته باشی! در غیر این صورت فرصت‌های زیادی رو در دنیای وب ۳ از دست خواهی داد.

یادگیری HTML/CSS هم که دیگه یادت نره این‌ها رو باید عین آب خوردن بلد باشی که الآن هرکسی سواد اینترنت داشته باشه اینارو بلده. 😐

با هر کدوم از ابزار‌ها بتونی بالاترین راندمان رو نشون بدی، اون ابزار مناسب هست.
اما در مورد سی++ قضیه خیلی متفاوته، چون کاربردش چند-منظوره هست. در همهٔ شاخه‌های مختلف می‌تونی ازش استفاده کنی؛ سخته! اما خب یک زبان کاملاً تخصصی و خفنه.

این گزینهٔ Purge Followers دنبال کننده‌هایی رو نشون میده که اسپم نیستند. یعنی کاربران فیلتر شده رو شمارش می‌کنه.

کاربرانی که غیر فعال نباشن، اسپمر نباشن و به هر نحوی رتبه‌های خوب و حساب با کیفیتی داشته باشن.

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

پیداش کردم! همین طرحم بود روی برد! 😍😎

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

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

هر دو حالت حمایتگری on-chain و off-chain باید ارائه بشه.
اما یک استثناء داریم، کسی که روی بلاک‌چین به صورت آنی از کسی حمایت می‌کنه، باید سهمیه ضریب‌دار بگیره.
به دو دلیل:

۱) تراکنش ایجاد می‌کنه، واقعیه! فیک نیست.
۲) در لحظه حمایت می‌کنه و ممکن نیست در زمان کلیم حمایت‌هاش سوخته باشه یا به بهانه بن بودن یا هر موضوعی شمارش نشده باشه.