Generic/Abstract Programming με C

[migf1]

..

@migf1:

Βεβαίως ο πελάτης έχει σχεδόν πάντα δίκιο αλλά από την περιγραφή εμένα αυτό μου φαίνεται πως είναι list με περιορισμένες δυνατότητες και όχι stack με αυξημένες.

 

Yeap, και μένα έτσι μου κάνει. Αλλά αν το δεις ως υποσύνολο του γενικότερου, είναι το ίδιο πράγμα και actually it makes sense.

 

Δηλαδή, έχοντας το ίδιο underlying structure θα μπορείς να το διαχειρίζεσαι ως στοιβα με τις gstack_ συναρτήσεις, ως ουρά με τις gqueue_ συναρτήσεις, κλπ (btw, να θυμηθώ να βάλω κι ένα id field στον constructor για να μπορώ να κάνω validate ποιες συναρτήσεις θα έχουν access στο structure και ποιες όχι ).

 

Η όλη ιδέα με ένα stack είναι πως επίτηδες δεν μπορείς να κάνεις άλλο access πέραν του peek(). Π.χ. στη C++ θα ήταν trivial ο stack να υποστηρίζει iterators (μιας και οι containers που χρησιμοποιεί για το implementation το κάνουν ήδη) αλλά αυτό δε συμβαίνει -- προφανώς by design.

 

Yeap, αυτή είναι η περπατημένη. Υποθέτω πως για αυτόν ακριβώς τον λόγο πήρα τη δουλίτσα, γιατί δεν θέλουν την περπατημένη

 

Παρεμπιπτόντως όμως, ρίξε μια ματιά και σε αυτό: http://sourcemaking.com/design_patterns/iterator/cpp/1.

 

Ελπίζω πάντως να συμφωνούμε πως εντάσσεται στα πλαίσια της κοινής λογικής το να μπορείς τουλάχιστον να ερευνήσεις efficiently την στοίβα σου για την ύπαρξη ή όχι ενός στοιχείου της, κι ας μην υπάγεται στα strictly defined operations της κοινής στοίβας.

 

Όπως και το να μπορείς να κάνεις update τα περιεχόμενα της.

 

Για παράδειγμα: http://harmony.apache.org/subcomponents/drlvm/doxygen/vmcore/html/stack_walking.html

 

Ανέκαθεν, το γενικότερο "thinking out of the box" προσέλκυε το αμέριστο ενδιαφέρον μου

 

Update:

 

...

(btw, να θυμηθώ να βάλω κι ένα id field στον constructor για να μπορώ να κάνω validate ποιες συναρτήσεις θα έχουν access στο structure και ποιες όχι ).

 

Εννοώ π.χ η gstack_new() να θέτει το field ας πούμε σε GSTACK_TYPE, οπότε αν π.χ. έχει φτιάξει μια stack και πάει μετά να κάνει πάνω της ας πούμε: gqueuue_enqueue() να του λέει "φίλε, το έχεις φτιάξει ως στοίβα, αν θες να κάνεις enqueue φτιάξε το ως ουρά πρώτα).

 

[defacer]

Παρεμπιπτόντως όμως, ρίξε μια ματιά και σε αυτό: http://sourcemaking....iterator/cpp/1.

 

“Every ‘container-like’ class must have an iterator.” It may seem like a violation of encapsulation for a Stack class to allow its users to access its contents directly, but John Lakos’ argument is that the designer of a class inevitably leaves something out. Later, when users need addi- tional functionality, if an iterator was originally provided, they can add functionality with “open for extension, closed for modification”.

 

Δεν ξέρω αν αναφέρεσαι στο bolded, αλλά μετα συγχωρήσεως αυτή η ατάκα δε σημαίνει τίποτα χωρίς context. Mε το ίδιο "επιχείρημα" ο designer του std::string ξέχασε να βάλει έναν operator* που να λειτουργεί σαν string("z") * 3 == string("zzz") -- το παράδειγμα είναι επιλεγμένο επειδή πρόκειται για γνωστή περίπτωση που ο designer δεν ξέχασε τίποτα, αντίθετα αυτός που κάνει την παρατήρηση

1. δεν έχει συνειδητοποιήσει πως υπάρχουν και μειονεκτήματα στο να κάνεις κάτι τέτοιο
    
   
2. δεν έχει καταλάβει ότι το standard library way θα ήταν μια free function την οποία μπορεί να γράψει μόνος του
   

Συμφωνούμε βέβαια πως δεν είναι γραμμένο σε καμία πέτρινη πλάκα ότι απαγορεύεται να κάνεις iteration πάνω στις τιμές ενός stack, είναι όμως λίγο ασυνήθιστο. Με την έννοια πως αν ήθελες να κάνεις iteration τότε τι σε χαλούσε να έχεις list αντί για stack? Όπως και να 'χει πάντως, δεν έχω αντίρρηση στην ουσία του πράγματος.

 

Από την άλλη το να μπορείς να πειράζεις τα περιεχόμενα κάποιου container που στο όνομά του υπάρχει η λέξη stack (π.χ. replace αυτό με εκείνο) είναι πιο πολύ violation of encapsulation => πεθαίνεις.

 

Για παράδειγμα: http://harmony.apach...ck_walking.html

 

Δεν έκατσα να το ψειρίσω αλλά αυτό το παράδειγμα δε μου φαίνεται σχετικό. Ναι μεν λέει "Stack" αλλά αυτό το Stack αναφέρεται στην έννοια του execution stack και όχι του stack σαν data structure. Ένα data structure που απεικονίζει μια κατάσταση του execution stack δε θέλουμε απαραίτητα να το χειριζόμαστε το ίδιο με ένα data structure που είναι stack.

 

Ανέκαθεν, το γενικότερο "thinking out of the box" προσέλκυε το αμέριστο ενδιαφέρον μου

 

Ντύσου καλύτερα στο forum, κυκλοφορεί Δελαπόρτας

 

Σοβαρά τώρα, το thinking out of the box το αντιλαμβάνομαι ως "ασυνήθιστη προσέγγιση". Δε σημαίνει απαραίτητα ότι είναι και καλή ιδέα. Μπορεί να υπάρχει λόγος που δε συνηθίζεται...

[migf1]

@defacer:

 

Επί της ουσίας δεν διαφωνούμε σε κάτι εδώ. Τα λινκς τα έβαλα για να δώσω έμφαση στο ότι οι υλοποιήσεις του εκάστοτε data structure έχουν ανοχές ελαστικότητας, ανάλογα τις εκάστοτε ανάγκες.

 

Βtw, και μένα με χαλάει που θα μπορούν να έχουν ελεύθερο write access στα data της stack, επειδή προσωπικά θεωρώ στοιχειώδες χαρακτηριστικό της το να μην μπορείς να "χαλάσεις" την αντιστοιχία μεταξύ σειράς με την οποία έχουν μπει στην στοίβα και τιμής που περιέχουν.

 

Καταλαβαίνω βέβαια από την άλλη, πως εφόσον η στοίβα είναι ουσιαστικά υποσύνολο ενός γενικότερου και πιο αφηρημένου context, η δυνατότητα αυτή είναι χρήσιμη σε άλλα interfaces του ίδιου structure (π.χ. μιας απλής λίστας). Καταλαβαίνω επίσης πως ακόμα και σε στοίβες υπάρχουν περιπτώσεις που είναι και επιθυμητό και βολικό να μπορούν να γίνουν update τα περιεχόμενά της, κι ακόμα περισσότερο να μπορούν να ερευνηθούν.

 

At the end of the day, όμως, εφόσον έτσι το θέλουν δεν μου πέφτει λόγος.

 

Να προσθέσω όμως στην απορία που εξέφρασες: γιατί αν θες iteration δεν το κάνεις list αντί για stack, ότι αν η γενική περίπτωση εξυπηρετείται από το stack concept, τότε το είναι λογικό να την εξυπηρετήσεις έτσι και να τις έχεις enhancments για τις εξαιρέσεις.

 

Ένα πολύ απλοϊκό παράδειγμα που μου έρχεται πρόχειρα στο μυαλό, είναι ας πούμε οι τραπεζικές συναλλαγές που γίνονται μέσω ATM. Η γενική περίπτωση να τις επεξεργάζεσαι σε χρονολογική σειρά, δικαιολογεί την υλοποίησή τους είτε με stack είτε με queue. Η πολύ πιο σπάνια περίπτωση να θέλεις να βρεις αν π.χ. ο τάδε λογαριασμός έχει κινηθεί μέσω του ATM, δικαιολογεί ας πούμε μια κανονική λίστα. Οπότε it only makes sense να το υλοπιήσεις με μια stack (ή queue) η οποία θα παρέχει και ως έξτρα δυνατότητα την αναζήτηση αν και όταν την χρειαστείς.

 

Και μάλιστα είναι απόλυτα θεμιτό και σωστό να την παρουσιάσεις ως στοίβα (ή ως ουρά), αφού στη γενική περίπτωση ως τέτοια λειτουργεί.