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

[C++] const function που καλεί non-const function


Kercyn

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

Ωραία, άρα κάνεις μια SetPosition η οποία θα μπορούσε να είναι const (με την έννοια ότι δε θα σε εμποδίσει ο compiler) και αμέσως μετά μπορείς να κάνεις μια GetPosition και να δεις τα definitely not const αποτελέσματα της SetPosition που έκανες μόλις πριν.

 

Άρα η SetPosition είναι κάθε άλλο παρά logically const, άρα δεν πρέπει να είναι const.

 

Απλό.  :-D

 

ΥΓ note ότι δε χρειάστηκε καν να μπει το wrapped στη συζήτηση.

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

  • 2 εβδομάδες αργότερα...
Δημοσ. (επεξεργασμένο)

Που είχε θαφτεί το thread αυτό και πέρασε έτσι;

 

Η άποψή μου για το logically const vs physically const είναι πως 9 στις 10 υπάρχει τρόπος και είναι προτιμότερο να γίνει και physically const μιας και προσφέρει έναν πολύ πιο maintainable κώδικα. Γιατί ποιος εγγυάται ότι το logically const θα παραμένει για πάντα logically const;

 

 

Σε ένα εντελώς τυχαίο παράδειγμα και ανεξάρτητα framework/πλατφόρμας μιας και δεν υποστήριζεται παντού:

 

Εστω ένα thread object ως attribute μιας κλάσης Α. Έχω εγώ μια const method της Α που απλά ζητάει από το thread να τρέξει. Για τους δικούς μου λόγους μέσα στη method αυτή πάω και αλλάζω το thread priority μιας και στην αρχική μου υλοποίηση με ότι priority και να το τρέξουν οι υπόλοιπες methods μου τα ίδια θα υπολογίζει και η τιμή του thread prority δε χρησιμοποιείται πουθενά αλλού. Κατά την έννοια του defacer, αυτό είναι virtually const.

 

Ναι, μονάχα που έχω κάνει απαγορευτική τη χρήση του getThreadPriority() σε οποιαδήποτε αλλαγή κάνω αργότερα. Και τι μου το απαγορεύει αυτό; Μονάχα το documentation...

Επεξ/σία από jimex
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Εστω ένα thread object ως attribute μιας κλάσης Α. Έχω εγώ μια const method της Α που απλά ζητάει από το thread να τρέξει. Για τους δικούς μου λόγους μέσα στη method αυτή πάω και αλλάζω το thread priority μιας και στην αρχική μου υλοποίηση με ότι priority και να το τρέξουν οι υπόλοιπες methods μου τα ίδια θα υπολογίζει και η τιμή του thread prority δε χρησιμοποιείται πουθενά αλλού. Κατά την έννοια του defacer, αυτό είναι virtually const.

 

Ναι, μονάχα που έχω κάνει απαγορευτική τη χρήση του getThreadPriority() σε οποιαδήποτε αλλαγή κάνω αργότερα. Και τι μου το απαγορεύει αυτό; Μονάχα το documentation...

 

Semantics.

 

Εγώ αυτό δε θα το έλεγα logically const επειδή προκαλείς αλλαγές στο περιβάλλον που είναι observable εκτός του αντικειμένου που τις προκαλεί (ξεκινάς καινούριο thread, never mind η αλλαγή του priority).

 

Ακόμα κι αν δεν ξεκινούσες το thread αλλά απλώς άλλαζες το priority που θα έχει όταν ξεκινήσει τότε προφανώς πάλι έχεις αλλάξει το state του αντικειμένου και πάλι είναι observable η αλλαγή που έκανες (ξεκινάω το thread με όποιο τρόπο παρέχεις και μετά βλέπω το priority του, οπότε καταλαβαίνω αν νωρίτερα είχες καλέσει την "const" method ή όχι).

 

Ποιός εγγυάται ότι το logically const θα παραμείνει έτσι; Ο maintainer. Στην τελική ποιός εγγυάται ότι σε μια physically const method δε θα πάει κάποιος κανίβαλος να βάλει mutable τα πάντα και να την κάνει const μόνο στο όνομα;

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Εγώ αυτό δε θα το έλεγα logically const επειδή προκαλείς αλλαγές στο περιβάλλον που είναι observable εκτός του αντικειμένου που τις προκαλεί (ξεκινάς καινούριο thread, never mind η αλλαγή του priority).

 

Ακόμα κι αν δεν ξεκινούσες το thread αλλά απλώς άλλαζες το priority που θα έχει όταν ξεκινήσει τότε προφανώς πάλι έχεις αλλάξει το state του αντικειμένου και πάλι είναι observable η αλλαγή που έκανες (ξεκινάω το thread με όποιο τρόπο παρέχεις και μετά βλέπω το priority του, οπότε καταλαβαίνω αν νωρίτερα είχες καλέσει την "const" method ή όχι).

 

Το δέχομαι ότι χρησιμοποιήσα μια χαλαρή ερμηνεία του logically const. Αλλά that's the case 9 στις 10 και σχεδόν πάντα θα υπάρχει τρόπος να γίνει observe, εύκολος ή δύσκολος. Πολλές φορές αυτός ο τρόπος μπορεί να μη φαίνεται καν με την πρώτη ματιά. Οπότε γιατί να πρέπει να προσθέτει κανείς μια έγνοια ακόμη, για κάτι μάλιστα που και πάλι 9 στις 10 θα δηλώνει κακό σχεδιασμό;

 

 

Ποιός εγγυάται ότι το logically const θα παραμείνει έτσι; Ο maintainer. Στην τελική ποιός εγγυάται ότι σε μια physically const method δε θα πάει κάποιος κανίβαλος να βάλει mutable τα πάντα και να την κάνει const μόνο στο όνομα;

 

Κανείς. Απλά ποιο από τα δύο είναι πιο εύκολο να γίνει καταλάθος σε ένα αρχείο 2k γραμμών;

 

Φυσικά σε κάθε περίπτωση don't be a slave to the rules. Δε σημαίνει ότι αν μια virtually const method είτε με την αυστηρή έννοια, είτε με μια πιο χαλαρή προσέγγιση θέλει πολλαπλάσια δουλειά προκειμένου να γίνει physically const και όλα αυτά σε ένα μικρό project δεν πρέπει να χρησιμοποιηθεί όπως είναι. Πάντως εκ σχεδιασμού, δεν υπάρχει περίπτωση είτε να το έκανα εγώ είτε να προέτρεπα κάποιον να χρησιμοποιήσει τέτοιες λύσεις. Δεν μπορεί να χρησιμοποιούμε δεκάδες design patterns για να έχουμε πιο maintainable κώδικα, και στην τελική να βγάζουμε μόνοι μας τα μάτια μας. ;)

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Το δέχομαι ότι χρησιμοποιήσα μια χαλαρή ερμηνεία του logically const. Αλλά that's the case 9 στις 10 και σχεδόν πάντα θα υπάρχει τρόπος να γίνει observe, εύκολος ή δύσκολος. Πολλές φορές αυτός ο τρόπος μπορεί να μη φαίνεται καν με την πρώτη ματιά. Οπότε γιατί να πρέπει να προσθέτει κανείς μια έγνοια ακόμη, για κάτι μάλιστα που και πάλι 9 στις 10 θα δηλώνει κακό σχεδιασμό;

 

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

 

Πάντως εκ σχεδιασμού, δεν υπάρχει περίπτωση είτε να το έκανα εγώ είτε να προέτρεπα κάποιον να χρησιμοποιήσει τέτοιες λύσεις. Δεν μπορεί να χρησιμοποιούμε δεκάδες design patterns για να έχουμε πιο maintainable κώδικα, και στην τελική να βγάζουμε μόνοι μας τα μάτια μας. ;)

 

Κι εγώ δε θα έλεγα ότι προτρέπω κανέναν να κάνει αυτό το πράγμα επίτηδες στην πράξη. Η κουβέντα ξεκίνησε με ένα αφηρημένο ουρανοκατέβατο παράδειγμα και το εξετάζω ακαδημαϊκά. Στην περίπτωση όμως που ταιριάζει τότε ναι, ενδεχομένως θα το έκανα.

  • Like 1
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

  • Moderators

Με μπερδέψατε ρε παιδιά. Τελικά ποιο απ' τα δύο είναι το πιο σωστό και λογικό;

 

παπι έχεις δίκιο γι' αυτό με το interface, θα προσπαθήσω να το αλλάξω έτσι όπως το έχεις εσύ αν έχω το χρόνο στο τέλος!

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Με μπερδέψατε ρε παιδιά. Τελικά ποιο απ' τα δύο είναι το πιο σωστό και λογικό;

 

παπι έχεις δίκιο γι' αυτό με το interface, θα προσπαθήσω να το αλλάξω έτσι όπως το έχεις εσύ αν έχω το χρόνο στο τέλος!

 

Δεν αφορά την περίπτωση σου. Σε εσένα έτσι κι αλλιώς δεν υπάρχει virtually const με καμία έννοια και ισχύει ότι σου απάντησαν παραπάνω.

 

Επίσης ναι αν είναι project με το οποίο ασχολείσαι σοβαρά και αξίζει να ασχοληθείς, το interface είναι σαφώς προτιμότερο και πολύ πιο εύκολα επεκτάσιμο. 

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Με μπερδέψατε ρε παιδιά. Τελικά ποιο απ' τα δύο είναι το πιο σωστό και λογικό;

 

παπι έχεις δίκιο γι' αυτό με το interface, θα προσπαθήσω να το αλλάξω έτσι όπως το έχεις εσύ αν έχω το χρόνο στο τέλος!

Το σωστο ειναι χωρις const εφοαον το ομπτζεκτ που κανεις ενκαψουλειτ δεν ςιναι const. Αν κανεις το ομπτζεκτ κονστ, τοτε θα κανεις και τις μεθοδους κονστ και τελος θα πεις, τι μαλακια εκανα???

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

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

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

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

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

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

Σύνδεση

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

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