השוואת מחרוזות ב- JAVA

[capslock1]

השוואת מחרוזות ב- JAVA

למישהו יש הסבר למה אני מקבל תוצאה שלילית עבור השוואה של 2 מחרוזות שוות:

TextField inputText = new TextField("0",30); String a1 = inputText.getText(); String a2 = "0"; if (a1==a2) System.out.print("true a1="+a1+" a2="+a2); else System.out.print("false a1="+a1+" a2="+a2);​

וזו היא תוצאה ההרצה:

false a1=0 a2=0​

אודה לכם עבור התשובה...... תודה

 

[Zack DA]

טעות ראשונה -

String-ים משווים ע"י המתודה equals ולא ע"י ==. חשוב למה. את הטעות השניה אתה כבר תמצא...

 

[capslock1]

2 שאלות:

עד עכשיו תמיד ביצעתי השוואות ע"י שימוש ב- "==" 1. למה זה תמיד עבד - ובדוגמא זו זה לא עבד? 2. אני לא חושב שהבנתי מה בטעות השניה, כעת כאשר אני משתמש ב- equal זה עובד מצויין. אז מדוע אתה טוען שיש עוד טעות? אודה לך עבור התשובות. ותודה עבור התשובה הקודמת

 

[Zack DA]

כי, בעצם, עד היום לא השתמשת נכון

ב- strings. כשאתה מבצע == אתה משווה את הפוינטר, וכשאתה משתמש ב- equals אתה משווה את התוכן. ועד היום זה פעל לך כי לא יצרת strings חדשים עם new, אלא פשוט הצבת לתוכם מה שרצית כדי שהערך יהיה אותו הדבר.

 

[DNile]

מקור חמור לבאגים יש לציין...

חלק מהיותה של java שפה מסריחה.

 

[vinney]

../images/Emo6.gif

 

[אלוהים1980]

אז בעצם המסקנה היא

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

 

[vinney]

בג'אווה

ב++C דווקא == אמור לתת את המענה, כי כל אחד מממש אותו למחלקה שלו כדי שיעבוד כמו שצריך. בגלל זה ג'אווה זה קקה של שפה (בין היתר)

 

[Zack DA]

נו, באמת ../images/Emo13.gif

כמו שאתה דורס את == כדי שזה יעבוד כמו שצריך, הציפיה היא שידרסו את המתודה equals כדי שזה יעבוד כמו שצריך. == אמור בהגדרה לבדוק את הפוינטר. מה לעשות ש- java שונה מ- cpp, וכמעט תמיד לטובה ולא לרעה...

 

[gmorphus]

לא ממש מסכים

אני חושב שהרעיון של operator overloading הוא מצוין. מה יותר טריוויטלי וקריא מ str1 == str2? ולמה ש== ישווה לי את הכתובות של המשתנים כאשר כל הרעיון הוא בהפשטה ו encapsulation זה להסתיר מימוש מהמשתמש. כשאתה רואה str1 == str2 אני יודע בדיוק למה הכוונה - וכאן היא לזה שאתה משווה את המחרוזות עצמן.

 

[Zack DA]

ב- Sun (וגם אני) לא מסכימים איתך.

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

 

[IsraeliSecretToilets]

גם זה עניין של הרגל.

כמו שצריך לדעת לתכנת ב-java צריך גם לדעת לתכנת ב-c++ ולא לעשות overloading בכל חור אפשרי. בתוכנות מתמטיות וגרפיות זה בכלל מפשט את העניינים. ניסית פעם לכתוב מנוע גרפי בשפה שאין בה operator overloading? זה סיוט!

 

[Zack DA]

אם בלי אופרטורים זה סיוט,

כנראה שהקוד "מגעיל" בכל מקרה (מעצם היותו מאוד טכני). אז לפי האידיאולוגיה של Sun - או שמתאמצים מאוד שיהיה קריא ואז בכל זאת יורדים מהרעיון של שימוש באופרטורים, או שזה כבר לא ממש משנה ועדיף לכתוב ב- CPP. גם ככה, Java היא לא שפה מתאימה למנועים גרפיים, ברוב המקרים אין לה את הביצועים לזה, אלא אם כן היא מנוע לוגי מעל מנוע native-י, ואז בכלל לא רצוי שתשתמש באופרטורים בכל מקום. דעתי האישית, האמת היא איפה שהוא באמצע. Sun היו יכולים לבנות special designed interfaces שיכילו בתוכם אופרטורים, בדיוק בהתאם למקרים הקלאסיים בעולם התכנות שבהם זה אינטואיטיבי (ואפשר בהחלט להרכיב רשימה כזאת). הם לא עשו זאת, בדוט נט זה כבר יכנס לסטנדרט די מהר, לגבי java 1.5, אני די בספק.

 

[IsraeliSecretToilets]

במנועים גרפיים..

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

 

[voguemaster]

לא כולה כתובה בג'אווה

 

[IsraeliSecretToilets]

אחרי בדיקה מעמיקה (או שלא ../images/Emo3.gif)

אני מגיע לאותה מסקנה

אבל הרבה ממנה עדיין כתוב בג'אווה.

 

[voguemaster]

אני יודע לפחות על רכיב אחד שלא

וזו ההגנה

 

[Zack DA]

לא מכיר את המקרה הספציפי,

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

 

[IsraeliSecretToilets]

זה בזבוז מיותר של זמן פיתוח.

בעיקר כאשר רוב הקוד הוא בעצם פעולות על מטריצות ווקטורים.

 

[voguemaster]

אולי

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