נו באמת, ממך הייתי מצפה ליותר.
1. כמו שאמרתי, format אפשר להוסיף בקלילות למחלקה, אם זה מה שחסר לך. ומה זאת אומרת "אל תערבב"? אנחנו מדברים על מחלקה אחת, שיש בה "יתרונות" ויש בה המון חסרונות. ברור שאני "אערבב", ברנדל. המחלקה היא גוש אחד, וצריך להתייחס אליה ככזו, על כל מגרעותיה. היא לא OOP-ית והיא לא פורטבילית. 2. האופרטור שהבאת מתייחס ל-LPCTSTR. נסה להמיר את המחרוזת ל-*char. 3. "מבנה נתונים נוסף"? אתה מדבר על מערך של char-ים? זה "מבנה נתונים", זה? תעשה לי טובה
. ושנית, c_str מחזירה לך CONST, ואילו GetBuffer נותנת לך לשנות את תוכן ה-STRING. זה פתח לצרות. למשל, מה יקרה אם ביקשתי 10 תווים ובטעות דרסתי אותם? 4. אתה צודק, דיברתי על מיידי בקונטקסט של (3). לגבי LoadString, אתה צודק, בשימוש ב-std::string אני איאלץ להעתיק את ה-BUFFER אל המחרוזת. ללא ספק, לתוכנות בהן 90% מהפעילות היא LoadString הייתי ממליץ לעבוד עם CString
. 5. שטויות, ברנדל. הבעיה היא ש-CString היא מאוד, מאוד
ספציפית. אתה מבין, כשתכננו את std::string תכננו אותה לכל מחרוזת שהיא, בכל פלטפורמה שהיא. זה היתרון הגדול שלה. אם אתה תוכניתן WINDOWS שנשבע אמונים ל-MFC ולא מתכנן לעולם לעבור למשהו אחר, אולי עדיף לך לעבוד עם CString. אישית זה נראה לי כמו לכתוב year בשתי ספרות, אבל זו כבר הבעיה שלך. אתה אח"כ תצטרך לעשות שמיניות באוויר כדי לעבור ל-string נורמלית, פורטבילית, וגמישה. בד בבד, זה ש-string גמישה מונע מבעדה להחזיק באי אילו פונקציונליות. מחלקה כמו CString שחושפת את הקרביים שלה קובעת הלכה למעשה גישה מאוד מסויימת שאי אפשר יהיה לשנות אותה אח"כ. אתה מסתמך היום על כך ש-GetBuffer מחזירה לך כך וכך. מחר יכול להיות שירצו לשנות, ואז יצטרכו לעשות CString2. נהדר
6. ברור שאין מאמר שעושה פעולה הפוכה, כי אין צורך. CString קנתה אותך תמורת נזיד עדשים. כמו שכל בר דעת יכול לראות במאמר, הפונקציונליות של CString ממומשת במספר שורות קוד פשוטות, ולכן אין שום סיבה
בעולם לוותר על הגמישות ועל הפורטביליות של std::string.