CTOR ו DTOR

הם קיצורים נפוצים לconstructor / destructor.

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

obj x;
try
  x=obj();


catch(ex){
...
}




continue the code...
use x somewhere

הרי יש לנו exc כדי לתפוס אותם במהלך הקוד ולהתגבר על שגיאות שקרו.

X הוא אובייקט ref. הוא קיים בזיכרון (HEAP), לא שחררת אותו כשיצאת בצורה אלימה מהCTOR. (דליפת זיכרון)

אבל אתה לא יכול "לאפס" אותו. גם אם יש בו רק members פשוטים כמו INT. אי אפשר לגעת בו יותר...

אם X חשוב לא רק מקומית ? נגיד שהוא איזה סינגלטון גלובלי שלך לדוגמא ? דפקת אותו.

אתה מציע לבצע את הEXIT בפונקצייה אחרת במחלקה?

RollStorm:

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

עוד אחד:

אתה מבלבל בין ++C ושפות מנוהלות כמו #C ו-Java. ב-++C, רק דברים שהוקצו דינמית (באמצעות new/malloc) מוקצים על ה-heap - כל השאר על ה-stack.

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

obj x;

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

x = obj();

עושה שני דברים:

א. יוצרת אובייקט זמני מטיפוס obj באמצעות הבנאי שלא מקבל פרמטרים.

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

אם בעת היצירה של ה-obj הזמני תעוף חריגה אז לא יקרה כלום, כי התוכן של x יהיה זה שנוצר בעת היצירה של x בהתחלה.

(כמובן, גם ב-#C וג'אווה אין כאן שום בעיה, כי אם יש חריגה ביצירת ה-obj אז התוצאה בכלל לא תושם לתוך x, והוא ימשיך להצביע למה שהוא הצביע לפני כן)

החריגות נימצאות אצלי בספר רק אחרי תורשה חפיפות איסוף דינמי של זיכרון

עצים בינאריים ממש בסוף(שמו של הספר :C++ כשפת אם)

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

או שאתה מציע לי לקפוץ עכשיו ולקרוא ולתקן וכו?

לא, תלמד על חריגות כשתגיע אליהן.

מה שמומלץ לעשות בינתיים הוא מה ש"עוד אחד" הציע, ואני הצעתי בהודעה הקודמת: תוסיף עוד איבר ל-rect מטיפוס bool, שאומר האם הבנייה הצליחה או לא. אם יש שגיאה בבנאי אז תגדיר אותו ל-false, אחרת ל-true. ואז תגדיר למחלקה פונקציה נוספת שמחזירה את אותו איבר. אז ה-main צריך פשוט לקרוא לפונקציה הזו אחרי יצירת ה-rect, וככה היא תדע אם הוא נוצר בהצלחה.

זה כבר אני אעשה מחר

שברתי את כל היום ואתמול בלהבין מה לא נכון בתוכנית

גג אדבר עם אחד מכם אם יהיו בעיות

תודה רבה רבה

אפשר לנעול

לא - אם עוד לא למדת חריגות - אל תסתבך איתן.

פתרון במקרה שלך לדוגמא - בדוק את הקלט של a,b לפני שאתה שולח אותו לבנאי (ב MAIN)

עוד אחד:

אתה מבלבל בין ++C ושפות מנוהלות כמו #C ו-Java. ב-++C, רק דברים שהוקצו דינמית (באמצעות new/malloc) מוקצים על ה-heap - כל השאר על ה-stack.

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

בכל מקרה התכוונתי במקרה שמדובר באובייקט על ה HEAP. (כלומר לא משוחרר בקלות ע"י סגירת ה FRAME בזיכרון ברגע שה scope נסגר)

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

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

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

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

זה גם מה שאני חשבתי.

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

נסה.

זה פשוט לא נכון. אתה מוזמן להעלות קטע קוד שמוכיח את צדקתך...

יכול להיות שזה תלוי קומפיילר?