דברים שלא נאמרים על Boost.

ב־20.5.2009, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, פיתוח, תכנה ומחשבים; ‏3 תגובות

או ליתר דיוק, לא מודגשים לגביו.

http://boost.org היא אחת הספריות הפופולריות ביותר ב־C++‎, היא מהווה ל־C++‎ מה ש־JDK מהווה ל־Java, מה ש־RTL ו־‏FCL מהווים ל־FreePascal, היא מה ש־Python Standard Library מהווה ל־Python.

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

  • תמיכה ב־Threads.
  • עבודה עם socketים.
  • כלי עיבוד טקסט.
  • ביטויים רגולריים.
  • עבודה עם זיכרון משותף.
  • ועוד.

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

יחס עם זו. יש לה חיסרון אחד עצום שבמקרים רבים לא מורגש ע"י מפתחי יישומים, אבל כן מורגש ע"י מפתחי ספריות ו־toolkitים שונים. החיסרון הוא העדר תאימות כלשהי של ABI לאחור והעדר תאימות מלאה של API לאחור.

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

הבעיה היותר גדולה, היא בניית ספריות. האופציה הראשונה היא:

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

האופציה השנייה היא:

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

יש לציין, שהבעיה היא יותר גדולה בפלטפורמה שמשתמשת ב־ELF, (קרי Linux, UNIX) בו כל הסימבולים הם "פומביים כברירת מחדל" ודווקא DLLים, שבד"כ עושים חיים מאוד קשים, מאפשרים למנוע התנגשות של בין סימבולים זהים בגרסאות שונות של אותה הספרייה ואף לעשות Link דינמי עם גרסאות שונות של אותה ספריה.

מה זה אומר בפועל? כל toolkit גדול שמבטיח תאימות ABI לאחור ורוצה להשתמש ב־Boost, חייב:

  • לא לחשוף מחלקות של Boost ב־API שלו, כי הגרסה שלהן עלולה להשתנות ולשבור תאימות ABI. מדובר כאן בדברים בסיסיים ביותר כמו:
    • boost::shared_ptr
    • ‏boost::function
    • ‏boost::any
    • ‏boost::regex שזה בהחלט מגביל מאוד את היכולת של אותו ה־toolkit להשתמש בכלים מודרניים.

  • לספק יחד אתו את עותק של ספריות ה־Boost הנדרשות מקומפלות סטטית.

    מה אם מדבור בספריה שמורכבת ממספר מודולים כמו: libfoo-core ו־libfoo-bar ו־libfoo-bee? אז או שכל אחד מהם מכיל עותק מלא של ספרית Boost, כי הם לא יכולים לשתף ביניים הסימבולים של Boost בלי שידלפו החוצה, או שצריך לכתוב מעטפות שמסתירות את העובדה שבפנים יש שימוש ב־Boost.

לדוגמה, הנה הדיון של מפתחי GtkMM על שימוש ב־Boost. הוא מראה, שהשימוש בו, זו משימה כמעט בלתי אפשרית.

המזל הוא, ש־C++0x מביא את רוב הדברים החיוניים באמת ישירות לקומפיילרים, והם כנראה לא ישברו את ה־API ו־ABI.

השאלה היא, מתי הוא כבר יהפוך לסטנדרט באופן רשמי וימומש ברוב הקומפיילרים?

תגובות

שניר ד, ב־21.5.2009, 0:03

תענוג לקרוא את הפוסטים שלך. ח"ח.

ארתיום, ב־21.5.2009, 17:42

תענוג לקרוא את הפוסטים שלך. ח"ח.

תודה

הבלוג של ארתיום, ב־24.5.2009, 14:07

תסריט פיתון להחלפת namespace של Boost.

הכנתי תסריט קטן שמאפשר שינוי גורף של Namespace עץ הקוד של Boost ל־Namespace חילופי כדי למנוע התנגשות בין גרסאות Boost שונות: http://art-blog.no-ip.info/files/rename.py.

הרצה:

הוסף תגובה:

 
 כתובת דוא"ל לא תוצג
 

ניתן לכתוב תגובות עם שימוש בתחביר Markdown.

חובה לאפשר JavaScript כדי להגיב.

דפים

נושאים