מאמרים בנושא ‏Boost‏‏.

אמת המרה על רמת התמיכה בלוקליזציה

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

כפי שחלק מקוראי הבלוג אולי יודעים, אני עובד על ספריית Boost.Locale‏ שאני מקווה תשולב ב־Boost בעתיד.

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

כדי לאפשר תמיכה נאותה בכל המרכיבים האלה, אני משתמש בספרית ICU‏ שנותנת את כל הדרוש, למעט API שמתכנת C++‎ שפוי יכול להשתמש בו.

למרות ש־ICU היא ספריה מצוינת, יש לה גם לא מעט חסרונות:

  • גודל הספרייה שמכילה את כל הנתונים הוא כ־12 מ"ב! זה בד"כ מאוד בעייתי עבור סביבות משובצות מחשב.
  • ביצועים - היא לא מצטיינת בהם, למשל יצירת תאריך או מספר לוקחת עד פי 10 יותר זמן בעזרת פונקציות ICU השוואה לפונקציות כמו strftime.

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

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

אבל עדיין, יש לי שלוש אופציות:

  • שימוש בספריית C++‎ הסטנדרטית שמכילה את מרבית הדברים הנדרשים.
  • שימוש ב־API של POSIX 2008 שמגדיר אוסף פונקציות כמו newlocale, strftime_l או strcoll_l במערכות תואמות POSIX (למעשה, ה־API הזה נתמך בלינוקס ובמק).
  • שימוש ב־Win32 API שנותן פונקציות די עשירות כמו GetDateFormat, CompareString וכד' שנותנות תמיכה רצינית בלוקליזציה.

כמובן פה ושם צריך לסדר דבר או שניים כמו MSVC שלא מכיר בשמות לקול כמו en_US.UTF-8 ולא תומך ב־UTF-8, לעשות התאמות פה ושם להבדלים בין לינוקס ומק במימוש של API של לוקליזציה וכד'.

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

  • libstdc++‎ של GCC לא תומך בלוקליזציה בשום מערכת הפעלה מלבד Linux (לא שזה חדש, בגלל זה הוספתי את שתי האופציות הנוספות).
  • ‏מסתבר שב־Mac OS X (וגם ב־FreeBSD) פונקציה strcoll שבורה לחלוטין, כך הוא לא יודע לסדר a < ç < d או אפילו a < C < d כפי שזה מתבקש בשפה בטבעית.
  • ב־Solaris פונקציות towupper ו־towlower לא ממש מתחשבות בלוקל (למשל בלוקל טורקי i הופכת ל-"İ" ולא ל־"I" ב־upper case)

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

לשרוד פיתוח תואם "Windows" בעידן Unicode...

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

אם פיתחתם מעט עבור Windows אתם בוודאי מכירים את המושג שנקרא Wide-API. קרי לכל פונקציית המערכת יש שתי גרסאות: "ANSI" ו־"Wide", למשל: DeleteFileA ו־DeleteFileW, כאשר אחת מהן מקבלת char const *‎ והשניה wchar_t const *‎.

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

למעשה, לפי מדיניות של Microsoft, כדי לגשת לכל הכוח של מערכת ההפעלה אתה חייב להשתמש ב־Wide API אחרת... אתה אפילו לא תוכל ליצור קובץ "שלום.txt". נחמד, לא?

הבעיה שלא C99 ולא, C++‎, וגם לא C++0x לא מכירים במושג העמעום של wide-path ולמעשה, לפי התקן אין, דרך לפתוח קובץ שהשם לו הוא "שלום.txt" מקודד כמחרוזת של wchar_t (רק char). כמובן חבר'ה ב־MS הם "ידידותיים" למפתחים והם הציע API חילופי: ‎_wfopen(wchar_t const *,wchar_t const *);‎ וגם הוסיפו הרחבה לסטנדרט ב־Visual Studio‏: std::fstream::open(wchar_t const *,...);‎ הכל לטובת המפתח (הם כנראה לא שמעו בכלל על UTF-8)...

כאן, מתחיל הסיוט, למעשה למפתח יש שתי אופציות:

  • להתעלם מהטמטום של Wide-API ולעבוד רק עם "ANSI-API" ו... התוכנה תפסיק לעבוד באופן אקראי על קבצים אקראיים, והמשתמשים המסכנים ישברו את הראש מה לא עובד.
  • להתחיל לשכפל את כל הקוד שלך למקרה wide ולמקרה נורמלי.

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

כך גם, אני כשהתחלתי תמיכה בחלונות ב־CppCMS החלטתי להתעלם מהעובדה ש־fopen או std::fstream::open לא יעבדו לי. אבל בסוף ייסורי מצפון הזיזו את כף־המאזניים: מספיק לכתוב קוד גרוע... והכנתי ספריית עזר קטנה, קראתי לה booster::nowide. כל מה שהיא עושה זה: להעביר ל־namespace שלך את הכלים סטנדרטיים שקיימים ב־stdio וב־STL בכל מערכות ההפעלה נורמליות. ובחלונות, היא פשוט עוטפת אתה API‏ ‎_w*‎ עם פונקציות משלה שממירות UTF-8 ל־UTF-16 ואז קוראות לפונקציות המתאימות.

בנוסף יצרתי מחלקות תואמות ל־std::fstream שעובדות מעל stdio (ועל הדרך סוף־סוף הבנתי כיצד לממש streambuf משלך).

התוצאה? אם אתה מתכוון לתמוך בחלונו, במקום לכתוב

std::ofstream f("שלום.txt")

שמייצרת ג'יבריש במקרה הטוב אתה כותב:

booster::nowide::ofstream f("שלום.txt")

וזה עובד בצורה שקופה, כנ"ל, std::fopen, std::freopen, std::remove, std::rename - רק החלף std::‎ ב־booster::nowide::‎.

במילים אחרות: no-more-wide-crap!

הספרייה היא חלק מ־booster של CppCMS ומופצת תחת רישיון Boost (משהו סגנון MIT). אם מישהו ירצה ספריה בלתי תלויה ב־booster, אז תגידו ואני אגזור אחת (לא מסובך בכלל).

קריאה נוספת: "Should UTF-16 be considered harmful?‎‏"

גרסת הספרית nowide התלויה בקומפיילר C++‎ לבלבד ניתנת להורדה כאן:
http://art-blog.no-ip.info/files/nowide.zip

ספריית Boost.Locale הוגשה לביקורת רשימית

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

בשעה טובה, הגשתי את הספריית לוקליזציה Boost.Locale‏ לביקורת רשמית (formal review) של קהילת ה־Boost. אם היא תעבור אותה היא תתקבל כחלק רשמי של Boost.

קישורים:

אעדכן אתכם על התפתחויות בהמשך.

עדכון: זה רשמי -- Boost.Locale התווספה לרשימת הספריות הממתינות לביקורת. עכשיו צריך שמישהו מהקהילה יתנדב להיות מנהל הביקורת (review manager).

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++‎.

העמוד הבא

העמוד הבא

דפים

נושאים