מאמרים בנושא ‏C++‎‏‏.

Boost חסרת תועלת למפתחי ספריות

ב־יום שישי, 21 במאי 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, CppCMS, C++‎‏, Boost‏; ‏5 תגובות

Boost חסרת תועלת למפתחי הספריות, או ליתר דיוק מפתחי ספריות שמנסים לשמור על ABI יציב של הספריות שלהן. זהו שם הדיון שפתחתי ברשימת תפוצה של Boost שאני חושב שעוררה סערה קטנה בקרב המפתחים שלה. אני מאוד מקווה שזה יגרום לשינויים בתפיסה של Boost ובסופו של דבר יגרום ליצירת Boost-stable, או boost::abi.

רקע קצר: ספרית Boost היא אוסף ספריות C++‎ עשיר שנותן כלים מצוינים למפתחים. אפשר להשוואות אותה ל־JDK של Java שנותן לך כלים כמעט לכל דבר. בעיקר היא ממלא חורים רבים שחסרים בספרית C++‎ סטנדרטית: טבלאות hash, ביטויים רגולריים, מצביעים חכמים, תמיכה בחוטים (threads), ועוד ועוד ועוד.

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

למעשה, Boost היא ספריה המנוהלת כמדיניות ע"י דחפים אבולוציוניים משפרת את התכנון שלה כל הזמן, אפיל רכיבים יסודיים ביותר כמו boost::shared_ptr עוברים שיפורים משמעותיים. וכאן מתחילה בעיה:

  • כל שלושה חודשים משוחררת גרסה חדשה של Boost.
  • כל גרסה חדש אינה מבטיחה תאימות כלשהי הן של ABI ואפילו API.

בפועל זה גורם לכך ש:

  • רוב החברות שעובדות עם Boost בד"כ תקועות עם גרסה מיושנות כי מפחדים לשדרג אותה

  • ישנים מקרים רבים של טעויות בהן שתי ספריות צד ג' בנויות עם גרסאות שונות של Boost פשוט קורסות ברגע שהן עבדות באותה יחידה (קובץ ריצה).

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

העליתי את זה (בפעם העשירית אולי) ברשימת התפוצה של Boost. אבל נראה לי הפעם זה יצר הד מסוים וגם נראה לי שקיר ה"אי־הבנה" התחיל להישבר, לפחות הרגשתי את זה ממספר מפתחי Boost מרכזיים.

כך או אחרת, בגלל הבעיות האלה וצרכים קיומיים של CppCMS:

  • הסתרתי חלקי Boost שהייתי מוכרח להשתמש בהם תחת namespace חילופי.
  • יצרתי ספריה חלופית Booster‎ שבנויה עם API מאוד דומה ל־API של Boost אבל משתמשת ברכיבים אחרים: למשל, לתמיכה בביטויים רגולריים אני משתמש ב־PCRE ל־threadים אני משתמש ב־pthreads (גם בחלונות).
  • חלקים קריטיים כמו shared_ptr פשוט לקחתי מ־Boost והתאמתי ליציבות בינארית.
  • חלקים שכתבתי כמו booster::function.

בגדול כל דבר שהייתי משתמש בו והייתי זקוק לו ב־API הכנסתי ל־Booster מ־Boost בצורה כזו או אחרת.

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

מי שמעוניין יכול לקחת Booster מ־svn כאן:

https://cppcms.svn.sourceforge.net/svnroot/cppcms/framework/branches/refactoring/booster

אבל תהיו מודעים לעובדה ש־Booster איננה Boost, והיא נבנתה לצורכי CppCMS בלבד.

שוחררה Boost.Locale

ב־יום שבת, 13 במרץ 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, תכנה ומחשבים, C++‎‏, Unicode, Boost‏; ‏0 תגובות

שוחררה גרסה חדשה של הספריה שמיועדת ל־boost ‏‏Boost.Locale‏ (ראה הודעה ברשמת התפוצה של Boost‏):

הגרסה הזו מכילה את השיפורים הבאים:

  • תכנון מחדש של איטרטור גבולות (כלי המאפשר להפריד בין מילים, משפטים וכד').
  • התווספה תמיכה בעבודה עם תאריכים בלוחות שנה שונים כמו גרגוריאני (לועזי), עברי ואחרים. ראה דוגמה calendar.cpp‏ המדפיסה לוח שנה בהתאם ללוקל.
  • תיקוני באגים רבים.
  • תמיכה בפלטפורמות נוספות

ועוד.

הספרייה מספקת:

  • נורמליזציה של Unicode, טיפול נכון בשינוי case של מחרוזות.
  • מיון (collation) לפי 4 רמות unicode שונות.
  • טיפול אחיד בלוחות שנה שונים כמו, גרגוריאני (לועזי), עברי ואחרים
  • אנליזה של גבולות הטקסט (מילים, משפטים, תווים ועוד).
  • הדפסה של מספרים, תאריכים, ערכי כסף, איות מספרים ועוד.
  • פרמוט של מחרוזות המתאים ללוקליזציה ותרגום מחרוזות בעזרת מילונים של gettext.

  • תמיכה בקידודים שונים, utf-8/16/32 וקידודים אחרים כמו cp1255.

  • תיעוד: http://cppcms.sourceforge.net/boost_locale/html/index.html

  • הורדה: https://sourceforge.net/projects/cppcms/files/
  • מדריך מקיף: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html

חשוב לציין

  1. Boost.Locale איננה חלק רשמי של Boost (בינתיים) ובתקווה תהפוך לכזו.
  2. היא לא מממשת את רוב כלי Uniode בעצמה אלא לרוב עוטפת API של ICU בצורה ידידותית למפתח C++‎.

מחשבות על Boost.

ב־יום חמישי, 21 בינואר 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, C++‎‏, Boost‏; תגובה אחת

ספריית Boost היא אחת הספריות הגדולות של C++‎ הן מבחינת הגודל הפיזי והיקף הספריות והן מבחינת המרכיבים החשובים שהיא מספקת.

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

למעשה, המתכנת C++‎ המודרני שהתרגל לנוחות ש־Boost מספקת יתקשה לכתוב בלעדיה את הקוד.

כמובן שהיא לא הספרייה היחידה, גם כלים כמו Qt, GTKmm ואחרים מספקים כלים בהיקף דומה... אבל ל־Boost יש יתרון גדול: חלק מהכלים שקיימים היום ב־Boost כבר עברו כפי-שהם ל־STL החדש. למעשה, יש ערך מוסף לעבודה עם Boost: אם אתה רגיל לעבוד עם boost:function,‏ boost::bind, ‏boost::regex, ‏boost::thread אתה תמצא את עצמך יום אחד משתמש ב־std::function, ‏std::bind בצורה שקופה לחלוטין בלי תלות בספריית צד ג'.

אבל מה? בניגוד לספריית STL שבאה עם קומפיילר ומבטיחה לך תאימות לאחור ואפשרת לא לדאוג ומגרסאות... Boost היא לא כזו:

  • כל מספר חודשים יוצאת גרסה חדשה שלא תואמת לקודמת!
  • אתה יכול לצפות שאיזושהי גרסת Boost תסופק עם הפצת לינוקס, אבל אתה לא יודע איזו?

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

התכנה הייתה בשתי גרסאות (עם ifdefים): כזו שהשתמשה ב־Qt4 בלבד (וסיפקה GUI), וכזו שהשתמשה ב־Boost ולא סיפקה GUI.

היה לי קל מאוד לקמפל את התכנה שעבדה עם GUI ולשלוח למישהו אחר לבדיקה, כי לא היה לי אכפת איזו גרסת Qt4 מותקנת אצלו, כל עוד היא מספיק חדשה!

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

Boost היא ספרייה נהדרת. אבל, היא גורמת לי להתרחק ממנה יותר ויותר - כי יש פרויקטים שהיא פשוט לא רלוונטית עבורם בגלל שהיא שוברת API/ABI לעתים קרובות.

שוחררה גרסת 0.0.5 של CppCMS (ענף יציב)

ב־יום שני, 11 בינואר 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, אינטרנט, לינוקס, פיתוח, תכנה ומחשבים, CppCMS, C++‎‏; ‏2 תגובות

שוחררה גרסה חדשה של ענף יציב של CppCMS, שינויים:

תיקוני בעיות אבטחה:

  • נכתב מעקף לבעיה של ספריית CgiCC שהיה יכול לגרום ל־DoS.
  • תוקנה בעיה שהייתה עלולה לגרום להווצרות SID בעלי אנטרופיה נמוכה.

תיקוני באגים:

  • תוקן זמן חיים של ערכים "חשופים" בניהול מצב (sessions)
  • תוקן באג שמנע אפשרות עבודה ב־FastCGI/SCGI מעל TCP/IP
  • תוקנו בעיות בניה עם גרסאות Boost לא סטנדרטיות.
  • תוקנו בעיות ביצירת HTTP Status Headers לא נכונים במקרה של שגיאות.
  • תוקנו בעיות בניה עם גרסאות gcc שונות ועם קומפיילר של אינטל.

שיפורים:

  • שופרו זמני בעיות views בצורה משמעות.

למה להמציא גלגל מחדש זה לא תמיד עובד טוב

ב־יום חמישי, 12 בנובמבר 2009, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, C++‎‏, ‏CMake‏; ‏8 תגובות

לאחרונה אני מנסה להגר ל־CMake מ־autotools בפרויקט CppCMS בעיקר כדי להבטיח תמיכה טובה יותר בסביבת Windows ובפרט ב־MSVC מתישהו בעתיד.

עשיתי כבר הרבה עובדה והענף הניסיוני עבר ל־CMake. אפילו לא מעט אנשים ברשימת התפוצה התלהבו מהעובדה שהמערכת תעבוד על CMake... רבים חוץ ממני. אחרי שהתחלתי לעבוד אתה בצורה יותר עניינית הבנתי: היא באמת יותר מוצלחת בפיתוח ל־Windows מאשר autotools בעיקר בגלל שהיא קצת יותר גמישה בנושא ה־exports וכמובן התמיכה ב־MSVC.

אבל פה בערך נגמר היתרון. עכשיו אני אתלונן על דברים שמעצבנים אותי:

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

  1. ב־autotools הייתה הפרדה ברורה בין automake שמגדיר את מבנה הפרויקט לבין autoconf שמגדיר את קונפיגורציית הפלטפורמה. מצד אחד זה היה קצת מפריע אבל מצד שני זה היה מאוד נוח: הוספת קובץ חדש לא פרויקט לא דרשה הרצת configure מחדש מצד אחד, מצד שני כל שינוי בצורת הקונפיגורציה ביצע הרצת configure שלמה.

    לעומת זאת, CMake אף פעם לא מנקה את ה־Cache שלו (אלא אם אתה עושה את זה במפורש). מה שגורם לכך ששינויים בקונפיגורציה לא תמיד יבואו לידי ביטוי כי ב־cache שלו הוא זוכר משהו אחר (אולי בדיקה אחרת לא תקינה).

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

  2. מנגנון מעקב אחרי התלויות של CMake לא בודק את הקובץ config.h משמע... אם עשיתי שינויים בקונפיגורציה הקוד לא ייבנה מחדש. צריך להריץ make clean ו־make שוב! העיקר שיש להם cache חזק.

הרבה מגנונים הקיימים לוקים בחסר או לא מתוכננים היבט. לדוגמה:

  1. משהו מאוד פופולרי כמו AC_SEARCH_LIBS שמאפשר לך לבדוק אם פוקנציה מסוימת קיימת, אם כו אז אל תעשה דבר, חפש אותה בספריות. דוגמה קלאסית. pthreads, iconv, dlopen, socket שלפעמים מהווים חלק מהספרייה הסטנדרטית ולפעמים דורשים ספריות חיצוניות. אין פונקציונליות כזו בכלל.

  2. בדיקת sizeof היא בכלל פנינת CMake. יש לה מספר בעיות:

    • היא נעשית ע"י הרצת קוד מה שאומר היא לא תעבוד בקרוס־קומפילציה. כאשר ב־autotools עושים טריק מאוד יפה המאפשר לבצע בדיקה כזו ללא הרצת קוד אלא קומפילציה בלבד.
    • היא לא מאפשרת להוסיף header כך שלא ניתן לבדוק sizeof של טיפוסים הנמצאים ב־includes לא סטנדרטיים.
  3. אין פונקציונליות דומה ל־AC_ARG_ENABLE המאפשרת להציג רשימת הפרמטרים לקונפיגורציה והערות לגביהם -- קרי אין כלי כמו ‎./configure --help שמאוד עוזר בהרבה מקרים.

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

אני מקווה שיום אחד autotools ידעו לתמוך גם ב־MSVC בסה"כ זה לא אמור להיות מי יודע מה מסובך... ICU משתמשים ב־autotools יחד עם MSVC בצורה מוצלחת למידי (למעשה הבעיה היא אפילו לא automake ו־autoconf הם דווקא איכשהו עובדים עם הקומפיילר, (הוא מסתבר כן תומך בהרבה דגלונים הרגילים כמו "‎-o -I" ועוד) הבעיה היא בעיקר libtool.

במילים אחרות... אם אתם לא מתכוונים לתמוך ב־MSVC תתרחקו מ־CMake, אבל ממש תתרחקו ממנו.

העמוד הבא

העמוד הבא

דפים

נושאים