Προς το περιεχόμενο

Προτεινόμενες αναρτήσεις

Δημοσ.

Καλησπέρα σας!
Έχω το έξεις πρόβλημα. Δημιουργώ έναν πίνακα μονοδιάστατο με String μέσα. 
Έστω ότι στην θέση a[0] έχω το αλφαριθμητικό "hello". Σε περίπτωση που πάω να πω if (a[0] == "hello") αυτός ο λογικός έλεγχος γίνεται false. Μήπως ξέρετε τι πρέπει να κάνω για να το ελέγξω σωστά? Έχω βρεί τον ακόλουθο τρόπο αλλά δεν νομίζω πως είναι και ο καλύτερος και ο ποιο εύχρηστος:

String[] test = new String[3];
test[0] = "hello";
String k = "hello";
System.out.println(k.contains(test[0]));

Άν ξέρει κανείς καλύτερο τρόπο θα περιμένω απάντης!
Ευχαριστώ.

 

Δημοσ.
if (a[0] == "hello") 

Αυτό σου βγάζει false... γιατί γίνεται αυτό άραγε;;;;;

Σωστό είναι...

Επίσης υπάρχει και το .equals

k.equals(a[0])
Δημοσ.
if (a[0] == "hello") 

Αυτό σου βγάζει false... γιατί γίνεται αυτό άραγε;;;;;

Σωστό είναι...

Επίσης υπάρχει και το .equals

k.equals(a[0])

Σωστός μου αρέσει περισσότερο το δικό σου! να σαι καλά! απλά νόμιζα οτι υπάρχει ποιο απλός τρόπος και κάτι μου διέφευγε!

  • Like 1
Δημοσ. (επεξεργασμένο)
if (a[0] == "hello") 

Αυτό σου βγάζει false... γιατί γίνεται αυτό άραγε;;;;;

 

Γιατί το == σε Objects συγκρίνει διεύθυνση μνήμης και όχι περιεχόμενο.

Επεξ/σία από PC_MAGAS
  • Like 1
Δημοσ.

Α πα πα

100 φορες πιο απλη η C#

 

Μμμμννννννννχχχχχχχχχχχννννννννννννν.... ναι αλλά και όχι.

 

Το λεπτό σημείο είναι πως η Equals (τόσο στη Java όσο και στη C#) είναι virtual, επομένως δουλεύει σωστά πάντα -- ανεξάρτητα από το static type των τιμών που συγκρίνεις.

 

Στη Java ο operator == είναι πάντα ισοδύναμος με το object.ReferenceEquals() της C#, οπότε σου αρέσει δε σου αρέσει το πώς λειτουργεί τουλάχιστον είναι προβλέψιμο.

 

Στη C# όμως το τι κάνει ο == εξαρτάται από το static type των τιμών. Για παράδειγμα:

var i1 = 1;
var i2 = 1;
Console.WriteLine(i1 == i2); // true
object o1 = 1;
object o2 = 1;
Console.WriteLine(o1 == o2); // false?!?!!!

Το ίδιο θα συνέβαινε αν αντί για int είχες string... περίπου:

var i1 = "1";
var i2 = "1";
Console.WriteLine(i1 == i2); // true, αναμενόμενο
object o1 = "1";
object o2 = "1";
Console.WriteLine(o1 == o2); // true?!?!?!?

Δεν το περίμενες ε; Σου την έφερε πισώπλατα το string interning (see "Remarks"). Το ίδιο πράγμα που έγινε και στο παράδειγμα με τη Java που έδωσες παραπάνω και "δούλευε". Δες τώρα αυτό:

object o1 = "1";
object o2 = "12".Substring(0, 1);
Console.WriteLine(o1 == o2);  // false, "αναμενόμενο"

Όλα αυτά τα προβλήματα, όπως και τη δυνατότητα να γράψει κάποιος operator == που δε συμπεριφέρεται "όπως το string" (το οποίο, πολύ σημαντικά, είναι immutable αφού δημιουργηθεί) δε θα υπήρχαν αν χρησιμοποιούσες και στη C# Equals(), αν δηλαδή δεν επέτρεπε η γλώσσα το overloading του operator ==. Παρόλα αυτά και το επιχείρημα "foo" == "foo", τι δεν καταλαβαίνεις είναι ισχυρό. Αρκετά ισχυρό για να υπερισχύσει τελικά στο "να το βάλουμε αυτό μέσα στη γλώσσα ή όχι".

 

Παρεμπιπτόντως ακόμα κι αυτή η επιφανειακή αναφορά στα προβλήματα που προκύπτουν αν ανοίξεις την πόρτα σε user-defined operators είναι αρκετή για να μυριστεί κανείς το πόσο τσίρκο μπορεί να γίνει η κατάσταση σε μια γλώσσα όπως η C++ όπου μπορείς να κάνεις override ο,τι σου καπνίσει.

  • Like 1
Δημοσ.

Απ οτι ξερω η java δεν εχει value types (struct η enum) ειναι ολα classes

 

Στην C# αρκει να ξερεις ότι οι αριθμοι ειναι value type και συγκρινονται οι τιμες τους.

Τα string και object ειναι reference types.

 

To string όμως εχει overload to == (και αλλα operators) και "συμπεριφερεται" σαν value.

Δημοσ.

Απ οτι ξερω η java δεν εχει value types (struct η enum) ειναι ολα classes

Ανάλογα πως το εννοείς, ναι (δεν μπορείς να ορίσεις δικά σου) ή ίσως και όχι (οι ακέραιοι π.χ. είναι value types). 

 

Στην C# αρκει να ξερεις ότι οι αριθμοι ειναι value type και συγκρινονται οι τιμες τους.

Ναι, αλλά μόνο όταν δεν είναι boxed. Δηλαδή σχεδόν πάντα (από τότε που υπάρχουν generics), αλλά πρέπει να το προσέχεις.

 

To string όμως εχει overload to == (και αλλα operators) και "συμπεριφερεται" σαν value.

Ναι αλλά μόνο όταν και οι 2 operands είναι typed σα string. Επιπλέον, το string οι δημιουργοί εν σοφία εποίησαν να είναι immutable. Αν δεν ήταν και δοκίμαζε να κάνει τέτοιες μαγκιές (ή αν κάνεις ένα δικό σου αντίστοιχο mutable type) θα είχαμε δάκρυα. Αυτά είναι σημαντικές λεπτομέρειες και θέλουν προσοχή.

 

Επίσης κατά την άποψή μου στη C# θέλει διαρκώς να έχεις στο μυαλό σου "άσε τι κάνουν τα strings, το σωστό είναι πάντα .Equals()" -- όπως στη Java δηλαδή. Το να μη βάλεις Equals εκεί που χρειάζεται είναι λάθος που έπιασα τον εαυτό μου να το κάνει ακόμα και πολλά χρόνια μετά από το σημείο "μαθαίνω πώς δουλεύουν οι συγκρίσεις".

Δημοσ.

"Παραδοσιακά" στην Java τα enum αντικαθίστανται από static και ταυτόχρονα final δηλώσεις μεταβλητών σε στυλ "static public CONST = 123" καθώς στην πρώτη έκδοση της γλώσσας το enum είχε παραληφθεί.

 

Από την έκδοση 1.5+ του JDK όμως υπάρχει υποστήριξη του enum keyword αλλά και πάλι δεν θα έλεγα ότι είναι τόσο δημοφιλές όσο σε άλλες γλώσσες (πχ. C/C++) - πάντα με βάση τον κώδικα που έχω συναντήσει ως τώρα.

Δημοσ.

"Παραδοσιακά" στην Java τα enum αντικαθίστανται από static και ταυτόχρονα final δηλώσεις μεταβλητών σε στυλ "static public CONST = 123" καθώς στην πρώτη έκδοση της γλώσσας το enum είχε παραληφθεί.

 

Από την έκδοση 1.5+ του JDK όμως υπάρχει υποστήριξη του enum keyword αλλά και πάλι δεν θα έλεγα ότι είναι τόσο δημοφιλές όσο σε άλλες γλώσσες (πχ. C/C++) - πάντα με βάση τον κώδικα που έχω συναντήσει ως τώρα.

 

Είναι παλιά κακιά συνήθεια θα έλεγα εγώ. Τα enum στη Java είναι πανίσχυρα αρκεί κάποιος να ασχοληθεί. Ειδικά όταν θέλουμε να γράψουμε type safe κώδικα. Απλά επειδή πολλοί παλιότεροι programmers το είχαν συνηθίσει το βλέπεις ακόμα σε σημερινό κώδικα.

 

On topic. Όταν λες a[0] == "hello"; ουσιαστικά τι κάνεις...το "hello" είναι σαν να γράφεις new String("hello"); Εκείνη τη στιγμή δημιουργείς ένα νέο string και ελέγχεις με το == αν δείχνουν στην ίδια θέση μνήμης με το String στο array...κάτι το οποίο φυσικά και θα σου βγάλει λάθος. Να χρησιμοποιείς .equals();

Δημοσ.

 

 

Είναι παλιά κακιά συνήθεια θα έλεγα εγώ. Τα enum στη Java είναι πανίσχυρα αρκεί κάποιος να ασχοληθεί. Ειδικά όταν θέλουμε να γράψουμε type safe κώδικα. Απλά επειδή πολλοί παλιότεροι programmers το είχαν συνηθίσει το βλέπεις ακόμα σε σημερινό κώδικα.

Σωστά.

 

Η επαφή μου με την Java περιορίζεται στην J2ME & Android και πολύ λιγότερο στους Η/Υ.  Στις πρώτες εκδόσεις του Android υπήρχε μεταξύ άλλων και ένας κανόνας που προέτρεπε τους προγραμματιστές να αποφεύγουν τα enum καθώς η υλοποίηση τους κόστιζε σε Dalvik resources, από την Froyo (Android 2.2) και μετά ο κανόνας αυτός αναιρέθηκε αλλά το παράδειγμα των "static final" μεταβλητών αντί enum παρέμεινε στις βιβλιοθηκών του Android οπότε μια γενιά Java/Android προγραμματιστών (μεταξύ μας το Android έδωσε μεγάλη ώθηση στην Java οπότε ... πολλοί γνωρίσανε σε βάθος την γλώσσα μαζί του) μένει μακριά (αναίτια πλέον) από αυτά.

 

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα
  • Δημιουργία νέου...