Κακές συνήθειες στη C

[m1cRo]

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" <- Donald Knuth

 

Κάτσε γιατί τα navigation systems έχουν μέχρι και ARM, σηκώνουν λειτουργικό και πολλά άλλα. Είναι και δεν είναι   πλέον embedded. Δηλαδή υποστηρίζουν σοβαρό Framework. Και εν συνεχεία όταν λες C++  τι εννοείς, κλάσεις υπερφορτώσεις την γενική μάχη ή απλά C γραμμένο σε C++. 

 

Σε σχετικό μάθημα/προτζεκτ (όχι στην πραγματικότητα/δουλεία) έχω δει βελτιστοποιήσεις να αποδίδουν μέχρι και 70% καλύτερα για MIPS αρχιτεκτονική και να φανταστείς αφορούσαν μεταφορά δεδομένων κ μόνο μετά γινόταν πάρτυ άν έβαζες χέρι στην λογική του προγράμματος!

 

Εξαρτάτε την εφαρμογή θα έλεγα....

Μιλάω για την κανονική c++. Εδώ υπήρχε framework για να γραφεις drivers σε c++ για windows νωμίζω απο τη compuware. Γενικός το rule είναι αν θες να κανεις τη βελτιστοποίηση πρώτα απέδειξε ότι πρέπει να γίνει εκεί που πας να τη κανεις.

 

Αυτές τις βελτιστοποιήσεις τις κάνει ο compiler κανονικά. Ποια ήταν τα options του compiler σου? Είχες gcc φαντάζομαι? Ο3? Σχετικα τώρα με τις ταχύτητες ποιο πολύ ρόλο παίζει ο αλγόριθμος παρα οτιδήποτε άλλο, βεβαια μετά το optimization του compiler. Απλά πάρε valgrind και κανε δοκιμη, γράψε κάτι με c++ και μετά το ίδιο σε c. Το ωραίο είναι ότι μερικές φορες όταν γράψεις με classes ίσος πάρεις και πιο καλά αποτελέσματα γιατί τέτοια προγράμματα είναι statefull ενώ κάτι που είναι γραμμένο σε c μερικές φορες θα κάνει διπλή δουλειά για να ανακτήσει κάποια δεδομένα -> προβλήματα λόγο αλγοριθμου.

[cyberrobot]

@m1cro

"Γενικός το rule είναι αν θες να κανεις τη βελτιστοποίηση πρώτα απέδειξε ότι πρέπει να γίνει εκεί που πας να τη κανεις."

 

Ναι εδώ με βρίσκεις απόλυτα σύμφωνο, το κυρίως κομμάτι ήταν βελτιστοποίηση σε memory transfers και κάποια άλλα πιο απλά αλλά εξίσου αποδοτικά.

 

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

 

"Ποια ήταν τα options του compiler σου?"

 

Τώρα θα σε γελάσω, πάει καιρός. Νομίζω Ο3 αλλά δεν είμαι σίγουρος ήταν gcc για emulator συγκεκριμένης αρχιτεκτονικής. Τώρα καταλαβαίνεις στα όρια του μαθήματος έπρεπε να φανεί η βελτιστοποίηση.

 

"Το ωραίο είναι ότι μερικές φορες όταν γράψεις με classes ίσος πάρεις και πιο καλά αποτελέσματα γιατί τέτοια προγράμματα είναι statefull ενώ κάτι που είναι γραμμένο σε c μερικές φορες θα κάνει διπλή δουλειά για να ανακτήσει κάποια δεδομένα -> προβλήματα λόγο αλγοριθμου."

 

 

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

 

Valgrind ωραίο εργαλείο....!

[defacer]

Πρώτα απ' όλα συγγνώμη για τη συμμετοχή μου στον παιδικό καβγά. Ι should have known better.

 

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

 

Πριν ξεκινήσω, θέλω να επιστήσω την προσοχή σε αυτό το post όπου ο mifg1 διορθώνει τον m1cr0 λέγοντάς του ότι είναι εκτός θέματος. Είναι καλό να αναγνωρίζουμε πότε είμαστε εκτός θέματος.

 

Έχουμε ήδη εξαντλήσει τα υπέρ και τα κατά των macros. Αν ξέρεις τι κάνεις, σου δίνουν ευελιξία, ισχύ και ταχύτητα πέρα από τις κλασικές δυνατότητες της γλώσσας. Πέρα από το forced inlining no matter what, πολυμορφισμός, overloading και code-generation είναι μερικοί ακόμα πολύ χαρακτηριστικοί λόγοι για να χρησιμοποιεί κανείς macros στην C.

 

Σε ποιό ακριβώς σημείο και από ποιόν έχει αναφερθεί ότι δεν υπάρχουν λόγοι να χρησιμοποιήσει κανείς macros στη C? Σίγουρα όχι απο τους Kernighan και Pike. Σϊγουρα όχι και από μένα, π.χ. στα πρώτα posts λέω στον Directx ότι με βάση την εικόνα που περιγράφει καλά έκανε και χρησιμοποίησε macro. Επομένως ποιό το συμπέρασμα που καλούμαστε να βγάλουμε από την παραπάνω παράγραφο;

 

Αν το συμπέρασμα είναι πως υπάρχουν και καλές χρήσεις των macros, παρακαλώ κάνε ένα topic όπου θα μας διαφωτίζεις επι του θέματος μοιραζόμενος την εμπειρία σου μαζί μας γιατί νομίζω πως στο συγκεκριμένο topic το θέμα είναι οι κακές χρήσεις των macros. Αν το συμπέρασμα είναι πως υπάρχουν μόνο καλές χρήσεις των macros, τότε παρακαλώ δώσε μία απάντηση επί των όσων παρέθεσα αντί να κάνεις hijack το topic.

 

Τέλος, αν θεωρείς ότι έχουμε εξαντλήσει το θέμα by all means μη σπαταλάς το χρόνο σου γράφοντας περισσότερα. Επίσης, το ότι εσύ προσωπικά μπορεί να το θεωρείς εξαντλημένο δεν είναι κάτι στο οποίο είμαστε υποχρεωμένοι να συμφωνήσουμε.

 

Θα ήθελα επίσης να σχολιάσω το "αν ξέρεις τι κάνεις". Προφανώς αν ξέρεις τι κάνεις μπορείς να εξάγεις ώφελος από πολλά πανίσχυρα εργαλεία ακόμα και σε καταστάσεις όπως ο προγραμματισμός σε C όπου είναι παροιμοιωδώς πολύ εύκολο "to shoot yourself in the foot". Το θέμα μας όμως εδώ δεν είναι αυτό, αλλά είναι το κατά πόσον είναι καλό να χρησιμοποιείς αυτά τα εργαλεία εκεί που δε χρειάζεται γιατί υπάρχουν εξίσου καλές ή ακόμα καλύτερες λύσεις οι οποίες μπορούν να φέρουν το ίδιο αποτέλεσμα.

 

Και στο engineering και στην τέχνη, η ομορφιά βρίσκεται στο να χρησιμοποιείς το μικρότερης εμβέλειας μηχανισμό ο οποίος σου επιτρέπει να κάνεις αυτό που θέλεις. Το να χρησιμοποιείς tank εκεί που αρκεί ένα τρακτέρ δεν είναι σε κανένα σύμπαν καλό, όσο κι αν ξέρεις τι κάνεις.

 

Επιπλέον είναι γνωστό σε όποιον έχει μια κάποια εμπειρία πως όταν είσαι "young and excitable", πολλά πράγματα σου φάινονται φανταστικά γιατί βλέπεις μόνο τα πλεονεκτήματά τους. Χρειάζεται να μπολιάσεις τον ενθουσιασμό με το σκεπτικισμό του έμπειρου για να μπορείς ψύχραιμα να δεις ότι κανένα πράγμα στη ζωή δεν έχει μόνο πλεονεκτήματα, και επίσης η εμπειρία χρειάζεται για να μπορείς να δεις ή ακόμα και να "μυριστείς" ποιά μπορεί να είναι τα μειονεκτήματα κάποιας τεχνικής υπό Χ ή Υ πιθανές συνθήκες στο μέλλον.

 

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

 

result = dieRoll != 8 && (++dieRoll & 1) ? hit : miss;

Αντί να γράψει αυτό:

 

switch (dieRoll) {
    case 1:
    case 3:
    case 7:
        result = hit;
    default:
        result = miss;
}

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

 

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

 

Good reads:
1. http://multi-core-dump.blogspot.gr/2010/11/interesting-use-of-c-macros-polymorphic.html
2. http://stackoverflow.com/questions/653839/what-are-c-macros-useful-for
3. https://blogs.oracle.com/ksplice/entry/8_gdb_tricks_you_should (Νούμερο 5)

 

1. Ποιά ακριβώς η σχέση του συγκεκριμένου post με το παρόν thread? Είναι on topic?

 

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

 

2. Το ίδιο ερώτημα όπως παραπάνω. Επίσης, παραθέτω αποσπάσματα από όσες απαντήσεις περιέχουν και σχολιασμό εκτός από καθαρή παράθεση τεχνικών. Emphasis mine.

 

2η απάντηση:

 

These days, many of the things that macros used to be the only way to do are better handled through newer mechanisms. But they still have their place, from time to time.

 

3η απάντηση:

 

 

Preprocessor macros add powerful features and flexibility to C. But they have a downside:

 

Και παραθέτει όχι ένα αλλά πολλά downsides. Και για να κάνω τη σύνδεση με το topic για να μη ξεχνιόμαστε, ποιός ο λόγος να φας στη μάπα τα downsides όταν δεν είσαι αναγκασμένος να χρησιμοποιήσεις macro?

 

4η απάντηση:

 

In practice, I'd recommend regarding preprocessor programming as a last resort, when you don't have the latitude to use high level constructs in safer languages. But sometimes it's good to know what you can do if your back is against the wall and the weasels are closing in...!

 

3. Αν για κάποιο λόγο ένα tip σχετικά με το πώς μπορείς να βελτιώσεις την κατάσταση στο debugging συγκεκριμένα με gdb όπου χρησιμοποιούνται macros δεν είναι off topic εδώ, θα χαρώ να τον ακούσω.

 

ΥΓ. Είναι από άκομψο έως και άστοχο να χαρακτηρίζουμε ως "κακή συνήθεια" π.χ. παραπάνω από το μισό code-base των Linux internals (και μυριάδων άλλων C APIs και μη) που είναι χτισμένα πάνω σε macros.

 

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

 

EDIT:

Παρεμπιπτόντως, για μια ακόμα φορά: http://c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=ansi#constasconst

 

Διαφωνείς με την παράθεση από το βιβλίο που προτείνει τη χρήση enum? Ή διαφωνείς με την παράθεση από το ίδιο το link που δίνεις,

 

When you need a true compile-time constant, use a preprocessor #define (or perhaps an enum).

 

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

 

Αλλά, ποιός ακριβώς θέτει τους κανόνες για το τί πρέπει και δεν πρέπει στο development και πως αυτό μεταφράζεται σαν "νόμος"?

Δηλαδή "according to who" κάτι είναι rule?

 

Σε όσα βιβλία και αν έχω διαβάσει σε όσα sources σέβονται τον εαυτό τους στο Internet όλοι λένε την φράση: "Informatics and Engineering is the Science and ART"

 

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

Δηλαδή ακούω και μου λένε: ά αφήνεις κενό κάτω από την προηγούμενη γραμμή, ά γιατί το άγκιστρο δεν είναι δίπλα στο function, ά γιατί γράφεις έτσι τα σχόλια...

 

Αυτά, είναι ΑΣΤΕΙΑ πράγματα. 

 

Ο κανόνας στο development προκύπτει από την κοινή λογική και την εμπειρία. Το ότι για παράδειγμα αν σε δω να δίνεις ονόματα μεταβλητών k1, k2, xx, yy, zz, f1n κλπ έχεις φύγει από το παράθυρο δε νομίζω ότι χρειάζεται συζήτηση. Δε με νοιάζει αν το έκανες για καλλιτεχνικούς λόγους.

 

Σαφώς υπάρχει και η διάσταση της τέχνης και στον προγραμματισμό και στο engineering. Αλλά τέχνη δεν είναι αυτό που εσένα σου φαίνεται ωραίο. Τέχνη είναι αυτό που φαίνεται ωραίο στους άλλους.

 

Στο ότι τα λεγόμενα "religious arguments" είναι αστεία να τα βλέπει κανείς σαν engineering decisions συμφωνώ απόλυτα.

 

Εάν δείτε πραγματικά commercial enterprise κώδικα από λογισμικά χωρισμένα σε modules θα δείτε μεν μια ομοιομορφία αλλά γενικά ο κάθε προγραμματιστής έχει βάλει την δικιά του "πένα" μέσα...

 

Δεν είμαι σίγουρος τι εννοείς. Είναι τυχαίο πως σε όλα μα όλα τα μεγάλα open source projects υπάρχει coding style standard με το οποίο αν δε συμμορφώνεσαι απλά δε μπαίνει ο κώδικάς σου μέσα;

 

Έχεις δοκιμάσει να κάνεις submit κώδικα σε open source projects ο οποίος ήταν γραμμένος με τη δική σου προσωπική πένα; Αν ναι, μπορείς να μας δείξεις ποιός ήταν αυτός ο κώδικας και να μας πεις πώς αντιμετωπίστηκε η συνεισφορά σου;

 

 

Απλά, θέλω να ξεκολήσετε και να κατανοήσετε επιτέλους ότι η τεχνολογία (υλικό, λογισμικό και προγραμματισμός...) είναι το μέσον και όχι το αποτέλεσμα. Με άλλα λόγια εάν κάτι δουλεύει και έχετε επιλέξει το τάδε εργαλείο όπως η C, δε νοιάζεται στο production κανείς μα κανείς αν το γράψατε εσείς με τους super τρομακτικούς αυστηρούς και με βάση τις πιο τέλειες πρακτικές τρόπους σας, ούτε αν το έγραψαν μαϊμούδες για εσάς!!!!

 

Το μόνο που τους νοιάζει είναι να δουλεύει όπως πρέπει και να είναι σταθερό για να πουληθεί!

 

Εάν μετά εσείς θέλετε να κάνετε την πλάκα σας και να λιώνετε για να το κάνετε super code, DO IT και ένα μεγάλο ΜΠΡΑΒΟ!

 

Πολύ καλά τα λες, αλλά έχω δύο σημαντικές παρατηρήσεις:

 

1. Όταν γράφω κώδικα και έχω την επιλογή ανάμεσα στο να γράψω "int dsfsfserrew323" και "int playerCount", το ένα είναι καλύτερο από το άλλο. Το γεγονός ότι ο πελάτης δε θα το δει ποτέ και δεν τον νοιάζει δε σημαίνει ότι πρέπει να κάνω την επιλογή μου στην τύχη ή χωρίς να έχω σκεφτεί πώς θα αντιμετωπίζω τέτοιες επιλογές στο χρόνο που αφιερώνω στην προσωπική μου εκπαίδευση.

 

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

 

 

Όμως, δε μπορώ να ακούω ιστορίες από άτομα που ΔΕΝ είναι στην παραγωγή κάθε μέρα...

και ΝΑΙ όπως λέει και ο @mifg1 υπάρχουν τεράστια λογισμικά και ανοικτού κώδικα μάλιστα που έχουν μέσα "κακό" κώδικα από άποψη δομής, ομορφιάς αρχιτεκτονικής... αλλά κάνουν αυτό που πρέπει να κάνουν και το κάνουν καλά.

 

Οπότε τι διάολο ζητάτε?

Θέλετε ένα productive λογισμικό ή μια έκθεση για να την δείχνετε στους φίλους σας. Εδώ είναι το ερώτημα!

 

Νομίζω πως εδώ μπαίνει το επιχειρείν στη μέση και γι αυτό έχουμε τόσο μεγάλο χάσμα και διαφορές στη φιλοσοφία μας.

Το καταλαβαίνω...

 

Σωστά τα όσα λες. Και πάλι όμως, στο παρόν topic δεν κάνουμε μάθημα "production-oriented software engineering practices". Επίσης, νομίζω ότι χρειάζεται να φέρουμε στο μυαλό μας και την (προφανή?) χρησιμότητα του να πιέζεις τον άλλο να κάνει "το σωστό" εκεί που δεν υπάρχει λόγος εκ πρώτης όψεως: όταν εκπαιδεύεται.

 

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

 

Για να το κάνω ακόμα πιο συγκεκριμένο: μπάινω να κάνω μια συγκεκριμένη βελτίωση/αλλαγή σε software της εταιρίας. Μου παίρνει μια βδομάδα παραπάνω απ' ότι θα 'πρεπε γιατί ο κύριος που το έγραψε δεν άκουσε ποτέ στη ζωή του την έκφραση "object-oriented design", παρόλο που ο κώδικάς του έχει classes να φαν κι οι κότες.

 

Στα πλαίσια της δουλειάς αυτής συνειδητοποιώ ότι Ν (και δεν εννοώ 2, εννοώ 30) features δεν δουλεύουν ή έχουν bugs λόγω της παντελούς απουσίας οργάνωσης, copy-paste programming κλπ -- παρόλο που κανένας δεν έχει διαμαρτυρηθεί γι' αυτό μέχρι σήμερα (επειδή δεν έτυχε κανείς ούτε να τεστάρει ούτε να χρησιμοποιήσει τα συγκεκριμένα features).

 

Όταν αύριο έρθει ένας πελάτης και σε "αναγκάσει" να ασχοληθείς μ' αυτό, ανεβάζονταις το κόστος του software κατόπιν εορτής από Χ που ήταν πριν σε Χ + όσο κοστίζει η εργασία μου, θα σε πειράξει σαν business owner ή όχι;

 

Η χρήση macros είναι κοινός τόπος στην συντριπτική πλειοψηφία των C projects, ειδικά όσα/όπου πραγματεύονται non-trivial tasks. Κάτι που με τη σειρά του αν μην τι άλλο αποδεικνύει πως η χρήση macros μόνο "κακή συνήθεια" δεν είναι.

 

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

 

Βέβαια νομίζω πως ήμουν αρκετά σαφής μιας και έκλεισα το post μου γράφοντας

 

 

Την επόμενη φορά που θα πάτε να γράψετε #define, σκεφτείτε: μήπως υπάρχει καλύτερος τρόπος;

 

και όχι

 

 

Την επόμενη φορά που θα πάτε να γράψετε #define, σκεφτείτε ότι είστε έτοιμοι να κάνετε τραγικό λάθος.

 

αλλά whatever.

Επεξ/σία 20 Ιανουαρίου 2013 από defacer

[Star_Light]

Chris, Star_Light και DirectX συμφωνώ μαζι σας 1000% για mission critical & games apps όχι όμως και για general apps ή εφαρμογές γραφείου! Εγώ εξάλλου αναφεροουν στις τελευταίες!!!

 

Star_Light, εργάζομαι ως CTO στην ARATOS Group και κάνουμε έρευνα και ανάπτυξη σε διαστημικές τεχνολογίες. Οπότε έχω μια άποψη σε διάφορα μήκη και φάσματα επί των έργων.

 

Εισαι ωραιος!!!!!

 

Αμα καταφερω και βρω και εγω καμια δουλειτσα τετοια τωρα που θα τελειωσω απο φανταρος θα ειμαι ευχαριστημενος.

Θα γουσταρα να ξεκινησω και κατι δικο μου αλλα θελει ακομη περισσοτερο τρεξιμο το οποιο δεν εχω προβλημα να κανω

αρκει να πετυχει. Το σκεφτομαι και αυτο δηλαδη.... διοτι απο παιδια που ρωταω και ενημερωνομαι στελνουν συνεχεια βιογραφικα χωρις καποια απαντηση της προκοπης οποτε ξεχναμε σιγα σιγα τις ιδιωτικες εκτος και αν εχουμε καποιον γνωστο !!!!!

 

Μ αρεσει πολυ να δουλευω την C ομως και δεν ξερω κατα ποσο εχει ζητηση αυτο στην Ελλαδα . Μεχρι που επεσα πανω σε αυτο ->

 

http://developer.android.com/tools/sdk/ndk/overview.html

και αρχισα καπως να ελπιζω. Ωστοσο ακομη διατηρω τις επιφυλαξεις μου μιας και οι περισσοτερες αγγελιες δεν ζητανε C και ειναι αξιοσημειωτο.

[gdelaportas]

Αστρο_Φως, ε στείλε μας κανένα CV... ;-)

 

@defacer

 

Και στο engineering και στην τέχνη, η ομορφιά βρίσκεται στο να χρησιμοποιείς το μικρότερης εμβέλειας μηχανισμό ο οποίος σου επιτρέπει να κάνεις αυτό που θέλεις. Το να χρησιμοποιείς tank εκεί που αρκεί ένα τρακτέρ δεν είναι σε κανένα σύμπαν καλό, όσο κι αν ξέρεις τι κάνεις.

 

Ναι ρε παιδί μου μαζί σου και γουστάρω αλλά όπως εξήγησα ο ιδεαλισμός από την πραγματικότητα και την πράξη απέχει παρασάγγας...

[defacer]

Ναι ρε παιδί μου μαζί σου και γουστάρω αλλά όπως εξήγησα ο ιδεαλισμός από την πραγματικότητα και την πράξη απέχει παρασάγγας...

 

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

 

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

 

Δεν διαφωνούμε σε κάτι.

[migf1]

@defacer:

 

Αναφέρθηκες ή όχι στο 1ο ποστ του νήματος σε συζητήσεις που έχουν γίνει για το θέμα, καταλήγοντας κατόπιν (αφ' εαυτού σου) πως ο Kernighan σε δικαιώνει;

 

Μια από τις συζητήσεις στην οποία αναφέρθηκες, αρχίζει ή όχι από εδώ: http://www.insomnia.gr/topic/437533-εÏÏÏήÏειÏ-για-c/page-25#entry4831509 ;

 

Είναι ή όχι δικό σου το...

Οι macros έχουν μόνο ένα 100% legit σενάριο χρήσης, και αυτό είναι να "παραμετροποιήσουν" τον κώδικά σου πριν τον δει ο compiler. Κατι σαν

#ifdef _WINDOWS
#define foo_function foo_win
#else
#define foo_function foo_other
#endif

foo_function();

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

 

 

 

Ρώτησες λοιπόν για παράδειγμα τον Kernighan αν σε δικαιώνει ή όχι πως είναι κατάχρηση να ορίζεις bit-values με #define αντί για enum? Διότι μας έχεις ξεκαθαρίσει εξαρχής εκεί (σε μια δλδ από τις συζητήσεις τις οποίες μόνος σου ανέφερες) πως αυτό είναι κατάχρηση (αφού ολοφάνερα δεν παραμετροποιεί τον κώδικα πριν γίνει compile).

 

Για τους υπόλοιπους, όποιος ενδιαφέρεται μπορεί να παρακολουθήσει όλη τη συζήτηση που ξεκινάει από το παραπάνω λινκ. Ίσως έχει ενδιαφέρον να παρακολουθήσει και τη συζήτηση πέριξ αυτού του link: http://www.insomnia.gr/topic/464308-signal-handlers/page-3?do=findComment&comment=5058787.

 

 

@gdelaportas

...

Anyway,Το define για τις σταθερες δεν μου αρέσει.Προτιμω το const...

Εξάλλου ιδιο χωρο πιανουν στη μνήμη...

...

Δεν είμαι σίγουρος τι εννοείς, αλλά π.χ. είναι άλλο το...

  

#define u 0x01

κι άλλο το ...

 

const unsigned int u 0x01;

To 1o αναφέρεται σε 1 byte σε όλους τους compilers, ενώ το 2ο σε τουλάχιστον 2 bytes ανάλογα τον compiler.

 

Στα υπόλοιπα, σε γενικές γραμμές συμφωνούμε.

[ZAKKWYLDE]

Επεξ/σία 21 Ιανουαρίου 2013 από ZAKKWYLDE

[defacer]

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

 

@defacer:

Αναφέρθηκες ή όχι στο 1ο ποστ του νήματος σε συζητήσεις που έχουν γίνει για το θέμα, καταλήγοντας κατόπιν (αφ' εαυτού σου) πως ο Kernighan σε δικαιώνει;

 

Φυσικά και αναφέρθηκα, εκεί είναι και μπορεί οποιοσδήποτε να το διαβάσει. Μόνο θα σε παρακαλέσω για άλλη μια φορά να σταματήσεις να μου βάζεις λόγια στο στόμα, μιας και δεν είπα ότι ο Kernighan "με δικαιώνει". Είπα πως "συμφωνεί μαζί μου".

 

 

C also has const values but they cannot be used as array bounds, so the enum statement remains the method of choice in C.

 

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

 

 

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

 

Σε ρωτάω ευθέως και αξιώνω απάντηση:

1. Πιστεύεις ότι το "συμφωνεί μαζί μου" είναι σωστή εκτίμηση; Αν όχι, θέλεις να προτείνεις μια σωστότερη;
2. Γιατί μου βάζεις λόγια στο στόμα όταν είναι γελοιωδώς εύκολο να κάνεις το σωστό quote, που όπως γνωρίζεις πολύ καλά βρίσκεται στο πρώτο post;

 

Μια από τις συζητήσεις στην οποία αναφέρθηκες, αρχίζει ή όχι από εδώ: http://www.insomnia.gr/topic/437533-εÏÏÏήÏειÏ-για-c/page-25#entry4831509;

 

Ναι. Αλλά δεν καταλαβαίνω γιατί ρωτάς, αναφέρθηκες σ' αυτήν και έκανα πως δεν την αναγνώρισα;

 

Είναι ή όχι δικό σου το...

 

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

 

Ρώτησες λοιπόν για παράδειγμα τον Kernighan αν σε δικαιώνει ή όχι πως είναι κατάχρηση να ορίζεις bit-values με #define αντί για enum? Διότι μας έχεις ξεκαθαρίσει εξαρχής εκεί (σε μια δλδ από τις συζητήσεις τις οποίες μόνος σου ανέφερες) πως αυτό είναι κατάχρηση (αφού ολοφάνερα δεν παραμετροποιεί τον κώδικα πριν γίνει compile).

 

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

 

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

 

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

 

Πραγματικά δεν καταλαβαίνω αν υπάρχει point σ' αυτά που λες και αν ναι ποιό είναι αυτό.

 

Για τους υπόλοιπους, όποιος ενδιαφέρεται μπορεί να παρακολουθήσει όλη τη συζήτηση που ξεκινάει από το παραπάνω λινκ. Ίσως έχει ενδιαφέρον να παρακολουθήσει και τη συζήτηση πέριξ αυτού του link: http://www.insomnia.gr/topic/464308-signal-handlers/page-3?do=findComment&comment=5058787.

 

Για να μη χάνουν τα παιδιά την ώρα τους, στη συζήτηση πέριξ του παραπάνω link έχω ξεχάσει κάποια από όσα είπαμε στην άλλη (αρχική) συζήτηση, συμπεριλαμβανομένου του πολύ βασικού πως δε μπορείς να ορίσεις στατικό πίνακα με const (μπορείς όμως με enum). Πράγμα το οποίο παραδέχομαι ο ίδιος λίγο παρακάτω, αναφέροντας ταυτόχρονα και το λόγο αλλά και το τελικά ποιό είναι το σωστό κατά την άποψή μου (πάλι με link στην αρχική συζήτηση).

 

Και τώρα η σειρά μου:

 

Είπες:

 

 

Ο μόνος λόγος που μπορώ να σκεφτώ αυτή τη στιγμή που θα προτιμούσα enum αντί για #define είναι αν ήθελα να κάνω type-checking στο compile time για τις τιμές μιας μεταβλητής, ορισμένης of enumerator type. Στο συγκεκριμένο παράδειγμα που δίνεις δεν το κάνεις και δεν χρειάζεται καν, οπότε δεν βλέπω να μειονεκτεί σε κάτι το #define έναντι του enum σε αυτό το παράδειγμα.

 

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

 

Προς το τέλος της συζήτησης, στην οποία επιμένεις να μπλέκεις τα χίλια μύρια άσχετα πράγματα προκειμένου να βρεις λόγους να αποφύγει κανείς τη χρήση enum, ξεκαθαρίζω τη θέση μου για άλλη μια φορά πέρα από κάθε πιθανότητα παρανόησης:

 

 

 

Νομίζω πως η άποψή μου είναι ξεκάθαρη (και το γιατί τεκμηριωμένο), θα τη συνοψίσω κι εδώ για να συνεννοούμαστε:

• If η δουλειά γίνεται με const τότε const
• Else if η δουλειά γίνεται με enum τότε enum
• Else με macro

 

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

 

Αν δε διαφωνείς, τότε ευθέως προκύπτει το συμπέρασμα πως το macro πρέπει να είναι η τελευταία μας επιλογή, πράγμα το οποίο είναι το νόημα του topic και η κατακλείδα του post με το οποίο ξεκίνησε.

 

I rest my case.

 

 

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

[Directx]

Μιλάω για την κανονική c++. Εδώ υπήρχε framework για να γραφεις drivers σε c++ για windows νωμίζω απο τη compuware.

Yeap! Η Compuware είχε προσφέρει εξαιρετικά εργαλεία - κορωνίδα της το θρυλικό SoftICE!

 

Όσον αφορά την C++ και τα embedded συστήματα, αν μπορούμε να κατατάξουμε τα Λ. Σ. των κινητών σε αυτή την κατηγορία, το πλέον κλασσικό παράδειγμα χρήσης της C++ ήταν το SYMBIAN OS όπου σχεδόν εξ ολοκλήρου ήταν γραμμένο σε μια μορφή C++ με αρκετές ιδιορρυθμίες που καθιστούσε την ανάπτυξη λογισμικού μαζί της μια πολύ επίπονη διαδικασία (ενώ στο τέλος σκότωσε και το ίδιο το SYMBIAN αφού κρίθηκε εξαιρετικά δαπανηρή η συντήρηση του κώδικα που με τα χρόνια είχε προκύψει).

[migf1]

@defacer:

 

Αξιώνεις δεν αξιώνεις, εγώ θα απαντάω όπου, όταν και όπως θέλω εγώ.

 

1. Μας έγραψες ένα ολόκληρο σεντόνι για να πεις πως είμαι off-topic. Κατά την άποψή μου, το τελευταίο μου ποστ και τα links που έδωσα καταρρίπτουν αυτόν σου τον ισχυρισμό. Συμφωνείς δεν συμφωνείς, εμένα το ίδιο μου κάνει.

 

2. Τα τελικά "ξεκαθαρίσματα" των θέσεών σου έχουν αλλάξει τουλάχιστον 2 φορές από την αρχική σου θέση στα links που παρέθεσα στο προηγούμενο ποστ. Ως εκ τούτου προσωπικά τα θεωρώ αναξιόπιστα, αφού είναι πολύ πιθανό να αλλάξουν άλλες 2. Στο δια ταύτα, προσωπικά δεν με ενδιαφέρουν ούτε οι δικές σου θέσεις, ούτε ποια αξιώματα χρησιμοποιείς εσύ, διότι δεν έχεις την παραμικρή εμπειρία σε real-life προγραμματισμό με C (το έχεις παραδεχτεί ο ίδιος).

 

Γενικώς:

 

Αυτό που με ενδιαφέρει είναι όσοι ξεκινούν να μαθαίνουν C να έχουν ανοιχτό ορίζοντα και να μην επηρεάζονται από ανθρώπους σαν εσένα που δεν έχουν προγραμματίσει ποτέ τους σε C, όπως έχεις παραδεχτεί περισσότερες από 1 φορές, αλλά πάραυτα αρέσκονται να υποδεικνύουν κακές και μη κακές συνήθειες και κατ' επέκταση να ενοχοποιούν και να απενεχοποιούν πρακτικές και χαρακτηριστικά μιας γλώσσας με την οποία δεν έχουν δουλέψει ποτέ, Επικλήσεις αποσπασματικών παραθέσεων καταξιωμένων ανθρώπων στο CS όπως σου είχα ξανα-γράψει, πείθουν με λίγη τύχη το πολύ έως και πρωτο-ετείς πανεπιστημίου (άπειρους δηλαδή), ενίοτε και τον ίδιο τον εαυτό σου, πάντα σε όμως θεωρητικό επίπεδο... αν και όταν αρχίσεις να ασχολείσαι σοβαρά με τη γλώσσα για την οποία "κηρύττεις" καλές και κακές πρακτικές, τότε εκτιμώ ως πολύ πιθανό να ξεκαθαρίσεις 1-2 ακόμα φορές (ίσως και περισσότερες) τις τωρινές σου "ξεκαθαρισμένες" θέσεις, οι οποίες είναι κι αυτές προϊόν 1-2 προηγούμενων (θεωρητικών πάντα) ξεκαθαρισμάτων.

 

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

 

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

 

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

 

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

 

EDIT:

 

typos

Επεξ/σία 20 Ιανουαρίου 2013 από migf1

[defacer]

Εγώ αυτό που ξέρω migf1 είναι πως όποιος φοράει παντελόνια αφ ενός αναλαμβάνει την ευθύνη για όσα λέει και όσα κάνει και αφ ετέρου όταν του ζητάνε το λόγο απαντάει στα ίσια.

 

Καλή σας μέρα.

[gdelaportas]

Εγώ αυτό που ξέρω είναι πως όποιος φοράει παντελόνια αφ ενός αναλαμβάνει την ευθύνη για όσα λέει και όσα κάνει και αφ ετέρου όταν του ζητάνε το λόγο απαντάει στα ίσια.

 

Καλή σας μέρα.

 

Εσύ τί πετάγεσαι? Τί επαγγέλεσαι?

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

 

Δε θα κάτσω να ασχοληθώ με έναν "κύριο" οποίος θίγει όμιλο εταιριών 15 ετών με παρουσία σε παγκόσμια έργα και τον μόνο συνεργάτη ελληνική εταιρία με την ESA.

 

Ας μας δώσει τα στοιχεία του ο κύριος και θα τα πούμε όπως πρέπει και όπως ορίζει ο νόμος.

[defacer]

Εσύ τί πετάγεσαι? Τί επαγγέλεσαι?

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

 

Δε θα κάτσω να ασχοληθώ με έναν "κύριο" οποίος θίγει όμιλο εταιριών 15 ετών με παρουσία σε παγκόσμια έργα και τον μόνο συνεργάτη ελληνική εταιρία με την ESA.

 

Ας μας δώσει τα στοιχεία του ο κύριος και θα τα πούμε όπως πρέπει και όπως ορίζει ο νόμος.

 

Chill out. Δεν αναφερόμουν σε σας παιδιά. Έκανα edit το post προς αποφυγήν παρεξηγήσεων.

[migf1]

 

Εγώ αυτό που ξέρω είναι πως όποιος φοράει παντελόνια αφ ενός αναλαμβάνει την ευθύνη για όσα λέει και όσα κάνει και αφ ετέρου όταν του ζητάνε το λόγο απαντάει στα ίσια.

 

Καλή σας μέρα.

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