Pass by Reference - Δεν βλέπω να γίνεται μεγάλη χρήση του

[Kercyn]

^ ούτε καν! όταν δουλεύεις με λίστες/πίνακες, και εφόσον το επιτρέπουν οι συνθήκες, το καλύτερο είναι να δουλεύεις πάνω στην υπάρχουσα. Αν γνώμονας μας είναι η απόδοση. Αλλά έχει προχωρήσει τόσο πολύ το hardware που καλύτερα να κάνεις αυτό που λες γιατί σου προσφέρει και καλύτερο έλεγχο κώδικα.

 

Γιατί να το κάνεις αυτό; Η λίστα που περνάς στη συνάρτηση είσαι σίγουρος ότι μπορείς να την πειράξεις και ότι τυχόν αλλαγές πάνω της δε θα έχουν καμία απρόβλεπτη επίδραση στο πρόγραμμα; Αυτό που λες μου ακούγεται, στην καλύτερη, σαν να ζητάς να σου δημιουργηθούν προβλήματα.

[Επισκέπτης]

Με την ίδια λογική βάλε παντού global μεταβλητές και μην περνάς τίποτα στις function.

[defacer]

^ ούτε καν! όταν δουλεύεις με λίστες/πίνακες, και εφόσον το επιτρέπουν οι συνθήκες, το καλύτερο είναι να δουλεύεις πάνω στην υπάρχουσα. Αν γνώμονας μας είναι η απόδοση. Αλλά έχει προχωρήσει τόσο πολύ το hardware που καλύτερα να κάνεις αυτό που λες γιατί σου προσφέρει και καλύτερο έλεγχο κώδικα.

 

Εκεί που καταλήγεις, ναι. Όπως λες "αν γνώμονας είναι η απόδοση". Αλλά στην πραγματικότητα, η απόδοση δεν είναι σχεδόν ποτέ γνώμονας. Η μόνη περίπτωση να σκεφτείς καν την απόδοση είναι αν κάνεις τέτοια πράγματα μέσα σε κάποιο loop, και πάλι τις περισσότερες φορές ούτε αυτό δεν πειράζει εκτός αν είναι interactive εκείνο το τμήμα της εφαρμογής.

 

Από άποψη δομής κώδικα το καλύτερο είναι να μη χρησιμοποιείς ούτε καν κάτι που δίνει interface πίνακα εφόσον δεν είναι απαραίτητο. Αν θέλεις να κάνεις απλά μια βόλτα να δεις τα δεδομένα τότε κάτι σε forward iterator (στη C#, IEnumerable) είναι το καλύτερο σημείο εκκίνησης.

[gdask]

^ ούτε καν! όταν δουλεύεις με λίστες/πίνακες, και εφόσον το επιτρέπουν οι συνθήκες, το καλύτερο είναι να δουλεύεις πάνω στην υπάρχουσα. Αν γνώμονας μας είναι η απόδοση. Αλλά έχει προχωρήσει τόσο πολύ το hardware που καλύτερα να κάνεις αυτό που λες γιατί σου προσφέρει και καλύτερο έλεγχο κώδικα.

 

 

Θα ήταν καλύτερα αν το έθετες "και εφόσον το απαιτούν οι συνθήκες" .

 

Στις περισσότερες εφαρμογές σπάνια θα "αναγκαστεί" κανείς να κάνει τέτοιου είδους optimization. Από την άλλη όμως, το mutable state ήταν, είναι και θα είναι πηγή προβλημάτων. Μάλιστα στο FP paradigm, που έχει γίνει και της μόδας τα τελευταία χρόνια, το mutable state απαγορεύεται.

[konqoro]

Οι references χρησιμοπιούνται για να επιστρέφει μια συνάρτηση περισσότερα από ένα αποτελέσματα.

[Shyn]

Οι references χρησιμοπιούνται για να επιστρέφει μια συνάρτηση περισσότερα από ένα αποτελέσματα.

 

Υπαρχει και Tuple. Ειδικα στην c#7 μπορεις να κανεις αυτο 

(string,string,string) foo() 
{
return ("","","");
}

ή

(string first, string second, string third) boo() {...}

var numbers = boo();

WriteLine($"{numbers.first} {numbers.second} {numbers.third}");

[SakislolGR]

^

ένα από τα καλά features αλλά πες στην m$ να πατήσει φρένο γιατί είμαστε ακόμα στο net framework 4,5. Μην μου γίνει σαν την apple!

[GReaperEx]

Εκεί που καταλήγεις, ναι. Όπως λες "αν γνώμονας είναι η απόδοση". Αλλά στην πραγματικότητα, η απόδοση δεν είναι σχεδόν ποτέ γνώμονας.

 

Αυτά ο τρόπος σκέψης, που έχει μολύνει τελευταία τους προγραμματιστές όλου του κόσμου, μόνο σε καλό δε πρόκειται να μας βγει... Πολλοί νομίζετε (ή σας έχουν μάθει) ότι αν χρησιμοποιείς τεχνικές που είναι αντικειμενικά πιο γρήγορες θα γίνει ξαφνικά το πρόγραμμα πιο δυσανάγνωστο... λες και θα αρχίσουμε να γράφουμε inline assembly παντού και θα κάνουμε τρομερά χακερίστικα κόλπα που κανείς δε θα μπορεί να καταλάβει...

 

Αναλόγως τη γλώσσα που χρησιμοποιείς, έχεις και άλλες μεθόδους για να βελτιστοποιήσεις την απόδοση χωρίς να θυσιάσεις το πόσο κατανοητό είναι. Για παράδειγμα, στη C++ αν δε θες να δημιουργείς καινούργιο αντικείμενο κάθε φορά που περνάς μια παράμετρο σε μια συνάρτηση, πρέπει να χρησιμοποιήσεις references. Αν θες να μη μπορείς να την αλλάξεις, τη κάνεις const.

 

Δε καταλαβαίνω γιατί πρέπει να φερόμαστε στον προγραμματιστή λες και είναι ένα σαλιάρικο μωρό που δε ξέρει πόσο κάνει 2+2...

[Alithinos]

Υπάρχει και το άλλο: Η ιδέα ότι θα πρέπει μια μέθοδος να κάνει 1 πράγμα, και να το κάνει καλά.

Άμα επιστρέφει 1 πράγμα, και βγάζει και με ref μερικά άλλα, τότε δεν κάνει 1 πράγμα, αλλά περισσότερα.

 

Σε αυτή τη περίπτωση θα έπρεπε να σκεφτούμε αν ίσως θα έπρεπε να φτιάξουμε ένα τύπο που να περιέχει τις τιμες που επιστρέφονται, αν συσχετίζονται όλες οι τιμές που εξάγει η μέθοδος με κάποιο τρόπο, ή αν θα ήταν καλύτερα να δημιουργήσουμε 2 μεθόδους.

 

.Γιατί είναι καλή ιδέα μια μέθοδος να επιστρέφει 1 μόνο πράγμα ?

 

Για να περιορίσεις τις ανεπιθυμήτες ενέργειες και το χρόνο του debugging. Σε μεγαλύτερα projects, ίσως να φτάσεις σε ένα σημείο όπου αλλάζεις κάτι εδώ και χαλάει κάτι εκεί. Ένα φαινόμενο που αναπαριστάται με ωραίο τρόπο σε αυτή την εικόνα:

 

 

Και ξέρεις γιατί συμβαίνει αυτό ? (μεταξύ άλλων) Γιατί έχουμε μεθόδους που λένε ψέματα!

Μια μέθοδος που λέει ψέμματα, είναι μια μέθοδος που δε κάνει μόνο αυτό που λέει το όνομά της, αλλά και κάτι άλλο! Είτε αλλάζει και κάποια μεταβλητή με ref χωρίς να το λέει το όνομά της, ή ακόμα χειρότερα το κάνει 'μέσα της', χωρίς καν να φαίνεται στην υπογραφή της! Έτσι όταν μετά από καιρό (που θα έχεις ξεχάσει εννοείται την εσωτερική υλοποιήσή της, γιατί άνθρωπος είσαι) θα δεις το όνομά της που λέει ότι κάνει το Χ, και θα τη χρησιμοποιήσεις για το Χ αλλά θα έχεις ξεχάσει ότι κάνει και το Ψ, θα κάνει και το Ψ και θα αναρωτιέσαι πως στο καλό είναι να αλλάζει το Ψ ενώ εσύ χρησιμοποίησες μια μέθοδο η οποία λέει μόνο ότι αλλάζει το Χ.

 

 

Αυτά ο τρόπος σκέψης, που έχει μολύνει τελευταία τους προγραμματιστές όλου του κόσμου, μόνο σε καλό δε πρόκειται να μας βγει... Πολλοί νομίζετε (ή σας έχουν μάθει) ότι αν χρησιμοποιείς τεχνικές που είναι αντικειμενικά πιο γρήγορες θα γίνει ξαφνικά το πρόγραμμα πιο δυσανάγνωστο... λες και θα αρχίσουμε να γράφουμε inline assembly παντού και θα κάνουμε τρομερά χακερίστικα κόλπα που κανείς δε θα μπορεί να καταλάβει...

 

Αναλόγως τη γλώσσα που χρησιμοποιείς, έχεις και άλλες μεθόδους για να βελτιστοποιήσεις την απόδοση χωρίς να θυσιάσεις το πόσο κατανοητό είναι. Για παράδειγμα, στη C++ αν δε θες να δημιουργείς καινούργιο αντικείμενο κάθε φορά που περνάς μια παράμετρο σε μια συνάρτηση, πρέπει να χρησιμοποιήσεις references. Αν θες να μη μπορείς να την αλλάξεις, τη κάνεις const.

 

Δε καταλαβαίνω γιατί πρέπει να φερόμαστε στον προγραμματιστή λες και είναι ένα σαλιάρικο μωρό που δε ξέρει πόσο κάνει 2+2...

 

Το θέμα είναι να κάνεις αλλαγές για το optimization όπου υπάρχει λόγος. Το να υπάρξει μια αναπαίσθητη στο τελικό χρήστη καθυστέρηση μερικών ms παραπάνω, δεν έχει και τόση σημασία.

 

Όταν μετράς το O, κρατάς τιμές όπως O(2n), O(N2) κτλπ και τα +1, +2 τα αφαιρείς. Γιατί τα αφαιρείς ?

[defacer]

Αυτά ο τρόπος σκέψης, που έχει μολύνει τελευταία τους προγραμματιστές όλου του κόσμου, μόνο σε καλό δε πρόκειται να μας βγει... Πολλοί νομίζετε (ή σας έχουν μάθει) ότι αν χρησιμοποιείς τεχνικές που είναι αντικειμενικά πιο γρήγορες θα γίνει ξαφνικά το πρόγραμμα πιο δυσανάγνωστο... λες και θα αρχίσουμε να γράφουμε inline assembly παντού και θα κάνουμε τρομερά χακερίστικα κόλπα που κανείς δε θα μπορεί να καταλάβει...

 

Αναλόγως τη γλώσσα που χρησιμοποιείς, έχεις και άλλες μεθόδους για να βελτιστοποιήσεις την απόδοση χωρίς να θυσιάσεις το πόσο κατανοητό είναι. Για παράδειγμα, στη C++ αν δε θες να δημιουργείς καινούργιο αντικείμενο κάθε φορά που περνάς μια παράμετρο σε μια συνάρτηση, πρέπει να χρησιμοποιήσεις references. Αν θες να μη μπορείς να την αλλάξεις, τη κάνεις const.

 

Δε καταλαβαίνω γιατί πρέπει να φερόμαστε στον προγραμματιστή λες και είναι ένα σαλιάρικο μωρό που δε ξέρει πόσο κάνει 2+2...

 

Επειδή υπάρχει τεράστιος αριθμός προγραμματιστών που απλά δεν ξέρουν περισσότερο -- δε θα τους έλεγα σαλιάρικα μωρά, καθώς θυμάμαι πολύ καλά ότι υπήρξα σίγουρα όχι σαλιάρικο μωρό αλλά με πολύ λιγότερες γνώσεις και κυρίως εμπειρία από τώρα -- και αυτοί είναι που θα ωφεληθούν από ένα καλό rule of thumb. Οι υπόλοιποι ήδη ξέρουν.

 

Και γενικότερα, δε νομίζω ότι κατάλαβες το πνεύμα. Το να μάθει κάποιος να γράφει idiomatic κώδικα κατάλληλο για την περίπτωση είναι κάτι που γίνεται σε επόμενο στάδιο εμπειρίας από το "τώρα που έμαθες τι κάνει το σφυρί, σταμάτα να βαράς τα πάντα δε χρησιμοποιείται έτσι".

 

Αυτά που λες παραπάνω (και με τα οποία συμφωνώ αλλά μόνο εν μέρει), είναι λίγο γενικότητες. Στην προκειμένη περίπτωση (ref στη C#) είναι not even wrong η ιδέα να χρησιμοποιηθούν -- και πρόσεξε, είναι ακριβώς αυτό που είπα παραπάνω: ο OP ρώτησε "γιατί δε χρησιμοποιούνται παραπάνω". Αν δεν είναι αυτό ο ορισμός της περίπτωσης "ωραία, τώρα που κατάλαβες πότε το χρησιμοποιούμε πρέπει να καταλάβεις και πότε δεν το χρησιμοποιούμε", δεν ξέρω τι είναι.

Οι references χρησιμοπιούνται για να επιστρέφει μια συνάρτηση περισσότερα από ένα αποτελέσματα.

 

Αυτό είναι red herring που λένε.

 

Αν το εξετάσεις "μηχανικά", τα περισσότερα από ένα αποτελέσματα μπορούν πολύ απλά να μπουν σε ένα class/struct/whatever αντίστοιχο της γλώσσας. Δεν υπήρχε ποτέ περίπτωση να μπουν references σε οποιαδήποτε γλώσσα αν το βαρύτερο επιχείρημα υπέρ τους ήταν "για να επιστρέφει πολλά αποτελέσματα".

[SakislolGR]

νταξ ο @greaperx αναφέρει μια πραγματικότητα. Αλλά δεν το βρίσκω κακό να ξεπετάς.

 

όπως είπα το hw έχει προχωρήσει τόσο πολύ που η διαφορά σε απλά προβήματα, από το βέλτιστο στο 'απλα καλο' ειναι μερικά ms

[παπι]

Υπάρχει και το άλλο: Η ιδέα ότι θα πρέπει μια μέθοδος να κάνει 1 πράγμα, και να το κάνει καλά.

Άμα επιστρέφει 1 πράγμα, και βγάζει και με ref μερικά άλλα, τότε δεν κάνει 1 πράγμα, αλλά περισσότερα.

Σε γενικες γραμμες μια μεθοδος θα επιστεψει ειτε καποια τιμη ειτε καποιο object ειτε καποιο range. Ειναι πολυ δυσκολο να θελεις να βγαλεις απο μια μεθοδο ενα σουβλακι μια πιτσα και 2 λιτρα βενζινη.

[solarpower]

Μια ιδέα:

private static void goodluck(GoodObject a) {
a.wish = "good luck " + a.name;
}

 

Η άλλη ιδέα είναι να έχει κανείς στο ίδιο το αντικείμενο μια μέθοδο που θα αλλάζει τιμές. Είναι θέμα σχεδιασμού.

[defacer]

νταξ ο @greaperx αναφέρει μια πραγματικότητα. Αλλά δεν το βρίσκω κακό να ξεπετάς.

 

όπως είπα το hw έχει προχωρήσει τόσο πολύ που η διαφορά σε απλά προβήματα, από το βέλτιστο στο 'απλα καλο' ειναι μερικά ms

 

Δεν έχει κανένα νόημα να το λες αυτό "in a vacuum". Δεν έχει σημασία πόσα ms παίρνει κάτι, σημασία έχει πόσα ms πήρε παραπάνω από αυτά που είχες στη διάθεσή σου. Όταν πατάς το ίσον στο κομπιουτεράκι δεν έχει καμία σημασία αν το αποτέλεσμα θα βγει σε 1 ή σε 10 ή σε 100 ms, γιατί δε θα υπάρξει καμία "παρατηρήσιμη διαφορά" στο σύμπαν ανάλογα την περίπτωση.

 

Ή για να το πω και αλλιώς. Όταν είσαι στην έρημο, το να στάζεις προσεκτικά τις τελευταίες 5 σταγόνες από το μπουκάλι στο στόμα είναι καλή ιδέα. Όταν είσαι στα starbucks είναι περίεργος ψυχαναγκασμός. Το ότι "είναι πιο γρήγορο έτσι" δε σημαίνει πως έκανες κάτι χρήσιμο. Και αυτό είναι το τελικό κριτήριο στο engineering: αυτό που έκανες, ήταν χρήσιμο; Αν όχι, πιθανότατα ξόδεψες πόρους που δε μας περισσεύουν (εργατοώρες/χρήμα) για να κάνεις οικονομία σε πόρους που μας περισσεύουν (CPU cycles). That is just bad engineering.

 

Φυσικά στη θεωρητική περίπτωση που είσαι τόσο μάγκας που κάνεις το καλύτερο δυνατό χωρίς να ξοδέψεις ούτε δευτερόλεπτο παραπάνω* από τον άλλο που κάνει το λιγότερο καλό, μπράβο και να συνεχίσεις έτσι. Αλλά δεν υπάρχει κανένας τουλάχιστον στο insomnia που να είναι πραγματικά world class και να ανήκει σ' αυτό το γκρουπάκι, οπότε καλή η θεωρία αλλά...

 

 

 

 

* Και όταν λέω "να ξοδέψεις", δεν εννοώ μόνο εσένα. Μεθαύριο που θα φύγεις και θα έρθει άλλος, όταν θα δει το Α που έγραψες αντί για το Β, θα ξύσει 5 παραπάνω δευτερόλεπτα το κεφάλι του; Αυτός είναι χρόνος που εσύ έκανες να ξοδευτεί.

[SakislolGR]

Αχχχ και να ήμουν καθηγητής ΑΕΙ. 1200 ευρώ τζάμπα και μπόλικο χρόνο να εξελιχθώ σε ότι πραγματικά αγαπώ και όχι σε τι μου επιβάλλουν.

 

Σπάνιο πράγμα ο χρόνος

 

@defacer σε βλέπω ασχολείσαι και γνωρίζεις πολλά... δεν πιστεύω να είσαι καθηγητής;.