ABA


"חידה: למה אופרטור prefix יעיל יותר מאשר postfix"
גירסת הדפסה        
קבוצות דיון פיתוח, תיכנות ובניית אתרים נושא #15675 מנהל    סגן המנהל    מפקח   Winner    צל"ש   מומחה  
אשכול מספר 15675
ldan192 
חבר מתאריך 14.9.08
95119 הודעות
   12:03   14.01.10   
אל הפורום  
  חידה: למה אופרטור prefix יעיל יותר מאשר postfix  
 
מי שרוצה רמז שיבצע תגובה עם ציטוט.



בברכה,
עידן


                                שתף        
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

  האשכול     מחבר     תאריך כתיבה     מספר  
  אממ שמשון פישטונה 14.01.10 12:45 1
     בדיוק :) ldan192  14.01.10 12:47 2
     לא בדיוק נכון TTAsnn 14.01.10 20:34 3
         כתבתי כבר שזה תלוי בסוג הטיפוס, שמשון פישטונה 14.01.10 21:06 4
             הוא לא זניח, הוא לא קיים. TTAsnn 14.01.10 21:18 5
                 תממש מה שביקשתי ותחזור לפה :) ldan192  14.01.10 23:51 11
             זה תלוי קומפיילר מן הסתם DLN 14.01.10 22:32 6
                 קשה לי להאמין שיש קומפיילרים מפגרים, אולי בעבר הרחוק מאוד (1980 ומשהו) TTAsnn 14.01.10 22:40 7
                     לא הייתי כזה קשה אמונה במקומך DLN 14.01.10 22:58 8
                         אני סומך על gcc :) הוא לא יעשה שום דבר בשביל לפגוע בי! TTAsnn 14.01.10 23:00 9
         זה לא מדוייק, מהסיבה הפשוטה שהתעסקת עם טיפוסים ldan192  14.01.10 23:48 10
             לא רואה הבדל. TTAsnn 15.01.10 01:19 12
                 שוב, אתה רק מדבר אבל לא מממש :) ldan192  15.01.10 01:50 13
                     לא יודע מאיפה הציטוט, אבל לא רשמתי ''אופקוד אחד הבדל'' TTAsnn 15.01.10 17:59 16
  מישהו מתכוון להרים את הכפפה ולהביא פה קוד? Deuce  15.01.10 14:17 14
     קצת פספסתם את הנקודה, בכל מקרה, הכוונה שלי הייתה ldan192  15.01.10 14:33 15
     הרמתי את הכפפה ב C, ב CPP עוד לא היה לי זמן, כמעט ולא בבית. TTAsnn 15.01.10 18:01 17
         תגובה לשניכם, Deuce  16.01.10 04:19 18
             זה לא קשור לאופטימיזציה! TTAsnn 16.01.10 17:42 19
                 קודם כל, זה לא מדוייק מהסיבה שפעולה אחת ldan192  16.01.10 19:23 20
                     אני לא מבין על מה אתה מדבר TTAsnn 16.01.10 20:18 21
                         טוב, קשקשת מספיק. מה אתה מצפה שאומר לך, ברצינות. ldan192  16.01.10 20:38 22
                             תתחיל בלענות תשובות רלוונטיות. TTAsnn 16.01.10 21:29 23
                                 תשמע, אם ברצינות לא הבנת אז אני אסביר שוב. ldan192  16.01.10 23:35 24
                                     הדבר היחיד שכתבת שאני מסכים איתו זה 3. (רק לגבייך) TTAsnn 17.01.10 00:06 25
  תותח ! תודה :) Sagittarius 21.01.10 15:04 26

       
שמשון פישטונה

   12:45   14.01.10   
אל הפורום  
  1. אממ  
בתגובה להודעה מספר 0
 
   עקרונית עם תשתמש בשניהם על int ההבדל ביעילות הוא זניח ואי אפשר להבחין בו.

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

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

וprefix פשוט משפיע ישירות על כתובת המקור של האובייקט בזיכרון.


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
ldan192 
חבר מתאריך 14.9.08
95119 הודעות
   12:47   14.01.10   
אל הפורום  
  2. בדיוק :)  
בתגובה להודעה מספר 1
 


בברכה,
עידן


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   20:34   14.01.10   
אל הפורום  
  3. לא בדיוק נכון  
בתגובה להודעה מספר 1
 
   סתכל על:

#include <stdio.h>

int main()
{
int a,b;
b = 5;
a = b++;
return 0;
}

לעומת:


#include <stdio.h>

int main()
{
int a,b;
b = 5;
a = ++b;
return 0;
}

הראשון מתרגם לאסמבלי הבא: (gcc)


0x08048374 <main+0>: push ebp
0x08048375 <main+1>: mov ebp,esp
0x08048377 <main+3>: sub esp,0x10
0x0804837a <main+6>: mov DWORD PTR [ebp-0x4],0x5
0x08048381 <main+13>: mov eax,DWORD PTR [ebp-0x4]
0x08048384 <main+16>: mov DWORD PTR [ebp-0x8],eax
0x08048387 <main+19>: add DWORD PTR [ebp-0x4],0x1
0x0804838b <main+23>: mov eax,0x0
0x08048390 <main+28>: leave
0x08048391 <main+29>: ret

והשני ל


0x08048374 <main+0>: push ebp
0x08048375 <main+1>: mov ebp,esp
0x08048377 <main+3>: sub esp,0x10
0x0804837a <main+6>: mov DWORD PTR [ebp-0x4],0x5
0x08048381 <main+13>: add DWORD PTR [ebp-0x4],0x1
0x08048385 <main+17>: mov eax,DWORD PTR [ebp-0x4]
0x08048388 <main+20>: mov DWORD PTR [ebp-0x8],eax
0x0804838b <main+23>: mov eax,0x0
0x08048390 <main+28>: leave
0x08048391 <main+29>: ret

כמו שאתה רואה, ההבדל הוא רק בסדר, שום העתקה שום דבר.

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


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

   21:06   14.01.10   
אל הפורום  
  4. כתבתי כבר שזה תלוי בסוג הטיפוס,  
בתגובה להודעה מספר 3
 
   בטיפוסים פרימיטיביים ההבדל הוא זניח ולא בר הבחנה בכלל,

ברגע שתגיע למצב (למרות שיש מקרי קצה) של opreator overloading אז אתה תראה הבדל משמעותי.

http://www.velocityreviews.com/forums/t291031-prefix-vs-postfix.html
http://www.devx.com/tips/Tip/12634


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   21:18   14.01.10   
אל הפורום  
  5. הוא לא זניח, הוא לא קיים.  
בתגובה להודעה מספר 4
 
   אין שום הבדל בין שני חתיכות הקוד שהראתי (למעט סדר), ככה שההבדל לא זניח, הוא פשוט *לא* קיים.

חוץ מזה, שבשתי הדוגמאות שהבאת, פשוט כתוב את מה שאמרת בלי הוכחה.
הלינק הזה:
http://www.velocityreviews.com/forums/t291031-prefix-vs-postfix.html
עולה כל פעם שמישהו שואל את ה"חידה" הזו.

הלינק השני:
http://www.devx.com/tips/Tip/12634
נכתב לפני כ"כ הרבה שנים, שיש מצב שלא היה אז אופטימיזציות טובות בקומפיילרים, למרות שקשה לי להאמין, ונראה לי שמה שהוא כתב שם זה בדיוק כמו שכתבת עכשיו, מבוסס על איזה סיפור אורבני. זה סוג של תושב"ה, אבל אף פעם אף אחד לא סיפק הוכחה.
אין שום סיבה שתצטרך להעתיק ואז להשתמש, שינוי הסדר יכול לסדר הכל.
תן דוגמה נגדית (קוד ו disassembly) ואז אולי יהיה לזה ביסוס.
שוב, בינתיים אין שום סיבה.

יכול להיות שזה נכון, אני לא אומר שלא, אני רק אומר שזה רץ באינטרנט שנים ואף פעם לא ראיתי מישהו עם דוגמה תומכת.


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
ldan192 
חבר מתאריך 14.9.08
95119 הודעות
   23:51   14.01.10   
אל הפורום  
  11. תממש מה שביקשתי ותחזור לפה :)  
בתגובה להודעה מספר 5
 


בברכה,
עידן


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
DLN
חבר מתאריך 20.4.07
15884 הודעות
   22:32   14.01.10   
אל הפורום  
  6. זה תלוי קומפיילר מן הסתם  
בתגובה להודעה מספר 4
 
  


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   22:40   14.01.10   
אל הפורום  
  7. קשה לי להאמין שיש קומפיילרים מפגרים, אולי בעבר הרחוק מאוד (1980 ומשהו)  
בתגובה להודעה מספר 6
 
  


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
DLN
חבר מתאריך 20.4.07
15884 הודעות
   22:58   14.01.10   
אל הפורום  
  8. לא הייתי כזה קשה אמונה במקומך  
בתגובה להודעה מספר 7
 
   קומפיילרים יכולים לעשות דברים טיפשיים מאוד
את זה ספציפית אני לא מכיר


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   23:00   14.01.10   
אל הפורום  
  9. אני סומך על gcc :) הוא לא יעשה שום דבר בשביל לפגוע בי!  
בתגובה להודעה מספר 8
 
  


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
ldan192 
חבר מתאריך 14.9.08
95119 הודעות
   23:48   14.01.10   
אל הפורום  
  10. זה לא מדוייק, מהסיבה הפשוטה שהתעסקת עם טיפוסים  
בתגובה להודעה מספר 3
 
פרמטיביים ולא רפרנס טייפ.
החידה הייתה כמובן מכוונת לרפרנס טייפ, כי ברור שכל קומפיילר מבצע אופטימיזציות.
מה שגם, גם אם זה מה שאתה קורא טקסטואלית באסמבלי לא אומר שאופטימיזציית קאש מאחורי הקלעים לא תאיץ את אחד קטעי הקוד פי כמה (אפילו פי 100), אבל זה כבר סיפור אחר.


קח קלאס עם 3 קוארדינטות, x, y, z שהם int.
תממש לשניהם את האופרטורים שדיברנו עליהם (שמעלים לכולם את הערכים ב-1 נניח), ותבין למה ההבדל עצום


בברכה,
עידן


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   01:19   15.01.10   
אל הפורום  
  12. לא רואה הבדל.  
בתגובה להודעה מספר 10
 
   הקומפיילר גם יכול לבצע אופטימיזציות למבנים מורכבים, אבל בכל מקרה, זה לא העניין פה. זו לא אופטימיזציה, אלא ייצוג בסיסי.

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

לגבי הקלאס, אין סיבה שהוא לא יממש את זה באותה צורה (שינוי הסדר הוא ההבדל בין המקרים).

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

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


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
ldan192 
חבר מתאריך 14.9.08
95119 הודעות
   01:50   15.01.10   
אל הפורום  
  13. שוב, אתה רק מדבר אבל לא מממש :)  
בתגובה להודעה מספר 12
 
ואתה לא מבין אפילו כמה אתה טועה בנוגע ל-"אופקוד אחד הבדל".
פשוט, זה הדבר הכי פחות נכון לומר מבין המשפטים שרשמת.


בברכה,
עידן


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   17:59   15.01.10   
אל הפורום  
  16. לא יודע מאיפה הציטוט, אבל לא רשמתי ''אופקוד אחד הבדל''  
בתגובה להודעה מספר 13
 
  


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Deuce 
חבר מתאריך 1.9.08
6225 הודעות
   14:17   15.01.10   
אל הפורום  
  14. מישהו מתכוון להרים את הכפפה ולהביא פה קוד?  
בתגובה להודעה מספר 0
 
על ה-VS שלי יש קצת אופטימיזציות. אם אף אחד מכם לא יעשה זאת, אני אעשה זאת בימים הקרובים ב-GCC.






                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
ldan192 
חבר מתאריך 14.9.08
95119 הודעות
   14:33   15.01.10   
אל הפורום  
  15. קצת פספסתם את הנקודה, בכל מקרה, הכוונה שלי הייתה  
בתגובה להודעה מספר 14
 
כזו:
עבור

class Tri {
int x, y, z;
}


/* Prefix */
const Tri& Tri::operator++()
{
x++; y++; z++;
return *this;
}

/* Postfix */
const Tri Tri::operator++(int)
{
Tri tmp(*this);
++(*this);
return temp;
}


ושימו לב שזה עוד לא מטפל גם במקרה של:
a++ = b; vs. ++a = b;
ששם בכלל ההבדל הופך למשמעותי.

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


בברכה,
עידן


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   18:01   15.01.10   
אל הפורום  
  17. הרמתי את הכפפה ב C, ב CPP עוד לא היה לי זמן, כמעט ולא בבית.  
בתגובה להודעה מספר 14
 
  


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Deuce 
חבר מתאריך 1.9.08
6225 הודעות
   04:19   16.01.10   
אל הפורום  
  18. תגובה לשניכם,  
בתגובה להודעה מספר 17
 
ראיתי את הקוד שלך ו-100%, אבל אפשר לתת דוגמאות מעט יותר מורכבות וזה כן תלוי קומפיילר - GCC פשוט עושה עבודה טובה. הכל טוב ויפה ברגע שדנים ב-C (שאני מאוד אוהב), אבל בשפות כמו JAVA ו-C++ אפשר לדבר על האופרטור מעל טיפוסים מורכבים (GENERICS ב-JAVA ו-TEMPLATES ב-C++).

לעידן, אני הבנתי לחלוטין ואני מכיר את זה - אפילו דיברנו על זה פעם בפרטי

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






                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   17:42   16.01.10   
אל הפורום  
  19. זה לא קשור לאופטימיזציה!  
בתגובה להודעה מספר 18
 
   עזבו רגע את סוג הטיפוס (כי זה לא משנה)
אני מניח שברור לכולם ש:

a = ++b;
//and
a = b++;

זה מקביל בצורה מלאה ל:

++b;
a= b;
//and
a=b;
b++;

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

גם אם הטענה שכתבתי לא היתה נכונה, זה לא היה משנה כלום כי דובר על postfix לעומת prefix בכלליות כלומר גם ב"שורה לעצמו" וזה ברור שזה לא נכון, אבל כמו שהראתי, זה לא נכון גם בהשמות וביטויים אבלואציה.


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
ldan192 
חבר מתאריך 14.9.08
95119 הודעות
   19:23   16.01.10   
אל הפורום  
  20. קודם כל, זה לא מדוייק מהסיבה שפעולה אחת  
בתגובה להודעה מספר 19
 
למרות שהיא כתובה כ-2 פעולות מכונה, יכולה לאחד אותן כפעולה מכונה אחת (כמו במקרה הנ"ל).

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

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


בברכה,
עידן


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   20:18   16.01.10   
אל הפורום  
  21. אני לא מבין על מה אתה מדבר  
בתגובה להודעה מספר 20
 
   "למרות שהיא כתובה כ-2 פעולות מכונה, יכולה לאחד אותן כפעולה מכונה אחת (כמו במקרה הנ"ל)."

איפה כתבתי משהו על 2 פעולות מכונה? ועל מה אתה מדבר במקרה הנ"ל שאפשר לאחד? a = ++b במקרה הכי טוב יהיה 3 פעולות מכונה (x86).

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

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

פי 50? לא יודע מאיפה הבאת פתאום את המספר הזה.

בכל מקרה, מה שאני כתבתי בתגובה הקודמת זה בסה"כ, שלא משנה איזה טיפוס,
a = ++b;
ו
++b;
a = b;
הם שקולים
וגם
a=b++;
ו
a=b;
b++;
הם שקולים.

בלי קשר ל int/Tri או כל class/מבנה אחר לצורך העניין, ולכן זה לא עניין של אופטימיזציה, פשוט ככה זה.


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
ldan192 
חבר מתאריך 14.9.08
95119 הודעות
   20:38   16.01.10   
אל הפורום  
  22. טוב, קשקשת מספיק. מה אתה מצפה שאומר לך, ברצינות.  
בתגובה להודעה מספר 21
 


בברכה,
עידן


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   21:29   16.01.10   
אל הפורום  
  23. תתחיל בלענות תשובות רלוונטיות.  
בתגובה להודעה מספר 22
 
  


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
ldan192 
חבר מתאריך 14.9.08
95119 הודעות
   23:35   16.01.10   
אל הפורום  
  24. תשמע, אם ברצינות לא הבנת אז אני אסביר שוב.  
בתגובה להודעה מספר 23
 
נניח a++ ממומש ככה שהוא מעלה את כל השדות שיש לקלאס Tri באחד
ו-++a ממומש שהוא מעלה רק לשדה הראשון. או שבראשון הוא מעלה ב-1 ובשני ב-2. או כל דבר שעולה על רוחך.

אתה טוען ש-++b=a ו-b=++a מתנהג בדיוק כמו בטיפוסים פרמטיביים - ברור לנו שלא כי התכונה של מימוש ++a ו-a++ בכלל לא קרובים אחד לשני.
כנ"ל אם אתה מגדיר a++ ו-++a להיות אותו הדבר, רק עם סדר קדימויות שונה!
לקומפיילרים כיום אין שום אפשרות לדעת בצורה יעילה שהקוד שלך זהה בשניהם, רק שהראשון והשני מבצעים סדר קדימויות שונות (זו בעיה NPC).

לכן, הוא מבצע את הקוד 1:1 כמו שתממש אותו (או כמו שנתתי דוגמא לעי"ל).
עובר שורה שורה בקוד ומבצע בדיוק מה שרשמתי.
זו המשמעות של operators overloading ב-++C, אם אתה לא מכיר.

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

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


לילה טוב


בברכה,
עידן


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
TTAsnn

   00:06   17.01.10   
אל הפורום  
  25. הדבר היחיד שכתבת שאני מסכים איתו זה 3. (רק לגבייך)  
בתגובה להודעה מספר 24
 
   אז נראה לי נסיים פה.


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Sagittarius
חבר מתאריך 29.1.17
909 הודעות
   15:04   21.01.10   
אל הפורום  
  26. תותח ! תודה :)  
בתגובה להודעה מספר 0
 
  

"ברוך אלוקים אשר לא הסיר תפילתי וחסדו מאתי" (תהילים סו כ)


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

תגובה מהירה  למכתב מספר: 
 
___________________________________________________________________

___________________________________________________________________
למנהלים:  נעל | תייק בארכיון | מחק | העבר לפורום אחר | מחק תגובות | עגן אשכול
       



© כל הזכויות שמורות ל-רוטר.נט בע"מ rotter.net