imitheos Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 Τέλος πάντων, επειδή ο στόχος μου ήταν άλλος, που μάλλον δεν έγινε αντιληπτός, κακώς μπήκα στην κουβέντα, δυστυχώς το forum πηγαίνει από το κακό στο χειρότερο. Χμ. αυτό από που προέκυψε τώρα; Συζήτηση κάνουμε, δεν κάνουμε διαγωνισμό. Πολύ καλά έκανες και μπήκες στη κουβέντα, σε δημόσιο φόρουμ είμαστε. Ο καθένας μας έχει δικό του στυλ γραψίματος οπότε κάτι που κάποιος θεωρεί βολικό ένας άλλος μπορεί να το θεωρεί άσκοπο. Προσωπικά βρήκα το COPY πολύ άσχημο εκτός από άσκοπο για αυτό σχολίασα το "κοίτα μια ωραία copy" αλλά δεν είχα πρόθεση να προσβάλλω τον bokarinho και δεν περίμενα να το πάρει προσωπικά. Αν ήμουν απότομος ζητώ συγγνώμη.
Timonkaipumpa Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 Γνωρίζω πολύ καλά τι λες, άλλωστε έδωσα κάποια παραδείγματα, γενικά επειδή είπες ότι και το NEW μου έχει κάποιο θέμα, να ξέρεις ότι αυτά τα οποία έδωσα δεν είναι για οτιδήποτε project υλοποιώ, σε μερικά τα χρησιμοποιώ ανάλογα την περίπτωση για να εξοικονομώ χρόνο. Το copy μου είναι μια χαρά, σε διαβεβαιώ, για αυτό που το χρειαζόμουν ήταν μια χαρά, αυτά που λες είναι αυτονόητα, ευχαριστώ για τις συμβουλές σου από την άλλη. Επίσης και το δεύτερο που λες πάλι το γνώριζα, για το NEW αναφέρομαι. Τέλος πάντων, επειδή ο στόχος μου ήταν άλλος, που μάλλον δεν έγινε αντιληπτός, κακώς μπήκα στην κουβέντα, δυστυχώς το forum πηγαίνει από το κακό στο χειρότερο. Πώς το forum πηγαίνει από το κακό στο χειρότερο επειδή επισήμαναν το λάθος σου κάποιοι... δεν μπορώ να καταλάβω. Δηλαδή.. έπρεπε να κάνουν όλοι τεμενάδες επειδή μοιράστηκες με εμάς τους ταπεινούς τις τόσο σπουδαίες γνώσεις σου, για να πηγαίνει το forum προς το καλύτερο; Ό,τι να 'ναι.
παπι Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 > /* Copy to obj from src, using sizeof(obj). Note that obj is an lvalue but src is a pointer! */ #define COPY(obj, src) (void)memcpy(&(obj), (src), sizeof(obj)) Δεν διαφωνώ, το πνεύμα είναι αυτό που κρίνουμε, κοίτα μία ωραία copy που την χρησιμοποιώ γενικά σε διάφορα project, πόσο γρήγορα και ευκολότερα κάνεις την δουλειά σου. Το να κανεις wrap συναρτησεις οπως η SendMessage με macro το καταλαβαινω, ομως συναρτησεις που παιρνουν στανταρ ορισματα δεν το καταλαβαινω.
imitheos Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 Πώς το forum πηγαίνει από το κακό στο χειρότερο επειδή επισήμαναν το λάθος σου κάποιοι... δεν μπορώ να καταλάβω. Δυστυχώς πολλά άτομα έχουν αυτή τη νοοτροπία. Όταν κάποιος τους λέει κάτι αρνητικό αρχίζουν "όποιος δεν θέλει ας μην απαντήσει" "το φόρουμ πάει από το κακό στο χειρότερο" "το παίζεις μάγκας" και άλλα παρόμοια. Είναι πολύ πιθανό η άποψή μου να είναι λάθος αλλά προσωπικά πιστεύω ότι τα φόρα υπάρχουν για διαφωνίες . Αν σε ένα thread όλοι συμφωνούμε τότε έκλεισε το thread. Η διαφωνία προωθεί τον διάλογο. Υπάρχουν πολλά άτομα με τρελές γνώσεις (όπως στο παρόν υποφόρουμ ο DirectX, ο defacer και πολλά άλλα παιδιά) και μέσα από τα επιχειρήματά τους γίνομαι και εγώ καλύτερος. Αλλιώς θα μιλούσα στο καθρέφτη που θα συμφωνούσε και θα μου έδινε δίκιο πάντα
migf1 Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 > void roll_dice_adv(int n , int guess , int arr1[] , int arr2[]) { int j=0 , count=0; if( guess < 0 || guess > 6) return; roll_dice(n,arr1,arr2); for(; j<n; j++) { if(arr1[j] == ( guess ) && arr2[j] == ( guess ) ) count++; } if(count) printf(" Congratulations you have : %d Win(s) in Advanced Mode!!! " , count ); else puts("Sorry! You lost."); return; } Που ρε συ migf1 την οριζω τοπικα??? μηπως εννοεις οτι την περναω σαν εξτρα ορισμα??? ενω θα μπορουσα να την διαχειριστω απλα μεσα στην συνάρτηση τοπικα? δεν σε καταλαβα ρε φιλε.. Ναι αυτό εννοούσα, ότι δηλαδή θα μπορούσες να την ορίζεις, να την διαβάζεις και να την διαχειρίζεσαι τοπικά μέσα στην συνάρτηση, γιατί η τιμή της δεν επηρεάζει κανένα άλλο σημείο του κώδικα έξω από την συνάρτηση. Αυτό δεν σημαίνει πως είναι λάθος να τη διαβάζεις στην main() και να την περνάς μετά ως όρισμα στη συνάρτηση που τη διαχειρίζεται. Απλώς όσο μεγαλώνει ο κώδικας τόσο περισσότερο βοηθάει να έχεις τις μεταβλητές σου συγκεντρωμένες τοπικά στα σημεία που τις διαχειρίζεσαι. Βοηθάει επίσης στο να μη σου τρώνε stack-space καθ' όλη τη διάρκεια του προγράμματός σου, μιας και όταν ορίζονται τοπικά τότε η μνήμη που καταναλώνουν στο stack απελευθερώνεται στη λήξη της συνάρτησης. Κάτι παραπλήσιο ισχύει και για αυτό που σου είπα και για τους πίνακες. Χρησιμοποιώντας πίνακες χωρίς να χρειάζεται, ουσιαστικά δεσμεύεις μνήμη χωρίς λόγο. Αν τους έχεις ορίσει και στη main() αντί μονάχα μέσα στις συναρτήσεις που χρειάζονται, τότε αυτή η μνήμη δεσμεύεται μόνιμα καθ' όλη τη διάρκεια του προγράμματος. ... Είναι πολύ πιθανό η άποψή μου να είναι λάθος αλλά προσωπικά πιστεύω ότι τα φόρα υπάρχουν για διαφωνίες . ... +1
defacer Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 @defacer. > /* Allocate a new object of the given type */ #define NEW(type) ((type *) Malloc(sizeof(type))) ..... void* Malloc(size_t n) { void* new = malloc(n); if(new==NULL) FATAL_ERROR("Out of memory."); return new; } Πως σου φαίνεται; Αργό; Γρήγορο; Ευέλικτο; Χρήσιμο; Άχρηστο; Λιτό; Την γνώμη σου. Δεν είμαι σίγουρος αν αξίζει το έξτρα macro για να γλυτώνεις ένα sizeof() σε κάθε call site. Όμως δε θα το κεραυνοβολήσω κιόλας. Αν εσένα σου αρέσει και σε βολεύει τότε ΟΚ, αλλά έχε υπόψη ότι δεν υπάρχει πουθενά compiler warning "το έχεις παρακάνει με τις macros φίλε, σβήσε". Εννοώ ότι μπορείς να καταλήξεις σε source το οποίο από την υπερβολική κατάχρηση macros πλέον "δε διαβάζεται" (δες π.χ. source της PHP) ή/και δεν είναι debuggable. Γενικά η άποψή μου γι' αυτά τα πράγματα είναι η λογική των "-100 points" που εφαρμόζεται και στο language design: οποιοδήποτε τέτοιο trick (νέο feature όταν μιλάμε για γλώσσες) ξεκινάει με "-100 points" από τους οποίους πρέπει να φτάσει σε θετικό σύνολο για να δικαιολογήσει την αξία του (με άλλα λόγια, πρέπει να μπορείς να δώσεις έναν η περισσότερους πολύ καλούς λόγους). Σύγκρινέ το με το να ξεκινάς με 0 points, όπου οποιοδήποτε επιχείρημα του στυλ "σε κάποια περίπτωση κάποτε μπορεί να φανεί χρήσιμο" θα ήταν αρκετό για να σε πάει στα θετικά (και ο κώδικας θα γέμιζε macros ή η γλώσσα θα γινόταν ένα άναρχο συνοθύλευμα features). Αυτό λοιπόν που θέλω να πω είναι ότι δεν είμαι σίγουρος αν το συγκεκριμένο macro μπορεί να δικαιολογήσει τους αρχικούς -100. > /* Copy to obj from src, using sizeof(obj). Note that obj is an lvalue but src is a pointer! */ #define COPY(obj, src) (void)memcpy(&(obj), (src), sizeof(obj)) Δεν διαφωνώ, το πνεύμα είναι αυτό που κρίνουμε, κοίτα μία ωραία copy που την χρησιμοποιώ γενικά σε διάφορα project, πόσο γρήγορα και ευκολότερα κάνεις την δουλειά σου. Αυτό εδώ σίγουρα δεν δικαιολογεί τους -100 points. Βασικά αφαιρούνται ακόμα περισσότεροι γιατί βλέποντάς το σε ένα call site δεν είσαι σίγουρος τι ακριβώς συμβαίνει. Φαντάσου να έβλεπες εσύ σε κώδικα άλλου ένα COPY(x,y). Το πρώτο πράγμα που θα σκεφτόσουν είναι WTF is that? Τα WTFs λοιπόν είναι βασικό πράγμα προς αποφυγή στον προγραμματισμό και με τίποτα μα με τίποτα δε θα προτιμούσα να γλυτώσω μερικά keystrokes πληρώνοντας αυτό το τίμημα. Σε καθαρά προσωπικό επίπεδο και χωρίς παρεξήγηση, αυτήν τη macro θα τη χαρακτήριζα όχι μόνο άσχημη αλλά και misguided. Μη ξεχνάς ότι ο κώδικας γράφεται μόνο μια φορά αλλά διαβάζεται και γίνεται debug πολλές. Δεν αξίζει να γλυτώσεις λίγο χρόνο μία φορά και να τον πληρώνεις μετά με δόσεις. Και τέλος να αναφέρω και κάτι που νομίζω ότι είναι γνώριμο σε όλους όσους ασχολούνται πολλά χρόνια: όσο λιγότερη εμπειρία (όχι γνώση!) έχεις, τόσο περισσότερο γράφεις "έξυπνο" κώδικα (στην περίπτωση της C αυτό σημαίνει λιγότερα keystrokes). Και όσο περισσότερη αποκτάς, τόσο περισσότερο καταλαβαίνεις ότι fuck that, ο σκοπός είναι όταν ξαναδιαβάσω τον κώδικα αργότερα που δε θα θυμάμαι τίποτα (ή όταν τον διαβάσει άλλος) να καταλάβω ακριβώς τι κάνει όσο το δυνατόν ευκολότερα και γρηγορότερα. Φυσικά και συμφωνώ στην συνεχόμενη εξέλιξη. Όμως, όταν φτάνει σε σημείο σε πολλά project τα εργαλεία να είναι hardware και vendor dependent, με διάφορα ωραία σε μερικά micro controllers (όπως 3 περιοχές μνήμης, όλες από το 0x0000), τότε το να γυρίσεις πίσω και να μάθεις είναι, νομίζω, όχι και τόσο ωφέλιμο. Γιατί δεν αφορά την ουσία της γλώσσας (ή των νοητικών μοντέλων που θα χρησιμοποιήσει κανείς) αλλά "παραξενιές" του vendor. Οπότε, δεν είναι θέμα να καταλάβει κανείς τι κάνει, αλλά ότι δεν υπάρχει χρόνος για να μαθαίνει κανείς τις παραξενιές της κάθε εταιρείας, του κάθε compiler και του κάθε linker (βέβαια, και εντελώς προσωπικά μιλώντας, αυτό το προωθώ και λίγο... πιστεύω ότι συμβάλει σε x platform κώδικα... όσο μπορεί να γίνει φυσικά, εντάσεις δεκτές ). Δε θα διαφωνήσω. Όντως από ένα σημείο και μετά αν ο γιαλός είναι στραβός πρέπει να αρμενίσεις και συ στραβά γιατί αλλιώς δε θα πας πουθενά. Αλλά νομίζω πως είναι καλό να υπάρχει μια εσωτερική "φυσική αποστροφή" στον καθένα για τέτοιες πρακτικές -- αρκετά μεγάλη που να σε εμποδίζει να βάζεις macros για ψύλλου πήδημα, αλλά όχι τόσο μεγάλη που να σε οδηγεί ακριβώς σ' αυτό που θέλεις να αποφύγεις (το δογματισμό) σε βάρος των πρακτικών διαστάσεων της κατάστασης. Δυστυχώς πολλά άτομα έχουν αυτή τη νοοτροπία. Όταν κάποιος τους λέει κάτι αρνητικό αρχίζουν "όποιος δεν θέλει ας μην απαντήσει" "το φόρουμ πάει από το κακό στο χειρότερο" "το παίζεις μάγκας" και άλλα παρόμοια. Όπως τα λες. Γενικά είναι δύσκολο στην ανθρώπινη φύση να πάρει κάτι at face value αντί να το πάρει προσωπικά, αλλά να ποιά είναι η εναλλακτική: να πιστέψεις ότι όποιος σου φέρνει αντίρρηση το κάνει γιατί θέλει να το παίξει daddy ή γιατί "το δικό του είναι καλύτερο" -- και στις 2 περιπτώσεις αποδεικνύεται τελικά πως ούτε λίγο ούτε πολύ δε ζητάς κριτική αλλά αυτοεπιβεβαίωση γιατί η τελευταία είναι πιο νόστιμη. Μόνο που σε αντίθεση με την κριτική δεν είναι απλά άχρηστη αλλά ακόμα και επιζήμια. Εδώ ζητώ προκαταβολικά συγγνώμη γιατί μπορεί να φανεί σαν αυτοπροβολή κάποιου είδους, αλλά έχω ένα πολύ πρόσφατο και κατάλληλο παράδειγμα όπου κατάφερα νομίζω να επιδείξω την ιδανική αντιμετώπιση το οποίο δίνω σε link παρακάτω (διαβάστε τα comments της απάντησης). Και το παραθέτω με τη λογική putting my money where my mouth is. Απαραίτητο για την κατανόηση context: η ερώτηση αναφέρεται σε feature της C++11 και είναι εντελώς "language lawyer" κατηγορία (δηλαδή σκάψε στο spec να δεις τι προβλέπει για τέτοιες περιπτώσεις). Το βρίσκω πολύ χρήσιμο να απαντάω σε τέτοιες ερωτήσεις που αφορούν τη C++ γιατί δεν έχω πλέον τη δυνατότητα να προγραμματίζω συχνά σε C++ και δε θέλω να σκουριάσω (όσο γίνεται). Ο Alf που αρχικά μου βάζει με συνοπτικές διαδικασίες το -1 έχει περίπου 10 απιθανικομμύρια τόνους παραπάνω εμπειρία απο μένα στη language lawyer προσέγγιση της C++, και παρόλα αυτά τυχαίνει στη συγκεκριμένη περίπτωση να κάνει λάθος. Ορίστε λοιπόν πώς νομίζω ότι πρέπει να αντιμετωπίζεται η κριτική (πόσο μάλλον όταν έχει και δίκιο!): http://stackoverflow.com/questions/11164354/does-the-standard-behavior-for-deleters-differ-between-shared-ptr-and-unique-ptr/11164463#comment14643170_11164463 (πατήστε "show more comments" και πάρτε τα με χρονολογική σειρά) (Eπίσης προσέξτε ότι ο Alf παρόλο που μπήκε δυναμικά δε συνέχισε με "STFU u n00b" αλλά μάλιστα μπήκε στον κόπο να ελέγξει και μόνος του σε 2 διαφορετικούς compilers παρόλο που πίστευε ακράδαντα πως έχει δίκιο. Νομίζω πως αυτό είναι ενδεικτικό της αξίας τόσο του Alf σα χαρακτήρα όσο και της απάντησης χωρίς φωνές αλλά με λογικά επιχειρήματα εκ μέρους μου).
migf1 Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 ... Ορίστε λοιπόν πώς νομίζω ότι πρέπει να αντιμετωπίζεται η κριτική (πόσο μάλλον όταν έχει και δίκιο!): http://stackoverflow...643170_11164463 (πατήστε "show more comments" και πάρτε τα με χρονολογική σειρά) ... [/offtopic] Το θέμα των εντάσεων είναι γενικότερο σε όλα τα φόρα, ντόπια και ξένα. Μια βασική αιτία κατά τη δική μου άποψη είναι η αμφισβήτηση (φανερή ή ενδόμυχη) του ενός συνομιλητή για την αρμοδιότητα αλλά και τις προθέσεις του άλλου συνομιλητή. Συνήθως οι διαφωνίες ξεκινούν ήπια και στη συνέχεια κλιμακώνονται (συνήθως όσο πιο τεχνικές γίνονται). Οπότε συχνότατα προκύπτει το πρόβλημα του ποιος είναι κατάλληλος να κρίνει αν η κριτική έχει δίκιο ή όχι. Στις περισσότερες περιπτώσεις αρκούν 1-2 τεκμηριωμένες δημοσιεύσεις για να βγουν χρήσιμα συμπεράσματα εκατέρωθεν. Συχνά όμως δεν αρκεί, κι εκεί αρχίζουν τα... όργανα. Προσωπικά δεν το θεωρώ καθόλου απαραίτητο να συμφωνήσουν όλοι σε κάτι, ούτε καν 2 (ένας από κάθε μεριά). Αυτό που θεωρώ το πλέον σημαντικό σε οποιονδήποτε διάλογο είναι ο σεβασμός προς τον συνομιλητή και η εκ προοιμίου αντιμετώπισή του έως τουλάχιστον "ισοδύναμο" σε γνώσεις, εμπειρία, ή οτιδήποτε άλλο σχετικό με το θέμα γύρω από το οποίο περιστρέφεται μια συζήτηση, προφανώς "unless otherwise stated". Όσους δηλαδή ξεκαθαρίζουν από την αρχή πως δεν έχουν πολλές γνώσεις στο αντικείμενο, ή και καθόλου. Και σε αυτή την περίπτωση οι πιο έμπειροι οφείλουν (πάντα κατά την προσωπική μου άποψη) να αντιμετωπίζουν τους λιγότερο έμπειρους επίσης με σεβασμό και να προσπαθούν να τους βοηθήσουν, διότι κανείς δεν γεννήθηκε παντογνώστης. Μια άλλη αιτία (προφανώς επίσης κατά τη γνώμη μου) είναι ο απόλυτος και κάθετος τρόπος να παρουσιάζει κάποιος έμπειρος τη θέση του, χωρίς να αφήνει παράθυρο πιθανότητας ενδεχόμενου σφάλματος ή έστω διαφορετικής θεμιτής προσέγγισης πέρα από τη δικιά του, όταν ακόμα η συζήτηση βρίσκεται στο ήπιο στάδιο (αυτό το τελευταίο φίλε @defacer είναι και δικό σου χαρακτηριστικό... συμπεριέλαβα αυτή την παρένθεση με αφορμή το παραπομπή που μας έκανες στο SO με σένα πρωταγωνιστή έως παράδειγμα υγιούς διαλόγου). Όταν συμβαίνει το παραπάνω και μπει στη συζήτηση κάποιος άλλος έμπειρος (ή μη) με διαφορετική & τεκμηριωμένη προσέγγιση από την απόλυτα παρουσιασμένη του προηγούμενου έμπειρου, τότε αν ο προηγούμενος έμπειρος επιμείνει στην απόλυτη αρχική του θέση (σε αρκετά μεγάλο βαθμό ενστικτώδης αντίδραση) αρχίζει κι επιδεινώνεται το πράγμα γιατί όσο προχωράει η συζήτηση αρχίζουν να μπαίνουν πλέον στο παιχνίδι και θέματα εγωισμού, επίδειξης, αυτοπροβολής, ματαιοδοξίας, κλπ που συχνά οδηγεί σε "μουλάρωμα" κι απο εκεί και πέρα χάνεται η μπάλα και η συνέχεια της συζήτησης συνήθως αναλώνεται σε ανούσιες αντιπαραθέσεις που κυρίως περιστρέφονται γύρω από θέματα του στυλ "εκεί έγραψες αυτό", "όχι δεν έγραψα αυτό, έγραψα αυτό", "ίσως αυτό να εννοούσες αλλά άλλο έγραψες" καθώς και λοιπά διαλεκτικά τρικ προκειμένου να μη παραδεχτεί κάποιος ούτε καν ότι "μπορεί και να έκανα λάθος"¨. Σε ότι αφορά τη δική συμμετοχή πάντως στο φόρουμ συνοψίζεται εν πολλοίς σε μια παροιμία: το τερπνό (κουβεντούλα, χαλαρή ή όχι) μετά του ωφελίμου (ανταλλαγή πληροφοριών). Κατά καιρούς παρασύρομαι κι εγώ σε διάφορες ανούσιες κόντρες, μιας και σαν παιδί κι εγώ έχω τα ελαττώματά μου. [/offtopic]
Timonkaipumpa Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 Δυστυχώς πολλά άτομα έχουν αυτή τη νοοτροπία. Όταν κάποιος τους λέει κάτι αρνητικό αρχίζουν "όποιος δεν θέλει ας μην απαντήσει" "το φόρουμ πάει από το κακό στο χειρότερο" "το παίζεις μάγκας" και άλλα παρόμοια. Είναι πολύ πιθανό η άποψή μου να είναι λάθος αλλά προσωπικά πιστεύω ότι τα φόρα υπάρχουν για διαφωνίες . Αν σε ένα thread όλοι συμφωνούμε τότε έκλεισε το thread. Η διαφωνία προωθεί τον διάλογο. Υπάρχουν πολλά άτομα με τρελές γνώσεις (όπως στο παρόν υποφόρουμ ο DirectX, ο defacer και πολλά άλλα παιδιά) και μέσα από τα επιχειρήματά τους γίνομαι και εγώ καλύτερος. Αλλιώς θα μιλούσα στο καθρέφτη που θα συμφωνούσε και θα μου έδινε δίκιο πάντα Δεν ανέφερες και εμένα μέσα στα άτομα; Τελικά αυτό το forum πάει από το κακό στο χειρότερο.
migf1 Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 @defacer: Θεωρώντας πως έχουμε και οι 2 την ικανότητα να διαφωνήσουμε πολιτισμένα και εποικοδομητικά, η ένστασή μου στην παράθεση που ακολουθεί είναι το πως αποφασίζει κανείς τι είναι "ψύλλου πήδημα" και τι όχι στη C (είναι σημαντικό ότι μιλάμε για C, για αυτό και του δίνω έμφαση). ... Αλλά νομίζω πως είναι καλό να υπάρχει μια εσωτερική "φυσική αποστροφή" στον καθένα για τέτοιες πρακτικές -- αρκετά μεγάλη που να σε εμποδίζει να βάζεις macros για ψύλλου πήδημα, αλλά όχι τόσο μεγάλη που να σε οδηγεί ακριβώς σ' αυτό που θέλεις να αποφύγεις (το δογματισμό) σε βάρος των πρακτικών διαστάσεων της κατάστασης. ... Θα φέρω ένα παράδειγμα, με σημείο αναφοράς τα generic text mappings στα Windows (TCHAR functions) όπου για παράδειγμα όλες οι string συναρτήσεις του c-runtime γίνονται mapped σε generic που ξεκινούν με το πρόθεμα _t και βασικά είναι macro mappings στις κανονικές συναρτήσεις. Π.χ. για την strlen: http://msdn.microsof...v=vs.80%29.aspx το text mapping της είναι το _tcslen() Ας υποθέσουμε τώρα ότι θέλω να χρησιμοποιήσω στο πρόγραμμά μου 6-7 τέτοιες συναρτήσεις, οι οποίες θα εμφανίζονται σε διάφορα μέρη και files του κώδικα. Επειδή είμαι καινούριος σε αυτή την πλατφόρμα, δυσκολεύομαι να αποστηθίσω τα ονόματα των mappings οπότε αποφασίζω να τις μαζέψω όλες σε ένα .h και να τους ορίσω δικά μου έξτρα macro wrappers με πιο οικεία για μένα ονόματα. Π.χ. > #define genSTRLEN _tcslen ... Στη θεωρία το να φτιάχνεις macro-wrappers απλώς για να μετονομάσεις υπάρχουσες συναρτήσεις μπορεί να θεωρηθεί "ψύλλου πήδημα", στο παραπάνω όμως πρακτικό παράδειγμα είναι όντως "ψύλλου πήδημα"; Για κάποιους μπορεί να είναι, για άλλους όμως μπορεί και να μη είναι. Το παράδειγμα αυτό δεν είναι τυχαίο, το έχω χρησιμοποιήσει προσωπικά στην πρόσφατη (επιφανειακή προφανώς) ενασχόλησή μου με τα Windows μετά από μακρόχρονη αποχή... το έχω φυσικά χρησιμοποιήσει και πολλές ακόμα φορές κατά το παρελθόν σε άλλο context. Θεώρησα λοιπόν ότι από το να κάθομαι κάθε φορά που θέλω να χρησιμοποιήσω την κάθε συνάρτηση να ανοίγω help/browsers και να ψάχνω που είναι και πως τη λένε τη συνάρτηση που θέλω να χρησιμοποιήσω, γίνομαι πολύ πιο παραγωγικός ραπάροντάς τες μια μόνο φορά με οικεία ονόματα, που τα θυμάμαι απέξω κάθε φορά που τα χρειάζομαι. Επίσης δεν επιβαρύνω σε τίποτα το run-time κι επίσης δεν χάνω τίποτα από το type-checking του compiler. Γράφω αυτό το παράδειγμα με αφορμή ΚΑΙ την πρόσφατη δημοσίευση του φίλου bokarinho με το COPY macro, που όλοι λίγο-πολύ του είπαμε πως δεν έχει νόημα να ραπάρει κάτι που του διατίθεται έτοιμο. Προσωπικά όμως ήμουν πολύ προσεκτικός όταν του έγραφα να το αποφεύγει, δίνοντας έμφαση στο ότι δεν έχει νόημα στο συγκεκριμένο παράδειγμα, και όχι ως γενική ντιρεκτίβα να το αποφεύγει παντού και πάντα. Έχω επίσης διαφωνία και στην εξής διατύπωσή σου... ... Εννοώ ότι μπορείς να καταλήξεις σε source το οποίο από την υπερβολική κατάχρηση macros πλέον "δε διαβάζεται" (δες π.χ. source της PHP) ή/και δεν είναι debuggable. ... Στο πρώτο μέρος της πρότασης έχω διαφωνία, διότι αδυνατώ να κατανοήσω γιατί πλήττει το readability η χρήση macros ενώ για παράδειγμα δεν το πλήττει η χρήση συναρτήσεων (από ότι έχω προσέξει τις προτείνεις παντού & πάντα αντί για αντίστοιχα macros). Προφανώς αναφέρομαι σε custom συναρτήσεις και όχι στις στάνταρ (τα macros είναι έτσι κι αλλιώς custom). Αλλά ακόμα και χωρίς αναφορά στις συναρτήσεις, η σωστή χρήση των macros δεν μειώνει το readability, το αυξάνει. Μόνο η κακή χρήση των macros μπορεί να χαλάσει το readability). Το κλασσικό παράδειγμα εδώ είναι η χρήση του για υπολογισμό boolean συνθηκών, που είναι συχνότατη στη μεγάλη πλειοψηφία των προγραμμάτων. Τώρα σε ότι αφορά το debugging, επειδή δεν είμαι σίγουρος σε τι ακριβώς αναφέρεσαι, θα περιμένω να το διευκρινήσεις πρώτα πριν τοποθετηθώ εκ νέου.
defacer Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 Γράφω αυτό το παράδειγμα με αφορμή ΚΑΙ την πρόσφατη δημοσίευση του φίλου bokarinho με το COPY macro, που όλοι λίγο-πολύ του είπαμε πως δεν έχει νόημα να ραπάρει κάτι που του διατίθεται έτοιμο. http://www.youtube.com/watch?v=1_Ti5qeFkOs Τώρα για τα υπόλοιπα... Θεώρησα λοιπόν ότι από το να κάθομαι κάθε φορά που θέλω να χρησιμοποιήσω την κάθε συνάρτηση να ανοίγω help/browsers και να ψάχνω που είναι και πως τη λένε τη συνάρτηση που θέλω να χρησιμοποιήσω, γίνομαι πολύ πιο παραγωγικός ραπάροντάς τες μια μόνο φορά με οικεία ονόματα, που τα θυμάμαι απέξω κάθε φορά που τα χρειάζομαι. Επίσης δεν επιβαρύνω σε τίποτα το run-time κι επίσης δεν χάνω τίποτα από το type-checking του compiler. Στη συγκεκριμένη περίπτωση έχω έναν και μοναδικό λόγο να μην το κάνεις αυτό: συνέπεια. Για σένα προσωπικά (όπως και για τον καθένα) είναι εύλογα ευκολότερο να θυμάσαι τα "δικά σου" ονόματα για τις συναρτήσεις. Το θέμα είναι πως εφόσον τα δικά σου ονόματα είναι διαφορετικά από τα στάνταρ ονόματα, καλώς ή κακώς δυσχαιρένεις την επικοινωνία με άλλους developers όταν το θέμα προς συζήτησης είναι ο κώδικας που έγραψες. Ακριβώς όπως όταν ας πούμε λύνοντας ένα πρόβλημα φυσικής μπορείς να ονομάσεις τη μάζα f και την ταχύτητα s -- δεν αλλάζει τίποτα, αλλά για να διευκολύνεις ένα άτομο μόνο (εσένα) δυσκολεύεις όλο τον υπόλοιπο πλανήτη όταν και αν αυτός ασχοληθεί με τη δουλειά σου. Και το χειρότερο είναι πως αν χρειαστείς τη συνδρομή κάποιου άλλου τότε δυσκολεύοντας αυτόν κατάφερες έμμεσα να δυσκολέψεις ακόμα και τον εαυτό σου. Αυτά σε καθαρά θεωρητικό επίπεδο. Αν το δούμε λίγο πιο συνοπτικά/πρακτικά, νομίζω πως δε χρειάζεται συζήτηση το γεγονός ότι αν το έκανες αυτό σε κοινό code base οι υπόλοιποι συνάδελφοι θα σε σταύρωναν και θα είχαν δίκιο. Συνοψίζοντας λοιπόν, εγώ δε θα το έκανα ποτέ όχι μόνο για το θεωρητικό λόγο αλλά και για το ότι πιστεύω πως αφήνοντας στον εαυτό μου την "άπλα" να το κάνει, έστω και μία φορά, έστω και μόνο για τα δικά μου μάτια, απλά με εκπαιδεύω να αποκτήσω μια κακή συνήθεια. Οπότε δε θα πάρω. Καλύτερα να με εκπαιδεύσω να αποκτήσω μια καλή συνήθεια ακόμα κι αν αυτό έχει πιο απότομο learning curve. Τώρα από τα παραπάνω πιστεύω πως μπορεί ο καθένας να εξάγει πλήθος επιπλέον συμπερασμάτων για το πού και πώς θα σου προκαλέσει "ζημιά" μια τέτοια πρακτική, οπότε δε θεωρώ σκόπιμο να κάτσω να τα απαριθμήσω ένα ένα. Βεβαίως το παραπάνω δεν έχει να κάνει αποκλειστικά με τις macros οι οποίες καλώς ή κακώς είναι par for the course όταν μιλάμε για το Win32 API (για ιστορικούς λόγους αν μη τι άλλο). Αν μιλούσαμε για codebase που αναπτύσσεται από την αρχή θα είχα και τις προηγουμένως αναφερθείσες ενστάσεις περι macros. Στο πρώτο μέρος της πρότασης έχω διαφωνία, διότι αδυνατώ να κατανοήσω γιατί πλήττει το readability η χρήση macros ενώ για παράδειγμα δεν το πλήττει η χρήση συναρτήσεων (από ότι έχω προσέξει τις προτείνεις παντού & πάντα αντί για αντίστοιχα macros). Προφανώς αναφέρομαι σε custom συναρτήσεις και όχι στις στάνταρ (τα macros είναι έτσι κι αλλιώς custom). Αλλά ακόμα και χωρίς αναφορά στις συναρτήσεις, η σωστή χρήση των macros δεν μειώνει το readability, το αυξάνει. Μόνο η κακή χρήση των macros μπορεί να χαλάσει το readability). Υπάρχουν 2 διαστάσεις του θέματος οι οποίες δεν πρέπει να συγχέονται: α) χρήση macros αντί για πράγματα που μπαίνουν στο symbol table β) "κρύψιμο" κώδικα πίσω από κάποιο construct (που μπορεί να είναι και function εκτός από macro) Στην παραπάνω τοποθέτησή σου μπερδεύεις αυτές τις 2 διαστάσεις (βασικά τις ανακατεύεις σα να ήταν μία και αδιαίρετη). Το αναφέρω εδώ στην αρχή για να μη χρειάζεται να το λέω σε κάθε point παρακάτω. Στην πρώτη σου ερώτηση λοιπόν η απάντηση είναι ότι και η χρήση συναρτήσεων με το ίδιο signature θα ήταν το ίδιο άσχημη για το readability. Η "γενική" αντίθεσή μου στη χρήση macros έχει να κάνει με τη διάσταση (α) παραπάνω, ενώ η "ειδική" περι readability με τη διάσταση (β). Στο περι αύξησης readability η απάντηση είναι ότι δεν υπάρχει μπούσουλας. Σε μια high-level function που είναι 50 γραμμές το να κρύψεις ένα "σύνθετο" allocation αυξάνει το readability (γιατί έτσι δε σε αποσπά στην ανάγνωση ο μηχανισμός του πώς γίνεται κάτι όταν εσύ θέλεις να καταλάβεις τι είναι αυτό που γίνεται). Σε μια low-level function που είναι 5 γραμμές το ίδιο πράγμα μειώνει το readability (γιατί πρέπει να πας αλλού να δεις ακριβώς την υλοποίηση). Όλα αυτά ισχύουν και για macros όπως και για functions. Ελπίζω να μη χρειάζεται να πω ότι κάθε κανόνας έχει και εξαιρέσεις που τον επιβεβαιώνουν πάντως. Τώρα σε ότι αφορά το debugging, επειδή δεν είμαι σίγουρος σε τι ακριβώς αναφέρεσαι, θα περιμένω να το διευκρινήσεις πρώτα πριν τοποθετηθώ εκ νέου. Εννοώ τη διάσταση (α) παραπάνω. Δεν μπαίνουν πράγματα στο symbol table, οπότε δεν έχεις κανένα τρόπο να αναφερθείς σ' αυτά μέσα στο debugger. Έβαλες 5 γραμμές logic σε μια macro και ανακάλυψες ότι κάπου εκει μέσα υπάρχει bug? Πακέτο -- γράφτο τώρα σαν function γιατί αλλιώς debugging γιοκ.
Re4cTiV3 Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 Εγω αυτο που κραταω ειναι οτι πρεπει να τα μαθεις ολα και αναλογα την χρηση που θες να κανεις να χρησιμοποιεις το αναλογο.. Αυτο καταλαβα μεχρι στιγμης Αποστολή από το GT-I9000 με τη χρήση Insomnia App
defacer Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 Εγω αυτο που κραταω ειναι οτι πρεπει να τα μαθεις ολα και αναλογα την χρηση που θες να κανεις να χρησιμοποιεις το αναλογο.. Αυτο καταλαβα μεχρι στιγμης Φυσικά, αλλά από την άλλη αυτό είναι τόσο γενικό που από μόνο του δεν είναι καθόλου χρήσιμο σε κάποιον που θέλει να μάθει πώς αποφασίζεις ποιό ακριβώς είναι το ανάλογο. Γι' αυτό και όταν παρουσιάζονται ευκαιρίες καθόμαστε και αραδιάζουμε επιχειρήματα -- για να μπορεί κάποιος που είναι λιγότερο έμπειρος να καταλάβει πώς ("πρέπει") να σκέφτεται μέσα από χειροπιαστά παραδείγματα. That's how humans learn stuff. Και επειδή πολλές φορές δε γίνεται ούτε καν να αντιληφθεί ο λιγότερο έμπειρος τη σημασία των επιχειρημάτων δημιουργήθηκαν οι μπούσουλες: κάντο έτσι που είναι "το σωστό" και κάθε όποτε φτάνεις σε νέο επίπεδο κατανόησης βάλε στο τραπέζι το μπούσουλα και τα καινούρια πράγματα που έμαθες για να καταλάβεις γιατί κάνεις αυτό που κάνεις.
migf1 Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 http://www.youtube.c...h?v=1_Ti5qeFkOs Τώρα για τα υπόλοιπα... Στη συγκεκριμένη περίπτωση έχω έναν και μοναδικό λόγο να μην το κάνεις αυτό: συνέπεια. Για σένα προσωπικά (όπως και για τον καθένα) είναι εύλογα ευκολότερο να θυμάσαι τα "δικά σου" ονόματα για τις συναρτήσεις. Το θέμα είναι πως εφόσον τα δικά σου ονόματα είναι διαφορετικά από τα στάνταρ ονόματα, καλώς ή κακώς δυσχαιρένεις την επικοινωνία με άλλους developers όταν το θέμα προς συζήτησης είναι ο κώδικας που έγραψες. Ακριβώς όπως όταν ας πούμε λύνοντας ένα πρόβλημα φυσικής μπορείς να ονομάσεις τη μάζα f και την ταχύτητα s -- δεν αλλάζει τίποτα, αλλά για να διευκολύνεις ένα άτομο μόνο (εσένα) δυσκολεύεις όλο τον υπόλοιπο πλανήτη όταν και αν αυτός ασχοληθεί με τη δουλειά σου. Και το χειρότερο είναι πως αν χρειαστείς τη συνδρομή κάποιου άλλου τότε δυσκολεύοντας αυτόν κατάφερες έμμεσα να δυσκολέψεις ακόμα και τον εαυτό σου. Αυτά σε καθαρά θεωρητικό επίπεδο. Αν το δούμε λίγο πιο συνοπτικά/πρακτικά, νομίζω πως δε χρειάζεται συζήτηση το γεγονός ότι αν το έκανες αυτό σε κοινό code base οι υπόλοιποι συνάδελφοι θα σε σταύρωναν και θα είχαν δίκιο. Συνοψίζοντας λοιπόν, εγώ δε θα το έκανα ποτέ όχι μόνο για το θεωρητικό λόγο αλλά και για το ότι πιστεύω πως αφήνοντας στον εαυτό μου την "άπλα" να το κάνει, έστω και μία φορά, έστω και μόνο για τα δικά μου μάτια, απλά με εκπαιδεύω να αποκτήσω μια κακή συνήθεια. Οπότε δε θα πάρω. Καλύτερα να με εκπαιδεύσω να αποκτήσω μια καλή συνήθεια ακόμα κι αν αυτό έχει πιο απότομο learning curve. Τώρα από τα παραπάνω πιστεύω πως μπορεί ο καθένας να εξάγει πλήθος επιπλέον συμπερασμάτων για το πού και πώς θα σου προκαλέσει "ζημιά" μια τέτοια πρακτική, οπότε δε θεωρώ σκόπιμο να κάτσω να τα απαριθμήσω ένα ένα. Δεν θα διαφωνήσω ολικώς για το argument περί κοινού code-base, πλην όμως ότι το εξειδίκευσες σε μια συγκεκριμένη περίπτωση. Ακόμα κι έτσι όμως (την δέχομαι γιατί εκφράζει μεγάλο μέρος του οργανωμένου software development) στο συγκεκριμένο παράδειγμα που έδωσα ο wrapper δεν ορίζει ένα άσχετο όνομα, ορίζει το όνομα που αντιστοιχεί στην στάνταρ βιβλιοθήκη της γλώσσας. Ως εκ τούτου είναι αδύνατον να μπερδέψει τον οποιονδήποτε δει τον κώδικα. Και όχι μόνο αυτό, αλλά βοηθάει κιόλας το readability του κώδικα, είτε τον διαβάσει κάποιος εξοικειωμένος είτε κάποιος μη εξοικειωμένος με τα text mappings των Windows, αφού είναι αδύνατον να μην καταλάβει κάποιος ότι μια υπογραφή ονοματισμένη ως genSTRLEN() το ελάχιστο που κάνει είναι να μετράει το μήκος ενός string (edit: και μάλιστα του δίνει και hint να κοιτάξει γιατί δεν χρησιμοποιείται απευθείας η στάνταρ strlen). Προσωπικά το θεωρώ αν όχι περισσότερο τουλάχιστον το ίδιο κατανοητό και μακράν λιγότερο επιρρεπές σε σφάλματα από μια παραπλήσια & ευρέως χρησιμοποιούμενη τεχνική σε κοινό code-base και κυρίως επαγγελματικά, που χρησιμοποιεί το εξής... > typedef struct Data { ... }Data, *DataPtr, *DataArray; Όλα αυτά σε ότι αφορά το readability πάντα, που είναι και το σημείο αναφοράς μας σε αυτή τη νέα συζήτηση (βέβαια, το παραπάνω typedef προσωπικά το θεωρώ αδικαιολόγητα επιρρεπές σε σφάλματα, αλλά δεν καθορίζω εγώ το τι έχει επικρατήσει και τι όχι... έχει κι αυτό τα θετικά του, άσχετα αν εγώ τα αξιολογώ ως λιγότερα από τα αρνητικά του). Βεβαίως το παραπάνω δεν έχει να κάνει αποκλειστικά με τις macros οι οποίες καλώς ή κακώς είναι par for the course όταν μιλάμε για το Win32 API (για ιστορικούς λόγους αν μη τι άλλο). Αν μιλούσαμε για codebase που αναπτύσσεται από την αρχή θα είχα και τις προηγουμένως αναφερθείσες ενστάσεις περι macros. Υπάρχουν 2 διαστάσεις του θέματος οι οποίες δεν πρέπει να συγχέονται: α) χρήση macros αντί για πράγματα που μπαίνουν στο symbol table β) "κρύψιμο" κώδικα πίσω από κάποιο construct (που μπορεί να είναι και function εκτός από macro) Στην παραπάνω τοποθέτησή σου μπερδεύεις αυτές τις 2 διαστάσεις (βασικά τις ανακατεύεις σα να ήταν μία και αδιαίρετη). Το αναφέρω εδώ στην αρχή για να μη χρειάζεται να το λέω σε κάθε point παρακάτω. Όμως δεν τις ανακατεύω τυχαία ή από άγνοια ή χωρίς λόγο... τις βάζω κάτω από το συγκεκριμένο πλαίσιο του readability, στο οποίο είναι άμεσα συγκρίσιμες και για το οποίο εξέφρασα την ένστασή μου. Στην πρώτη σου ερώτηση λοιπόν η απάντηση είναι ότι και η χρήση συναρτήσεων με το ίδιο signature θα ήταν το ίδιο άσχημη για το readability. Η "γενική" αντίθεσή μου στη χρήση macros έχει να κάνει με τη διάσταση (α) παραπάνω, ενώ η "ειδική" περι readability με τη διάσταση (β). Στο περι αύξησης readability η απάντηση είναι ότι δεν υπάρχει μπούσουλας. Σε μια high-level function που είναι 50 γραμμές το να κρύψεις ένα "σύνθετο" allocation αυξάνει το readability (γιατί έτσι δε σε αποσπά στην ανάγνωση ο μηχανισμός του πώς γίνεται κάτι όταν εσύ θέλεις να καταλάβεις τι είναι αυτό που γίνεται). Σε μια low-level function που είναι 5 γραμμές το ίδιο πράγμα μειώνει το readability (γιατί πρέπει να πας αλλού να δεις ακριβώς την υλοποίηση). Όλα αυτά ισχύουν και για macros όπως και για functions. Ελπίζω να μη χρειάζεται να πω ότι κάθε κανόνας έχει και εξαιρέσεις που τον επιβεβαιώνουν πάντως. Η προσωπική μου εμπειρία υποδεικνύει πως το βασικότερο ρόλο στο readabillity του κώδικα (και με διαφορά) τον παίζει η οργάνωση του κώδικα και οι ονομασίες των identifiers (με την ευρύτερη έννοια, μεταβλητές, συναρτήσεις, macros, κλπ, κλπ). Αν αυτά τα 2 είναι μελετημένα είναι τόσο μεγάλη η συμβολή τους στο readabilty που πολύ συχνά απαλείφουν ακόμα και την ανάγκη συγγραφής σχολίων. Χωρίς να αποκλείουμε τις εξαιρέσεις, το παραπάνω εξασφαλίζει readability ανεξαρτήτως μεγέθους του κώδικα, πλήθους γραμμών συναρτήσεων ή level of abstraction. Εννοώ τη διάσταση (α) παραπάνω. Δεν μπαίνουν πράγματα στο symbol table, οπότε δεν έχεις κανένα τρόπο να αναφερθείς σ' αυτά μέσα στο debugger. Έβαλες 5 γραμμές logic σε μια macro και ανακάλυψες ότι κάπου εκει μέσα υπάρχει bug? Πακέτο -- γράφτο τώρα σαν function γιατί αλλιώς debugging γιοκ. Εδώ θα συμφωνήσουμε, διότι εξ όσων γνωρίζω όντως ισχύει ως κανόνας (ήθελα να βεβαιωθώ πως εννοούσαμε το ίδιο πράγμα). Πρέπει όμως να συμπληρώσω πως τουλάχιστον στον gdb υπάρχουν πολλές διευκολύνσεις που αφορούν το macro debugging εδώ και πολύ καιρό (χρόνια): http://www.delorie.c...gdb/gdb_70.html Δυστυχώς όμως όχι μόνο o gcc δεν αποτελεί τον κανόνα σε όλες τις πλατφόρμες (παρόλο που είναι ο πιο ported compiler) αλλά και οι συγκεκριμένες διευκολύνσεις δεν παρέχονται σε όλα τα ports του (για παράδειγμα, στα Windows το mingw δεν τα υποστηρίζει, ενώ το cygwin τα υποστηρίζει, όπως τα υποστηρίζει και το djgpp που είναι για DOS). Ακόμα κι έτσι πάντως, δεν συγκρίνεται με την ευκολία που παρέχει μια συνάρτηση στο debugging. Εγω αυτο που κραταω ειναι οτι πρεπει να τα μαθεις ολα και αναλογα την χρηση που θες να κανεις να χρησιμοποιεις το αναλογο.. Αυτο καταλαβα μεχρι στιγμης Αποστολή από το GT-I9000 με τη χρήση Insomnia App Εντάξει, όλα είναι αδύνατον να τα μάθει κανείς (αλλά ποτέ δεν βλάπτει να ψάχνεται όσα περισσότερο μπορεί). Ακόμα και όλα να τα ξέρει (ή έστω να ξέρει πάρα πολλά ή έστω να έχει το feeling και να ξέρει που να τα αναζητήσει για να τα φρεσκάρει) δεν είναι καθόλου σπάνιο οι πιεστικές προθεσμίες σε επαγγελματικό περιβάλλον να μη του επιτρέπουν να το ψάξει όσο θα ήθελε. Σε γενικές γραμμές, οι "μπούσουλες" δεν είναι κακό πράγμα γιατί αν είναι καλοί μπούσουλες τότε κατά κανόνα σου επιτρέπουν να φτάσεις πιο γρήγορα σε ένα αποτέλεσμα που μπορεί να μην είναι βέλτιστο αλλά δεν θα είναι και χείριστο. Από εκεί και πέρα, όταν βρεθεί χρόνος (και χρήμα) κάνεις revisit τον κώδικα για βελτιώσεις. Αλλιώς πας παρακάτω, στην προθεσμία του επόμενου πρότζεκτ και εύχεσαι η εμπειρία σου να σε έχει βοηθήσει να μη σου έχει ξεφύγει καμιά χοντρή πατάτα στο προηγούμενο project και σκάσει πριν πληρωθείς .
bokarinho Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 Πώς το forum πηγαίνει από το κακό στο χειρότερο επειδή επισήμαναν το λάθος σου κάποιοι... δεν μπορώ να καταλάβω. Δηλαδή.. έπρεπε να κάνουν όλοι τεμενάδες επειδή μοιράστηκες με εμάς τους ταπεινούς τις τόσο σπουδαίες γνώσεις σου, για να πηγαίνει το forum προς το καλύτερο; Ό,τι να 'ναι. Αρχικά δεν έχω σπουδαίες γνώσεις, ούτε ποτέ σε αυτό το φόρουμ θέλησα να δείξω κάτι τέτοιο. Τα ότι να ναι δεν θα τα λες σε εμένα, δεν με ξέρεις για αυτό κόψε το, δεν σου έδωσα ποτέ το δικαίωμα να μου απαντάς με αυτό τον τρόπο. Για αυτό τα ότι να ναι αλλού, όχι σε εμένα. Επίσης να σου τονίσω πως ουδέποτε η ειρωνεία δεν αποτέλεσε ορθό τρόπο αντιμετώπισης, για αυτό με εσένα δεν θέλω να έχω καμία κουβέντα. Με ρώτησες γιατί είπα ότι το φόρουμ πάει από το κακό στο χειρότερο; Τι μπορεί να εννοούσα; Τέλος, δεν νομίζω να είναι λάθος αυτό που έβαλα στον κώδικα, αλλά δεν πειράζει σε αφήνω στην πλάνη σου, ουδέποτε δε είπα ότι είναι for generic use, είπα ότι είναι παράδειγμα. Δυστυχώς πολλά άτομα έχουν αυτή τη νοοτροπία. Όταν κάποιος τους λέει κάτι αρνητικό αρχίζουν "όποιος δεν θέλει ας μην απαντήσει" "το φόρουμ πάει από το κακό στο χειρότερο" "το παίζεις μάγκας" και άλλα παρόμοια. Είναι πολύ πιθανό η άποψή μου να είναι λάθος αλλά προσωπικά πιστεύω ότι τα φόρα υπάρχουν για διαφωνίες . Αν σε ένα thread όλοι συμφωνούμε τότε έκλεισε το thread. Η διαφωνία προωθεί τον διάλογο. Υπάρχουν πολλά άτομα με τρελές γνώσεις (όπως στο παρόν υποφόρουμ ο DirectX, ο defacer και πολλά άλλα παιδιά) και μέσα από τα επιχειρήματά τους γίνομαι και εγώ καλύτερος. Αλλιώς θα μιλούσα στο καθρέφτη που θα συμφωνούσε και θα μου έδινε δίκιο πάντα Συμφωνώ απόλυτα, η διαφωνία προωθεί τον διάλογο και εδώ είμαστε για διάλογο, από την άλλη επειδή έχω κάποιον καιρό σε αυτό το φόρουμ, το παρακολουθώ αρκετά, μπορεί βέβαια να μην γράφω όπως κάποτε παρατηρώ ότι η αρετή της ειρωνείας έχει μεγαλουργήσει στις μέρες μας, δυστυχώς εις βάρους αυτού του φόρουμ που κάποιοι επειδή δεν ξέρω μάλλον πιστεύουν πως τα ξέρουν όλα, ειρωνεύονται και την αντίθετη άποψη. Ναι στον διάλογο, όχι στην ειρωνεία, όλοι έχουν δικαίωμα να πουν την άποψη τους.
Timonkaipumpa Δημοσ. 3 Ιουλίου 2012 Δημοσ. 3 Ιουλίου 2012 Αρχικά δεν έχω σπουδαίες γνώσεις, ούτε ποτέ σε αυτό το φόρουμ θέλησα να δείξω κάτι τέτοιο. Τα ότι να ναι δεν θα τα λες σε εμένα, δεν με ξέρεις για αυτό κόψε το, δεν σου έδωσα ποτέ το δικαίωμα να μου απαντάς με αυτό τον τρόπο. Για αυτό τα ότι να ναι αλλού, όχι σε εμένα. Επίσης να σου τονίσω πως ουδέποτε η ειρωνεία δεν αποτέλεσε ορθό τρόπο αντιμετώπισης, για αυτό με εσένα δεν θέλω να έχω καμία κουβέντα. Με ρώτησες γιατί είπα ότι το φόρουμ πάει από το κακό στο χειρότερο; Τι μπορεί να εννοούσα; Τέλος, δεν νομίζω να είναι λάθος αυτό που έβαλα στον κώδικα, αλλά δεν πειράζει σε αφήνω στην πλάνη σου, ουδέποτε δε είπα ότι είναι for generic use, είπα ότι είναι παράδειγμα. Μα φυσικά! Silly me. Έπρεπε όλοι να απορήσουν και να τρέξουν γεμάτοι αγωνία να ρωτήσουν τον μέγιστο bokarinho: "Τι εννοούσες, ω, εσύ, bokarinho; " Ό,τι να ΄ναι2
Προτεινόμενες αναρτήσεις