בעד ונגד שימוש ב MFC

[ilankt]

בעד ונגד שימוש ב MFC

אני די בטוח שאני יתחיל פה עוד מלחמה, אבל, למה לא?

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

 

[andav]

בלי שאני מבין הרבה - QT

של trolltech

 

[desertboy]

בהחלט ../images/Emo45.gif

ובכלל בכל מקרה אין טעם לעשות משהו עם mfc אלה אם יש לך נטיות מזוכיסטיות.

 

[voguemaster]

המממ

כמה דברים: 1. MFC היא דבר נחמד וקליל עבור דברים טריויאליים. 2. הבעיה היא שגם QT היא כזו. היא לגמרי לא בשלה ודברים מסובכים יכולים לגרום לך להקיז דם. יש בה הרבה נואנסים שצריך ללמוד והיא בכלל אבל בכלל לא דבר של מה בכך. מניסיון אני אומר, היא אומנם ה-widget library הכי בשלה בלינוקס לדוגמא אבל היא לא קלה לפיתוח. שלא לדבר על זה שבגרסא שלה לחלונות היא רק בגרסא 2 ולא חינמית.

 

[desertboy]

אם אפשר

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

 

[voguemaster]

אפשר אפשר

עבדתי עם QT עד לפני ממש כמה שבועות. אז ככה: 1. בוא נתחיל מזה שאין בונה GUI אוטומטי כמו שצריך. היחיד שמתקרב ללהיות נורמלי הוא QT DESIGNER והם החליטו ללכת על כיוון מאוד מעניין של קובץ מבוסס XML שהוא מייצר לך. אפשר להתווכח על האם זה נכון או לא לעבוד בצורה כזו. בסביבות פיתוח אחרות זה לא עובד כך, הקוד משולב לאן שאתה אומר לו. וגם אם סביבות אחרות שומרות פנימית את ה-XML הזה, אתה בתור תוכניתן לא נחשף אליו אף פעם. כשאתה עובד עם QT DESIGNER אתה לא יכול להימנע מזה, פשוט כך. לעבוד עם KDEVELOP ללא QMAKE זה סיוט מההפטרה. שילוב גם של autotools וגם של ניהול פרויקט שלם וזה לא מבוצע כמו שצריך. כמו שאתה יודע, בכל פעם שאתה משנה form מסוים ב-DESIGNER אתה חייב להעביר אותו קומפילציה ע"י uic. קורה, מתישהו KDEVELOP הורס לך את הקבצים בצורה כזו שהוא לא מריץ את זה יותר. זה פשוט נורא קל, אפילו אם אתה לא עורך שום דבר ידנית. הכל מתוך סביבת העבודה. אין מספיק בשלות. הלאה, אתה יכול לעבוד עם QMAKE דרך KDEV אבל זה גם לא אידאלי. הדרך האמיתית לעבוד בצורה מסודרת עם QT זה לעבוד עם סביבת פיתוח אבל ליצור Makefile בעזרת QMAKE. הבעיה - QMAKE זה כלי ייעודי שנועד לעבוד בצורה מסוימת ונותן פיתרון אחד ויחיד לסביבה אחת. הוא מצוין בלנהל את כל נושא ה-uic וה-moc compiler אבל בזה זה נגמר. אין לו את הגמישות של autotools. כך יוצא שאין לך פיתרון כולל טוב. אם אתה עובד עם QMAKE, זה רק לסביבה מסוימת וצורת בניה מסוימת. אם אתה עובד עם autotools אין לך את הסקריפטים המתאימים כדי לשלב את הפונקציונליות של uic ו-moc. אתה צריך את הסקריפטים האלה אחרת automake לא ידע איך לשלב אותם ב-Makefile. לצורך העניין, החבר'ה של KDEV כתבו כאלה אבל לך תדע איך הם עובדים ומה צריך לעשות כדי להשתמש בהם. 2. עכשיו כשכיסינו את האופציות של הפרויקט, בוא נדבר פרטנית על הספריה. עבודה עם אובייקטים של QT היא לא תמיד נוחה ואינטואיטיבית. לעבוד עם tree זה דבר מעצבן (מניסיון). לעשות עליו מניפולציות זה עוד יותר גרוע. שלא לדבר על זה שהחבר'ה של QT ניסו לגנוב רעיונות מג'אווה (הצליח חלקית) אבל לא עשו את זה נכון. אין בכלל את כל הנושא של tree model ואתה נדרש לרשת מ-node כדי שיהיה לך node שפועל. כאילו שזה לא מספיק, אתה חייב לבצע cast בחזרה בכל פעם שאתה מאחזר node מתוך העץ כי מה לעשות שהעץ מכיר רק את טיפוס הבסיס של ה-node שלו ואתה לפעמים צריך לבצע דברים עם node מסוג חדש. 3. סידור GUI כמו שצריך - לוקח לא מעט זמן להתמקצע בבניית GUI כמו שצריך, גם אם זה דרך QT DESIGNER. צריך לעבוד נכון עם spacerים וקבוצות. לא טריויאלי לגמרי כי אין הסברים ודוגמאות איך לעצב כל מיני דברים מיוחדים. אין הסברים על הנואנסים של הפקדים (אני לא אומר שיש ב-MFC אבל שם הם מתנהגים אינטואיטיבי). 4. לגבי הטענה שלך שאפליקצית QT תדרוש פחות שורות קוד - תביא סימוכין, אל תזרוק באוויר. אני בכלל לא בטוח שאתה צודק. 5. דבר אחרון וחשוב מאוד - החבר'ה שמפתחים את QT באופן קונסיסטנטי למדי משנים דברים בספריה שלהם בצורה קיצונית. לצורך העניין זה גם גורר שינויים די מאסיביים ב-KDE בלינוקס. זה מתחיל להזכיר את מיקרוסופט אבל דבר אחד אפשר להגיד על מיקרוסופט - הם מנסים לשמור על תאימות אחורה ולא לשנות יותר מדי אובייקטים קיימים (לא תמיד הולך להם

). ב-QT המצב אחר - הם לפעמים יכולים לעשות שינויים קיצוניים ולא אכפת להם בכלל. אנחנו מדברים על מצבים שאפליקציות שנכתבו עם גרסאות ישנות של הספריה לא ירוצו דומה בכלל עם גרסא חדשה. פשוט לא לעניין. בקיצור, גם למיקרוסופט וגם ל-trolltech יש הרבה מה ללמוד מסאן בכל מה שקשור ב-DESIGN נכון ותכנון של כלי UI. ג'אווה פשוט שמה את שניהן בכיס הקטן, בלי להתווכח בכלל. ולמרות שסאן משנים את ה-API שלהם מגרסא לגרסא הוא בד"כ עובד עם תאימות אחורה (למרות הערות deprecation) ומתנהג בצורה קונסיסטנטית.

 

[desertboy]

אהם

1. לגבי autotools גם אני לא ממש אוהב את המפלצת הזאת (אם כי אני לא נתקל בבעיות עם ניהול הפרוייקט ב kdevelop) , ופה בדיוק עוד יתרון של QT הם Qmake מערכת ניהול פשוטה ביותר ועושה את העבודה . חיסרון של autotools הוא לא חיסרון של Qt (במיוחד. 2. לגבי Designer פה אני חולק אל דעתך אני מצאתי אותו מעוד פשוט לקח לי בערך חצי שעה להתמצות באיך הדברים עובדים , אם נשווה לג'אווה (לגבי swing) עוד לא נתקלתי ב Designer טוב הכי טוב שנתקלתי בו הוא של Intelij שלמעשה מזכיר מאוד את Qt designer אבל הרבה יותר מצומצם וגם אז אתה נעול על Intelij . 3. לגבי ה Tree וה Listview ועוד כמה אתה צודק לחלוטין , בעיות אלו נענות בגירסה 4 (אם עוד כמה דברים) ככה שכיום יש הפרדה מוחלטת בין ה modek וה view שלבטח זה הרבה יותר נוח . 4. גבי התאימות ב Qt בכל גירסה גדולה יש תאימות מלאה אחורה וקדימה מדי כמה שנים (לדוגמא לגבי Qt 3 זה לקח 4 שנים) מבצעים שינויים ושיפורים משמעותיים כדי לנצל אותם צריך לבצע שינויים לא קיצוניים מדי והמדריכים ש trolltech מספקים בנושא הם מעולים , אני מוצא את הדרך הזאת הרבה יותר טובה מאשר לגלות יום אחד ש api שלך נראה כמו מתקופת האבן (win32) ואתה צריך להליף אותו לחלוטין (winfx) . דרך אגב אחד מהשנויים שביצעו ב Qt4 מאפשר להם לספק תאימות מלאה אחורה אבל אז כמובן אתה לא נהנה מהיתרונות החדשים . 5. לגבי sun אני אוהב לכתוב ב java אבל תאימות אחורה , האם תוכניות שאני יכתוב ב java 5 יעבדו על גרסאות מוקדמות יותר ? אמנם נכון הם מספקים (או סיפקו) תאימות טובה יותר אבל הם שולטים בשפה מכל הכיוונים ובל נשכח שעד יציאת Net. לא ראית שום שינו.שיפור משמעותי ב java במשך כמה שנים חוץ מתוספת של ספריות חדשות . קצת off. לגבי מנהלי פרוייקטים ממליץ לנסות את Scons כלי מעוד נחמד ופשוט , הוא מספק את כל היכולות של automake אבל בצורה פשוטה מאוד עם סקריפט אחד .

 

[voguemaster]

look

1. למעשה, autotools היא לא מפלצת, פשוט כלי חזק מאוד. כמו שאמרתי אין ספק שעבור תוכניות מבוססות QT, הפיתרון הוא QMAKE. מצד שני החיסרון שלו הוא שהוא נותן פיתרון יחיד לבעיה יחידה, בעוד ש-autotools נותן פיתרון לכל תוכנית. 2. לא אמרתי שהוא קשה לשימוש. מצד שני יש בו הרבה דקויות מעצבנות. בוא נגיד כך - ברמת העיקרון אתה לא אמור להיות חשוף לניהול הפורמט שבו נשמרים ה-forms. אם אני בתור מפתח נחשף לזה מדי פעם בגלל כל מיני בעיות מה אתה יכול להסיק מזה ? ולגבי להיות נעול על IJ, מה ההבדל ? המצב גרוע באותה מידה ב-QT, אתה נעול על QT DESIGNER מהסיבה הפשוטה שכל השאר לא עומדים ברמה שלו, כנ"ל לגבי ג'אווה. ההבדל היפה הוא שג'אווה אני יכול לכתוב גם ידנית פי 1000 יותר בקלות מאשר QT. 3. אני מקווה

4. אני לא מסכים לגבי תאימות, בכלל בכלל לא. אם תיקח מערכת מותקנת של לינוקס עם גרסא מסוימת של QT ותשדרג גרסא (בוא נגיד מ-3 ל-3.2) תגלה שהדברים נראים ומגיבים אחרת לגמרי, לפעמים עד כדי התרסקות של המוצר. אין תאימות אחורה. לגבי תאימות קדימה, מה זה בכלל ?

5. תלוי מה תכתוב. אם תכתוב בג'אווה 5 עם חלקים מה-API שקיימים בגרסאות ישנות יותר זה יעבוד. זה לא שונה מ-QT או כל ספריה אחרת. להזכירך שכל תוכנה מלוקקת היום שרוצה גרסא חדשה יותר של QT מכריחה אותך לשדרג את הספריה שלך ? אין באמת מצב שבו אתה מריץ תוכנת QT שדורשת גרסא חדשה בעוד שלך יש גרסא ישנה. זה לא קורה בג'אווה וזה לא קורה ב-QT ולא בשום מצב אחר.

 

[vent91]

תכתוב ב C#

או JAVA

 

[mag net]

למה MFC?

כמו לכל דבר יש יתרונות וחסרונות. לדעתי MFC מספקת כלי GUI נוחים למדי לסביבה חלונאית תוך עקומת לימוד סבירה. לדעתי MFC נוחה יותר מ QT. לגבי השאלה אם לכנס היום ל MFC לדעתי אם אין סיבה מיוחדת התשובה היא לא אם הסביבה שבה התוכנה תרוץ היא חלונות למה לא לבחור ב C#? ואם ברצונך לכתוב אפליקציות קלות WTL עדיפה על MFC. מקווה שלא בלבתי אותך יותר מדי שבת שלום

 

[gmorphus]

../images/Emo45.gif בהחלט

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

 

[מאה קולפה]

ממליץ על C++Builder של בורלנד

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

 

[amirjak]

אני התחלתי ללמוד לא מזמן mfc

ומצאתי שהשד לא נורא כ"כ, התיעוד בmsdn מעולה ועוזר מאד.. העניין שכדי ליצור תוכנות יחסית פשוטות, הקוד עצום וצריך לדאוג להמון דברים בהתנהלות של התוכנה בעצמך.. משהו שקשה למתחיל כמוני, מה שכן אם עובדים בצמוד עם msdn וספר טוב הספריה הזו מתגלה דווקא כספריה נוחה שנותנת המון כוח ליישום. בנוגע ל.net, יצא לי לעבוד עם זה טיפה וממה שראיתי כל מה שנוגע לgui הוא הרבה יותר פשוט, יש לך את הקלות של יצירת הgui מvb ואת הכוח להשתמש באיזה שפה שאתה רוצה ובספריה חדשה וממומשת בצורה טובה.

 

[voguemaster]

עצום ?? ../images/Emo2.gif

על מה אתה מדבר ? הוא לא קרוב ללהיות עצום בכלל. וה-FRAMEWORK מטפלת לך במלא דברים אוטומטית. מאיפה הבאת את הטענה הזאת ?

 

[amirjak]

....

הקוד שנוצר בשביל יישום פשוט הוא בהחלט יותר מhello world בסי ככה שהמעבר לסביבה הזו די הרתיע אותי בהתחלה לא לדבר על הצורך שלי להבין כל דבר שהFRAMEWORK והאשפים עושים.. אני לא אוהב להסתמך על מה שהסביבה הזו עושה בשבילי... ובשביל מישהו שלא תכנת בסביבת חלונות ולא מקבל בעיניים עצומות מה שנכתב בשבילו אוטומטית זה נראה המון...

 

[voguemaster]

אוקיי הבנתי אותך

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

 

[amirjak]

 

[ניר טייב]

נצל"ש - מה זה GTK ?

והאם זה קשור בכל העניין של יצירת GUI ? תודה

 

[desertboy]

The GIMP Toolkit

כן, עוד toolkit נחמד יותר מידע תמצא כאן