Skip to main content

[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.



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

Back to the top