c++

[Kercyn]

btw ?? :: 

 

http://stackoverflow.com/questions/19020092/multiple-ternary-operator-in-c

[defacer]

Αυτό το κόλπο με τον πίνακα f είναι πολύ γουστόζικο, το είχα πρωτοπετύχει σε λύση προβλήματος "γράψε ένα πρόγραμμα που να τυπώνει τους αριθμούς από 1 ως 1000 χωρίς loops και χωρίς conditionals".

 

Εκεί γινόταν κάτι του στυλ

 

(iterate + (exit - iterate) * ( i / 1000))();

 

που δουλεύει επειδή το i / 1000 είναι ακέραια διαίρεση. Βέβαια το exit - iterate παίζει να είναι UB αλλά ποιός νοιάζεται.  

[imitheos]

χαχαχα

 

btw ?? ::

Αυτό το κόλπο με τον πίνακα f είναι πολύ γουστόζικο, το είχα πρωτοπετύχει σε λύση προβλήματος "γράψε ένα πρόγραμμα που να τυπώνει τους αριθμούς από 1 ως 1000 χωρίς loops και χωρίς conditionals".

 

Εκεί γινόταν κάτι του στυλ

 

(iterate + (exit - iterate) * ( i / 1000))();

 

που δουλεύει επειδή το i / 1000 είναι ακέραια διαίρεση. Βέβαια το exit - iterate παίζει να είναι UB αλλά ποιός νοιάζεται.  

Ήθελα κάτι που να "κρύβει" if, for, κτλ οπότε το πρώτο που μου ήρθε στο μυαλό είναι ένας πίνακας αντιστοιχίας. Στην περίπτωση των function pointer ήταν εύκολο αλλά στον έλεγχο δεν μου βγήκε κάτι αρκετά obfuscated έτσι αναγκαστικά χρησιμοποίησα το διπλό ternary.

 

Ναι είναι UB (error σε C++) όπως και το δικό μου >> 31 είναι UB αν ο int έχει μικρότερο μέγεθος από το κλασικό αλλά λόγω της φύσης του κώδικα, το παρέβλεψα

[dpetka2001]

static int m =(145^1169)>>31;

ποιος ο λογος για αυτο? το m δεν ειναι στην ουσια counter για το ποσες φορες εμφανιζεται μεσα στο ευρος? δε θα μπορουσαμε απλα να το αρχικοποιησουμε με μηδεν? επισης αν καποιος θα μπορουσε να εξηγησει το λογο για τον οποιο το οριζουμε static εδω?

[imitheos]

 

static int m =(145^1169)>>31;

δε θα μπορουσαμε απλα να το αρχικοποιησουμε με μηδεν?

 

Εσύ με εμάς είσαι ή με το λιοντάρι ;

 

επισης αν καποιος θα μπορουσε να εξηγησει το λογο για τον οποιο το οριζουμε static εδω?

Ώστε να διατηρηθεί το αντικείμενο αυτούσιο και να μην δεσμεύεται (και αποδεσμεύεται) μνήμη κάθε φορά που τρέχει η συνάρτηση.

[Kercyn]

Να ρωτήσω κι εγώ κάτι τώρα. Απ' ό,τι διάβασα, το standard δεν απαιτεί το m να γίνει evaluate στο compile time, αλλά ότι όλοι οι σοβαροί compilers θα το κάνουν. Θα μπορούσε κάποιος "έξυπνος" compiler να δει το >> 31 και να αγνοήσει το 145^1169 (όπως, πχ, γίνεται σε bitwise πράξεις) ή διατηρείται η σειρά προτεραιότητας;

[παπι]

Οι compiler αγνοουν πολυ πιο περιπλοκες καταστασεις.

[imitheos]

Να ρωτήσω κι εγώ κάτι τώρα. Απ' ό,τι διάβασα, το standard δεν απαιτεί το m να γίνει evaluate στο compile time, αλλά ότι όλοι οι σοβαροί compilers θα το κάνουν. Θα μπορούσε κάποιος "έξυπνος" compiler να δει το >> 31 και να αγνοήσει το 145^1169 (όπως, πχ, γίνεται σε bitwise πράξεις) ή διατηρείται η σειρά προτεραιότητας;

Όπως είπε και ο παπί, οι compilers μπορούν να βελτιστοποιήσουν πολύ πιο πολύπλοκες εκφράσεις. Για του λόγου το αληθές, gcc και clang αφαιρούν εντελώς την δήλωση και ξεκινούν από το m += v ακόμη και σε -O0.

[Kercyn]

Ευχαριστώ παιδιά.

[dpetka2001]

Εσύ με εμάς είσαι ή με το λιοντάρι ;

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

 

υγ: το UB τι σημαινει?

[παπι]

Δεν είναι σιγουρακι