הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא תכנה ומחשבים.
ויקי של CppCMS עלה ברשת
הערה: היה באג בקוד JavaScript שמנע הרשמה לויקי, הוא תוקן ועכשיו ניתן להרשם
הויקי של פrויקט CppCMS עלה ברשת. כל התיעוד השייך ל־CppCMS עתיד להופיע בויקי הזה. כמובן, שהויקי עצמו בנוי בטכנולוגית CppCMS... (למישהו היה ספק?).
ויקי יאפשר לי לכתוב ולעדכן תיעוד בצור הרבה יותר מהירה ונוחה. הוא תומך בריבוי שפות, כך שאפשר יהיה לתרגם אותו לעברית או לכל שפה אחרת בקלות. הוא יהיה מענה לתיעוד הלוקה בחסר.
חייב לציין שלמדתי המון מכתיבת יישום ויקי זה. היא גרמה לי לעשות מספר שינויים מהותיים ב־CppCMS כמו: תמיכה בטפסים, שינוי במבנה היישום ועוד.
כרגע התכנים בויקי בתחילת דרכם... אבל, עכשיו, לאט־לאט, אחרי שאשלים כמה דברים הרבה יותר דחופים, אוכל לתת מאמץ לכתיבת התיעוד הכל־כך נחוץ עבור CppCMS.
חייב לציין: ללא תיעוד מצוין של Django שמהווה מקור השראה שלי וללא עזרה של מאיר קריחלי שעדיין ממשיך לענות על אלף ואחת השאלות שאני מעלה, היה לי הרבה יותר קשה להגיע לנקודה זו.
יצירת dllים בעזרת autotools תחת cygwin.
כידוע, dllים הם ייצורים פגומים שהשימוש בהם הוא סיוט. זה חמור עד כדי כך, שבד"כ, מפתחים רבים משתדלים להמנע ממנו.
הדרך הסטנדרטית, בה רוב חבילות cygwin מתמודדות עם הבעיה: יצירה של ספריות סטטיות בלבד. זה נוח, במקרים מסוימים כי זה מאוד מפשט את העבודה, אבל זה מנפח את קבצי ה־exe בצורה משמעותית. מה שעוד יותר חשוב, מחייב אותך לעשות link עם הספריה והתלויות שלה.
כך למשל, עם ספריה libabc תלויה ב־libxyz1 ו־libcoco2. אז כדי לבנות תכנה שמשתמשת ב־libabc במקום לקמפל:
g++ code.o -o prog -labc
חייבים לקמפל:
g++ code.o -o prog -labc -lxyz1 -lcoco2
זה הופך את הקמפול לפעולה מאוד לא טריוויאלית, במיוחד כשיש הרבה תלויות. לחילופין, ניתן להשתמש ב־libtool שיודע לאתר קבצי עזר עם התלויות -- libabc.la. במקרה כזה הבניה הופכת ל:
libtool --mode=link g++ code.o -labc -o prog
שזה מנפח את כלי הבניה וגם מחייב אותך להשתמש תמיד ב־libtool.
מסתבר, שעם הקפדה על כלל מאוד פשוט בכתיבה של תסריטי automake, ניתן לבנות ספרות דינאמיות בצורה מסודרת ו"כמעט" שקופה למשתמש.
המשך...מה צפוי ב"בטא 2" של CppCMS?
בקרוב תשוחרר בטא השניה של CppCMS. מה החידושים הצפויים:
- מערכת cache מבוזרת מעל TCP/IP שנותנת אפשרות scale up במקרה של עומסים גבוהים במיוחד. המערכת מבצעת ביזור של cache בסגנון memcached ונותנת ניהול load ballancing אוטומטי.
- שינוי משמעותי במערכת התבניות, מעכשיו, התבניות יהיו staticly typed. ה"תוכן" ייוצג ע"י מבני C++ טבעיים, התבניות עצמן יתוגרמו לקוד C++, שמייצר את העמוד מה"תוכן". המעבר מאפשר לממש מספר דברים:
- ירושה של תבניות בסנגון Django.
- יכולת לבצע הרחבות בקלות ע"י השתלת קוד C++ באופן ישיר.
- בעתיד יהיה קל יותר לחבר טיפול בטפסים.
- התבניות יכולות להיות מקומפלות סטטית ישירות ליישום או והיטען כמודולים (so/dll) בנפרד.
ייתכן, שמערכת יצירה ובדיקה של טפסים תצורף לבטא 2, גם כן.
המשך יבוא...
שפת C, פקודות goto, ניהול משאבים ומה שביניהם.
לאחרונה, התפתח דיון מעניין ב־WhatsUp שהפתח מהצגה של דוגמת הקוד הקטנה, שמשתמשת ב־goto. אחת הסיבות ל"רעש" מסביב לקוד הזה, היא העובדה מפקודות goto נחשבת למסוכנת ומזיקה. אבל, כידוע, בעולם שלנו לא הכל שחור לבן.
בשפות ללא destructorים כמו Java זה מאוד מקובל להשתמש בקטעי־try/finally לניהול משאבים. לדוגמה:
void function()
{
resource r1,r2;
try {
r1.allocate()
if(error1) throw;
r2.allocate()
if(error2) throw;
do_something;
if(error3) throw;
}
finally {
r1.free();
r2.free();
}
}
למעשה, throw מקפיץ אותך לקטע finally שמאפשר שחרור מסודר של משאבים שלא מנוהלים ב־gc. עכשיו בואו נסתכל בקוד הבא:
void function()
{
resource r1,r2;
{
r1.allocate()
if(error1) goto filally;
r2.allocate()
if(error2) goto filally;
do_something;
if(error3) goto filally;
}
finally: {
r1.free();
r2.free();
}
}
אתם מזהים את הדמיון המפתיע? כן, זאת השיטה המקובלת, המסודרת והנכונה לנהל משאבים ב־C. לאתחל את כל המשאבים בצורה מרוכזת, לשחרר אותם בצורה מרוכזת ובכל מקרה של שגיאה לקפוץ לקטע שדואג לטפל בהם.
זה מבטיח קוד נקי, קריא ומסודר. אם מישהו יגיד לכם אחרת... אז הוא לא מבין את המשמעות של exceptions בשפות התכנות המודרניות אחרות, שיכולים להיות הרבה יותר מסובכים ולא מובנים מאשר goto פשוט.
לוותר על gc או לוותר על destructor?
היום, יש נטייה להשתמש בכל שפה אפשרית ב־GC -- כי היא פותרת המון בעיות בניהול זיכרון. כמעט כל השפות פופולריות (למעט C/C++/Pascal) מממשות אותה בצורה זו או אחרת.
כמעט כולם (למעט CPython, Perl ו־vala) משתמשות בשיטה של "בדיקת נגישות" (Reachability). בשיטה זו מנוע GC פועל אחת לזמן מה, מחפש כל מופעי אובייקטים שאינם נגישים יותר ומוחק אותם.
השיטה הפחות נפוצה, שמתשמשים בה למשל ב־CPython, היא שימוש ב"ספירת הפניות" (Reference counting), אבל היא קשה למימוש ובעייתית באופן כללי, בגלל טיפול בלולאות סגורות, כאשר אובייקט יכול להפנות לעצמו, ובכך "מספר הפניות" לעולם לא ירד מתחת ל־0.
שימוש ב־GC שיטה הראשונה פותרת את בעיית ניהול הזיכרון, יחד עם זו היא מציבה בעיה הגדולה אחרת: destructors או finalizers --- מתודות שמבצעות "מחיקה" של האובייקט, הופכות לכמעט ולא רלוונטיות. כי אי אפשר לדעת מתי ישוחרר האובייקט. כלומר ב־Java, C#, IronPython, PHP, D וכמעט כל שפות אחרות שמשתמשות בשיטה הזו, destructors הם חסרי משמעות.
המשך...