[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [paho-dev] Using C++ with the Paho C client library
|
Hi Ian,
I was suggesting the pragmatic approach that would allow people using
C++ to use the Paho C library with string literals without requiring a
cast to (char *).
Declaring all arguments as const where appropriate is a good goal, but
it's not as much of a problem as the above.
Cheers,
Roger
On Fri, May 17, 2013 at 12:01 PM, Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi Roger,
>
> I don't see why it should be unimportant that a member of a structure is not
> const while the structure is const. If the purpose is to help the writer of
> a function using the data not to inadvertently modify caller data, then they
> are both important.
>
> Maybe I misunderstand the purpose of the suggestion of adding const to these
> fields. What do we hope to achieve by doing so, if not the reason I stated
> above? And in that case what principle would we be following in deciding
> which fields to apply const to, and which not?
>
> Ian
>
>
> On 17/05/13 11:43, Roger Light wrote:
>>
>> Hi Ian,
>>
>>> what about the elements of the connectOptions, willOptions and SSLOptions
>>> structures, for instance?
>>
>> Neither SSLOptions nor willOptions are directly exposed in the
>> external API because they are only used as members of connectOptions.
>> connectOptions itself can be const because none of its members are
>> modified. My understanding is that it is not important that, for
>> example, the username member of connectOptions is not const even
>> though connectOptions may be. Username is mutable but connectOptions
>> is not.
>>
>> Regards,
>>
>> Roger
>> _______________________________________________
>> paho-dev mailing list
>> paho-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/paho-dev
>>
>