σύγκριση χαρακτήρων στην C

[imitheos]

Και γιατί να χρησιμοποιήσω την ICU αν το πρόγραμμά μου προορίζεται μονάχα για Windows και όχι το native framework της συγκεκριμένης πλατφόρμας, σου απαντάω εγώ; Επίσης, γιατί να χρησιμοποιήσω την ICU και όχι μια δική μου υλοποίηση καστομαρισμένη ακριβώς πάνω στις δυνατότητες και τις ανάγκες μιας resource-critical εφαρμογής;

Γιατί το native framework δεν υλοποιεί όλα τα πεδία του unicode. Ο defacer μίλησε 5 φορές για collation και εγώ σου ανέφερα πριν παράδειγμα (για MacOS αλλά δεν παίζει ρόλο) για normalization.

 

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

Φυσικά. Δεν έβγαλε το μαχαίρι ο defacer και να σου πει "θα χρησιμοποιείς μόνο icu ρε αλήτη". Αυτό που λέμε όμως είναι ότι χωρίς την icu (ή κάποια αντίστοιχης ποιότητας βιβλιοθήκη) _δεν_ έχεις πλήρη υποστήριξη unicode. Αν η εφαμοργή σου δεν χρησιμοποιεί collation ή κάτι άλλο και απλά σε νοιάζει να μπορείς να μετράς πόσους "χαρακτήρες" έχει ένα string τότε φυσικά σου αρκεί το framework. Για αυτό σου είπα εξαρτάται από την εφαμοργή.

 

@imitheos: για 3η φορά, επαναλαμβάνω πως κι εσύ κι ο defacer έχετε δίκιο για το μη-portability της τεχνικής.

Εδώ και κάμποσα μηνύματα δεν μιλάμε πια για portability αλλά για το γεγονός ότι το native framework δεν είναι αρκετό σε πολλές περιπτώσεις.

 

Προσπαθείς εδώ και καμιά 10αριά posts να με κάνεις discredit και κυρίως να κάνεις discredit μια διαδεδομένη τεχνική διαχείρισης Unicode strings με C. Όταν σου παραθέτω άρθρο που εσύ υπέδειξες ως must-read σε αρχαρίους που περιγράφει ακριβώς αυτή την τεχνική, βαφτίζεις ως μη-αντιπροσωπευτικό το συγκεκριμένο κομμάτι του και μου λες ότι είναι άδικο.

Απλά αναφέρει ρε συ ότι η "διαδεδομένη τεχνική" δεν αρκεί. Το να διαφωνεί μαζί σου δεν σημαίνει ότι έχει σκοτεινό σχέδιο να σε μειώσει.

[migf1]

Γιατί το native framework δεν υλοποιεί όλα τα πεδία του unicode. Ο defacer μίλησε 5 φορές για collation και εγώ σου ανέφερα πριν παράδειγμα (για MacOS αλλά δεν παίζει ρόλο) για normalization.

...

Εδώ και κάμποσα μηνύματα δεν μιλάμε πια για portability αλλά για το γεγονός ότι το native framework δεν είναι αρκετό σε πολλές περιπτώσεις.

...

Φυσικά. Δεν έβγαλε το μαχαίρι ο defacer και να σου πει "θα χρησιμοποιείς μόνο icu ρε αλήτη". Αυτό που λέμε όμως είναι ότι χωρίς την icu (ή κάποια αντίστοιχης ποιότητας βιβλιοθήκη) _δεν_ έχεις πλήρη υποστήριξη unicode. Αν η εφαμοργή σου δεν χρησιμοποιεί collation ή κάτι άλλο και απλά σε νοιάζει να μπορείς να μετράς πόσους "χαρακτήρες" έχει ένα string τότε φυσικά σου αρκεί το framework. Για αυτό σου είπα εξαρτάται από την εφαμοργή.

...

Οπότε για να καταλάβω, η ενδεδειγμένη λύση κατά την άποψή σας όταν γράφω ένα πρόγραμμα που θέλω να υποστηρίζει Ελληνικά και Αγγλικά είναι να χρησιμοποιήσω μια από τις πιο βαριές βιβλιοθήκες που κυκλοφορούν (ICU) για να υποστηρίζει το πρόγραμμά μου άλλες 30 γλώσσες επειδή η wstrcoll δεν υποστηρίζει τη διάλεκτο του νοτιότερου χωριού στο Θιβέτ;

 

Σόρρυ για τον σαρκασμό αλλά εγώ έτσι την εισπράττω αυτή την επιχειρηματολογία.

 

Απλά αναφέρει ρε συ ότι η "διαδεδομένη τεχνική" δεν αρκεί. Το να διαφωνεί μαζί σου δεν σημαίνει ότι έχει σκοτεινό σχέδιο να σε μειώσει.

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

[imitheos]

Οπότε για να καταλάβω, η ενδεδειγμένη λύση κατά την άποψή σας όταν γράφω ένα πρόγραμμα που θέλω να υποστηρίζει Ελληνικά και Αγγλικά είναι να χρησιμοποιήσω μια από τις πιο βαριές βιβλιοθήκες που κυκλοφορούν (ICU) για να υποστηρίζει το πρόγραμμά μου άλλες 30 γλώσσες επειδή η wstrcoll δεν υποστηρίζει τη διάλεκτο του νοτιότερου χωριού στο Θιβέτ;

 

Σόρρυ για τον σαρκασμό αλλά εγώ έτσι την εισπράττω αυτή την επιχειρηματολογία.

Εσύ (και ο κάθε εσύ μια και βλέπω ότι το παίρνεις προσωπικά) μπορείς φυσικά να κάνεις ό,τι θες. Δεν προσπαθεί κανείς να πιέσει τον άλλον τι θα χρησιμοποιεί. Χρησιμοποίησε και CodePage 869 αν θέλεις και θα έχεις Ελληνικά και Αγγλικά. Αν πρόσεξες όμως το παράδειγμα που έδωσα πριν με το git, δεν ανέφερα ότι βγάζει πρόβλημα όταν γράψει κάποιος Θιβετιανά. Και στα Ελληνικά και στα Αγγλικά ακόμη θα έχεις πρόβλημα.

 

Υπάρχουν πολλές εφαρμογές που χρησιμοποιώντας wchar_t δεν θα αντιμετωπίσουν ποτέ προβλήματα γιατί δεν κάνουν χρήση κάποιων συγκεκριμένων πραγμάτων. Αυτό όμως δεν σημαίνει ότι υποστηρίζουν σωστά το Unicode και αν πας να χρησιμοποιήσεις κάποια στοιχεία θα έχεις πρόβλημα χωρίς κάποια εξειδικευμένη βιβλιοθήκη.

 

Δεν μπορώ να καταλάβω γιατί δεν καταλαβαίνεις αυτό που λέμε.

[migf1]

Εσύ (και ο κάθε εσύ μια και βλέπω ότι το παίρνεις προσωπικά) μπορείς φυσικά να κάνεις ό,τι θες. Δεν προσπαθεί κανείς να πιέσει τον άλλον τι θα χρησιμοποιεί. Χρησιμοποίησε και CodePage 869 αν θέλεις και θα έχεις Ελληνικά και Αγγλικά. Αν πρόσεξες όμως το παράδειγμα που έδωσα πριν με το git, δεν ανέφερα ότι βγάζει πρόβλημα όταν γράψει κάποιος Θιβετιανά. Και στα Ελληνικά και στα Αγγλικά ακόμη θα έχεις πρόβλημα. Αυτό λέμε τόση ώρα. Υπάρχουν πολλές εφαρμογές που χρησιμοποιώντας wchar_t δεν θα αντιμετωπίσουν ποτέ προβλήματα γιατί δεν κάνουν χρήση κάποιων συγκεκριμένων πραγμάτων. Αυτό όμως δεν σημαίνει ότι υποστηρίζουν σωστά το Unicode. Αυτό λέμε τόση ώρα.

 

Δεν μπορώ να καταλάβω γιατί δεν καταλαβαίνεις αυτό που λέμε.

Πολύ καλά καταλαβαίνω. Απλώς διαφωνώ πως οι εξαιρέσεις πρέπει πάση θυσία να αντικαθιστούν παντού και πάντα τον κανόνα.

 

Από αυτό εδώ το ποστ: http://www.insomnia....ost__p__4802661 έχω ήδη ξεκαθαρίσει όλα τα points μου πιστεύω με ικανοποιητική σαφήνεια.

 

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

[defacer]

Και γιατί να χρησιμοποιήσω την ICU αν το πρόγραμμά μου προορίζεται μονάχα για Windows και όχι το native framework της συγκεκριμένης πλατφόρμας, σου απαντάω εγώ; Επίσης, γιατί να χρησιμοποιήσω την ICU και όχι μια δική μου υλοποίηση καστομαρισμένη ακριβώς πάνω στις δυνατότητες και τις ανάγκες μιας resource-critical εφαρμογής;

 

Να μη χρησιμοποιήσεις ICU αν σου κάνει η υποστήριξη των Windows ή της glibc και ταυτόχρονα είσαι σίγουρος ότι θα εξακολουθήσει να σου κάνει στο μέλλον. Εγώ θα χρησιμοποιούσα ICU με το σκεπτικό ότι αφού θα κάτσω που θα κάτσω να μάθω μια λύση, ας μάθω τουλάχιστον αυτή που τα έχει όλα και συμφέρει. Αν εσύ έχεις άλλα κριτήρια είναι λογικό να καταλήξεις σε άλλη απόφαση.

 

Θα πρόσεξες επίσης ότι μιλάμε για αρκετές σελίδες και ανέφερα την ICU μόνο προς το τέλος, γιατί απ' τη δική μου οπτική το θέμα μας εδώ δεν είναι ποιανού το παραπαίδι την έχει μεγαλύτερη αλλά το αν η platform-specific υποστήριξη Unicode είναι αρκετή ή όχι.

 

Όσο για την καστομαρισμένη υλοποίηση -- πραγματικά δε θέλω να έρθω σε αντιπαράθεση, αλλά α) αυτός είναι ο ορισμός του not invented here syndrome και β) το 99.99% των περιπτώσεων όπου κάποιος λέει "θα το κάνω έτσι γιατί θα είμαι πιο γρήγορος και η ταχύτητα αυτή έχει σημασία" γελάει και το παρδαλό κατσίκι. Και πάλι όμως αν η συγκεκριμένη περίπτωση υπάγεται στο 0.01% τότε βεβαίως και να το κάνεις έτσι.

 

Προσπαθείς εδώ και καμιά 10αριά posts να με κάνεις discredit και κυρίως να κάνεις discredit μια διαδεδομένη τεχνική διαχείρισης Unicode strings με C. Όταν σου παραθέτω άρθρο που εσύ υπέδειξες ως must-read σε αρχαρίους που περιγράφει ακριβώς αυτή την τεχνική, βαφτίζεις ως μη-αντιπροσωπευτικό το συγκεκριμένο κομμάτι του και μου λες ότι είναι άδικο.

 

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

 

Δεύτερον discredit δεν είναι η σωστή λέξη για τη διαδεδομένη τεχνική διαχείρισης strings που αναφέρεις. Το σωστό θα ήταν να πούμε ότι πιστεύω πως όταν μιλάμε τελείως ακαδημαϊκά νομίζω πως υπάρχει καλύτερη λύση. Αν υπάρχουν 7 εκατομμύρια projects τα οποία ποτέ δεν είχαν σα στόχο να είναι π.χ. cross platform και τους έκανε η glibc τότε με γειά τους με χαρά τους. Καθ' όλη τη διάρκεια της κουβέντας όμως βλέπω πως υπάρχει μια διαρκής σύγχυση ανάμεσα στο "τι είναι αυτό που δουλεύει παντού και πάντα" το οποίο προμοτάρω εγώ και στο "τι δουλεύει υπο συνθήκες" το οποίο προμοτάρεις εσύ και ο Directx.

 

Προσωπικά θεωρώ πως είναι απόλυτα δίκαιο, γιατί αν μη τι άλλο αποδεικνύει πως δεν τα βγάζω από το μυαλό μου αυτά που υποστηρίζω.

 

Το ότι ο Joel στο τάδε προϊόν το οποίο αναπτύχθηκε υπο συγκεκριμένες συνθήκες για συγκεκριμένους πελάτες πριν από 10 σχεδόν χρόνια επέλεξε Χ δεν αποδεικνύει τίποτα. Όπως τίποτα δεν αποδεικνύει το γεγονός ότι ο τάδε χρησιμοποίησε μόνο glibc ή ότι ο δείνα χρησιμοποίησε ICU. Αν ήταν έτσι θα έβγαινα και γω να πω ότι την ICU την ανέπτυξε κατα βάση η IBM οπότε όλοι οι υπόλοιποι που δεν είστε κολοσσός δισεκατομμυρίων να κάνετε τουμπεκί, Joel και χέστηκε η φοράδα στ' αλώνι.

 

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

 

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

 

Συνεπώς το πιο σωστό είναι να πούμε ότι: "πριν τα Vista δεν μπορεί να την κάνεις αυτή την δουλεία στις ανατολικές γλώσσες με stock Win32".

 

Αυτό δεν σημαίνει ότι αξίζει να την θυσιάσεις όμως ως δυνατότητα για να διευκολύνεις την ζωή σου (εκτός και αν πας να γράψεις σε Kanji ή Dravidians οπότε πάσο).

 

Θα μου επιτρέψεις να διορθώσω λέγοντας ότι το ακόμα πιο σωστό είναι να πούμε ότι "πριν τα Vista δεν μπορεί να την κάνεις αυτή την δουλεία σε όλες τις γλώσσες με stock Win32". Η διαφορά είναι ότι το documentation δεν αναφέρει ρητά σε ποια scripts μπορεί να υπάρχει πρόβλημα και σε ποιά όχι (αναφέρει μόνο ενδεικτικά), και βάσει των γνώσεών μου νομίζω πως χρειάζεται πραγματικά Unicode guru για να αποφανθεί. Συγκεκριμένα επειδή γνωρίζω ότι δεν γνωρίζω, δε θα μπω στον κόπο να βγάλω από τον πάτο μου μια πρόβλεψη για το που υπάρχει πρόβλημα και που όχι.

 

Κατά τα άλλα βεβαίως αν το κριτήριο είναι η διευκόλυνση της ζωής τότε να τη χρησιμοποιήσεις. Το δικό μου κριτήριο που είναι η εύρεση του Άγιου Δισκοπότηρου σε C δε μου επιτρέπει να μείνω εκεί.

 

Μάλλον το πρόβλημα είναι ότι δεν είχες την ρουτίνα υπόψη σου και αυτό σε ενόχλησε κάπως. Δεκτό.

 

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

 

Οπότε για να καταλάβω, η ενδεδειγμένη λύση κατά την άποψή σας όταν γράφω ένα πρόγραμμα που θέλω να υποστηρίζει Ελληνικά και Αγγλικά είναι να χρησιμοποιήσω μια από τις πιο βαριές βιβλιοθήκες που κυκλοφορούν (ICU) για να υποστηρίζει το πρόγραμμά μου άλλες 30 γλώσσες επειδή η wstrcoll δεν υποστηρίζει τη διάλεκτο του νοτιότερου χωριού στο Θιβέτ;

 

Σόρρυ για τον σαρκασμό αλλά εγώ έτσι την εισπράττω αυτή την επιχειρηματολογία.

 

Όχι. Αν θέλεις ελληνικά και αγγλικά να βάλεις codepage 869 που λέει και ο imitheos και να πάμε όλοι σπίτια μας. Μάλλον δεν έχεις εισπράξει την επιχειρηματολογία μας σωστά.

 

Δεν αντέχω πάντως να μη σχολιάσω το "από τις πιο βαριές βιβλιοθήκες": στο άλλο thread που αναφέρθηκε η Qt δεν είδα να έχεις κάποιο πρόβλημα πάντως.

 

 

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

 

Δεν υποννοώ τίποτα τέτοιο. Έχω ακόμα την απορία (μιας και δεν το έχεις ξεκαθαρίσει) αν όντως έχεις καταπιαστεί με όλα αυτά τα θέματα που αφορούν το Unicode γιατί Unicode δεν είναι το wchar_t και η wcscmp αλλά scripts, glyphs, code points, collations, normalization forms και άλλα.

 

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

[Directx]

[..]Το εξήγησα θέλω να ελπίζω ποιό ακριβώς είναι το πρόβλημα. Απο κει και πέρα μη μπερδεύεις την υποστήριξη των απόψεών μου με όλα τα επιχειρήματα που έχω στη διάθεσή μου με τέτοιου είδους ψυχολογικά. Αν μου επιτρέπεις, ποτέ δε θα είχα φτάσει στο επίπεδο που είμαι τώρα αν την έλλειψη γνώσεων την αντιμετώπιζα σαν ανάθεμα και όχι σαν ευκαιρία να μάθω.

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

[migf1]

Είναι η 2η φορά που χρησιμοποιείς στην επιχειρηματολογία σου την αμφισβήτηση για το αν έχω δουλέψει ποτέ πάνω σε αυτά που υποστηρίζω (η 1η ήταν με τα dual monitors) και για 2η φορά θα σε αφήσω με την απορία. Κι ο λόγος είναι πως μετά από τόσο καιρό θα έπρεπε να είναι ήδη ξεκάθαρο προς άπαντες το αν αρέσκομαι ή όχι να συζητώ για πράγματα με τα οποία δεν έχω ασχοληθεί ποτέ. Ως εκ τούτου τη συγκεκριμένη ερώτηση σου τη εκλαμβάνω για 2η φορά αφενός ως ατυχή προσπάθεια δικού μου discredit και αφετέρου ως αδυναμία επιχειρημάτων από την μεριά σου.

 

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

 

Επιστρέφοντας τώρα και πάλι στην ουσία του νήματος. Γνωρίζεις οποιοδήποτε τομέα της C (πέρα από το ήμισυ περίπου των στάνταρ βιβλιοθηκών) που να είναι 100% portable σε όλες τις πλατφόρμες και διαχρονικά; Και μόνο το γεγονός πως ακόμα και τα primitive datatypes έχουν implementation defined size σβήνει μονοκοντηλιά τον όρο "portability".

 

Αυτό λοιπόν τι σημαίνει, πως για κάθε γραμμή που γράφεις σε C πρέπει να λαμβάνεις υπόψη σου όλες τις πιθανές κι απίθανες πλατφόρμες που υπάρχουν στην υδρόγειο, με το σκεπτικό ότι μπορεί κάποια στιγμή στο διηνεκές να θελήσεις να κάνεις compile ή να θελήσει ο χρήστης να τρέξει το πρόγραμμά σου σε οτιδήποτε computerized κυκλοφορεί παγκοσμίως;

 

Ελπίζω κι εύχομαι πως όχι.

 

Είναι το portability ο Νο.1 στόχος σε κάθε έκφανση του προγραμματισμού; Ελπίζω και εύχομαι πως όχι.

 

Για να μην τα πολυλογώ, το portability είναι ένα ζητούμενο. Η ταχύτητα είναι ένα άλλο ζητούμενο. Η εξοικονόμηση πόρων είναι ένα ακόμα ζητούμενο. Το χρονικό πλαίσιο ανάπτυξης μιας εφαρμογής είναι ακόμα ένα ζητούμενο. Και πάει λέγοντας.

 

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

 

Όσο θεμιτό είναι να ακολουθήσει κανείς π.χ αυτές τις οδηγίες: http://utf8everywhere.org/ όταν φτιάχνει μια Win32 εφαρμογή κάτω από ένα συγκεκριμένο πλαίσιο ανάπυτυξης, άλλο τόσο θεμιτό είναι να χρησιμοποιήσει το native API σε κάποιο άλλο πλαίσιο ανάπτυξης, άλλο τόσο θεμιτό είναι να χρησιμοποιήσει ICU σε άλλο πλαίσιο, κι άλλο τόσο θεμιτό είναι να χρησιμοποιήσει εσωτερική μετατροπή σε wchar_t σε κάποιο άλλο πλαίσιο ανάπτυξης, κι άλλο τόσο θεμιτό είναι να χρησιμοποιήσει custom κώδικα σε άλλο πλαίσιο.

 

Τα "τι είναι αυτό που δουλεύει παντού και πάντα" το οποίο προμοτάρεις εσύ και "τι δουλεύει υπο συνθήκες" το οποίο προμοτάρω εγώ και ο Directx είναι δυο θεμιτές προσεγγίσεις, σε διαφορετικά πλαίσια το καθένα τους. Η 2η όμως είναι η μόνη ρεαλιστική.

 

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

 

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

 

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

 

EDIT:

το bold

EDIT2:

typos

[defacer]

@DirectX:

 

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

 

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

 

@migf1:

 

Στα τελευταία posts (εμένα τουλάχιστον έτσι μου φαίνεται) έχεις απομακρυνθεί από την άποψη "μια χαρά είναι το Unicode με standard C99" και κλίνεις προς το "είναι κι αυτό μια επιλογή η οποία υπό συγκεκριμένες συνθήκες έχει πρακτική αξία". Χρειαζόταν να έχουμε εξάψεις για να φτάσουμε εκεί; Ρητορική ερώτηση, η οποία απευθύνεται και σε μένα γιατί φυσικά χρειάζονται δύο χέρια για να χτυπήσεις παλαμάκια.

 

Σου ζητώ και γω συγγνώμη αν μ' αυτά που έχω πει σε αδίκησα, κάτι το οποίο δεν ήταν ο σκοπός μου. Σαν "αιτιολόγηση" (και σε παρακαλώ, όχι σαν round 2) σου ποστάρω σε spoiler μερικά αποσπάσματα των post σου τα οποία -- κρίνε και μόνος σου αν θέλεις -- με έκαναν να αμφιβάλλω αν έχεις τις διάφορες έννοιες καλά ξεκαθαρισμένες στο μύαλό σου.

 

 

 

ένας δημοφιλής τρόπος για διαχείριση Unicode σε C ήταν η μετατροπή τους κατά την είσοδο από Unicode σε wide

 

(Δεν υπάρχει μετατροπή από "Unicode" σε wide. Ακόμα δεν έχω καταλάβει τι ήθελες να πεις εκεί.)

 

Επίσης, νομίζω πως είναι εγγυημένο πως κανένα Unicode πρότυπο δεν χρησιμοποιεί περισσότερα από 4 bytes.

 

(Υπάρχει μόνο ένα Unicode πρότυπο. Εννοείς encodings. Σκέφτομαι: είναι δυνατόν να ξέρει από Unicode και να κάνει ένα τόσο βασικό λάθος ορολογίας 5 φορές στην απο πάνω παράγραφο?)

 

Στο Win32API όπως ήδη ανέφερε κι ο φίλος xdir το wchar_t εξακολουθεί να είναι το στάνταρ της εσωτερικής UTF16LE απεικόνισης των πάντων (fixed στα 2 bytes).

 

(Το wchar_t μπορεί να είναι δύο bytes στα Windows, όμως υπάρχουν glyphs τα οποία αναπαρίστανται με χρήση surrogate pairs δηλαδή συνολικά 4 bytes, όπως και code points που καταλαμβάνουν μεν 2 bytes αλλά δεν αντιστοιχούν σε κάποιο glyph απο μόνα τους. Για το λόγο αυτό π.χ. η wcslen δεν είναι ασφαλής στα Windows! Δεν είναι καθόλου προφανές αν το γνωρίζεις αυτό βάσει της παραπάνω πρότασης.)

 

Δεν τα μπερδεύω ρε συ.

 

(Αναφερόμενος στο τι κάνει specify το standard vs. στο τι προσφέρει η glibc. Κι όμως, τα μπερδεύεις.)

 

 

 

Απο κει και πέρα, με συγχωρείς πολύ αλλά νομίζω ότι έκανες εντελώς αυτό που λες ότι δεν έκανες, δηλαδή να επηρεάσεις εναντίον της χρήσης της ICU. Ορίστε:

 

Οπότε για να καταλάβω, η ενδεδειγμένη λύση κατά την άποψή σας όταν γράφω ένα πρόγραμμα που θέλω να υποστηρίζει Ελληνικά και Αγγλικά είναι να χρησιμοποιήσω μια από τις πιο βαριές βιβλιοθήκες που κυκλοφορούν (ICU) για να υποστηρίζει το πρόγραμμά μου άλλες 30 γλώσσες επειδή η wstrcoll δεν υποστηρίζει τη διάλεκτο του νοτιότερου χωριού στο Θιβέτ;

 

Συμφωνούμε στο ότι δεν υπάρχουν πανάκειες στον προγραμματισμό. Υπάρχουν όμως ενδεδειγμένες λύσεις. Ορίστε μια αναζήτηση στο StackOverflow για τα tags [c] και [unicode], στα αποτελέσματα της οποίας αν ρίξεις μια ματιά θα δεις ότι κανένας πρακτικά δε μιλάει για τη standard library παρά μόνο για ICU.

 

Edit: μόλις είδα το edit σου που έβαλε bold στο ότι η standard library είναι "η μόνη ρεαλιστική προσέγγιση". Πραγματικά δεν ξέρω τι να πώ. Μάλλον όσοι ασχολούνται επί τόσα χρόνια με την ICU απλά τσαλαβουτάνε στα ρηχά περιμένοντας να βρουν κανένα ρεαλιστικό project να υλοποιήσουν...

 

Τέλος, όσον αφορά τη δουλειά υπο πραγματικές συνθήκες: ελπίζω να μη μπερδεύεις τον τρόπο με τον οποίο δουλεύει ο χώρος της πληροφορικής στην Ελλάδα με τον τρόπο που δουλεύουν έξω που είναι άνθρωποι (νομίζω ότι τα project τους δεν είναι λιγότερο πραγματικά από τα δικά μας). Και όσον αφορά την άποψη ή όχι των developers: όπως ο developer δεν έχει άποψη πάνω στο time to market, έτσι δε νομίζω και ότι κάποιος μη-developer θα υποδείξει σε κάποιον developer με ποιον ακριβώς τρόπο θα προστεθεί κάποιο feature στο software.

[Directx]

@DirectX:

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

Νομίζω ότι όσον αφορά το ερώτημα σου σχετικά με την διαχείριση των διακριτικών σε UNICODE κάτω από το Windows API σου απάντησα (άσχετα αν δεν δέχεσαι ή τέλος πάντων διαφωνείς με τις τεχνικές λεπτομέρειες της απάντησης αυτής). Στα μεν XP έχουμε μια υπό συνθήκη λύση ενώ στα Windows Vista και μετά έχουμε πλήρη λύση χρησιμοποιώντας μια χαρά τα wchar_t και κλήσεις σε native ρουτίνες του λειτουργικού δίχως ανάγκη άλλων εξωτερικών βιβλιοθηκών (πρόοδος / ωρίμανση του API).

 

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

 

..

Και προς χάριν της συζήτησης, ας δώσω και ένα bonus λόγο πρόσφατης ενασχόλησης. Στο Android η διαχείριση διακριτικών UNICODE από το 2.3+ επιλύεται μέσο συντονισμένης χρήσης του Normalizer class και RegEx (κυκλοφορεί ευρέως διαδεδομένη συνταγή), στο 2.2- επιλύεται δυσκολότερα λόγο ανυπαρξίας άμεσα διαθέσιμων native class & ρουτινών (εκτός και αν υπάρχει κάποια συνταγή που μου έχει ξεφύγει οπότε ευχαρίστως να την ακούσω από κάποιον επαΐοντα).

 

Για άλλα λειτουργικά συστήματα (πχ. SYMBIAN ειλικρινά δεν μου χρειάσθηκε κάτι τέτοιο για τα προγράμματα που έγραψα σε αυτό -αρκούσαν να δουλεύουν σωστά στα Ελληνικά & Αγγλικά- ή UNIX/LINUX που γράφω ελάχιστα σε αυτά) δεν έχω άποψη άρα δεν παίρνω καμία θέση.

[migf1]

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

 

@migf1:

 

Στα τελευταία posts (εμένα τουλάχιστον έτσι μου φαίνεται) έχεις απομακρυνθεί από την άποψη "μια χαρά είναι το Unicode με standard C99" και κλίνεις προς το "είναι κι αυτό μια επιλογή η οποία υπό συγκεκριμένες συνθήκες έχει πρακτική αξία". Χρειαζόταν να έχουμε εξάψεις για να φτάσουμε εκεί; Ρητορική ερώτηση, η οποία απευθύνεται και σε μένα γιατί φυσικά χρειάζονται δύο χέρια για να χτυπήσεις παλαμάκια.

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

 

Σου ζητώ και γω συγγνώμη αν μ' αυτά που έχω πει σε αδίκησα, κάτι το οποίο δεν ήταν ο σκοπός μου. Σαν "αιτιολόγηση" (και σε παρακαλώ, όχι σαν round 2) σου ποστάρω σε spoiler μερικά αποσπάσματα των post σου τα οποία -- κρίνε και μόνος σου αν θέλεις -- με έκαναν να αμφιβάλλω αν έχεις τις διάφορες έννοιες καλά ξεκαθαρισμένες στο μύαλό σου.

 

ένας δημοφιλής τρόπος για διαχείριση Unicode σε C ήταν η μετατροπή τους κατά την είσοδο από Unicode σε wide

 

(Δεν υπάρχει μετατροπή από "Unicode" σε wide. Ακόμα δεν έχω καταλάβει τι ήθελες να πεις εκεί.)

Σημαίνει πως πρέπει να γνωρίζεις ('η να ανιχνεύεις) σε τι Unicode encoding είναι η είσοδός σου, και την μετατρέπεις σε fixed-size wchar_t.

 

Επίσης, νομίζω πως είναι εγγυημένο πως κανένα Unicode πρότυπο δεν χρησιμοποιεί περισσότερα από 4 bytes.

 

(Υπάρχει μόνο ένα Unicode πρότυπο. Εννοείς encodings. Σκέφτομαι: είναι δυνατόν να ξέρει από Unicode και να κάνει ένα τόσο βασικό λάθος ορολογίας 5 φορές στην απο πάνω παράγραφο?)

Παρενέργεια του να γράφω τα μισά ελληνικά και τα άλλα μισά αγγλικά. Αν έγραφα μόνο ελληνικά ή μόνο αγγλικά πιθανότατα θα έγραφα την σωστή ορολογία.

 

Στο Win32API όπως ήδη ανέφερε κι ο φίλος xdir το wchar_t εξακολουθεί να είναι το στάνταρ της εσωτερικής UTF16LE απεικόνισης των πάντων (fixed στα 2 bytes).

 

(Το wchar_t μπορεί να είναι δύο bytes στα Windows, όμως υπάρχουν glyphs τα οποία αναπαρίστανται με χρήση surrogate pairs δηλαδή συνολικά 4 bytes. Για το λόγο αυτό π.χ. η wcslen δεν είναι ασφαλής στα Windows! Δεν είναι καθόλου προφανές αν το γνωρίζεις αυτό βάσει της παραπάνω πρότασης.)

 

Δεν τα μπερδεύω ρε συ.

 

(Αναφερόμενος στο τι κάνει specify το standard vs. στο τι προσφέρει η glibc. Κι όμως, τα μπερδεύεις.)

Για αυτό και το Win32API παρέχει δικές του C-ryntime συναρτήσεις, ως generic που ξεκινούν με _t

Ειδικά μάλιστα για τα surrogates είχα ρωτήσει σχετικά πρόσφατα (καμία σχέση με την αναφορά μου πριν από πολλά χρόνια) εδώ: http://www.insomnia....ost__p__4567231 (είχες απαντήσει κιόλας).

 

Απο κει και πέρα, με συγχωρείς πολύ αλλά νομίζω ότι έκανες εντελώς αυτό που λες ότι δεν έκανες, δηλαδή να επηρεάσεις εναντίον της χρήσης της ICU. Ορίστε:

Δεν το έθεσα γενικώς, αλλά υπό συγκεκριμένο πλαίσιο (μόνο Αγγλικά και Ελληνικά).

 

Συμφωνούμε στο ότι δεν υπάρχουν πανάκειες στον προγραμματισμό. Υπάρχουν όμως ενδεδειγμένες λύσεις. Ορίστε μια αναζήτηση στο StackOverflow για τα tags [c] και [unicode], στα αποτελέσματα της οποίας αν ρίξεις μια ματιά θα δεις ότι κανένας πρακτικά δε μιλάει για τη standard library παρά μόνο για ICU.

 

Edit: μόλις είδα το edit σου που έβαλε bold στο ότι η standard library είναι "η μόνη ρεαλιστική προσέγγιση". Πραγματικά δεν ξέρω τι να πώ. Μάλλον όσοι ασχολούνται επί τόσα χρόνια με την ICU απλά τσαλαβουτάνε στα ρηχά περιμένοντας να βρουν κανένα ρεαλιστικό project να υλοποιήσουν...

Το "παντού και πάντα" είναι ουτοπία! Τα προγράμματα ρεαλιστικά δουλεύουν "υπό συνθήκες". Όσο περισσότερες τόσο καλύτερα, παντού και πάντα δεν δουλεύει κανένα πρόγραμμα.

[ChRis6]

.... και ετσι fastmanakos τυπωνεις τις λεξεις με αλφαβητικη σειρα !

[παπι]

.... και ετσι fastmanakos τυπωνεις τις λεξεις με αλφαβητικη σειρα !

 

χαχαχα

[migf1]

.... και ετσι fastmanakos τυπωνεις τις λεξεις με αλφαβητικη σειρα !

:lol:

 

Όντως το ξεσκίσαμε το νήμα!

 

Ελπίζω όμως να βγει και κάτι καλό από αυτό, γιατί περιέχει και χρήσιμα πράγματα (κείμενα και links). Προσθέτω και τον Tim Bray σε όλο αυτόν τον... σαματά, ο οποίος έχει γράψει 2-3 πολύ χρήσιμα εισαγωγικά άρθρα για όποιον ενδιαφέρεται να ασχοληθεί με Unicode.

 

Π.χ. http://www.tbray.org.../2003/04/26/UTF και http://www.tbray.org...3/04/06/Unicode (έχει γράψει κι άλλα).

 

EDIT:

 

Αναθεματισμένα typos

[Directx]

Αυτό δεν το γνώριζα! Εξαιρετικά ενδιαφέρον και χρήσιμο! Thanks!

 

ΥΓ. Ισχύει ανεξαιρέτως optimization flags?

Δυστυχώς είχα και εγώ την ίδια εντύπωση αλλά μετά από ένα πείραμα σε C++ Builder τούτο δεν ισχύει (στον εν λόγο compiler πάντα) οπότε αν και έχω χρησιμοποιήσει κατά κόρον αυτό το ιδίωμα στο Insomnia (υπό την συνθήκη ότι τα προγραμματάκια εδώ είναι μικρά - απλά), καλύτερα αποθήκευση του strlen άπαξ για σταθερού μήκους strings (σε πραγματικές εφαρμογές) διότι πράγματι το πέναλτι σε ταχύτητα είναι πολύ μεγάλο τελικά (έχεις δίκιο!).

[migf1]

Δυστυχώς είχα και εγώ την ίδια εντύπωση αλλά μετά από ένα πείραμα σε C++ Builder τούτο δεν ισχύει (στον εν λόγο compiler πάντα) οπότε αν και έχω χρησιμοποιήσει κατά κόρον αυτό το ιδίωμα στο Insomnia (υπό την συνθήκη ότι τα προγραμματάκια εδώ είναι μικρά - απλά), καλύτερα αποθήκευση του strlen άπαξ για σταθερού μήκους strings (σε πραγματικές εφαρμογές) διότι πράγματι το πέναλτι σε ταχύτητα είναι πολύ μεγάλο τελικά (έχεις δίκιο!).

 

 

Ευτυχώς δεν ισχύει το ίδιο για τον τελεστή sizeof, που υπολογίζεται στο compilation (και όχι στο run time). Υπάρχει μια εξαίρεση για τα VLA, αλλά ακόμα κι εκεί νομίζω υπολογίζεται μόνο μια φορά και κατόπιν απλώς επαναχρησιμοποιείται.