הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא C++.
ניהול Sessions ב־CppCMS
הערה 05/01/2009: פורסם מדריך לעבודה עם sessions בויקי
אחד החלקים חשובים של כל תשתית פיתוח יישומי אינטרנט הוא --- תמיכה בניהול Sessions: שמירת מידע בין בקשות שונות. זה מאפשר להפוך פרוטוקול HTTP שהוא stateless בטבעו ל־statefull. זהו מרכיב הכרחי שקיימ ברוב התשתיות כמו Django או RoR.
בד"כ, אני נוהג להסתכל בפתרונות הקיימים, לבחור את הטוב ביותר וליישמו במסגרת האילוצים של CppCMS. גם הפעם הסתכלתי בשתי התשתיות הפופולריות RoR ו־Django והבנתי, שהפתרון שהם מציעים, כפי שהוא לא מתאים בגלל אילוצי ביצועים.
הדרך "זולה" ביותר, היא לשמור את המידע ב"עוגיות" אבל יש לה שני מגרעות:
- יש מגבלה של כ־4K נתונים שניתן לשמור בעוגיה (לא כולל קידוד וכד').
- RoR שנותנת אפשרות ניהול מידע בעוגיות, לא מבטיחה שהמידע השמור לא ייחשף ללקוח --- תחשבו על פתרון Captcha ששמור בתוך עוגיה..
שמירת המידע בצד השרת כרוכה בשתי בעיות:
- ניהול בסיס נתונים כלשהו לשמירת המידע --- שיכול להוות צוואר בקבוק.
- בעית הביזור שלו גישה מרובת משתמשים.
לכן, החלטתי שב־CppCMS אני אלך על פתרון קצת שונה שמשלב את התכונות של שניהם (עם שיפורים).
המשך...מה אני שונא ב־C++.
אחד הדברים החשובים במלחמת "שפות/דתות" זה לדעת טוב מאוד את המגרעות של השפה. כך, כדי "לאזן" את הכתבות על C++ החלטתי לפרסם רשימת הדברים שאני שונא ב־C++.
- זמן קומפילציה --- נוראי. לפעמים כשאני מקמפל קוד C או Java אני לא מבין מה קורה? מדוע לחצתי על "Enter" והקמפול נגמר.
- קשה מאוד ליצור ספריות עם ABI תואם לאחור. כל שינוי קטן בממשק הורס תאימות לאחור. או צריך להמציא טריקים כמו "הסתרת מימוש" או לעבוד עם מחלקות אבסטרקטיות בלבד.
- שגיאות קומפילציה נוראיות: אני כבר מחכה ש־ConceptsGCC יתמזג לענף gcc הראשי --- שוב, חלק מ־C++Ox.
- מתכנתי C++ שאין להם מושג ירוק מה הם עושים.
- קוד C++ כתוב כמו קוד C... מקור מעולה לבאגים.
- ספריות "C++" שתואמות קומפיילרים טרם־היסטוריים --- ללא namespaces, ללא STL, ללא RTTI ועוד. (למשל ממשק C++ של BDB).
- ספריות שממציאות גלגל מחדש: בא לנו string משופר, רשימה מקושרת משופרת ועוד -- אבל הורסות את התאימות עם שאר הספריות.
- עבודה עם ספריות C מתוך C++ --- כי ב־C אין destructors ואז הקוד הופך לספגטי של try/catch. או צריך לעטוף כל שטות במחלקה. מצד שני, אי אפשר לוותר על זה, כי יש המון ספריות מעולות, מדובגות ונפוצות הן ספריות C.
- אני שונא iostreams -- הם מסובכים, לא נוח לעבוד עם format, לא נותנים גישה ל־file descriptors כמו FILE של C. מצד שני, הם הפתרון הטוב ביותר לעבודה אחידה מול streamים שונים -- למשל, כתיבה לקטע בזיכרון, כתיבה ל־socket ועוד.
- כתיבת טיפוסים של iterators --- אני כבר מחכה ל־auto של C++0x.
- קומפיילרים גרועים --- ראה ערך VS6 שאני לא מבין מדוע אנשים עדיין משתמשים בו.
אני מעביר את השרביט ל:
הסבר: הכוונה היא --- לתת ביקורת על מה שאפשר היה לשפר בשפה, או מה שלא ניתן לשנות וזה לפעמים מפריע.
האם C++ היא שפה דלה?
ב־C++ אין הרבה דברים מאוד נפוצים ושימושיים, למשל:
- אין תמיכה ב־threads.
- אין תמיכה בעבודה עם זיכרון משותף.
- אין תמיכה ב־IPC ויצירת תהליכים.
- אין תמיכה ב־base64 ו־md5.
- אין תמיכה מובנית בעבודה עם בסיסי נתונים כמו sqlite3.
- אין תמיכה מובנית בדחיסת gzip.
- אין כלי עבודה מול XML.
אם תסתכלו בשפות כמו Java/C#/PHP/Python/FPC תגלו שלמעשה, כמעט כל הדברים האלה, נתמכים ברמת השפה עצמה (עם שינויים כאלה ואחרים), אבל C++ דורשת ספריות צד ג' כדי לטפל דברים כל־כך בסיסיים.
האם זה אומר שהשפה דלה או האם זה אמור משהו אחר?
המשך...כתיבת GUI יכולה להיות נסבלת
לפני מספר חודשים, הייתי צריך להתחיל לעבוד על פרויקט בתחום מתמטיקה וויזואליזציה. הייתי צריך לכתוב יישום שמדגים כל מיני דברים מתמטיים מסובכים בצורה יפה ואינטואיטיבית. אחת הדרישות הייתה --- תמיכה בריבוי פלטפורמות (לא הייתי בא למרצה עם יישום שאפשר להריץ רק על לינוקס).
לפני עמדו מספר אפשרויות:
- לממש את הכל ב-Matlab.
- לקחת שפה כמו python עם איזשהם bindings שהם לא תלויים בפלטפורמה.
- לכתוב ב־C++ ולקחת כלי שהוא בלתי תלוי בפלטפורמה:
- להשתמש ב־wxWidgets.
- להשתמש ב־GTKmm.
- להשתמש ב־Qt4.
לצורך העניין, עד היום, הניסיון היחיד שהיה לי בבניית GUI, היה רק עם MFC.
המשך...יצירת 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, ניתן לבנות ספרות דינאמיות בצורה מסודרת ו"כמעט" שקופה למשתמש.
המשך...