Ερωτήσεις για C

[migf1]

Αφού όμως είναι δηλωμένη ως unsized δεν μπορώ να της αλλάξω το μέγεθος;

Όχι, το αντίθετο. Το δεσμεύεις στο μήκος της αρχικοποίησης που του κάνεις (+1 για το '\0').

[defacer]

Μπορείς να δεις τον κώδικά μου στη Ναυμαχία που είναι ΠΗΧΤΡΑ στα typedef enum {} Type;

Όταν θέλω type-safeness το χρησιμοποιώ, όταν δεν το θέλω δεν το χρησιμοποιώ!

 

Tο typedef enum τι σχέσει έχει με αυτό που συζητάμε;

 

Λες ότι το χρησιμοποιείς (και καλά κάνεις) προκειμένου φαντάζομαι να αποφύγεις κάτι τέτοιο:

>
#define LEFT  1
#define RIGHT 2

switch(direction) { /* κλπ κλπ */ }

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

[capoelo]

Όχι, το αντίθετο. Το δεσμεύεις στο μήκος της αρχικοποίησης που του κάνεις (+1 για το '\0').

 

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

[migf1]

Tο typedef enum τι σχέσει έχει με αυτό που συζητάμε;

Λες ότι το χρησιμοποιείς (και καλά κάνεις) προκειμένου φαντάζομαι να αποφύγεις κάτι τέτοιο:

>
#define LEFT  1
#define RIGHT 2

switch(direction) { /* κλπ κλπ */ }

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

 

Βγάλε το αν σε χαλάει το typedef, δεν αλλάζει σε κάτι αυτό που λέμε. Όταν θέλω int type-safeness χρησιμοποιώ (και) enum. Όταν δεν θέλω δεν το χρησιμοποιώ.

 

Για το παράδειγμα που έδωσα στο ideone έχεις κάποιο σχόλιο;

Έχω ένα σχόλιο, ναι... πριν γράψεις κώδικα διάβασε πρώτα κάποιο από τα διαθέσιμα C Code Styles ή ακόμα πιο εύκολα, τις γενικότερες συμβάσεις της γλώσσας. Στην προκειμένη περίπτωση η σύμβαση υποδεικνύει όλα τα preprocessor directives να γράφονται με κεφαλαία γράμματα, ενώ όλα τα var identifiers είτε πεζά είτε με camel-case είτε με hungarian notation... ποτέ όμως με όλα κεφαλαία.

 

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

Εφόσον το ορίζεις στατικά το str το δεμσμεύεις στο μέγιστο μήκος του ορισμού του (ή της αρχικοποίησής του αν δεν ορίζεις μήκος).

 

Αν θες να αλλάζεις μέγεθος όποτε θες πρέπει να το ορίζεις ως δείκτη και κατόπιν να το διαχειρίζεσαι δυναμικά με malloc/calloc/realloc και free.

[defacer]

Έχω ένα σχόλιο, ναι... πριν γράψεις κώδικα διάβασε πρώτα κάποιο από τα διαθέσιμα C Code Styles ή ακόμα πιο εύκολα, τις γενικότερες συμβάσεις της γλώσσας. Στην προκειμένη περίπτωση η σύμβαση υποδεικνύει όλα τα preprocessor directives να γράφονται με κεφαλαία γράμματα, ενώ όλα τα var identifiers είτε πεζά είτε με camel-case είτε με hungarian notation... ποτέ όμως με όλα κεφαλαία.

 

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

• μπορεί να προκληθεί από κάποιο λιγότερο γνώστη συνάδελφό σου ο οποίος έλειπε από το σχολείο τη μέρα που έλεγαν για coding styles και το έγραψε με μικρά
  
• αν συμβεί σε ένα τεράστιο compilation unit με πολλά includes θα τραβάς ό,τι προεξέχει μέχρι να καταλάβεις ποιός έφταιγε και γιατί
  
• όσο περνάει ο χρόνος αυξάνονται (από απειροελάχιστες σε απλά πολύ μικρές) οι πιθανότητες να συμβεί γιατί λάθη είμαστε ανθρώπους κάνουμε
  

 

Θα πάρω να διαβάσω κανα code style guide και τον K&R γιατί το σημείο που λέει "άσε ανοιχτές τις πιθανότητες για στραβή, χαλάλι σου αγόρι μου" δεν το έχω υπόψη.

[migf1]

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

• μπορεί να προκληθεί από κάποιο λιγότερο γνώστη συνάδελφό σου ο οποίος έλειπε από το σχολείο τη μέρα που έλεγαν για coding styles και το έγραψε με μικρά
• αν συμβεί σε ένα τεράστιο compilation unit με πολλά includes θα τραβάς ό,τι προεξέχει μέχρι να καταλάβεις ποιός έφταιγε και γιατί
• όσο περνάει ο χρόνος αυξάνονται (από απειροελάχιστες σε απλά πολύ μικρές) οι πιθανότητες να συμβεί γιατί λάθη είμαστε ανθρώπους κάνουμε

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

 

Έχεις μια απέχθεια προς τον C pre-processor, κατανοητό, δεκτό και σεβαστό. Μην προσπαθείς όμως να με πείσεις να μην το χρησιμοποιώ. Δόξα το Θεό υπάρχουν ένα κάρο γλώσσες πολύ πιο ασφαλείς από την C.. και για τους έμπειρους και για τους μη έμπειρους.

 

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

 

Ως εκ τούτου, εγώ θεωρώ σημαντική την γνώση και τη χρήση του στη C. Η C++ ξεκίνησε αποκλειστικά γραμμένη στον προ-επεξεργαστή της C. Αυτό αν μη τι άλλο κάτι λέει για τις δυνατότητες και τη χρησιμότητά του ακόμα και στους πιο δύσπιστους.

 

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

 

Θα πάρω να διαβάσω κανα code style guide και τον K&R γιατί το σημείο που λέει "άσε ανοιχτές τις πιθανότητες για στραβή, χαλάλι σου αγόρι μου" δεν το έχω υπόψη.

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

[defacer]

Έχεις μια απέχθεια προς τον C pre-processor, κατανοητό, δεκτό και σεβαστό. Μην προσπαθείς όμως να με πείσεις να μην το χρησιμοποιώ. Δόξα το Θεό υπάρχουν ένα κάρο γλώσσες πολύ πιο ασφαλείς από την C.. και για τους έμπειρους και για τους μη έμπειρους.

 

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

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

 

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

 

Ως εκ τούτου, εγώ θεωρώ σημαντική την γνώση και τη χρήση του στη C. Η C++ ξεκίνησε αποκλειστικά γραμμένη στον προ-επεξεργαστή της C. Αυτό αν μη τι άλλο κάτι λέει για τις δυνατότητες και τη χρησιμότητά του ακόμα και στους πιο δύσπιστους.

Οπότε δηλαδή κατά τη δική σου άποψη πρέπει να χρησιμοποιούν αυτό το πανίσχυρο εργαλείο ακόμα κι εκεί όπου δε χρειάζεται γιατί έτσι κάνουν στη C οι πραγματικοί άντρες;

 

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

 

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

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

 

Τελευταία απάντηση απο μένα στο συγκεκριμένο topic γιατί πραγματικά κουράστηκα και δε βλέπω να βγάζει κάπου.

[migf1]

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

 

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

 

Το άλλο, το bold, για τα πεζά/κεφαλαία αδυνατώ να κατανοήσω τι εννοείς.

[imitheos]

Ρε παιδιά,ποιο είναι το λάθος μου εδώ;

 

>#include<stdio.h>
#include<stdlib.h>
#include<string.h>

int main(void)
{
       char str[]="tom";
	strcpy(str,"dimitris");

	printf(str);

	system("Pause");

	return 0;

}

 

Αφού τη δηλώνω ως unsized!!!

Αφού όμως είναι δηλωμένη ως unsized δεν μπορώ να της αλλάξω το μέγεθος;Υπάρχει κάποιος περιορισμός;

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

 

Δεν την δηλώνεις "unsized". Όπως σου απάντησε και ο migf1, την δηλώνεις με τόσο χώρο όσο χρειάζεται το string literal που παρέχεις. Δηλαδή είναι σαν να έχεις γράψει str[4] απλά αντί να σκέφτεσαι "3 γράμματα το tom + το χαρακτήρα 0 = 4", το str[] είναι μια συντακτική ευκολία που λέει στον compiler "ωχ ρε παιδί μου βαριέμαι τώρα να μετράω τα γράμματα και το χαρακτήρα 0. βρες τα εσύ". Λύση σε αυτό που θες είναι να χρησιμοποιήσεις malloc όπως είπε ο migf1 ή να ορίσεις ένα σχετικά μεγάλο χώρο πχ str[50].

 

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

 

Έχεις μια απέχθεια προς τον C pre-processor, κατανοητό, δεκτό και σεβαστό. Μην προσπαθείς όμως να με πείσεις να μην το χρησιμοποιώ. Δόξα το Θεό υπάρχουν ένα κάρο γλώσσες πολύ πιο ασφαλείς από την C.. και για τους έμπειρους και για τους μη έμπειρους.

 

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

 

Εκτός από τους άπειρους όμως και οι έμπειροι κάνουν λάθη και είναι γεγονός ότι είναι πιο εύκολο να φας πίκρα με τον pre-processor παρά με enums-const. Αυτό δεν σημαίνει ότι δεν πρέπει ποτέ να χρησιμοποιούμε #define. Εννοείται πως ό,τι σου παρέχει η γλώσσα είναι για να το χρησιμοποιείς. Από όλο το διάλογο όμως, εγώ κρατάω την φράση του defacer "Γιατί δεν το χρησιμοποιείς παντού όταν είναι εφικτό όμως;" Όταν η εναλλακτική λύση σου παρέχει ακριβώς τα ίδια πλεονεκτήματα χωρίς όμως την (έστω μικρή) πιθανότητα να φας τα μούτρα σου, γιατί να μην την χρησιμοποιήσεις ?

 

"Κανένα εργαλείο δεν είναι κακό αν το χρησιμοποιούμε σωστά. Και οι δύο λύσεις είναι πολύ χρήσιμες και βολικές. Ο pre-processor όμως είναι πολύ πιο χαζός από τον compiler. Έτσι είναι πιο εύκολο να γίνει λάθος ακόμη και από ένα έμπειρο προγραμματιστή (μην ξεχνάμε την κούραση ως παράγοντα) για αυτό ΑΝ μπορούμε να χρησιμοποιήσουμε functions ή enums ή οτιδήποτε άλλο, καλό είναι να το κάνουμε."

 

Διαφωνεί κανείς με την παραπάνω πρόταση ως σύνοψη ?

[defacer]

"Κανένα εργαλείο δεν είναι κακό αν το χρησιμοποιούμε σωστά. Και οι δύο λύσεις είναι πολύ χρήσιμες και βολικές. Ο pre-processor όμως είναι πολύ πιο χαζός από τον compiler. Έτσι είναι πιο εύκολο να γίνει λάθος ακόμη και από ένα έμπειρο προγραμματιστή (μην ξεχνάμε την κούραση ως παράγοντα) για αυτό ΑΝ μπορούμε να χρησιμοποιήσουμε functions ή enums ή οτιδήποτε άλλο, καλό είναι να το κάνουμε."

 

Διαφωνεί κανείς με την παραπάνω πρόταση ως σύνοψη ?

 

Εγώ συμφωνώ 100%. Αλλά τώρα you are it!

[Timonkaipumpa]

Ωραίος ο pre-processor και ακόμα πιο ωραία τα typedefs της C... πόσο μάλλον δε όταν χρησιμοποιούνται για function pointer types, callback tables κτλ. Πραγματικά βολεύουν.

 

Όμως, προσωπική μου γνώμη, η C σαν γλώσσα βολεύει για να χτίσει κανείς ένα "υπόβαθρο" υπηρεσιών και όχι για να φτιάξει ένα front end. Βολεύει για embedded systems, βολεύει για drivers (αν και το microframework είναι αρκετά βολικό) ακόμα και για file managers back end.

 

Σε αυτά τα πεδία λοιπόν, συχνά - πυκνά χρειάζεσαι not type specific λειτουργίες, απλές λειτουργίες αντικατάστασης και ό,τι άλλο μπορεί να παρέχει ένα macro από τον pre-processor. Από μερικά or σε pins μέχρι και global variables σε όλο το project (ειδικά όταν πρόκειται για network communication oriented projects).

 

Όπου, ένα enum με τιμές 1, 2, 3, 4, κτλ... δεν είναι τόσο safe όσο ένα #define με τιμές 0x00, 0xA0, 0x10 και ό,τι άλλο. Όχι απλά δεν είναι τόσο safe, αλλά αναλόγως και τον εκάστοτε compiler του vendor (ειδικά σε embedded systems) μπορεί να μην έχεις ακριβή έλεγχο στον buffer που θες να γεμίσεις με συγκεκριμένες τιμές εάν χρησιμοποιήσεις enums... ή να κάνεις το λάθος και να μην βάλεις cast. Άρα, εκεί κερδίζει το #define και χάνει το enum.

[migf1]

...

Εκτός από τους άπειρους όμως και οι έμπειροι κάνουν λάθη και είναι γεγονός ότι είναι πιο εύκολο να φας πίκρα με τον pre-processor παρά με enums-const. Αυτό δεν σημαίνει ότι δεν πρέπει ποτέ να χρησιμοποιούμε #define. Εννοείται πως ό,τι σου παρέχει η γλώσσα είναι για να το χρησιμοποιείς. Από όλο το διάλογο όμως, εγώ κρατάω την φράση του defacer "Γιατί δεν το χρησιμοποιείς παντού όταν είναι εφικτό όμως;" Όταν η εναλλακτική λύση σου παρέχει ακριβώς τα ίδια πλεονεκτήματα χωρίς όμως την (έστω μικρή) πιθανότητα να φας τα μούτρα σου, γιατί να μην την χρησιμοποιήσεις ?

 

"Κανένα εργαλείο δεν είναι κακό αν το χρησιμοποιούμε σωστά. Και οι δύο λύσεις είναι πολύ χρήσιμες και βολικές. Ο pre-processor όμως είναι πολύ πιο χαζός από τον compiler. Έτσι είναι πιο εύκολο να γίνει λάθος ακόμη και από ένα έμπειρο προγραμματιστή (μην ξεχνάμε την κούραση ως παράγοντα) για αυτό ΑΝ μπορούμε να χρησιμοποιήσουμε functions ή enums ή οτιδήποτε άλλο, καλό είναι να το κάνουμε."

 

Διαφωνεί κανείς με την παραπάνω πρόταση ως σύνοψη ?

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

 

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

 

Προφανώς κι εγώ χρησιμοποιώ "τεχνικές" που μειώνουν τις πιθανότητες σφάλματος, αλλά προσπαθώ να τις κρατάω στα απολύτως minimum (χωρίς να σημαίνει πως το καταφέρνω πάντα). Αt the end of the day πιστεύω βαθύτατα πως είναι λάθος να πηγαίνει κανείς κόντρα στη φύση της γλώσσας που χρησιμοποιεί. Το κλειδί για μένα, είναι πως δεν υπάρχουν μαγικές συνταγές για τα πάντα και επίσης πιστεύω πως τη διαφορά μεταξύ του καλού και του πολύ καλού την κάνει ακριβώς αυτή η διαφοροποίηση.

 

Ερχόμενος τώρα στο enum vs define. Ας πάρουμε το παρακάτω παράδειγμα...

 

>
#include <stdio.h>

enum Direction { North, South, East, West };
enum Color { Red, Green, Blue };

void paint_screen(enum Color c) {
switch(c) {
case Red:
   	puts("painting screen red");
   	break;
case Green:
   	puts("painting screen green");
   	break;
case Blue:
   	puts("painting screen blue");
   	break;
}
}

int main(void) {
enum Direction d = South;

paint_screen(d); /* oops! */

return 0;
}

Πήγε περίπατο κατά το ήμισυ το περίφημο enum, διότι στη C αντίθετα με την C++ το enum δεν εξασφαλίζει strong-type check.

 

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

 

Επίσης, ποιο είναι το όφελος να ορίσεις μια μόνο σταθερά με enum αντί για #define, όπως π.χ. στα παραδείγματα των προηγούμενων posts; Βασικά κανένα.

 

Ακόμα, ας πούμε πως χρειάζεσαι οι σταθερές σου να συμμετάσχουν σε bit operations. Το enum δεν είναι καν επιλογή.

 

Οπότε τι είναι καλύτερο, να εμφυσήσουμε σε κάποιον την νοοτροπία "απόφευγε τα #define και χρησιμοποίησε enum instead" ή "μάθε τα + και τα - των #define και των enum και κρίνε εσύ ποιο θα χρησιμοποιήσεις που, πως και γιατί".

 

Εγώ πιστεύω το 2ο και μάλιστα hands-down.

[defacer]

Όπου, ένα enum με τιμές 1, 2, 3, 4, κτλ... δεν είναι τόσο safe όσο ένα #define με τιμές 0x00, 0xA0, 0x10 και ό,τι άλλο. Όχι απλά δεν είναι τόσο safe, αλλά αναλόγως και τον εκάστοτε compiler του vendor (ειδικά σε embedded systems) μπορεί να μην έχεις ακριβή έλεγχο στον buffer που θες να γεμίσεις με συγκεκριμένες τιμές εάν χρησιμοποιήσεις enums... ή να κάνεις το λάθος και να μην βάλεις cast. Άρα, εκεί κερδίζει το #define και χάνει το enum.

 

Μένω πραγματικά άφωνος και περιμένω να διαφωτιστώ. Please?

[migf1]

Μένω πραγματικά άφωνος και περιμένω να διαφωτιστώ. Please?

Υποθέτω αναφέρεται σε αυτό που έθιξα κι εγώ παραπάνω για τα bits, ότι δηλαδή δεν μπορείς να βασιστείς στο enum για να υλοποιήσεις bit-values μεγαλύτερες του platform-dependent implementation των int (μιας και τα enum γίνονται treat ως int). Π.χ. σε 4-byte int με enum μπορείς να πας το πολύ μέχρι 2^31.

[Timonkaipumpa]

Υποθέτω αναφέρεται σε αυτό που έθιξα κι εγώ παραπάνω για τα bits, ότι δηλαδή δεν μπορείς να βασιστείς στο enum για να υλοποιήσεις bit-values μεγαλύτερες του platform-dependent implementation των int (μιας και τα enum γίνονται treat ως int). Π.χ. σε 4-byte int με enum μπορείς να πας το πολύ μέχρι 2^31.

 

Ακριβώς.

 

Χώρια που, εάν έχεις δηλώσεις το τύπου:

 

>
#define uint8                   unsigned char
#define FIRST_VALUE       0x00
#define SECOND_VALUE   0xFF

uint8* buf;
uint8* pBuf;

*pBuf++ = FIRST_VALUE;
*pBuf++ = SECOND_VALUE;

 

με buf τον actual buffer για γέμισμα και pBuf έναν pointer για να κινείσαι στον buffer, εάν οι τιμές σου είναι byte specific, και ως τέτοιες θα διαβαστούν μετά, το πόσα bytes θα περαστούν στον buffer για μία τιμή του enum δεν είναι σίγουρο, ούτε και το πώς θα περαστούν. Εάν δε, έχεις και τιμές που καταλαμβάνουν παραπάνω από δύο bytes και το endian παίζει ρόλο... τότε πρέπει να έχεις απόλυτο έλεγχο στις τιμές που θα αποθηκευτούν στον buffer.

 

 

Επίσης, να παραθέσω:

 

Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined (6.7.2.2 Enumerationspecifiers)

 

 

Ελπίζω να σε κάλυψα defacer. Εάν κάπου κάνω λάθος ή κάτι είναι ακόμα σκοτεινό, εδώ είμαστε

 

Να συμπληρώσω πως ο buf πάει για αποστολή μέσω δικτύου (ό,τι δίκτυο και να είναι αυτό) και η άλλη άκρη θα διαβάσει ΕΝΑ ΕΝΑ τα bytes, για να βρει συγκεκριμένες τιμές.

 

Επίσης, παρέλειψα το memory allocation για χάρη απλότητας... παράδειγμα είναι