c++

[Kercyn]

  Στις 26/10/2014 στις 1:10 ΜΜ, παπι είπε

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]

  Στις 26/10/2014 στις 1:10 ΜΜ, παπι είπε

χαχαχα

 

btw ?? ::

  Στις 26/10/2014 στις 2:45 ΜΜ, defacer είπε

Αυτό το κόλπο με τον πίνακα 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]

  Στις 27/10/2014 στις 9:19 ΠΜ, dpetka2001 είπε

 

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

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

 

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

 

  Στις 27/10/2014 στις 9:19 ΠΜ, dpetka2001 είπε

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

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

[Kercyn]

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

[παπι]

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

[imitheos]

  Στις 27/10/2014 στις 11:08 ΠΜ, Kercyn είπε

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

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

[Kercyn]

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

[dpetka2001]

  Στις 27/10/2014 στις 10:01 ΠΜ, imitheos είπε

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

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

 

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

[παπι]

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