שלום,

בימים אחרון אני עובד על פיתוח web development framework בסיסי ב-++C.

כן, אני יודע, שחלק מכם יגידו שאני "מאזוכיסט" אבל לא, אני רוצה לבנות סביבה נוחה לפיתוח web ב++C שתאפשר למפתח להתרכז בלוגיקת היישום עצמו במקום בכל הרכיבים מסביב. היא אמורה להשען על מספר רכיבים: FastCGI, cgicc קצת boost. ולתת ממשקים נוחים לכמה DBs.

כרגע אני מתכנן את הרכיבים הבאים:

- שלד שיטפל בכל בנושא של טיפול ב-fcgi, ניהול threads ועוד (כבר יש).
- ממשק נוח ואחיד ומאובטח נגד-sql injection לבסיסי נתונים (כרגע מומש mysql).
- עבודה עם כל הקלט/פלט דרך cgicc (מומש חלקית)
- טיפול ב-sessions וניהול משתמשים
- טיפול נוח בכל הנושא של templates - הפרדה של HTML וקוד ++C.
- טיפול כמה פורמטים של טקסטים בסיסיים כמו markdown, bbcode ו-html בסיסי
- ניהול cache המשותף בין ה-threads.


בגדול הכוונה להגיע למצב בו כל מי שיודע ++C יוכל לכתוב יישומי web תוך כדי טיפול בלוגיקת יישום ולא בכל מה שמסביב.

שאלות:

- איזה עוד רכיבים חיוניים חייבים להיות ב-framework כזה?
- איזה רכיבים שכדאי שיהיו ב-framework כזה.

you need a small testing web server, so you dont need to use apache when debugging

Anonymous :

you need a small testing web server, so you dont need to use apache when debugging

ברמת העקרון יישום FastCGI הוא יישום חיצוני, כך שכל מה שאני צריך זה להגדיר את ה-socket לאיזשהו שרת שיודע לעבוד עם fastcgi לפי לפנות, שם תבחר מה שבא לך apache/lighttpd או כל דבר אחר.

בצורה כזו אני יכול לדבג יישום אפילו מ-Anjuta (בדיוק מה שעושיתי לפני כמה דקות )

חופשי מזוכיסט...
בהצלחה !!

כמה דברים:

- עבודה בסגנון MVC, אתה מרמז על זה בפיצ'רים שאתה מוסיף, אבל אני מוסיף את זה כאן בכל מקרה.
- אופציה להפעלת סקריפטים. כן, אני יודע, אתה מעדיף לא להתעסק עם שפות ה P, אבל אם אתה בונה את הכלי לשימוש ה"קהילה", אז זה דרישה שתעלה.
- ניהול cache חיצוני (דוגמאת memcached) ע"י ממשק התחברות אחיד.
- טיפול ב url-ים.
- פלט יכול להיות גם דברים שאינם html (לדוגמא, xml, json) תדאג לא להתמקד ב html.
- בגדר "נחמד" - אבסטרקציה של תהליך המענה ככה שניתן יהיה להכניס middleware בשלבים שונים בדרך.

בגדול, תסתכל על frameworks מהדור החדש (django, RoR, turbogears) ותגנוב רעיונות.

נ.ב. - מזוכיסט!

תמיכה ביצוע ל wml ו wmlc.

אפשרות Validation עבור W3C.

אז ככה,
הקוד נמצא ב:

http://cppcms.svn.sourceforge.net/
כמובן זו מממממש התחלה, מימשתי איזה מיקרו פורומון שנותן 2000/2100 שאילתות בשניה.

לגבי שאלות

ציטוט:

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

למעשה כמעט כל אתר דינמי משתמש במודל כזה...

מצד שני, לעשות הפרדה יתרה בין "model" לבין "view" היא לא תמיד נבונה, למשל, על לצורך יצירת דף מסויים אתה יכול לבצע שאילתה SQL די מורכבת אחת שתענה על הדרישות שלך, ברגע שה-view שלך מתנתק יותר מידי מה-"model" אתה עלול להפסיד הרבה.

במילים אחרות, תמיד יש צריך להיות איזון בין איפה הפרדה צריך להיות ואיפה לא. אבל זה, נשאיר לשלב מאוחר יותר/או נשאיר ליישום עצמו. כלומר כן ל-templates. אבל לא לאובייקטים שנגזרים משאילתות SQL.

ציטוט:

אופציה להפעלת סקריפטים. כן, אני יודע, אתה מעדיף לא להתעסק עם שפות ה P, אבל אם אתה בונה את הכלי לשימוש ה"קהילה", אז זה דרישה שתעלה.

למעשה אם אתה יכול להפעיל שפת P כלשהי מתוך ++C אתה תוכל לעשות זאת.

בנוסף, שום דבר לא מפריע לך לממש חלקים ב-php. למשל

main.fcgi יגיש לך את העמודים.
post.php יקלוט נתונים ל-MySQL.

אבל כל זה לטיפולך.

המטרה של ה-Framework לעשות את העבודה ב-++C קלה ע"י לקיחת רוב עבודות התשתית לספריה.

בנוסף, לכל מי שתוהה, בזכות STL וקלאסים כמו string, ועם עבודה עם רכיבים כמו auto_ptr שמונעים בעיות זליגת זכרון העבודה ב-++C יכולה להיות די פשוטה.

כך שהמטרה היא לא לבנות מעטפת יעילה לשפות P אלא לעשות עבודה ב++C מספיק פשוטה.

ציטוט:

ניהול cache חיצוני (דוגמאת memcached) ע"י ממשק התחברות אחיד.

כן אני מתכנן גם את זה,
כפי שציינתי אני רוצה לממש גם מודולים עבור caching. כאשר מדובר במערכת מבוזרת (ברגע שבכל זאת יידרש scaling) היא תעבוד באחת משתי הצורות:

א. ה-cache שמור ב-memcached.
ב. ה-cache שמור בזכרון התהליכים עם dirty cache notifications שהתהליכים ישלחו אחד לשני.

ציטוט:

טיפול ב url-ים.

הסבר, פרט ונמק? הרי url זה משהו מאוד "אישי" כל יישום.

ציטוט:

פלט יכול להיות גם דברים שאינם html (לדוגמא, xml, json) תדאג לא להתמקד ב html.

הכוונה להוציא כל "x/ht/xht+ml" החוצה ל-templates. כך שביישום אתה תמלא רק ערכים שצריך למלא.

ציטוט:

תמיכה ביצוע ל wml ו wmlc.

wml ראה לעיל,
wmlc... מעניין... אולי מתישהו אם זה יצליח, בסה"כ אם יש ספריה שיודעת לבצע "דיחסה" אז לא תהיה בעיה גדול לחבר גם אותה.

ציטוט:

אפשרות Validation עבור W3C.

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

אבל למה?

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

אם אתה מפנטז שזה יהיה באמת שימושי -- אז זהו, שאתה מפנטז. למה שמישהו ירצה לפתח אתר ב-++C? למרות כל ה-STL, עדיין קל מאד לעשות שם שטויות שאתה פשוט לא יכול לעשות בשפות של managed code (בעיקר, שפות ה-P למיניהן, Java, ו-Net.). דברים כמו להחזיר מצביע למשתנה לוקאלי. דברים כמו Buffer overrun.

מה שחשוב יותר -- למפתחים הרבה יותר קל לעבוד בשפות (כמו Java ו-#C) שבהן כלי הפיתוח תומכים יותר. ב-++C, במיוחד עם שימוש כבד ב-templates (אלו של השפה, לא של ה-HTML), הכלים מתקשים להבין את הקוד. עוד לא ראיתי כלי אחד עם intellisense שעובד כמו שצריך באופן עקבי, דבר שהוא טריויאלי לגמרי ב-Java למשל. ועוד לא ראיתי קומפיילר שייתן הודעות שגיאה נורמליות על בעיות שימוש ב-STL.

ל-++C יש בהחלט יתרונות על כל השפות האלה; אבל החשוב ביניהם -- מהירות -- בד"כ לא משמעותי באתר web. כלומר, ודאי שהביצועים חשובים, אבל השפות האחרות מספקות ביצועים מספיק טובים אם אתה לא עושה שטויות שאינן קשורות בשפה עצמה (דברים ברמה של, למשל, לקרוא טבלה שלמה ולפלטר רשומות בקוד במקום להכניס תנאי-שליפה בשאילתת SQL).

ואם בכל-זאת אתה מתעקש -- לא עדיף לנסות לתרום לאחד הפרוייקטים הקיימים, כמו (לאחר חצי דקה בגוגל) http://www.webtoolkit.eu/wt ?

טוב,
יש פה שני נושאים:

א. למה לעזאזל לפתח ב-++C?

התשובה הראשונה היא: למה לא?
התשובה קצת יותר רצינית:

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


ב. מדוע לא לתרום לפרויקטים קיימים?

אין פרויקט בשל שמטרתו לספק סביבת פיתוח ידידותית לweb ב-++C שתדאג לביצועים.
יש פרויקטים שונים ועושים חלקים מהעבודה למשל:

- cgicc, אבל בד"כ הוא לא מספיק וגם משאיר הרבה עבודה מסביב.
- Klone מיועד בעיקר ל-Embedded וגם לא תומך ב-fastcgi בכלל.
- wt שציינת, מרוכז מסביב ל-GUI ולא מסביב ליישומי web במובן הקלאסי שלהם.


הערות

ציטוט:

דברים כמו להחזיר מצביע למשתנה לוקאלי.

מי שמחזיק מצביע למשתנה לוקלי ולא מבין מה לא בסדר בזה הוא לא יודע C ולא אמור לכתוב בו קוד עד שילמד אותו. חד וחלק!

זה נועד לאלו שיודעים לכתוב קוד ולא סקיפרטים

ב. אם אתה אומר בעצמך ש cgicc עושה חלק מהעבודה שאתה רוצה, אז למה לא להתחיל ממנו?

א. יש הרבה סיבות טובות לכתוב ב-++C. לא טענתי שלא. יש אפילו כמה סיבות לעשות את זה לממשקי web. אבל כל הסיבות שאני מכיר מתבטלות אם אתה מניח דברים כבדים אינהרנטית כמו עבודה מחוץ לתהליך של שרת ה-web (אמרת FastCGI) או גישה ל-database.

מי המשתמש שאתה רואה מול עיניך?

ובעניין בטיחות הכתיבה: תניח ש-v הוא std::vector, שכבר מכיל כמה ערכים. אתה רואה, במבט ראשון, מה הבעיה בפקודה הבאה?

קוד:

v.push_back(v[0]);

ציטוט:

ב. אם אתה אומר בעצמך ש cgicc עושה חלק מהעבודה שאתה רוצה, אז למה לא להתחיל ממנו?

אני משתמש בו, כפי שאני משתמש בספריות אחרות.

מצד שני הוא לא מספיק מקיף וגם התכנון שלו, לא תמיד נוח, למשל:
אני רוצה להכין את כל התוכן, אולי לעשות לו דחיסת gzip ואז לשלוח אותו לשרת, זה לא ממש נוח במסגרת cgicc. לא נוח לעבוד איתו מול fastcgi (צריך להכין כל מיני wrappers) ועוד.

אין בו תמיכה בניהול threads, cache, templates ועוד.

ציטוט:

אבל כל הסיבות שאני מכיר מתבטלות אם אתה מניח דברים כבדים אינהרנטית כמו עבודה מחוץ לתהליך של שרת ה-web (אמרת FastCGI)

דווקא fastcgi עוזר בזה המון, תמורת socket אחד נוסף אתה מקבל תהליך קבוע שרץ מחוץ לשרת (למשל lighttpd) ועונה על שאילתות, שבין השאר שומר בזכרון שלו את כל ה-cache האפשרי. יש כמה מאמרים מעניינים בנושא מהירות fastcgi. והוא בהחלט לא נופל על מהירות modים למיניהם.

ציטוט:

גישה ל-database.

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

זה פשוט לא נכון. SQLים יודעים לעבוד מהר מאוד (כמובן אם הם מנוהלים כראוי ואם אתה לא עושה שאילתות ענייניות).

ציטוט:

מי המשתמש שאתה רואה מול עיניך?

לא משתמש, מפתח -- מפתח שמעוניין לבנות מערכות תוכן שיודעות לעמוד בכמויות מבקרים גדולות... בלי שזה יורגש ע"י משתמש.

קוד:

v.push_back(v[0]);

כשאתה עושה push_back זה יכול להביא להגדלת גודל המערכת והעתקתו בזכרון, לכן ה-reference ל-[v[0 יכול להיות כבר לא עדכני וכיוצא בזה, תמשוך מידע ממקום לא נכון.

בנוסף, עבודה עם stl לא פותרת אותך בהבנה של מה שקורה מתחת.
כפי שאמרתי, זה נועד לאלה שיודעים ++C

ארתיום, המדידות שלך (שעזרתי בהן) הן micro benchmark וממש לא מייצגות אתרים עם כל הכבוד ל-ab והדמיות שונות.

הנה ממקור ראשון: הניסיון לאחר החלפת השרת של ווטסאפ. לפני ההחלפה, על השרת הישן mysql היה צוואר הבקבוק והעומס העיקרי. רוב העומס והאיטיות שאנשים חוו היו עקב IO ולא עקב CPֹU, כך שהחלפת שפות P למיניהם במהודרות לא הייתה עוזרת.

לגבי ה-URL שהזכירו: תשתיות כיום הן הרבה מעבר ליישום פשוט של CGI. כל הפופולריות מיישמות מנגנון של ניתוב url ללא קשר לפונקציה (decoupling) שתספק את התוכן ומאפשרות מיפוי דינאמי בין השניים (מה שמכונה "עיצוב URL").

לגבי התשתית (הצצתי מעט בקוד). הבעיה שהיא מספקת מעין חתונה קתולית. התשתיות הקיימות כיום מאפשר עבודה במגוון צורות בין אם fastcgi, scgi או מודול שהוא חלק מה-process של השרת, כאשר ההחלטה והשינוי אינן תלויות ביישום עצמו (לדוגמא: בווטסאפ כאשר החלפנו מ-mod_php להתקנת fastcgi, לא היינו צריכים לגעת בשום דבר בקוד עצמו, רק ב-deploy. בתשתית שכתבת זו די חתונה קתולית מהצצה החטופה שהזדמנה לי (וניטרליות מערכות הפעלה: מה קורה אם רוצים להתקין על מכונה חלונות ? סולאריס ? FreeBSD).

ראה אותו דבר בעבודה מול בסיסי נתונים שונים.


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

ציטוט:

זה נועד לאלו שיודעים לכתוב קוד ולא סקיפרטים

בתור אחד שכתב על מגוון שפות רחב כולל C ו-C++ (בגדול אני כותב קוד בשפה כלשהי כבר יותר מ-20 שנה) הערה כזו (או גאווה מטופשת שבדרך כלל מוגשת יחד עימה) לא ברורה לי. כבר עברתי את ימי המאצ'ו. אני לא רוצה לכתוב קוד. אני רוצה לכתוב יישום. אין לי שום צורך להתעסק באיך כאשר המה הוא החלק הקשה ביותר והחשוב - במיוחד כאשר מדובר במוטציה כמו C++ (שההיסטוריה שלי עימה די עתיקה, עוד לפני המצב הנסבל בקושי של היום) כאשר אין הכרח לעשות זאת.

יש מורכבות של קוד בשפות דינאמיות (ולא שפות סקריפט כמו שקוראים כאשר רוצים לזלזל בהן) שמי שכל חייו יושב רק בסביבה מהודרת לא יצליח להבין (וזה מתברר במיוחד כאשר קוראים קוד של מי ששקוע ב-C/C++ ומנסה לכתוב קוד בשפה דינאמית).

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

ציטוט:

בתור אחד שכתב על מגוון שפות רחב כולל C ו-C++ (בגדול אני כותב קוד בשפה כלשהי כבר יותר מ-20 שנה) הערה כזו (או גאווה מטופשת שבדרך כלל מוגשת יחד עימה) לא ברורה לי

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

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

פשוט טעות כזו מצביע על "אי הבנה מוחלטת" מה זה מחסנית, ו-heap של שפות מקומפלות שיכולה לקרות רק לאלה שתמיד כתבו ב-Perl/Python או Basic ולא מבינים משמעות של מצביע.

בכלל לא התכוונתי להעליב מישהו.

גם אני בתור מי שמכיר שפות מקומפלות בקושי מסתדר עם שפות סקריפטים/jit כי פשוט הן כל כך לא שקופות. ואני לא תמיד יודע מתי אני עלול להעתיק buffer בגדול של כמה עשרות K ומתי לא. כי זה פשוט לא שקוף.



לגבי ביצועים של מערכת תוכן,

שימוש ב-in memory cache של persistent process שמשותף ל-threadים שונים דווקא יוריד המון עומס מ-MySQL. וזה היה קל לממש כי לא צריך לאתחל דבר מחדש.

למשל ניתן לנהל את כל ה-sessions בזכרון... למה לא? ועוד. עובדה שתהליך persistent היא רק תשפר את המצב. פעולה שאתה פשוט לא יכול לעשות במסגרת modים למיניהם.

בנוסף אני עדיין מאמין שיש החלק של PHP הוא מאוד משמעותי...

בכל אופן, מה שאני רוצה לכתוב זה גם מעין "prove of concept". מבחינה זו עבודה ב++C היא לא שונה מהותית מעבודה מול #C או Java ל-web. כך שאני באמת אומר "למה לא?"

ציטוט:

התשתיות הקיימות כיום מאפשר עבודה במגוון צורות בין אם fastcgi, scgi או מודול שהוא חלק מה-process של השרת

לפי דעתי, ההפך הוא נכון.

fastcgi פותח לך גישה כמעט לכל שרת apache/lighty/nginex/IIS כי fastcgi הוא תקן שיש לו הרבה מימושים. והוא רץ על כל פלטפורמה אפשרית win32/UNIX/BSD/linux ועוד.

למעשה הוא ממשק תקשורת סטנדרטי בין יישום לבין השרת. כך גם ספריית fastcgi עובדת על הרבה פלטפרומות כולל win32/AIX/solaris ועוד.

למשל, אפילו apache-mpm-worker יודע לעבוד מול perl/python/php רק דרך fastcgi.

ציטוט:

וניטרליות מערכות הפעלה

כל מערכות POSIX זה ממש לא בעיה. אני לא משתמש במשהו linux ספציפי.

לגבי winows אז pthreads קיימים אפילו ב-windows.

הרכיב היחיד שהוא POSIX ספציפי שהשתמשתי בו היא קריאת poll, ו-pipe ועבודה עם signal. אבל חשוב לציין שזה בקלאס בודד ובו אפשר יהיה להחליף את הרכיבים ל-win32 ספציפיים שקשורים בניהול process. אבל זה בגלל שב-windows דברים נעשים אחרת לחלוטין. בכל אופן רוב הדברים אפשר יהיה להתאים ולשנות בקלות.

אבל אלה הם רכיבים מאוד מיוחדים שקשורים הדוק ל-API של מערכת הפעלה. וכך או אחרת אם אתה רוצה לטפל בניהול "services" אתה תצטרך לעשות דברים אחרים ב-windows.
כל השאר בלתי תלוי.

ציטוט:

ראה אותו דבר בעבודה מול בסיסי נתונים שונים.

לגבי DB. כפי שציינתי לעיל, אני רוצה לממש גם ממשק זהה ל-PostgeSQL וכל מי שחפץ לו יכול להתממשק לכל DB שיש לו ספריית C++/C.

אגב יש לי גם הכנות לממשק הרבה יותר ידידותי ל-berkeley db (שלא העליתי עדיין) שגם היא multiplatform.

השאלה היא האם זה באמת יותר יעיל, בסופו של דבר המערכת שלך צריכה לעשות איזשהו query ל- db אולי איזשהו parsing ולהחזיר תוצאה לשרת web. האם הדבר הזה יותר יעיל ב- c++ מאשר בשפת סקריפט?
בנוסף ברור שתחזוקה פיתוח דיבוג ו- deploy הרבה יותר מסובכים כאשר מדובר בשפה מקומפלת כך ששום אירגון שפוי לא ישקיע כל כך הרבה מאמץ בשביל כל כך מעט תועלת. עדיף לקנות עוד זיכרון/שרת או להחליף CPU מאשר להשקיע כל כך הרבה בפיתוח.

whoisa :

בנוסף ברור שתחזוקה פיתוח דיבוג ו- deploy הרבה יותר מסובכים כאשר מדובר בשפה מקומפלת כך ששום אירגון שפוי לא ישקיע כל כך הרבה מאמץ בשביל כל כך מעט תועלת. עדיף לקנות עוד זיכרון/שרת או להחליף CPU מאשר להשקיע כל כך הרבה בפיתוח.

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

בלי חלומות לא נגיע רחוק אני אישית חושב שאם הגלגל שהוא ימציא יעזור אפילו לאדם אחד להתגלגל אז זו עבודה מבורכת.חוץ מזה שעל הדרך הוא ילמד מלא דברים חדשים.

כשאני מריץ אפליקציית Django דרך fastcgi היא גם persistent.

לגבי sessions בזכרון, כמובן שיש לך את זה גם בתשתיות השונות (חפש לדוגמא session_handler של php). מצד שני זה לא שומר state בין הפעלות (אפשר לשמור ביציאה/טעינה אך כאשר שרת מתרסק אכלת אותה). בד"כ תשתיות מאפשרות לך לבחור מול מה עובדים.

יש גם את בעיית הביזור, כאשר sessions נשמרים בזכרון, קשה לבזר אותם למכונה אחרת.

כך גם caching: לדוגמא, ב-Django אני לא צריך להתחייב מראש איך אני רוצה לשמור cache (בסיסי נתונים, קבצים, memcached) וכך ניתן להחליפם בעת הצורך ללא לגעת ביישום.

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

לגבי כמה ש-fastcgi נהדר, אתה מפספס את הנקודה. האפליקציה שלך הופכת להיות תלויה ביישום ספציפי. עוד חצי שנה יש את super duper extra speedy cgi. בתשתיות דינאמיות אין לך בעיה, מאחר והיישום אינו קשור לצורת ה-deploy.

לגבי החלטה על סוגי מתכנתים משהו בסגנון "מתי אני עלול להעתיק buffer בגדול של כמה עשרות K ומתי לא. כי זה פשוט לא שקוף" זו מחלה טיפוסית של מתכנתי C. כמובן שזה אמור לעניין ואתה צריך להיות מודע לזה, אך זה לא אמור לעניין אותך בפיתוח. כאשר זו בעיה אז מטפלים בזה (premature optimization וגו').


DiamondDog: שלא יהיה לך ספק, אף אחד לא בא לרסק חלומות, להיפך, וכשאפשר עוזרים. אך איני מקבל הנחות יסוד שאינן מתיישבות נכון עם מה שמתרחש באמת בשרתים עמוסים או עם ניסיון שנצבר (במיוחד כאשר ההנחות מתבססות על micro benchmarks או ניסיון עם שיטת עבודה אחת ולא עם מגוון שיטות שכאלה), ולא מדובר רק בפיתוח אלא על ליווי הקוד לאורך זמן ובצורה שוטפת.

ציטוט:

כשאני מריץ אפליקציית Django דרך fastcgi היא גם persistent.

python interpreter עצמו presistent או יישום שכתוב ב-python. קרי אם הגדרת משתנה/קלאס "גלובלי" אז הוא יישמר עד לחיבור הבא עם כל התוכן? למשל אם תשמור את ה-templates או נתוני משתמשים ועוד?

אני יודע שכמובן גם ב-python כמו גם בשפות אחרות אפשרות לכתוב יישום fcgi. אבל במקרים רבים כמו למשל במקרה של php עבודה מול fcgi סה"כ משמשת כלי להרצת php מחוץ לשרת.

ציטוט:

לגבי החלטה על סוגי מתכנתים משהו בסגנון "מתי אני עלול להעתיק buffer בגדול של כמה עשרות K ומתי לא. כי זה פשוט לא שקוף" זו מחלה טיפוסית של מתכנתי C.

אני מבין על מה אתה מדבר, אבל אני חולק בנקודה זו, למשל ב-++C קל מאוד לכתוב

string s=result+"Hello"+ someting else וזה בסדר אם זה נעשה פעם או 100 פעמים בתוכנה, אבל אם זה מתבצע 10000 פעמים בשניה זה לא יעיל. מסיבות שציינתי.

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

ציטוט:

לגבי כמה ש-fastcgi נהדר, אתה מפספס את הנקודה. האפליקציה שלך הופכת להיות תלויה ביישום ספציפי. עוד חצי שנה יש את super duper extra speedy cgi. בתשתיות דינאמיות אין לך בעיה, מאחר והיישום אינו קשור לצורת ה-deploy.

יבוא super duper cgi+++^2 אז אני אוכל להשתמש בו כבסיס נוסף לספריה שלי, כל עוד יהיו ספריות להממשק או הפרוטוקול יהיה מספיק שקוף לממש אותו.

זו לא הבעיה. מצידי שיחליפו פרוטוקול הרעיון נשאר אותו רעיון:

- יישום שנמצא כל הזמן בזכרון.
- יישום שמקבל שאילתות מהשרת ועונה עליהם

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

לגבי צורת deploy, אני מתכוון לתמוך בשיטות שונות של caching של ביזור ועוד. כפי שכתבתי לעיל.

בכל אופן...

אם אפשר לכתוב יישומי web ב#C או ב-Java אין שום סיבה לא לכתוב אותם ב++C.

אלו פחות או יותר המטרות שלי:
- לבנות סביבה נוחה לבניית יישומי web ב++C.
- להוכיח, ש-framework מבוסס ++C יהיה יעיל יותר מדומים המבוססים על שפות משוערכות/jit.

אבל בשביל להוכיח את הטענה השניה, אצטרך לעבוד "קצת"...

ארתיום :

אם אפשר לכתוב יישומי web ב#C או ב-Java אין שום סיבה לא לכתוב אותם ב++C.

אני אתעכב רק על הנקודה הזאת עכשיו, אם כי יש לי גם הערות לדברים אחרים שנאמרו.
האם אפשר לכתוב ישומי web ב ++C? כמובן.
אבל מכאן לכך שאין שום סיבה לא לכתוב אותם ב ++C? הסיבה היא שזאת לא השפה המתאימה (לדעתי). יש דברים ששפות low-level לא מתאימות להן.
אני יכול להקצין את האמירה שלך לאמירה הבאה:

אם אפשר לכתוב תסריטי הרצה ב bash, אין שום סיבה לא לכתוב אותם ב ++C.

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

יש עוד מקרים לא מעטים בהם כתיבה בשפות אחרות (יותר high-level, או מתודולוגיות פיתוח אחרות, או יותר פורטביליות וכו') עדיפה על כתיבה ב ++C (ואתה יכול להחליף את ++C בכל שפה X).

אה, ולגבי ה url-ים בקצרה.

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

http://www.exampleblog.com/archive/2007/11/15/name-of-entry

בתור מי שבונה מערכת תוכן, אני ארצה כלי שיעשה לי decoupling בין תכנון ה url-ים לבין הפונקציה שתקרא בסוף.
הייתי רוצה להגיד (כנראה ע"י regex) איך נראים כל ה url-ים שיפעילו את הפונקציה שתציג את name-of-entry, אבל שאני אוכל בקלות להגדיר בשלב מאוחר יותר שגם url כדוגמאת

http://www.exampleblog.com/archive/2007/nov/15/name-of-entry

יפעיל את אותה הפונקציה (וגם יכניסו את התאריך כקלט לפונקציה)

בקיצור, כלי נוח שיתן לי להגדיר את הממשק שלי מול המשתמש בתחום ה url-ים, ושידע להפעיל פונקציה ספציפית עם פרמטרים ע"פ התאמה ל regex.

mksoft :

DiamondDog: שלא יהיה לך ספק, אף אחד לא בא לרסק חלומות, להיפך, וכשאפשר עוזרים. אך איני מקבל הנחות יסוד שאינן מתיישבות נכון עם מה שמתרחש באמת בשרתים עמוסים או עם ניסיון שנצבר (במיוחד כאשר ההנחות מתבססות על micro benchmarks או ניסיון עם שיטת עבודה אחת ולא עם מגוון שיטות שכאלה), ולא מדובר רק בפיתוח אלא על ליווי הקוד לאורך זמן ובצורה שוטפת.

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

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

הקפצה:

אם מישהו מעוניין, כתבתי קצת על התקדמות של בניית Web Development Framework ב־++C.

http://art-blog.no-ip.info/wp/index.php/2007/11/23/cppcms_first_look/

אגב - smart urls בפנים.

עוד שאלה מעניינת

אני מתלבט בין ספריות C++/C השונות שמספקות API אחיד לבסיסי נתונים שונים, בין השאר אני מתלבט אם פשוט לכתוב כזה עבור postgresql/sqlite3/mysql או אם להשתמש ב-libdbi (שיש שם חלק מהדברים שאני לא גמרי מחבב) או להשתמש במשהו יותר כבד כמו odbc.

המלצות?

יפה

חיפוש ברשימות הדיוור של boost העלה את SOCI, אולי זה יעניין אותך:
http://soci.sourceforge.net/

ולדיון עצמו:
http://lists.boost.org/Archives/boost/2006/12/113961.php

ראיתי את soci וחייב לציין שהוא נראה די חביב...

אבל יש בו משהו שלא לגמרי מוצא חן בעיניי (לפחות ממבט הראשון):

בניקוד ל-libdbi שיודע לטעון מודולים של בסיסי נתונים לפי הצורך ב-soci זה די hard coded - קרי דורש קימפול מחדש... (ייתכן ופספסתי משהו).

בכל אופן זה הדבר הקרוב ביותר שמצאתי.

אההה...

עוד משהו קטן, אני חושב שהם "קצת" הגזימו כשעשו overloading ל-","...

ככל שאני נכנס עמוק יותר לתוך boost אני מתחיל להבין שבעצם ב-++C אפשר לעשות הכל ובכל syntax אפשרי

אולי פספסתי משהו, אך כתוב באתר שלהם:

קוד:

Starting from its 2.0.0 release, SOCI uses the plug-in architecture for backends - this allows to target various database servers. Currently (2.2.0), the following database servers are supported:     * Oracle     * PostgreSQL     * Firebird     * MySQL     * SQLite     * MS SQL Server (via ODBC)

לגבי מה שאפשר לעשות ב-C++, לא משנה הלבוש, זה עדיין ייראה כמו מוטציה

העניין הוא כזה:

אתה מציין במפורש בקוד שלך ע"י include soci/mysql/blabla.h
את המנוע שאתה רוצה להשתמש בו.

וזה גורם לך executable חייב לטעון so של libmysqlclient או כל ספריה אחרת.

קרי, אם אני רוצה ש-executable שלי ידע לעבוד לפי בחירה עם 3 בסיסי נתונים PgSQL/MySQL/Sqlite3 אז שלושת בסיסי הנתונים (או לפחות clients) אמורים להיות מותקנים.

לעומת זאת, libdbi לא דורש זאת, הוא יודע לטעון shared object לפי דרישה.

לא צריך אצלך ממילא בניה מחדש רק כדי לעדכן דפים?

צפריר :

לא צריך אצלך ממילא בניה מחדש רק כדי לעדכן דפים?

ממש לא!

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

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

template נכתבים בשפת templates מאוד פשוט עם פעולות בסיסיות שמומרות ל-opcode שנטען ע"י התוכנה.

למעשה לאחר שאני מגדיר ממשק בין templates לבין הקוד כל מה שצריך לעשות זה "למקמפל" את הtemplates למבנה פנימי וזהו. (שזה בסה"כ חוסך text parsing בקוד יישום עצמו ומפשט ממשק).

עדכון... לכל מי שלא האמין...

עלה בלוג פיתוח המערכת CppCMS שכמובן נכתב ב-++C בעזרת libcppcms.

זאת מערכת תוכן ראשונה (עדיין מאוד פשוטה ונמצאת בשלבי בטא) שבניתי בעזרתו.

http://art-blog.no-ip.info/cppcms/blog

כמובן יש עוד דרך ארוכה, אבל בלי מערכת תוכן קיימת כלשהי, קשה לראות את הכיוונים הנכונים.

מזל טוב , גם המימוש היה יחסית מהיר.

mksoft :

מזל טוב ,.

תודה

mksoft :

גם המימוש היה יחסית מהיר.

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

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


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

אההה....

האם יש כבר מעוניינים להשתמש בה? או ש++C עדיין מפחיד מידי?