signal handlers

[migf1]

 

 

+1

 

Ωραίος. Μα ιστορική πληροφορία θα είναι, μα σωστή μεθοδολογία για το Χ πρόβλημα θα είναι, πάντα μπορείς να βασιστείς στον DirectX και στον defacer ότι θα σου μάθουν κάτι σε κάθε post τους.

 

 

 

Pardon me, αλλά στο συγκεκριμένο νήμα ο defacer γράφει πως ο Windows Manager των Windows τρέχει στο ... userland, πως τεχνικά δεν υπάρχει λόγος που είναι ενσωματωμένος στον πυρήνα του OS και πως τα GUI signals υλοποιούνται μέσω kernel signals.

 

 

 

[defacer]

@migf1:

 

Για τα signals ήλπιζα ότι το ξεκαθαρίσαμε: το μόνο κοινό που έχουν τα 2 που αναφέρεις είναι ότι χρησιμοποιείς τη λέξη "signal" για να αναφερθείς σ' αυτά (ακουλουθώντας την ορολογία του GTK στη μία περίπτωση, η οποία δε μας βολεύει εδώ για να συνεννοούμαστε είναι η αλήθεια). Κατά τα άλλα καμία απολύτως σχέση.

 

Για τον window manager σωστά τα λες ότι πλέον τρέχει σε kernel mode, το είχα ξεχάσει τελείως.

 

Το unix-like layer των Windows που λες το απέφευγα πάντα σαν τον πλάγκουρα γιατί... δεν ήταν και ο,τι καλύτερο... -- πλέον στα Win8 είναι deprecated και έχει πάρει το δρόμο του για απόσυρση. Καιρός ήταν.

 

PS: Αν ξεκολλούσες λίγο και με το προσωπικό που έχεις μαζί μου θα είμασταν ζάχαρη εδω μέσα.

Για τα signals και το που τρέχει ο wm τα είπα (τελευταία φορά ελπίζω) αμέσως παραπάνω. Για τον "τεχνικό λόγο": όταν λέω "υπάρχει τεχνικός λόγος" εννοώ "δεν γίνεται διαφορετικά". Το ότι επιλέγεις να το κάνεις με τον Χ τρόπο προκειμένου να έχεις το τάδε πλεονέκτημα ας το ονομάσουμε κάπως αλλιώς. Δεν έχω διάθεση να συνεχιστεί η κολοκυθιά.

[migf1]

@migf1:

...

PS: Αν ξεκολλούσες λίγο και με το προσωπικό που έχεις μαζί μου θα είμασταν ζάχαρη εδω μέσα.

...

Για τα signals και το που τρέχει ο wm τα είπα (τελευταία φορά ελπίζω) αμέσως παραπάνω. Για τον "τεχνικό λόγο": όταν λέω "υπάρχει τεχνικός λόγος" εννοώ "δεν γίνεται διαφορετικά". Το ότι επιλέγεις να το κάνεις με τον Χ τρόπο προκειμένου να έχεις το τάδε πλεονέκτημα ας το ονομάσουμε κάπως αλλιώς. Δεν έχω διάθεση να συνεχιστεί η κολοκυθιά.

 

 

 

Καμία σχέση με προσωπικά το προηγούμενο ποστ μου. Θα έγραφα ακριβώς το ίδιο προς τον imitheo για οποιονδήποτε έγραφε στο νήμα 3 χτυπητές ανακρίβειες και ο imitheos του έδινε credit για αυτές.

 

ΥΓ. Παρεμπιπτόντως, σχετικά με την... ζάχαρη, δεν βοηθάει καθόλου το γεγονός πως ουδέποτε έχεις παραδεχτεί πως δεν ξέρεις ή πως μισο-ξέρεις πράγματα που τα έχεις προηγουμένως παρουσιάσει ως κεκτημένη γνώση σου. Αντιθέτως επιμένεις να τα υποστηρίζεις με προκλητική επιμονή, no matter what, συνήθως εις βάρος του on-topic ζητήματος που πραγματεύεται ένα νήμα.

 

 

[defacer]

Life is too short for this. Λυπάμαι, θα προτιμούσα να είναι αλλιώς, αλλά τι να γίνει.

[imitheos]

 

Καμία σχέση με προσωπικά το προηγούμενο ποστ μου. Θα έγραφα ακριβώς το ίδιο προς τον imitheo για οποιονδήποτε έγραφε στο νήμα 3 χτυπητές ανακρίβειες και ο imitheos του έδινε credit για αυτές.

 

Το μήνυμα του DirectX αποτέλεσε μεν αφορμή αλλά αυτό που έγραψα ήταν γενική παρατήρηση και δεν αφορούσε μόνο το παρόν νήμα.

 

Και εγώ και εσύ και πολύς κόσμος βοηθάει στο φόρουμ αλλά οι περισσότεροι είμαστε πιο πολύ "για τα εύκολα" (ή τουλάχιστον αυτό βλέπω εγώ. μπορεί κάποιοι να έχουν τρελές γνώσεις αλλά να βαριούνται να απαντήσουν). Αν διαβάσεις μηνύματα του DirectX και του defacer, πολλές φορές αναφέρουν ωραίες μεθόδους επίλυσης κάποιου προβλήματος και low level λεπτομέρειες που δεν τις ξέρει ο πολύς κόσμος ή που δεν πήγε το μυαλό των υπολοίπων μας εκεί.

[migf1]

 

 

Το μήνυμα του DirectX αποτέλεσε μεν αφορμή αλλά αυτό που έγραψα ήταν γενική παρατήρηση και δεν αφορούσε μόνο το παρόν νήμα.

 

Το δικό μου απεναντίας αφορούσε μόνο το παρόν νήμα (το οποίο συγκαταλέγεται στην γενική σου παρατήρηση). Αλλά ευχαρίστως να επεκταθώ και γενικώς (έτσι κι αλλιώς σε spoiler είμαστε).

 

Και εγώ και εσύ και πολύς κόσμος βοηθάει στο φόρουμ αλλά οι περισσότεροι είμαστε πιο πολύ "για τα εύκολα" (ή τουλάχιστον αυτό βλέπω εγώ. μπορεί κάποιοι να έχουν τρελές γνώσεις αλλά να βαριούνται να απαντήσουν). Αν διαβάσεις μηνύματα του DirectX και του defacer, πολλές φορές αναφέρουν ωραίες μεθόδους επίλυσης κάποιου προβλήματος και low level λεπτομέρειες που δεν τις ξέρει ο πολύς κόσμος ή που δεν πήγε το μυαλό των υπολοίπων μας εκεί.

 

Προσπαθώ να διαβάζω όλα τα μηνύματα του φόρουμ.

 

Μιας κι ανέφερες τα δυο αυτά παιδιά λοιπόν, και μιλώντας γενικώς (και φυσικά μέσα σε spoiler) η δική μου εκτίμηση είναι πως και οι 2 έχουν πολλές γνώσεις.

 

Η ειδοποιός διαφορά όμως είναι πως δεν έχω συναντήσει ακόμα τον DirectX να γράφει ανακρίβειες και κυρίως να τις υποστηρίζει με πείσμα ακόμα κι όταν είναι ή γίνεται ολοφάνερο πως είναι τέτοιες. Επίσης τις περισσότερες φορές ο DirectX όχι μόνο συνοδεύει τις τοποθετήσεις του με κώδικα, αλλά και με κώδικα που γράφει ο ίδιος (είτε ολοκληρωμένο κώδικα είτε αποσπάσματα).

 

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

 

Τον defacer από την άλλη μεριά τον θυμάμαι όχι μόνο να γράφει ανακρίβειες σε αρκετά νήματα αλλά και να επιμένει κιόλας σε αυτές και μάλιστα με το γνωστό του δασκαλίστικο ύφος. Για παραδοχή σφάλματος από μέρους του ούτε λόγος φυσικά.

 

Αμέσως-αμέσως μου έρχονται στο μυαλό (προφανώς επειδή είχα εμπλακεί κι εγώ) ..

 

1. το τρέχον νήμα (το μόνο που "παραδέχτηκε" ήταν πως ο Windows Manager τρέχει σε kernel-mode, και φυσικά όχι επειδή δεν το ήξερε, αλλά επειδή το "ξέχασε")

 

2. ένα περί "support" (σε εκείνο το νήμα έφτασε ακόμα και στο σημείο να γράψει πως η C είναι OOP paradigm γλώσσα, προκειμένου να μην παραδεχτεί πως δεν γνώριζε εξαρχής τι σημαίνει "support" σε computer-science context.)

 

3. ένα που υποστήριζε πως ένα βελτιστοποιημένο managed τρέχει ταχύτερα από ένα βελτιστοποιημένο unmanaged (δεν θυμάμαι λεπτομέρειες)

 

4. ένα που μας προέτρεπε να χρησιμοποιούμε τα const στην C σαν να ήμασταν σε C++ και φυσικά ουδέποτε παραδέχτηκε πως δεν ήξερε εξαρχής ούτε τα συγκριτικά πλεονεκτήματα των #define, ούτε ότι τα const στην C διαφέρουν από τα const στην C++

 

(είναι κι άλλα νήματα απλώς δεν τα θυμάμαι τώρα)

 

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

 

Αυτά από την μεριά μου, με αφορμή την γενική φύση του σχολιασμού σου, αναφορικά πάντα με τα 2 αυτά παιδιά που ανέφερες.

 

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

 

Το ίδιο ισχύει και για τις λύσεις.

 

Εγώ προσωπικά συναντώ στο φόρουμ έξυπνες/ενδιαφέρουσες/πρωτότυπες λύσεις (με ή χωρίς κώδικα) κι από τον timon, κι από τον παπι, κι από σένα, κι από άλλα παιδιά που δεν συμμετέχουν τόσο συχνά (π.χ. nspyroy, Chris6, TMark, Parsifal) κι άλλα παιδιά που ξεχνάω.

 

 

 

[defacer]

Η ειδοποιός διαφορά όμως είναι πως δεν έχω συναντήσει ακόμα τον DirectX να γράφει ανακρίβειες και κυρίως να τις υποστηρίζει με πείσμα ακόμα κι όταν είναι ή γίνεται ολοφάνερο πως είναι τέτοιες. Επίσης τις περισσότερες φορές ο DirectX όχι μόνο συνοδεύει τις τοποθετήσεις του με κώδικα, αλλά και με κώδικα που γράφει ο ίδιος (είτε ολοκληρωμένο κώδικα είτε αποσπάσματα).

 

Συγγνώμη που δεν ξεκλέβω περισσότερο χρόνο από την οικογένεια, τη δουλειά και την ενημέρωσή μου για να γράφω τελείως τετριμμένα πράγματα όπως linked list σε C και πως θα διαβάσουμε είσοδο με την scanf.

 

Η αλήθεια είναι πως ενίοτε γράφω κώδικα στο forum, και μάλιστα με μεράκι, αλλά δεν ήταν σε C οπότε δεν ξέρω αν μπορείς να τον εκτιμήσεις.

 

1. το τρέχον νήμα (το μόνο που "παραδέχτηκε" ήταν πως ο Windows Manager τρέχει σε kernel-mode, και φυσικά όχι επειδή δεν το ήξερε, αλλά επειδή το "ξέχασε")

 

Δεν είμαι σίγουρος σε τι ηλικίας παιδάκια αρμόζει αυτό το επιχείρημα. Το αδιαμφισβήτητο γεγονός είναι πως την ώρα που γινόταν η συγκεκριμένη κουβέντα δεν είχα στο μυαλό μου ότι σήμερα ο wm είναι μέρος του kernel. Το αν αυτό συμβαίνει επειδή δεν το ήξερα ποτέ, ή το ήξερα και το ξέχασα, ή το ήξερα αλλά προσποιούμαι άγνοια, ή για οποιοδήποτε άλλο λόγο, είναι η αιτία, όχι δικαιολογία. Κι αυτό γιατί η δήλωσή μου ήταν πληροφορία και όχι επιχείρημα -- έννοια με την οποία έχουμε συχνά πυκνά δυσκολίες σ' αυτό το forum.

 

Αν θέλεις μπορείς να ψάξεις να βρεις κάποιο παλιό post μου όπου λανθασμένα ανέφερα πως δεν δίνονται εγγυήσεις για το μέγεθος των integral types σε C και C++ -- προφανώς όχι επειδή δεν το θυμόμουν σωστά αλλά επειδή σύμφωνα με τη λογική σου δεν έχω διαβάσει το σχετικό τμήμα του standard (θέμα για το οποίο αφήνω να μιλήσουν οι δημοσιεύσεις). Αν το βρεις σταμάτα να διαβάζεις το thread πριν φτάσεις στο σημείο που λέω "συγγνώμη παιδιά, λάθος", μπορεί να μην ταιριάζει με την κοσμοθεωρία σου.

 

Επίσης, κάτι σχετικό και με τον Directx που λες παραπάνω αλλά και με το "ξέχασα" (οπότε είπα να το βάλω εδώ):

 

Τις συνεισφορές του Directx τις εκτιμώ και ο ίδιος (παρόλο που έχω να κάνω κριτική για τη νοοτροπία του ώρες ώρες -- το ένα δεν αποκλείει το άλλο), αλλά επέτρεψέ μου να σου θυμίσω μιας και επίτηδ^Η^Η^Η^Η^Η^Η ξέχασες πως το έχεις συναντήσει (μιας και μιλάμε για το #1 thread όπου μόνιμα συμμετέχεις, αμέσως μετά από ένα πάρτυ στο οποίο είμασταν καλεσμένοι οι δυο μας):

 

http://www.insomnia....10#entry4865486

 

Ζητώ συγγνώμη από τον Directx και τα υπόλοιπα μέλη για τη συμβολή μου στο πάρτυ που ξεκινάει απ' αυτό το post, αλλά μιας και μιλάμε για ανακρίβειες... just sayin'.

 

Φαντάσου να ήταν ξεκάθαρο από τα παραπάνω πως το quote σου με το οποίο ξεκίνησα αυτή την απάντηση είναι factually wrong λόγω "κακής μνήμης" (ακριβώς δηλαδή το ίδιο πράγμα για το οποίο μου σέρνεις).

 

Και φαντάσου το δικό σου λάθος να ήταν πάνω σε φάση επιχειρηματολογίας και όχι πληροφόρησης.

 

Tough.

 

2. ένα περί "support" (σε εκείνο το νήμα έφτασε ακόμα και στο σημείο να γράψει πως η C είναι OOP paradigm γλώσσα, προκειμένου να μην παραδεχτεί πως δεν γνώριζε εξαρχής τι σημαίνει "support" σε computer-science context.)

 

Η σελίδα με το λήμμα support λείπει από το computer science λεξικό μου. Αν έχεις την καλοσύνη να παραθέσεις από το δικό σου αντίγραφο;

 

3. ένα που υποστήριζε πως ένα βελτιστοποιημένο managed τρέχει ταχύτερα από ένα βελτιστοποιημένο unmanaged (δεν θυμάμαι λεπτομέρειες)

 

Δε θυμάσαι; Επίτηδες θα το κάνεις... αλλά δεν πειράζει, θα σου θυμίσω εγώ (από αυτό το thread):

 

Αν συγκρίνουμε ακριβώς ίδιες αλγοριθμικά υλοποιήσεις σε managed και unmanaged κώδικα, προσαρμοσμένες προφανώς στα πλεονεκτήματα της κάθε γλώσσας, τότε το unmanaged είναι νομοτελειακά πιο γρήγορο.

 

Όσο για το "νομοτελειακά" πιο γρήγορο: έτσι για να κάνω το δικηγόρο του διαβόλου, έχεις υπόψη ότι ας πούμε ένας jitter μπορεί να μετατρέψει IL σε ο,τι πιο σύγχρονο instruction set υποστηρίζει η CPU στην οποία τρέχει, ενώ από την άλλη σε ένα native binary επιλέγεις target CPU at compile time και τέλος;

 

Δε διαφωνώ με το "πολλές φορές" πιο γρήγορο (αν και όπως είπα διάλεξε τι προτιμάς: λίγο πιο αργό ή undefined behavior?) αλλά το "νομοτελειακά" απλά δεν ισχύει.

 

Τα σχόλια δικά σας. Δε θα μπω στον κόπο να παραθέσω επόμενα posts όπου συνεχίζεις ότι ντε και καλά το handcrafted unmanaged είναι πάντα γρηγορότερο από αυτό που κάνει ο JIT compiler. Υπάρχουν όλα σε κείνο το thread για όποιον ενδιαφέρεται.

 

4. ένα που μας προέτρεπε να χρησιμοποιούμε τα const στην C σαν να ήμασταν σε C++ και φυσικά ουδέποτε παραδέχτηκε πως δεν ήξερε εξαρχής ούτε τα συγκριτικά πλεονεκτήματα των #define, ούτε ότι τα const στην C διαφέρουν από τα const στην C++

 

"Να χρησιμοποιούμε const στη C σαν να ήμασταν σε C++" => ουδέν σχόλιο.

 

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

 

Κάπου στο ενδιάμεσο έχουμε την τύχη να πληροφορηθούμε από εσένα τον ίδιο για τα συγκριτικά πλεονεκτήματα των define, τα οποία περιλαμβάνουν

 

Εύκολη & γρήγορη παραμετροποίηση, π.χ. συγκεντρωμένα #defines σε ένα config.h χωρίς να χρειάζεται να καταφύγεις σε global consts.

 

Γιατί όπως όλοι ξέρουμε const μεταβλητές και enums δε μπορούν να δηλωθούν σε ένα config.h, η είσοδος επιτρέπεται μόνο στα #define.

 

Κλείνω με μία παράκληση: την επόμενη φορά που... δε θα θυμάσαι ακριβώς... τι ειπώθηκε σε κάποια θέματα, βρες τα και δίνε και κανα link.

[migf1]

 

 

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

 

Οι αποσπασματικές σου παραθέσεις είναι εκ του πονηρού (όπως για παράδειγμα στις παραθέσεις που κάνεις περιέργως δεν συμπεριλαμβάνονται π.χ. εκείνες στις οποίες φαίνεται πως δεν γνώρίζες πως τα consts δεν κάνουν για VLA array definitions, καθώς επίσης εκείνες στις οποίες φαίνεται πως δεν γνώριζες ούτε ότι τα enums βάζουν περιορισμούς στα bitflag definitions).

 

Btw, μιας και βλέπω πως δεν το έχεις εμπεδώσει ακόμα πως τα const στην C διαφέρουν από τα const στην C++, ίσως σου φανεί χρήσιμο αυτό link από ένα forum για beginners: http://www.gamedev.n...ences-in-const/ (θα βρεις κι άλλα links εκεί μέσα).

 

Over & out πάω να μελετήσω τους ωκεανούς κώδικα που έχεις ποστάρει στο φόρουμ... ιδιαίτερα τους μη-τετριμμένους (μιας και τους τετριμμένους που έχεις μάθει να χρησιμοποιείς έτοιμους τους έχουν γράψει κάποιοι άλλοι για σένα, σίγουρα όχι εσύ πάντως).

 

 

 

[defacer]

 

 

Οι αποσπασματικές σου παραθέσεις είναι εκ του πονηρού (όπως για παράδειγμα στις παραθέσεις που κάνεις περιέργως δεν συμπεριλαμβάνονται π.χ. εκείνες στις οποίες φαίνεται πως δεν γνώρίζες πως τα consts δεν κάνουν για VLA array definitions, καθώς επίσης εκείνες στις οποίες φαίνεται πως δεν γνώριζες ούτε ότι τα enums βάζουν περιορισμούς στα bitflag definitions).

 

Σε προκαλώ ευθέως να κάνεις ο ίδιος τις παραθέσεις που εκ του πονηρού παρέλειψα και ακριβώς από κάτω να σχολιάσεις βγάζοντας συμπεράσματα. Από αερολογία χόρτασα.

 

Απο κει και πέρα απλά λες βλακείες μιας και π.χ. φυσικά και μπορούν να χρησιμοποιηθούν const σε array definition. Το ότι το παραγόμενο array θα είναι "κλασικό" στατικό array και όχι VLA είναι κάτι που γνωρίζω πολύ καλά (όπως είπα προκαλώ για παράθεση) και έχει μόνο πλεονεκτήματα σε σχέση με ένα VLA -- όπως είναι φανερό σε οποιονδήποτε ξέρει πώς υλοποιείται από τον compiler το πρώτο (εξ ολοκλήρου at compile time) και το δεύτερο (at runtime).

 

Αντί γι' αυτά, το σχόλιό σου (φαντάζομαι όχι εκ του πονηρού) αφήνει να εννοηθεί πως οι VLA είναι αυτοσκοπός και όχι "αναγκαίο" κακό. "Αναγκαίο" σε εισαγωγικά γιατί μπορείς να κάνεις το ίδιο πράγμα με malloc (απλά με όχι τόσο βολικό τρόπο) και κακό χωρίς εισαγωγικά γιατί δεν υπάρχει κανένας λόγος να χρησιμοποιήσεις VLA αν ένας fixed array σε καλύπτει.

 

Και τέλος, επειδή πραγματικά με έχει κουράσει η υπόθεση: θα έρθει ποτέ η μέρα που θα υποστηρίξεις τα πράγματα τα οποία εσύ ο ίδιος έχεις πει στο παρελθόν (παρουσιάζοντας την άλλη όψη του νομίσματος που εγώ εκ του πονηρού παραλείπω), ή θα παραμείνεις μονίμως σαν το αρχέτυπο του παπατζή που όποτε τον φέρνουν μπροστά σε hard facts υπεκφεύγει;

 

 

[migf1]

 

 

Όσο και να προκαλείς, δεν πρόκειται να σου κάνω την χάρη διότι σε έχω βαρεθεί. Τα νήματα τα παράθεσες, ας τα διαβάσει όποιος ενδιαφέρεται.

 

ΥΓ1. Btw μιας και...

 

Το ότι το παραγόμενο array θα είναι "κλασικό" στατικό array και όχι VLA είναι κάτι που γνωρίζω πολύ καλά (όπως είπα προκαλώ για παράθεση) και έχει μόνο πλεονεκτήματα σε σχέση με ένα VLA -- όπως είναι φανερό σε οποιονδήποτε ξέρει πώς υλοποιείται από τον compiler το πρώτο (εξ ολοκλήρου at compile time) και το δεύτερο (at runtime).

 

για κάνε μας και initialize τον "παραγόμενο 'κλασικό' στατικό πίνακα (που δεν είναι VLA )" που όρισες με const size και πόσταρέ μας και πάλι σχετικό link αποτελέσματος.

 

ΥΓ2. Είναι όντως ολοφάνερο πως... ξέρεις.

 

 

[defacer]

για κάνε μας και initialize τον "παραγόμενο 'κλασικό' στατικό πίνακα (που δεν είναι VLA )" που όρισες με const size και πόσταρέ μας και πάλι σχετικό link αποτελέσματος.

 

ΥΓ2. Είναι όντως ολοφάνερο πως... ξέρεις.

 

Και εδώ είναι το σημείο που παραδέχομαι πως πιο πάνω πέταξα τούβλο μιας και δεν γράφω ποτέ "πραγματικό" κώδικα σε C κι έτσι ξέχασα τα όσα ισχύουν σχετικά από τον καιρό που το είχα ψάξει στα πλαίσια εκείνου του topic (στο οποίο βέβαια δεν γίνεται το ίδιο λάθος).

 

Κατά τα άλλα ορίστε το πώς μπορείς να το κάνεις (χωρίς VLA και χωρίς #define) με τον τρόπο τον οποίο είχα προτείνει τότε.

 

Admitting you were wrong: it's not that hard. Try it.

[ipduh]

ε__ do code , not war

[migf1]

 

 

 

Και εδώ είναι το σημείο που παραδέχομαι πως πιο πάνω πέταξα τούβλο μιας και δεν γράφω ποτέ "πραγματικό" κώδικα σε C κι έτσι ξέχασα τα όσα ισχύουν σχετικά από τον καιρό που το είχα ψάξει στα πλαίσια εκείνου του topic (στο οποίο βέβαια δεν γίνεται το ίδιο λάθος).

 

Κατά τα άλλα ορίστε το πώς μπορείς να το κάνεις (χωρίς VLA και χωρίς #define) με τον τρόπο τον οποίο είχα προτείνει τότε.

 

Γιατί χωρίς #define; Τι πρακτικό πρόβλημα έχει το #define? Και πιο συγκεκριμένα, ποιο πρακτικό ακριβώς πλεονέκτημα δίνει αυτός ο ορισμός που κάνεις στο enum έναντι του κλασικού #define (πλην του debugging... δες παρακάτω);

 

Ανεξάρτητα από το συγκεκριμένο παράδειγμα (για το οποίο δεν είναι αναγκαίο), αν θεωρείς πως χρησιμοποιώντας enums και ιδιαίτερα ανώνυμα enums, κερδίζεις type-safeness στη C, απατάσαι. At the very least, θα πρέπει να το ονοματίσεις το enum και όχι να το ορίζεις ανώνυμο. Επιπρόσθετα, θα πρέπει να ορίζεις explicitly ως τέτοιου τύπου μεταβλητές προορισμένες να διαχειρίζονται τιμές του ονοματισμένου enum.

 

Με ονοματισμένο το enum και explicit var definitions of that enum, έχεις πιθανότητες να σου βγάλει warning ο compiler (αν είσαι τυχερός κι έχεις καλό compiler). Στην C όμως ούτε αυτό σου εξασφαλίζει πως η μεταβλητή σου δεν θα μπορεί να πάρει τιμές έξω από το εύρος τιμών του enum, έστω και κατά λάθος.

 

Και από την επιμονή σου (αδικαιολόγητη εμμονή λόγω άγνοιας την χαρακτηρίζω εγώ) να χρησιμοποιείς πάντα enum αντί για #define (όπως μας προέτρεπες να κάνουμε σε εκείνο το νήμα, αν το θυμάμαι καλά... ή μπορεί να ήταν σε κάποιο άλλο) καταλαβαίνω (ή μάλλον μου υπενθυμίζεις) πως εκτός από τα const δεν γνωρίζεις ούτε πως και τα enum διαφέρουν μεταξύ C και C++.

 

Το μόνο λοιπόν πρακτικό πλεονέκτημα που έχουν τα anonymous enums έναντι των #define είναι πως δημιουργούν symbols για το debugging. Κάτι που αρκετό τώρα έχει πάψει να αποτελεί πρόβλημα για τον gdb, μιας και με το flag -g3 μπορεί και κάνει expand preprocessor macros: http://sourceware.org/gdb/onlinedocs/gdb/Macros.html (εξακολουθεί όμως να είναι ευκολότερο το debugging με τα enums).

 

Και τέλος, ένα βασικό μειονέκτημα των enums έναντι των #define (όπως σου είχαμε εξηγήσει ξανά και σε εκείνο το νήμα νομίζω, μιας και ούτε αυτό το ήξερες) είναι πως τα enum δεν είναι καλή ιδέα για ορισμό bit-flags, μιας και το εύρος τιμών τους είναι implementation dependent.

 

Βέβαια είμαι σίγουρος πως τα ήξερες κι αυτά, αλλά απλώς τα είχες... ξεχάσει.

 

ΥΓ. Κανείς δεν τα ξέρει όλα, ούτε πρόκειται να τα ξέρει ποτέ όλα. Θεμιτό, κατανοητό και πολύ σύνηθες για όλους μας.

 

Άλλο όμως αυτό κι άλλο το να παρουσιάζεις ανακρίβειες ως facts και να επιμένεις σε αυτές με όποια πιθανή κι απίθανη επιχειρηματολογία σου έρχεται πρόχειρη ή εφευρίσκεις κατά το δοκούν, η οποία κατά κανόνα είτε προσθέτει κι άλλες ανακρίβειες πάνω στις αρχικές, είτε αποπροσανατολίζει σκόπιμα τη κουβέντα. Μόνο και μόνο για να μην φανεί πως δεν γνώριζες ή μισο-γνώριζες εξαρχής, πράγματα που παρουσίασες ως κεκτημένη σου γνώμη (συνήθως μάλιστα με ύφος και με υποδείξεις τέτοιες που σε κάποιον λιγότερο εξοικειωμένο δημιουργεί το illusion πως ξέρεις για τι μιλάς).

 

Admitting you were wrong: it's not that hard. Try it.

I've already done that, many more times than once, and I'll keep doing it. I've even done it specifically against you (admitting I'm wrong, that is)... alas it didn't help, not even a bit. Frankly, when it comes to you, I don't give a damn!