Timeline for Gray codes addition
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 2, 2015 at 12:20 | history | edited | Morwenn | CC BY-SA 3.0 |
Gray is a name, therefore we can't you "grey" instead.
|
| Nov 8, 2014 at 2:56 | history | edited | Loki Astari | CC BY-SA 3.0 |
added 133 characters in body
|
| Nov 7, 2014 at 14:08 | comment | added | Loki Astari | No the mutable member trick is not going to be useful if you are deliberately leaving the value member open to be twiddled by bit operations. | |
| Nov 7, 2014 at 13:56 | comment | added | Morwenn |
Exposing value is a design choice. Many bit-tricks can be faster when done on the original value, and fast is one of the aims. Therefore, I see no problem in exposing the class internals: they are useful and clearly show that nothing fishy is happening behind the user's back.
|
|
| Nov 7, 2014 at 13:51 | comment | added | Morwenn |
Concerning the mutable value, the operators ++, --, >>=, <<=, &=, |= and ^=, so storing a second value and always getting it right through the changes may be expensive. Here, it is the responsibility of the user to know when they want to convert the value back to an integer. I could have made the conversion operation explicit though so that random conversions don't unexpectedly happen.
|
|
| Nov 7, 2014 at 13:48 | comment | added | Morwenn |
The last & is a ref-qualifier for *this. It ensures that operator= cannot be used with a temorary value, like (a + b) = c.
|
|
| Nov 7, 2014 at 13:33 | history | answered | Loki Astari | CC BY-SA 3.0 |