const_cast, reinterpret_cast

Discussion in 'C++' started by johny smith, Jun 24, 2004.

  1. johny smith

    johny smith Guest

    Can someone please give me some good reference site/information for
    understanding when and why I would use

    1.) const_cast
    Don't know why you would do this?

    2.) reinterpret_cast.
    I have used this a little when I converted a primitive to a class, but
    would like to see other applications.

    Yes, I have looked on the web, but want to know what some of the experts
    know about this.

    Thanks alot for your help,

    John
     
    johny smith, Jun 24, 2004
    #1
    1. Advertising

  2. johny smith

    Julie Guest

    johny smith wrote:
    >
    > Can someone please give me some good reference site/information for
    > understanding when and why I would use
    >
    > 1.) const_cast
    > Don't know why you would do this?


    I've had need to use this to cast away constness when interfacing w/ poorly
    written interfaces that treat a parameter as const, but don't qualify it as
    const in the parameter list.
     
    Julie, Jun 24, 2004
    #2
    1. Advertising

  3. johny smith

    David White Guest

    "johny smith" <> wrote in message
    news:...
    > Can someone please give me some good reference site/information for
    > understanding when and why I would use
    >
    > 1.) const_cast
    > Don't know why you would do this?


    It's for casting from const to non-const.

    > 2.) reinterpret_cast.
    > I have used this a little when I converted a primitive to a class, but
    > would like to see other applications.


    You use it to convert between incompatible types, e.g.,
    unsigned char buffer[20];
    if(read_message_from_com_port(buffer))
    {
    double x = *reinterpret_cast<double*>(buffer);
    //...
    }

    As a rule of thumb, use reinterpret_cast if there is no implicit conversion
    and static_cast is rejected by the compiler - and you are really sure that
    it's the conversion you need.

    If you are unable to find uses for these casts, then count your blessings.
    No one _wants_ to use them. They should be used as little as possible, but
    sometimes you have to use to use them.

    DW
     
    David White, Jun 24, 2004
    #3
  4. johny smith

    Siemel Naran Guest

    "johny smith" <> wrote in message

    > 1.) const_cast
    > Don't know why you would do this?


    If you implement the const function, you can implement the nonconst function
    in terms of the nonconst one.

    const T& Foo::stuff() const {
    /* lots of code */
    }

    T& Foo::stuff() {
    const Foo * cthis = this;
    return const_cast<T&>(cthis->stuff);
    }

    Also, you need const_cast to add 2nd level const. Though this is rarely
    used.

    int main(int argc, char * * argv) {
    char const *const * cargv = const_cast<char const *const *>(argv);
    };

    And you also need const_cast to deal with interfaces that aren't const
    correct, for example using a variable as const by not declaring it const, as
    Julie points out.

    > 2.) reinterpret_cast.
    > I have used this a little when I converted a primitive to a class, but
    > would like to see other applications.


    One can use it to convert an int, double, etc to a stream of bytes, suitable
    for a call to write.

    int i = 3;
    cout.write(reinterpret_cast<const char *>(&i), sizeof(i));

    In pool allocator schemes, we allocate space to store N elements, say N =
    100. You can treat the space of element as either an element or a pointer
    to the next element, provided that the sizeof the space is >= the space of a
    pointer to the element.

    There are lots of other domain specific examples.
     
    Siemel Naran, Jun 24, 2004
    #4
  5. johny smith

    David White Guest

    "David White" <> wrote in message
    news:sLsCc.14439$%...
    > "johny smith" <> wrote in message
    > news:...
    > > Can someone please give me some good reference site/information for
    > > understanding when and why I would use
    > >
    > > 1.) const_cast
    > > Don't know why you would do this?

    >
    > It's for casting from const to non-const.


    I guess now that you already knew that. I'm struggling to come up with
    necessary uses for it, or uses that don't indicate a flawed design.
    Stroustrup's "The C++ Programming Language" gives an example of a class
    member used to cache a value. Even in a const member function you might want
    to change the value of the cache, since the cache only affects performance
    and not the logical state of the object. Changing a class member in a const
    member function requires const_cast. However, I don't think this is a good
    example because the member used as the cache would be better declared
    'mutable', obviating the need for the const_cast. I did manage to find this
    rather unsual case in my own code that uses both const_cast and
    reinterpret_cast:

    class ParamDB
    {
    // A database class
    };

    // A handle used to access the database across a C interface
    typedef struct DBHandleStruct_{} *DBHandle;

    DBHandle asDBHandle(const ParamDB *pDB)
    {
    return reinterpret_cast<DBHandle>(const_cast<ParamDB*>(pDB));
    }

    I suppose I could have (or should have) made DBHandle const struct
    DBHandleStruct_{} * and I still wouldn't have needed the const_cast.

    DW
     
    David White, Jun 24, 2004
    #5
  6. "David White" <> wrote in message
    news:cxuCc.14446$%...
    > "David White" <> wrote in message
    > news:sLsCc.14439$%...
    > > "johny smith" <> wrote in message
    > > news:...
    > > > Can someone please give me some good reference site/information for
    > > > understanding when and why I would use
    > > >
    > > > 1.) const_cast
    > > > Don't know why you would do this?

    > >
    > > It's for casting from const to non-const.

    >
    > I guess now that you already knew that. I'm struggling to come up with
    > necessary uses for it, or uses that don't indicate a flawed design.


    Suppose you are writing an STL container class

    class MyIntContainer
    {
    iterator find(int x)
    {
    // some complex function
    }

    const_iterator find(int x) const
    {
    return const_cast<MyIntContainer*>(this)->find(x);
    }

    ...

    const_cast avoids repeating a whole lot of code. (Possibly this indicates
    the iterator/const_iterator concept in the STL is flawed design but there
    you go).

    john
     
    John Harrison, Jun 24, 2004
    #6
  7. John Harrison wrote:
    > David White wrote:
    >> johny smith wrote:
    >>> Can someone please give me some good reference site/information for
    >>> understanding when and why I would use
    >>>
    >>> 1.) const_cast
    >>> Don't know why you would do this?

    >>
    >> It's for casting from const to non-const.
    >>
    >> I guess now that you already knew that. I'm struggling to come up with
    >> necessary uses for it, or uses that don't indicate a flawed design.

    >
    > Suppose you are writing an STL container class
    >
    > class MyIntContainer
    > {
    > iterator find(int x)
    > {
    > // some complex function
    > }
    >
    > const_iterator find(int x) const
    > {
    > return const_cast<MyIntContainer*>(this)->find(x);
    > }
    >
    > ...
    >
    > const_cast avoids repeating a whole lot of code. (Possibly this indicates
    > the iterator/const_iterator concept in the STL is flawed design but there
    > you go).


    Or possibly that the first should be

    iterator find (int x) const

    Is there a particular reason this isn't the case?

    --
    Some say the Wired doesn't have political borders like the real world,
    but there are far too many nonsense-spouting anarchists or idiots who
    think that pranks are a revolution.
     
    Owen Jacobson, Jun 24, 2004
    #7
  8. "Owen Jacobson" <> wrote in message
    news:p...
    > John Harrison wrote:
    > > David White wrote:
    > >> johny smith wrote:
    > >>> Can someone please give me some good reference site/information for
    > >>> understanding when and why I would use
    > >>>
    > >>> 1.) const_cast
    > >>> Don't know why you would do this?
    > >>
    > >> It's for casting from const to non-const.
    > >>
    > >> I guess now that you already knew that. I'm struggling to come up with
    > >> necessary uses for it, or uses that don't indicate a flawed design.

    > >
    > > Suppose you are writing an STL container class
    > >
    > > class MyIntContainer
    > > {
    > > iterator find(int x)
    > > {
    > > // some complex function
    > > }
    > >
    > > const_iterator find(int x) const
    > > {
    > > return const_cast<MyIntContainer*>(this)->find(x);
    > > }
    > >
    > > ...
    > >
    > > const_cast avoids repeating a whole lot of code. (Possibly this

    indicates
    > > the iterator/const_iterator concept in the STL is flawed design but

    there
    > > you go).

    >
    > Or possibly that the first should be
    >
    > iterator find (int x) const
    >
    > Is there a particular reason this isn't the case?
    >


    Yes its by design. If it we're not the case you would be able to write code
    like this

    const MyIntContainer c = ...;
    iterator i = c.find(1);
    *i = 2;

    in other words you would be able to use an iterator to modify a const
    object.

    john
     
    John Harrison, Jun 24, 2004
    #8
  9. johny smith

    Mats Weber Guest

    In article <o8uCc.125821$>,
    "Siemel Naran" <> wrote:

    >If you implement the const function, you can implement the nonconst function
    >in terms of the nonconst one.
    >
    >const T& Foo::stuff() const {
    > /* lots of code */
    >}
    >
    >T& Foo::stuff() {
    > const Foo * cthis = this;
    > return const_cast<T&>(cthis->stuff);
    >}


    Is there a clean (without a cast) way to do this, implementing the
    non-const version first ?
     
    Mats Weber, Jun 24, 2004
    #9
  10. johny smith

    tom_usenet Guest

    tom_usenet, Jun 24, 2004
    #10
  11. johny smith

    Unforgiven Guest

    "johny smith" <> wrote in message
    news:...
    > Can someone please give me some good reference site/information for
    > understanding when and why I would use
    >
    > 1.) const_cast
    > Don't know why you would do this?
    >
    > 2.) reinterpret_cast.
    > I have used this a little when I converted a primitive to a class, but
    > would like to see other applications.


    This is a very good article about reinterpret_cast:
    http://msdn.microsoft.com/library/en-us/dndeepc/html/deep06012000.asp

    Don't worry about the fact that it's on MSDN, it's not in the least
    Microsoft specific. Robert Schmidt (the author) is a very standards-oriented
    guy.
    There's an article about static_cast too, but not about const_cast,
    unfortunately.

    --
    Unforgiven
     
    Unforgiven, Jun 24, 2004
    #11
  12. johny smith

    Siemel Naran Guest

    "John Harrison" <> wrote in message
    news:2jvbacF15ln3kU1@uni-

    > class MyIntContainer
    > {
    > iterator find(int x)
    > {
    > // some complex function
    > }
    >
    > const_iterator find(int x) const
    > {
    > return const_cast<MyIntContainer*>(this)->find(x);
    > }


    Coming to think of it, shouldn't you implement the const version, and
    nonconst one in terms of the const one. Because the original object may
    have been const. I didn't realize this until formulating my reply to Mats
    Weber.
     
    Siemel Naran, Jun 24, 2004
    #12
  13. johny smith

    Siemel Naran Guest

    "Mats Weber" <> wrote in message news:matsw-
    > "Siemel Naran" <> wrote:


    > >If you implement the const function, you can implement the nonconst

    function
    > >in terms of the nonconst one.
    > >
    > >const T& Foo::stuff() const {
    > > /* lots of code */
    > >}
    > >
    > >T& Foo::stuff() {
    > > const Foo * cthis = this;
    > > return const_cast<T&>(cthis->stuff);
    > >}

    >
    > Is there a clean (without a cast) way to do this, implementing the
    > non-const version first ?


    No. In this second approach example you need a const_cast to cast away the
    constness of this. So either way you need a const_cast.

    const T& Foo::stuff() const {
    Foo * ncthis = const_cast<Foo *>(this);
    return ncthis->stuff();
    }

    The advantage of the first way I posted is that the original object may have
    been declared const as in

    int main() {
    const Foo foo;
    foo.stuff();
    }

    so it's not safe to cast away the constness of this. So we implement the
    const version. The nonconst version will call the const version, then cast
    away the constness of the returned reference or iterator or pointer -- which
    should be OK because the original pointer, presumably a pointer to some part
    of the object, was originally non-const.
     
    Siemel Naran, Jun 24, 2004
    #13
  14. johny smith

    Siemel Naran Guest

    Siemel Naran, Jun 24, 2004
    #14
  15. Siemel Naran wrote in
    news:3eDCc.128476$ in
    comp.lang.c++:

    > "John Harrison" <> wrote in message
    > news:2jvbacF15ln3kU1@uni-
    >
    >> class MyIntContainer
    >> {
    >> iterator find(int x)
    >> {
    >> // some complex function
    >> }
    >>
    >> const_iterator find(int x) const
    >> {
    >> return const_cast<MyIntContainer*>(this)->find(x);
    >> }

    >
    > Coming to think of it, shouldn't you implement the const version, and
    > nonconst one in terms of the const one. Because the original object
    > may have been const. I didn't realize this until formulating my reply
    > to Mats Weber.
    >
    >


    Well should you be able to make an iterator from a const_iterator ?

    Ofcourse calling the non-const find on a const object is fine as
    long as we know that it doesen't modify the object, and in this
    case why would it ?

    Rob.
    --
    http://www.victim-prime.dsl.pipex.com/
     
    Rob Williscroft, Jun 24, 2004
    #15
  16. johny smith

    Siemel Naran Guest

    "Rob Williscroft" <> wrote in message

    > Ofcourse calling the non-const find on a const object is fine as
    > long as we know that it doesen't modify the object, and in this
    > case why would it ?


    Note in the example we are returning an iterator to the caller. There's no
    saying what they'll do with it.

    Also, the standard says casting away the constness of an object that was
    originally const, even if only for read purposes, is undefined. Maybe some
    implementations out there have read only pointers builtin into the system, I
    don't know. I suggested recently in a post that to get a "char *" from
    string.c_str() you could practically do "const_cast<char*>(string. c_str())"
    which would work on all implementations I know, but someone correctly
    pointed out it is still undefined behavior if the original string were
    const.
     
    Siemel Naran, Jun 24, 2004
    #16
  17. Siemel Naran wrote in
    news:4NDCc.128652$ in
    comp.lang.c++:

    > "Rob Williscroft" <> wrote in message
    >
    >> Ofcourse calling the non-const find on a const object is fine as
    >> long as we know that it doesen't modify the object, and in this
    >> case why would it ?

    >
    > Note in the example we are returning an iterator to the caller.
    > There's no saying what they'll do with it.
    >


    I was refering to the const_cast in the const member function,
    and then calling the non-const find on it.

    > Also, the standard says casting away the constness of an object that
    > was originally const, even if only for read purposes, is undefined.


    Do you have a reference ?

    > Maybe some implementations out there have read only pointers builtin
    > into the system, I don't know. I suggested recently in a post that to
    > get a "char *" from string.c_str() you could practically do
    > "const_cast<char*>(string. c_str())" which would work on all
    > implementations I know, but someone correctly pointed out it is still
    > undefined behavior if the original string were const.
    >


    Its UB anyway, we've no idea where the char const * returned by
    c_str() comes from.


    Rob.
    --
    http://www.victim-prime.dsl.pipex.com/
     
    Rob Williscroft, Jun 24, 2004
    #17
  18. johny smith

    DaKoadMunky Guest

    >> class MyIntContainer
    >> {
    >> iterator find(int x)
    >> {
    >> // some complex function
    >> }
    >>
    >> const_iterator find(int x) const
    >> {
    >> return const_cast<MyIntContainer*>(this)->find(x);
    >> }

    >
    >Coming to think of it, shouldn't you implement the const version, and
    >nonconst one in terms of the const one. Because the original object may
    >have been const. I didn't realize this until formulating my reply to Mats
    >Weber.


    In this case you probably can't implement the non-const version in terms of the
    const version.

    The return type of the const version is most likely not convertible to the
    return type of the non-const version.

    It seems reasonble that one shouldn't be able to convert a constant iterator
    into a non-constant iterator.

    The reverse of course is quite reasonable.
     
    DaKoadMunky, Jun 24, 2004
    #18
  19. johny smith

    Old Wolf Guest

    "David White" <> wrote:
    > "johny smith" <> wrote
    > > 1.) const_cast
    > > Don't know why you would do this?

    >
    > It's for casting from const to non-const.


    Also for casting from non-const to const, and volatile to non-volatile,
    and non-volatile to volatile, and any combinations of those.
    For example:

    void foo(const char **ptr);
    char *x;

    foo(const_cast<const char **>(&x));
     
    Old Wolf, Jun 24, 2004
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Suzanne Vogel
    Replies:
    17
    Views:
    846
    Suzanne Vogel
    Jul 7, 2003
  2. Scott Brady Drummonds

    reinterpret_cast<>() v. static_cast<>()

    Scott Brady Drummonds, Jan 13, 2004, in forum: C++
    Replies:
    11
    Views:
    20,937
    Nick Hounsome
    Jan 20, 2004
  3. Aman

    reinterpret_cast<>

    Aman, Feb 23, 2004, in forum: C++
    Replies:
    15
    Views:
    876
    Ben Hutchings
    Feb 25, 2004
  4. PowerStudent
    Replies:
    4
    Views:
    926
    Joshua Maurice
    Aug 5, 2010
  5. Alex Vinokur
    Replies:
    1
    Views:
    611
Loading...

Share This Page