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

[migf1]

 

 

...

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

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

...

Βασικά ο migf1 ( ) δεν λέει πως είναι κακός αυτός ο κώδικας. Ίσα-ίσα, λέω πως τα macros έχουν την θέση και τη χρησιμότητά τους στην C, ιδίως στους τομείς που ανέφερα επιγραμματικά παραπάνω ( polymoprhism/overloading, code-generation) συν το forced inlining που είχε θίξει ήδη ο DirectX.

 

Ένα απλούστατο και κοινότατο παράδειγμα... γράφω:

 

#define myMIN(x,y)  ( (x) < (y) ? (x) : (y) )

και το χρησιμοποιώ ως έχει είτε περάσω int's, είτε char's, είτε double's, είτε οτιδήποτε primitive type (ενίοτε και μη primitive).

 

Δηλαδή υπό ποια ακριβώς λογική θα έρθει ο κάθε defacer να μου επιβάλει να γράψω 10 διαφορετικές συναρτήσεις για κάθε ξεχωριστό τύπο που θέλω να συγκρίνω; Αν ήθελα σφιχτές ντιρεκτίβες θα έγραφα σε άλλη γλώσσα ή θα έγραφα 10 διαφορετικές συναρτήσεις. Εγώ όμως δεν θέλω, θέλω συνειδητά να χρησιμοποιήσω το type non-safety που μου παρέχουν τα macros, γιατί θέλω να χρησιμοποιήσω το MIN() overloaded με τον ταχύτερο κι απλούστερο τρόπο που μπορώ.

 

Επίσης, εγώ δεν κουνάω το δάχτυλο σε όποιον χρησιμοποιεί 10 διαφορετικές συναρτήσεις, μια για κάθε ξεχωριστό τύπο. Αυτό θέλει, αυτό κάνει... δεν μου πέφτει λόγος εμένα. Παίρνω σαν δεδομένο πως για να το κάνει έτσι, τον ενδιαφέρει πρωτίστως το type-safety. Το ίδιο κάνει και η C, σου λέει κύριε αυτά τα εργαλεία σου παρέχω, θες να το κάνεις έτσι; κάντο, έχει αυτά τα + κι αυτά τα -. Θες να το κάνεις αλλιώς; κάντο, έχει αυτά τα + κι αυτά τα -.

 

Και για να επανέλθω στην φοβερή & τρομερή ατάκα του defacer στο τέλος του αρχικού του ποστ στο νήμα, όσο χρειάζεται να σκεφτείς αν υπάρχει καλύτερος τρόπος από το #define, άλλο τόσο χρειάζεται να σκεφτείς αν υπάρχει καλύτερος τρόπος από το enum, κι άλλο τόσο χρειάζεται να σκεφτείς αν υπάρχει καλύτερος τρόπος από το const int.

 

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

[migf1]

EDIT:

 

Επίσης γράφω...

#define BIT_1 0x00
#define BIT_2 0x01
...

διότι θέλω να σιγουρέψω πως δεν θα πέσω στον περιορισμό του εκάστοτε compiler για τα enums.

κλπ, κλπ.

[m1cRo]

Ο Δημιουργός της C++ τα λέει ξεκάθαρα για τα macros:

http://www.stroustrup.com/bs_faq.html - Avoid macros excpt for include guards

 

Γενικός τα templates φτιάχθηκαν για να αντικαταστήσουν τα macros οποτε χρησιμοποιείτε είτε τα templates είτε το dynamic polymorphism εκεί που το θέλετε.

Όσο αφορά τα best practices θα ήθελα να συμβουλέψω ένα βιβλίο από την σειρά c++ in depth:

http://www.amazon.com/Coding-Standards-Rules-Guidelines-Practices/dp/0321113586
 

[parsifal]

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

 

Υπενθυμίζω τον απόλυτο κανόνα που αρκεί να ακολουθούμε για αποτελεσματικό self-moderation κατά την εμπλοκή μας σε debates μέσω ιντερνετοφόρουμ: "Attack the post, not the poster".

 

Ευχαριστώ.

[migf1]

Ο Δημιουργός της C++ τα λέει ξεκάθαρα για τα macros:

http://www.stroustrup.com/bs_faq.html - Avoid macros excpt for include guards

 

Γενικός τα templates φτιάχθηκαν για να αντικαταστήσουν τα macros οποτε χρησιμοποιείτε είτε τα templates είτε το dynamic polymorphism εκεί που το θέλετε.

 

Όσο αφορά τα best practices θα ήθελα να συμβουλέψω ένα βιβλίο από την σειρά c++ in depth:

http://www.amazon.com/Coding-Standards-Rules-Guidelines-Practices/dp/0321113586

 

 

Μόνο που το νήμα αναφέρεται στην C (και όχι στην C++).

[m1cRo]

Μόνο που το νήμα αναφέρεται στην C (και όχι στην C++).

Oo sorry  δεν το είδα, έκανα λάθος Αλλα τι τη θέλετε τη c? Και στην παραγωγή? Εδώ για embeded συστήματα γράφουμε c++.

[migf1]

Νο προμπλέμο (δεν με άφηνε το φόρουμ να γράψω σκέτο "no problem"... παραπονιόταν για αμιγή χρήση greeklish)

 

Όσοι δημοσίευσαν μεγάλα μηνύματα που τα 'φαγε η μαρμάγκα κι επιθυμούν να τα ξαναδημοσιεύσουν χωρίς τα προκλητικά τμήματά τους, είμαι διατεθειμένος να τους διευκολύνω.

 

 Υπενθυμίζω τον απόλυτο κανόνα που αρκεί να ακολουθούμε για αποτελεσματικό self-moderation κατά την εμπλοκή μας σε debates μέσω ιντερνετοφόρουμ: "Attack the post, not the poster".

 

Ευχαριστώ.

Σε ότι μου αναλογεί, απολογούμαι και δημόσια. Αν και όταν μπορείς, πιστεύω είναι παραπάνω από χρήσιμο να φαίνονται στο συγκεκριμένο νήμα τα posts μου με τα ενδεικτικά projects τεράστιας εμβέλειας που χρησιμοποιούν κατά κόρον macros (και τα οποία τα πήρε κι αυτά η -δικαιολογημένη- μπάλα).

 

EDIT-1:

 

Ενδεικτικά C projects που κάνουν heavy-use of macros είναι το Linux, το GTK+ και η SQL. Τα είχα αναφέρει ενδεικτικά, επειδή εκπροσωπούν διαφορετικές κατηγορίες. Είχα δώσει και link προς τον κώδικα του Linux, στο includes/ directory.

 

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

 

ΥΓ. @parsifal: ευχαριστώ!

 

EDIT-2:

 

Αλλα τι τη θέλετε τη c? Και στην παραγωγή? Εδώ για embeded συστήματα γράφουμε c++.

Αν γράφετε embedded σε C++ (ή Java) θεωρείστε niche market (λίγο-πολύ εξαίρεση δηλαδή). Εξ' όσων γνωρίζω, στα embedded systems κυριαρχεί ακόμα η C (κι αμέσως μετά η Assembly).

[gdelaportas]

Νομίζω ότι ο @m1cR0 έχει δίκιο και όμως παίζει πολύ η C++ αν και δεν είμαι ειδικός. Αλλά ο m1cR0 είναι...

[Star_Light]

gdelaportas σε ποια εταιρεια δουλευεις?

 

Σε αυτο που λεει δεν διαφωνω ουτε εγω μερικοι χεστηκανε πως εγραψες τον κωδικα

αρκει να τσεπωσουν τα φραγκακια απο την παραγωγη ωστοσο αν εγω κολλησω σε καποιο σημειο

και χρειαστει να ρωτησω τον φιλο μου τον migf1 ή τον οποιονδηποτε αλλον... αν ο κωδικας δεν διαβαζεται

θα με στειλει να τον αλλαξω ξανα.

 

Καλο ειναι να ακολουθει καποιος μερικους κανονες.... την τεχνη του θα την χρησιμοποιησει

στην προσεγγιση με την οποια θα δουλεψει ωστε να κωδικοποιησει τον αλγοριθμο πχ με arrays? ή με δείκτες? με συμπτυγμένο κωδικα ή πιο αναλυτικο??? κτλπ κτλπ αν παιζει με C  ή ακομη και αν βρει δικο του αλγοριθμο να υλοποιησει και να μην παρει κατι ετοιμο. Δεν χρειαζεται να βαλεις την πενα σου επειδη απλα αλλαξες τα ονοματα των μεταβλητων αυτο δεν ειναι πενα... μπορει να ειναι και κλεψια!!!!!

[ChRis6]

@gdelaportas

 

Τα 10ms που λες πιο πανω ειναι ΤΕΡΑΣΤΙΟ χρονικο διαστημα.Είναι σχεδόν το μισό από κάθε logic loop σε έναν ΑΑΑ τίτλο commercial παιχνιδιου.Έχεις περίπου 25ms για να κάνεις τα εξής: να τρέξεις αλγοριθμους τεχνητής νοημοσύνης,collision detection,rigid body physics ( νταξ μπορουν να γινουν και στη GPU ) και γενικότερα να αλλάξεις το State του "κόσμου".Ακόμα και 5ms ( που παλι ειναι τεραστιο χρονικο διαστημα )να αργησεις,το simulation παει περίπατο...

 

 

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

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

 

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

 

Περι ορέξεως λοιπον.... Κολοκυθοπιτα...

Επεξ/σία 19 Ιανουαρίου 2013 από ChRis6

[Directx]

@gdelaportas

 

Τα 10ms που λες πιο πανω ειναι ΤΕΡΑΣΤΙΟ χρονικο διαστημα.Είναι σχεδόν το μισό από κάθε logic loop σε έναν ΑΑΑ τίτλο commercial παιχνιδιου.Έχεις περίπου 25ms για να κάνεις τα εξής: να τρέξεις αλγοριθμους τεχνητής νοημοσύνης,collision detection,rigid body physics ( νταξ μπορουν να γινουν και στη GPU ) και γενικότερα να αλλάξεις το State του "κόσμου".Ακόμα και 5ms ( που παλι ειναι τεραστιο χρονικο διαστημα )να αργήσεις,το simulation παει περίπατο...

Σωστός, 10ms από εδώ 5ms από εκεί ακόμα και σε μια εφαρμογή (απλή όχι games κλπ) όταν έχεις να κάνεις με κώδικα που οφείλει να επεξεργάζεται χιλιάδες εγγραφές (και να το κάνει όσο πιο γρήγορα μπορεί), μαζεύονται και ρίχνουν κατακόρυφα την απόδοση του προγράμματος.

[cyberrobot]

 

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

 

Περι ορέξεως λοιπον.... Κολοκυθοπιτα...

 

Αν και newbie στην C (ξεκίνησα την διπλωματική πριν κάνα δίμηνο) και πολλά πράγματα δεν ξέρω π.χ. για macros,inline δεν είχα ιδέα. Προτιμώ συναρτήσεις (με βάση όσα διάβασα από εδώ και το googling) γίνετε πολύ πιο ευανάγνωστος ο κώδικας θεωρώ. Τώρα στο θέμα C++ στα embedded πρέπει να κοιτάς κάτι εξαιρετικά "trendy" ή αρκετά δυνατό.

 

Ένα +1 στον topic starter για την πρόταση του "βρήκα" το βιβλίο και θα του ρίξω μια ματιά γιατί διπλωματική είναι αυτή, θέλουμε απόδοση δι...λε!

[m1cRo]

Πολύ βασικό για το optimization είναι ότι δεν την κάνουμε στην αρχή, μη προσπαθείτε να γράψετε τον γρηγορότερο κώδικα σε επίπεδο implementation. Οι compiler θα κάνουν πολύ καλύτερη optimization από εσάς.
Αυτό που θα καταφέρετε είναι να κάνετε τον κώδικα μπερδεμένο. Το goal πρέπει να είναι να πετύχουμε maintainable κώδικα που σε καλύτερη περίπτωση θα δέχεται επεκτάσεις χωρίς καμια αλλαγή μέσα του. Αν για παράδειγμα διαβάσετε το Modern C++ design από τη c++ in depth serie θα δείτε πολύ ωραία πράγματα, όπως πως να φτιάξετε μια factory που να μη θέλει αλλαγές όταν πρόσθετε καινούριους τύπους.

http://en.wikipedia.org/wiki/Program_optimization

 

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

 

 

Αν και newbie στην C (ξεκίνησα την διπλωματική πριν κάνα δίμηνο) και πολλά πράγματα δεν ξέρω π.χ. για macros,inline δεν είχα ιδέα. Προτιμώ συναρτήσεις (με βάση όσα διάβασα από εδώ και το googling) γίνετε πολύ πιο ευανάγνωστος ο κώδικας θεωρώ. Τώρα στο θέμα C++ στα embedded πρέπει να κοιτάς κάτι εξαιρετικά "trendy" ή αρκετά δυνατό.

 

Ένα +1 στον topic starter για την πρόταση του "βρήκα" το βιβλίο και θα του ρίξω μια ματιά γιατί διπλωματική είναι αυτή, θέλουμε απόδοση δι...λε!

 

 

Από την εμπειρία μου τα περισσότερα navigation systems τρέχουν τον C++ κώδικα. Γιατί πρέπει να είναι κάτι trendy αν είναι σε c++?

[cyberrobot]

Από την εμπειρία μου τα περισσότερα navigation systems τρέχουν τον C++ κώδικα. Γιατί πρέπει να είναι κάτι trendy αν είναι σε c++?

"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 αρχιτεκτονική και να φανταστείς αφορούσαν μεταφορά δεδομένων κ μόνο μετά γινόταν πάρτυ άν έβαζες χέρι στην λογική του προγράμματος!

 

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

[gdelaportas]

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

 

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