C++ רוסיה: איך זה קרה

אם בתחילת ההצגה אתה אומר שיש קוד C++ תלוי על הקיר, אז עד הסוף הוא חייב לירות לך ברגל.

ביארנה שטרוסטרופ

בין ה-31 באוקטובר ל-1 בנובמבר, התקיים בסנט פטרסבורג כנס C++ Russia Piter - אחד מכנסי התכנות רחבי ההיקף ברוסיה, שאורגן על ידי JUG Ru Group. בין הדוברים שהוזמנו נמנים חברי ועדת התקנים של C++, דוברי CppCon, מחברי ספרי O'Reilly ומנהלי פרויקטים כגון LLVM, libc++ ו-Boost. הכנס מיועד למפתחי C++ מנוסים שרוצים להעמיק את המומחיות שלהם ולהחליף חוויות בתקשורת חיה. סטודנטים, סטודנטים לתארים מתקדמים ומורים באוניברסיטאות ניתנות להנחות יפות מאוד.

מהדורת מוסקבה של הכנס תהיה זמינה לביקור כבר באפריל בשנה הבאה, אבל בינתיים התלמידים שלנו יספרו לכם אילו דברים מעניינים הם למדו באירוע האחרון. 

תמונה מ אלבום ועידה

אודות

שני סטודנטים מבית הספר הגבוה לכלכלה של אוניברסיטת המחקר הלאומי - סנט פטרסבורג עבדו על הפוסט הזה:

• ליזה וסילנקו היא סטודנטית שנה רביעית לתואר ראשון שלומדת שפות תכנות במסגרת התוכנית למתמטיקה שימושית ומדעי המחשב. לאחר שהתוודעתי לשפת C++ בשנה הראשונה שלי באוניברסיטה, לאחר מכן צברתי ניסיון בעבודה איתה דרך התמחויות בתעשייה. התשוקה שלי לשפות תכנות בכלל ולתכנות פונקציונליות בפרט הטביעה את חותמה על מבחר הדוחות בכנס.
• דניה סמירנוב היא סטודנטית שנה א' בתכנית לתואר שני "תכנות וניתוח נתונים". עוד בבית הספר, כתבתי בעיות אולימפיאדה ב-C++, ואז איכשהו קרה שהשפה עלתה כל הזמן בפעילויות חינוכיות ובסופו של דבר הפכה לשפת העבודה העיקרית. החלטתי להשתתף בכנס כדי לשפר את הידע שלי וגם ללמוד על הזדמנויות חדשות.

בניוזלטר, הנהגת הפקולטה משתפת לעתים קרובות מידע על אירועים חינוכיים הקשורים למומחיות שלנו. בספטמבר ראינו מידע על C++ Russia והחלטנו להירשם כמאזינים. זה הניסיון הראשון שלנו בהשתתפות בכנסים כאלה.

מבנה הכנס

• דיווחים

במהלך יומיים, מומחים קראו 30 דוחות, המכסים נושאים חמים רבים: שימושים גאוניים בתכונות שפה לפתרון בעיות יישומיות, עדכוני שפה קרובים בקשר לתקן החדש, פשרות בעיצוב C++ ואמצעי זהירות בעבודה עם ההשלכות שלהם, דוגמאות של ארכיטקטורת פרויקטים מעניינת, כמו גם כמה פרטים מתחת למכסה המנוע של תשתית השפה. שלוש הופעות התקיימו בו זמנית, לרוב שתיים ברוסית ואחת באנגלית.

• אזורי דיון

לאחר הנאום הועברו כל השאלות שלא נשאלו והדיונים שלא הסתיימו לאזורים ייעודיים במיוחד לתקשורת עם הדוברים, מצוידים בלוחות סימון. דרך טובה להרחיק את ההפסקה בין הנאומים בשיחה נעימה.

• שיחות ברק ודיונים לא רשמיים

אם תרצו לתת דיווח קצר, תוכלו להירשם בלוח הלבן לשיחת הברק בערב ולקבל חמש דקות של זמן לדבר על כל דבר בנושא הכנס. לדוגמה, היכרות מהירה עם חומרי חיטוי עבור C++ (עבור חלק זה היה חדש) או סיפור על באג ביצירת גלי סינוס שניתן לשמוע אך לא לראות.

פורמט נוסף הוא דיון הפאנל "עם ועדת לב אל לב". על הבמה כמה מחברי ועדת התקינה, על המקרן אח (רשמית - כדי ליצור אווירה כנה, אבל הסיבה "כי הכל עולה באש" נראה מצחיק יותר), שאלות על התקן והחזון הכללי של C++ , בלי דיונים טכניים סוערים והוליוור. התברר שבוועדה יש ​​גם אנשים חיים שאולי לא בטוחים במשהו לגמרי או אולי לא יודעים משהו.

עבור חובבי ההוליבר, האירוע השלישי נשאר על המקרה - מפגש ה-BOF "Go vs. C++". אנחנו לוקחים חובב Go, חובב C++, לפני תחילת המפגש הם מכינים יחד 100500 שקופיות בנושא (כמו בעיות בחבילות ב-C++ או היעדר גנריות ב-Go), ואז הם מנהלים דיון ער בינם לבין עצמם. עם הקהל, והקהל מנסה להבין שתי נקודות מבט בבת אחת. אם הוליבר מתחיל מחוץ להקשר, המנחה מתערב ומפייס את הצדדים. הפורמט הזה ממכר: מספר שעות לאחר ההתחלה, רק מחצית מהשקופיות הושלמו. היה צריך להאיץ מאוד את הסיום.

• שותף עומד

שותפי הכנס היו מיוצגים באולמות - בדוכנים שוחחו על פרויקטים שוטפים, הציעו התמחות ותעסוקה, ערכו חידונים ותחרויות קטנות וגם הגרלו פרסים יפים. יחד עם זאת, חלק מהחברות אף הציעו לעבור את השלבים הראשוניים של הראיונות, מה שיכול להועיל למי שבא לא רק להאזין לדיווחים.

פרטים טכניים של הדוחות

הקשבנו לדיווחים בשני הימים. לפעמים היה קשה לבחור דו"ח אחד מבין המקבילים - הסכמנו להתפצל ולהחליף את הידע שנצבר בהפסקות. ולמרות זאת, נראה שהרבה נותר בחוץ. כאן ברצוננו לדבר על התוכן של כמה מהדוחות שמצאנו הכי מעניינים

חריגים ב-C++ דרך הפריזמה של אופטימיזציות מהדר, Roman Rusyaev

החלק מ מצגות

כפי שהכותרת מרמזת, רומן הסתכל על עבודה עם חריגים באמצעות LLVM כדוגמה. יחד עם זאת, עבור אלה שאינם משתמשים ב-Clang בעבודתם, הדוח עדיין יכול לתת מושג כלשהו כיצד ניתן לבצע אופטימיזציה של הקוד. הסיבה לכך היא שהמפתחים של מהדרים וספריות סטנדרטיות מתאימות מתקשרים זה עם זה ופתרונות מוצלחים רבים יכולים לחפף.

לכן, כדי לטפל בחריג, אתה צריך לעשות הרבה דברים: לקרוא לקוד הטיפול (אם יש) או למשאבים בחינם ברמה הנוכחית ולהפוך את הערימה גבוה יותר. כל זה מוביל לעובדה שהמהדר מוסיף הוראות נוספות לקריאות שעלולות לזרוק חריגים. לכן, אם החריג לא יועלה בפועל, התוכנית עדיין תבצע פעולות מיותרות. על מנת להפחית איכשהו את התקורה, ל-LLVM יש מספר היוריסטיות לקביעת מצבים שבהם אין צורך להוסיף קוד טיפול בחריג או שניתן להפחית את מספר ההוראות ה"נוספות".

הדובר בוחן כתריסר מהם ומראה הן מצבים שבהם הם עוזרים להאיץ את ביצוע התוכנית, והן את אלו שבהם שיטות אלו אינן ישימות.

לפיכך, Roman Rusyaev מוביל את התלמידים למסקנה שלא תמיד ניתן לבצע קוד המכיל טיפול בחריגים ללא תקורה, ונותן את העצה הבאה:

• כאשר מפתחים ספריות, כדאי לזנוח חריגים באופן עקרוני;
• אם עדיין יש צורך בחריגים, אז בכל פעם שאפשר כדאי להוסיף noexcept (ו-const) modifiers בכל מקום כדי שהמהדר יוכל לבצע אופטימיזציה כמה שיותר.

באופן כללי, הדובר אישר את הדעה שעדיף להשתמש בחריגים למינימום או לנטוש אותם לגמרי.

שקופיות הדוח זמינות בקישור הבא: ["חריגים ב-C++ דרך העדשה של אופטימיזציות מהדר של LLVM"]

גנרטורים, קורוטינות ועוד מתיקות מגלגלת מוח, עדי שביט

החלק מ מצגות

אחד מהדיווחים הרבים בכנס זה שהוקדש לחידושים ב-C++20 היה בלתי נשכח לא רק בזכות ההצגה הצבעונית שלו, אלא גם בזכות הזיהוי הברור של בעיות קיימות בלוגיקת עיבוד האיסוף (ללולאה, התקשרות חוזרת).

עדי שביט מדגישה את הדברים הבאים: השיטות הקיימות כיום עוברות את כל האוסף ואינן מספקות גישה למצב ביניים פנימי כלשהו (או שכן במקרה של התקשרות חוזרת, אך עם מספר רב של תופעות לוואי לא נעימות, כמו Callback Hell) . נראה שיש איטרטורים, אבל גם איתם הכל לא כל כך חלק: אין נקודות כניסה ויציאה משותפות (התחלה → סוף מול rbegin → rend וכן הלאה), לא ברור כמה זמן נחזור? החל מ-C++20, בעיות אלו נפתרות!

אפשרות ראשונה: טווחים. על ידי גלישת איטרטורים, אנו מקבלים ממשק משותף להתחלה ולסיום של איטרציה, ומקבלים גם את היכולת להלחין. כל זה מקל על בניית צינורות עיבוד נתונים מלאים. אבל לא הכל כל כך חלק: חלק מהלוגיקה החישובית ממוקם בתוך היישום של איטרטור ספציפי, מה שיכול לסבך את הקוד להבנה וניפוי באגים.

החלק מ מצגות

ובכן, למקרה זה, C++20 הוסיפו קורוטינים (פונקציות שהתנהגותן דומה למחוללים ב-Python): ניתן לדחות את הביצוע על ידי החזרת ערך נוכחי כלשהו תוך שמירה על מצב ביניים. לפיכך, אנו משיגים לא רק עבודה עם נתונים כפי שהם מופיעים, אלא גם לכלול את כל ההיגיון בתוך קורוטינה ספציפית.

אבל יש זבוב במשחה: כרגע הם נתמכים רק חלקית על ידי מהדרים קיימים, וגם לא מיושמים בצורה מסודרת כמו שהיינו רוצים: למשל, עדיין לא כדאי להשתמש ברפרנסים ובאובייקטים זמניים בקורוטינות. בנוסף, יש כמה הגבלות על מה שיכול להיות קורוטינים, ופונקציות constexpr, בנאים/הורסים ו-main אינם כלולים ברשימה זו.

לפיכך, קורוטינים פותרים חלק נכבד מהבעיות בפשטות ההיגיון של עיבוד הנתונים, אך היישום הנוכחי שלהם דורש שיפור.

חומרים:

• שקופיות מ-C++ רוסיה - ["גנרטורים, קורוטינים ועוד מתיקות מגלגלת מוח"]
• הקלטת וידאו של הדו"ח מ-CppCon 2019

C++ טריקים מ-Yandex.Taxi, Anton Polukhin

בפעילות המקצועית שלי, לפעמים אני צריך ליישם דברים עזר גרידא: מעטפת בין הממשק הפנימי ל-API של ספרייה כלשהי, רישום או ניתוח. במקרה זה, בדרך כלל אין צורך באופטימיזציה נוספת. אבל מה אם רכיבים אלה משמשים בכמה מהשירותים הפופולריים ביותר ב-RuNet? במצב כזה, תצטרכו לעבד טרה-בייט לשעה של יומנים בלבד! ואז כל אלפית השנייה נחשבת ולכן אתה צריך לנקוט בטריקים שונים - אנטון פולוכין דיבר עליהם.

אולי הדוגמה המעניינת ביותר הייתה היישום של תבנית המצביע ליישום (pimpl). 

#include <third_party/json.hpp> //PROBLEMS! 
struct Value { 
    Value() = default; 
    Value(Value&& other) = default; 
    Value& operator=(Value&& other) = default; 
    ~Value() = default; 

    std::size_t Size() const { return data_.size(); } 

private: 
    third_party::Json data_; 
};

בדוגמה זו, תחילה אני רוצה להיפטר מקבצי הכותרות של ספריות חיצוניות - זה יקמפל מהר יותר, ותוכל להגן על עצמך מפני התנגשויות שמות אפשריות ושגיאות דומות אחרות. 

אוקיי, העברנו את #include לקובץ .cpp: אנו זקוקים להצהרה קדימה של ה-API העטוף, כמו גם std::unique_ptr. עכשיו יש לנו הקצאות דינמיות ודברים לא נעימים אחרים כמו נתונים מפוזרים על פני חבורה של נתונים וערבויות מופחתות. std::aligned_storage יכול לעזור בכל זה. 

struct Value { 
// ... 
private: 
    using JsonNative = third_party::Json; 
    const JsonNative* Ptr() const noexcept; 
    JsonNative* Ptr() noexcept; 

    constexpr std::size_t kImplSize = 32; 
    constexpr std::size_t kImplAlign = 8; 
    std::aligned_storage_t<kImplSize, kImplAlign> data_; 
};

הבעיה היחידה: אתה צריך לציין את הגודל והיישור עבור כל עטיפה - בואו נעשה את תבנית הפצעונים שלנו עם פרמטרים , השתמש בכמה ערכים שרירותיים והוסף בדיקה למחסל שהבנו הכל נכון: 

~FastPimpl() noexcept { 
    validate<sizeof(T), alignof(T)>(); 
    Ptr()->~T(); 
}

template <std::size_t ActualSize, std::size_t ActualAlignment>
static void validate() noexcept { 
    static_assert(
        Size == ActualSize, 
        "Size and sizeof(T) mismatch"
    ); 
    static_assert(
        Alignment == ActualAlignment, 
        "Alignment and alignof(T) mismatch"
    ); 
}

מכיוון ש-T כבר מוגדר בעת עיבוד ההרס, קוד זה ינותח בצורה נכונה ובשלב הקומפילציה הוא יוציא את ערכי הגודל והיישור הנדרשים שיש להזין כשגיאות. כך, בעלות של ריצת קומפילציה אחת נוספת, אנחנו נפטרים מההקצאה הדינמית של מחלקות עטופות, מסתירים את ה-API בקובץ .cpp עם המימוש, וגם מקבלים עיצוב שמתאים יותר ל-caching על ידי המעבד.

רישום וניתוח נראו פחות מרשימים ולכן לא יוזכרו בסקירה זו.

שקופיות הדוח זמינות בקישור הבא: ["טריקים של C++ ממונית"]

טכניקות מודרניות לשמירה על הקוד שלך יבש, Björn Fahler

בהרצאה זו, Björn Fahler מראה כמה דרכים שונות להילחם בפגם הסגנוני של בדיקות מצב חוזרות ונשנות:

assert(a == IDLE || a == CONNECTED || a == DISCONNECTED);

נשמע מוכר? על ידי שימוש במספר טכניקות C++ חזקות שהוצגו בתקנים האחרונים, אתה יכול ליישם באלגנטיות את אותה פונקציונליות ללא כל עונש ביצוע. לְהַשְׁווֹת:   

assert(a == any_of(IDLE, CONNECTED, DISCONNECTED));

כדי לטפל במספר לא קבוע של צ'קים, עליך מיד להשתמש בתבניות וריאדיות ובביטויי קיפול. נניח שאנו רוצים לבדוק את השוויון של מספר משתנים לאלמנט state_type של ה-enum. הדבר הראשון שעולה על הדעת הוא לכתוב פונקציית עוזר הוא_כל_מה:

enum state_type { IDLE, CONNECTED, DISCONNECTED };

template <typename ... Ts>
bool is_any_of(state_type s, const Ts& ... ts) { 
    return ((s == ts) || ...); 
}

תוצאת הביניים הזו מאכזבת. עד כה הקוד לא הופך להיות קריא יותר:

assert(is_any_of(state, IDLE, DISCONNECTING, DISCONNECTED)); 

פרמטרים שאינם מסוג תבנית יעזרו לשפר מעט את המצב. בעזרתם, נעביר את הרכיבים הספורים של ה-enum לרשימת הפרמטרים של התבנית: 

template <state_type ... states>
bool is_any_of(state_type t) { 
    return ((t == states) | ...); 
}
	
assert(is_any_of<IDLE, DISCONNECTING, DISCONNECTED>(state)); 

על ידי שימוש באוטו בפרמטר של תבנית לא-טיפוס (C++17), הגישה פשוט מכליל להשוואות לא רק עם רכיבי state_type, אלא גם עם טיפוסים פרימיטיביים שיכולים לשמש כפרמטרים לא-טיפוסים:

template <auto ... alternatives, typename T>
bool is_any_of(const T& t) {
    return ((t == alternatives) | ...);
}

באמצעות שיפורים עוקבים אלה, מושג התחביר השוטף הרצוי עבור המחאות:

template <class ... Ts>
struct any_of : private std::tuple<Ts ...> { 
// поленимся и унаследуем конструкторы от tuple 
        using std::tuple<Ts ...>::tuple;
        template <typename T>
        bool operator ==(const T& t) const {
                return std::apply(
                        [&t](const auto& ... ts) {
                                return ((ts == t) || ...);
                        },
                        static_cast<const std::tuple<Ts ...>&>(*this));
        }
};

template <class ... Ts>
any_of(Ts ...) -> any_of<Ts ... >;
 
assert(any_of(IDLE, DISCONNECTING, DISCONNECTED) == state);

בדוגמה זו, מדריך הניכוי משמש להציע את פרמטרי תבנית המבנה הרצויים לקומפיילר, אשר מכיר את סוגי הארגומנטים של הבנאי. 

בהמשך - יותר מעניין. ביורן מלמד כיצד להכליל את הקוד המתקבל עבור אופרטורי השוואה מעבר ל==, ולאחר מכן עבור פעולות שרירותיות. לאורך הדרך, תכונות כגון תכונת no_unique_address (C++20) ופרמטרים של תבנית בפונקציות למבדה (C++20) מוסברות באמצעות דוגמאות לשימוש. (כן, עכשיו קל יותר לזכור את תחביר הלמבדה - אלה ארבעה זוגות עוקבים של סוגריים מכל הסוגים.) הפתרון הסופי באמצעות פונקציות כפרטי קונסטרוקטור ממש מחמם את נשמתי, שלא לדבר על הביטוי tuple במיטב המסורות של הלמבדה חֶשְׁבּוֹן.

בסוף, אל תשכח ללטש אותו:

• זכור כי למבדות הן constexpr בחינם; 
• בואו נוסיף העברה מושלמת ונסתכל על התחביר המכוער שלו ביחס לחבילת הפרמטרים בסגירת הלמבדה;
• בואו ניתן למהדר הזדמנויות נוספות לאופטימיזציות עם noexcept מותנה; 
• בואו נדאג לפלט שגיאות מובן יותר בתבניות הודות לערכי החזר מפורשים של למבדות. זה יאלץ את המהדר לבצע בדיקות נוספות לפני שפונקציית התבנית תיקרא בפועל - בשלב בדיקת הסוג. 

לפרטים נא לעיין בחומרי ההרצאה: 

• דווח על שקופיות: [טכניקות מודרניות לשמירה על הקוד שלך יבש]
• קוד מקור ב-github
• מאמר הבלוג של המחבר

ההתרשמות שלנו

ההשתתפות הראשונה שלנו ב-C++ Russia הייתה בלתי נשכחת בזכות עוצמתה. התרשמתי מ-C++ Russia כאירוע כנה, שבו הגבול בין אימון לתקשורת חיה כמעט ולא מורגש. הכל, ממצב הרוח של הדוברים ועד לתחרויות של השותפים לאירוע, מוביל לדיונים סוערים. תוכן הכנס, המורכב מדוחות, מכסה מגוון רחב למדי של נושאים כולל חידושי C++, תיאורי מקרה של פרויקטים גדולים ושיקולים אדריכליים אידיאולוגיים. אבל זה יהיה לא הוגן להתעלם מהמרכיב החברתי של האירוע, שעוזר להתגבר על מחסומי שפה ביחס לא רק ל-C++.

אנו מודים למארגני הכנס על ההזדמנות להשתתף באירוע שכזה!
אולי ראיתם את הפוסט של המארגנים על העבר, ההווה והעתיד של C++ Russia בבלוג JUG Ru.

תודה שקראתם, ואנו מקווים שהספר מחדש שלנו על אירועים היה מועיל!

מקור: www.habr.com