I love const_cast and it loves me back. (It's hard to go wrong adding const to things as long as you're confident that it's okay for them to be immutable. These totally are.)
I love immutability. I always tick off co-workers with liberal sprinklings of final on local variables and object fields in our Java code base. In fact, I enjoyed that so much I decided to get into Haskell and get the full benefits of "all constants, all of the time".
When I have some time to spare, I'm definitely going to finish working my way through Real World Haskell. I'm a big fan of LISP, but Haskell is really doing the Right Thing in terms of providing a well-supported standard library that handles tasks that people need to perform on a regular basis. (Taking a cue from Python, IMO.) Also, the fact that it easily compiles to machine code is just awesome; I want to write a TCP/IP stack in Haskell and stress-test it against existing C versions.
i wrote an immutable-programming-based tetris a couple days ago, partly out of boredom and partly as an exercise. (all functions take a piece and/or a board, apply some change, and return the new piece and/or board.) it's an interesting style to work in after a decade or so of unmitigated imperative coding.
I'm a big fan of writing in as functional a style as possible even when I'm writing in a procedural language. Fewer side effects and a well-defined sense of scope make debugging a lot easier.
I confess I both love and hate the C++ implementation of const.
Conceptually, I like it, but in practice, the syntax tends to drive me totally up the wall. It's not hard but it always bogs me down because I have to stop for a half-second and remember what const before and const after mean. Interrupts my workflow.
My trick for this one is that 'const' applies to whatever it comes directly after (with one exception, on which more shortly). For instance:
int const* foo - foo is a pointer to const int int * const bar - bar is a const pointer to int int const * const baz - baz is a const pointer to const int
The one exception is that if there's an empty string to the left of 'const', then 'const' applies to whatever token is directly to the right of it. Thus, int const* foo and const int* foo are both pointers to const int.
This also applies to const functions, where you can end up with crazy stuff like
const int*const Method3(const int*const&)const;
as described here (http://duramecho.com/ComputerInformation/WhyHowCppConst.html). This function takes a const reference to a pointer to const int, returns a const pointer to const int, and can't modify the object that it's a method of.
I'd personally write that declaration as int const * const Method3(int const * const &Param)const; just to make it easier to follow, but when I'm not doing something that awkward-looking, I tend to put the 'const' first, just like most people. It's probably not good style though.
Whoops, you've just exposed some sloppy thinking on my part. I should have said "reference to const pointer to const int", following the what-comes-before-it rule -- there's a const after the *, and the other one precedes the int but there's nothing before that, so it applies to the int.
For some reason, in my head that parses as "const reference". I suspect g++ error messages have something to do with it.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
maradydd![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2009-05-14 03:31 am (UTC)In fact, I enjoyed that so much I decided to get into Haskell and get the full benefits of "all constants, all of the time".
(no subject)
Date: 2009-05-14 03:56 pm (UTC)(no subject)
Date: 2009-05-14 12:26 pm (UTC)(no subject)
Date: 2009-05-14 03:50 pm (UTC)(no subject)
Date: 2009-05-14 03:13 pm (UTC)Conceptually, I like it, but in practice, the syntax tends to drive me totally up the wall. It's not hard but it always bogs me down because I have to stop for a half-second and remember what const before and const after mean. Interrupts my workflow.
(no subject)
Date: 2009-05-14 03:48 pm (UTC)int const* foo - foo is a pointer to const int
int * const bar - bar is a const pointer to int
int const * const baz - baz is a const pointer to const int
The one exception is that if there's an empty string to the left of 'const', then 'const' applies to whatever token is directly to the right of it. Thus, int const* foo and const int* foo are both pointers to const int.
This also applies to const functions, where you can end up with crazy stuff like
const int*const Method3(const int*const&)const;
as described here (http://duramecho.com/ComputerInformation/WhyHowCppConst.html). This function takes a const reference to a pointer to const int, returns a const pointer to const int, and can't modify the object that it's a method of.
I'd personally write that declaration as int const * const Method3(int const * const &Param)const; just to make it easier to follow, but when I'm not doing something that awkward-looking, I tend to put the 'const' first, just like most people. It's probably not good style though.
(no subject)
Date: 2009-05-16 01:03 pm (UTC)isn't "const reference" inherently redundant? (i'm a total c++ newb, so i'm honestly asking)
(no subject)
Date: 2009-05-16 01:20 pm (UTC)For some reason, in my head that parses as "const reference". I suspect g++ error messages have something to do with it.
Thanks for the catch!
(no subject)
Date: 2009-05-16 02:24 pm (UTC)