איטרטורים

[Zack DA]

אז לא יכלת לחכות עד יום ראשון ? ../images/Emo10.gif

אתה מתחיל לעצבן אותי עם הקשקושים האלה שלך בקשר ל- JAVA...

 

[vinney]

הזהרתי אותו ../images/Emo8.gif

 

[DadleFish]

אני לא יכול להתאפק

וחוץ מזה, עכשיו כבר יום ראשון

 

[DadleFish]

וחוץ מזה, מה שנכון נכון.

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

 

[DadleFish]

תשים לב,

ש-erase ב-list מחזירה לך את האיטרטור הנכון (הבא). הכי אינטואיטיבי. מה גם שבד"כ אתה יכול למחוק איברים בלי צורך באיטרטורים. למשל, תוך שימוש ב-remove.

 

[annefan]

אכפת לך להסביר את השאלה?

(כן, קראתי את הפתיל, ולא הבנתי מה אתה רוצה לעשות)

 

[gmorphus]

זו לא שאלה...

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

 

[annefan]

זה יותר חריף ממה שאתה חושב

בוקטור: 1. מחיקת אלמנט "שוברת" את כל המצביעים, הפניות ואיטרטורים שאחרי האלמנט הזה. 2. הכנסת אלמנט, עשויה שלא לשבור הכל, אלא אם כן ההכנסה גורמת להקצאת זכרון נוסף, ואז הכל (עלול) להישבר. ב-deque: הכנסת אבר (מלבד בהתחלה ובסוף) שוברת הכל. בהתחלה ובסוף רק איטרטורים נשברים. 3. ברשימה שום דבר לא נשבר.

 

[vinney]

אני לא חושב שזה צריך להוות שיקול

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

 

[annefan]

במקרה הזה אתה טועה

מה שכתבתי הן הדרישות של הסטנדרט מה-containers השונים, ללא תלות במימוש. כיוון שאיטרטור לא חייב להיות מצביע (כמו ב-STL של VS7.1) לא הכרחי שאינוולידציה של אחד תגרור את השני.

 

[vinney]

לא הכרחי

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

 

[annefan]

מה לא הכרחי?

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