This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [patch] Remove is_merge_section_for
- From: Cary Coutant <ccoutant at google dot com>
- To: Rafael EspÃndola <rafael dot espindola at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Mon, 23 Mar 2015 10:13:40 -0700
- Subject: Re: [patch] Remove is_merge_section_for
- Authentication-results: sourceware.org; auth=none
- References: <CAG3jReLX_6ZV9oWeJHp8NVroph9WjB1brdeZHyUjLAVjPxcZjg at mail dot gmail dot com> <CAHACq4rJb6upcCqZKgwCQG-L-VvFLArc5o9ysQ=FrhbpD3vUPA at mail dot gmail dot com> <CAG3jReLg05HubZuzxmPCXQ-FU0RUHJBwE8iNXtwBeEvU0jimpg at mail dot gmail dot com>
>> + const Input_merge_map*
>> + get_input_merge_map(unsigned int shndx) const {
>> + return const_cast<Object_merge_map*>(this)->get_input_merge_map(shndx);
>> + }
>>
>> When you need both const and non-const versions of a method, have the
>> non-const version call the const version, instead of the other way
>> around.
>
> I did as asked, but now we need two casts:
>
> Input_merge_map *
> get_input_merge_map(unsigned int shndx) {
> return const_cast<Input_merge_map *>(static_cast<const Object_merge_map *>(
> this)->get_input_merge_map(shndx));
> }
>
> Are you sure this is better?
Yes. The other way, by casting away the const-ness before you call the
non-const method, you risk that the non-const method might modify the
object that we only had a const pointer to. This way, we know it's
safe to cast away the const-ness because we were given a non-const
pointer to begin with.
-cary