zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Tyree <tyree...@gmail.com>
Subject Re: C API question
Date Thu, 01 Aug 2013 15:20:06 GMT
A slight nitpick (since hey, nitpicking is all I really do here) with C++
you can get away with doing a static_cast from void* to any pointer type
(instead of reinterpret_cast) because the cast to a void* didn't change the
pointer in any way. The more you know ----*


On Thu, Aug 1, 2013 at 11:14 AM, Marios Hadjieleftheriou
<mhadji@gmail.com>wrote:

> On Wed, Jul 31, 2013 at 1:31 PM, Marshall McMullen
> <marshall.mcmullen@gmail.com> wrote:
> > And obviously you could layer a reinterpet_cast on the const_cast to get
> it
> > from a void* to whatever your object type really is.
> >
> >
> > On Wed, Jul 31, 2013 at 11:25 AM, Marshall McMullen <
> > marshall.mcmullen@gmail.com> wrote:
> >
> >> IMO I think this is correct behavior from zookeeper's perspective. By
> >> marking the parameter as a const void* the C API is promising that *it*
> >> will not modify the contents of memory referred to by the pointer. That
> is
> >> absolutely the correct contract for zookeeper to make. If it were not
> const
> >> then the C API would not be able to guarantee that. Moreover, as a
> client
> >> building on top of the C API looking at the C API I can easily tell
> looking
> >> at these functions that it is promising not not modify that data. I
> don't
> >> see any problems with this.
> >>
>
> In other words you are saying that when I pass the data parameter to
> zookeeper through a get_children call let's say, I am passing it as
> const void and hence it is also stored within Zookeeper as const void.
> So when Zookeeper calls my callback it has no other choice but to pass
> it as const void again.
>
> Ok. That makes sense and answers my original question:
> "Is there any reason why this parameter needs to be const?"
>
> >> As to the problem in your callback, that is easily solvable since you
> own
> >> the memory in the callback so you know you can safely const-cast away
> the
> >> const. You mentioned reinterpet_cast, so in c++ this would be:
> >>
> >> void* data = const_cast<void *>(data_ptr);
> >>
> >>
> >>
> >> On Wed, Jul 31, 2013 at 10:24 AM, Marios Hadjieleftheriou <
> >> mhadji@gmail.com> wrote:
> >>
> >>> Hi Mohammad.
> >>>
> >>> The parameter is a const void * (reading from right to left: a pointer
> >>> to a void that is const). Hence the data pointed to cannot be changed.
> >>>
> >>> Moreover, it does not make sense to pass a void* const (right to left:
> >>> a const pointer to a void) as a function argument, because the pointer
> >>> itself ("data" in this case) is passed by value, hence it is
> >>> meaningless for it to be const or not.
> >>>
> >>> In any case, in my callback function I tried to reinterpret_cast my
> >>> data to a non-const instance and the compiler complained that it needs
> >>> to be const. I cannot change my data.
> >>>
> >>> On Wed, Jul 31, 2013 at 12:55 AM, Mohammad Shamma
> >>> <mohammadshamma@gmail.com> wrote:
> >>> > I think the const in this case would cause the pointer to be fixed.
> The
> >>> > data referred to by the pointer can still be updated.
> >>> >
> >>> > This is a similar question on stackoverflow:
> >>> > http://stackoverflow.com/questions/6407041/constant-pointer
> >>> >
> >>> >
> >>> > On Tue, Jul 30, 2013 at 7:06 PM, Marios Hadjieleftheriou
> >>> > <mhadji@gmail.com>wrote:
> >>> >
> >>> >> The string_completiion_t callback signature of the Zookeeper C
API
> is:
> >>> >>
> >>> >> typedef void(* string_completion_t)(int rc, const char *value,
const
> >>> void
> >>> >> *data)
> >>> >>
> >>> >> That means that when the callback is called, the user provided
data
> is
> >>> >> returned as a const void and cannot be modified by client code,
> which
> >>> >> kind of defeats the purpose of passing any data in the first place.
> >>> >>
> >>> >> Is there any reason why this parameter needs to be const?
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Mohammad Shamma
> >>>
> >>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message