Re: [boost] any

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-09-01 17:32:14

>In message <v03110700b5d46b34744f@[153.32.222.4]>, Jesse Jones
><jejones_at_[hidden]> writes
>>>In this case I would have said that the implicit conversion is benign,
>>>so I don't see a problem.
>>
>>Most of the time you're probably right, but it does introduce a hole in the
>>type system. For example if someone is transitioning code from using
>>void*'s to any they might run into trouble.
>
>Most of the time I'm probably right, and in this case I'm definitely
>right ;-) It introduces no hole in the type system and is safer than
>using operator bool, of which it is the (more) moral equivalent. I
>cannot see how anyone could genuinely run into trouble using it in the
>context you describe, w/o first running into compilation errors.

Yeah, operator bool is worse. That's why I suggested a member function like
empty. Here's the scenario I was thinking of. I'm working on an app
framework and need to have the document object broadcast as its state
changes. The code in the framework will broadcast when the document is
opened, reverted, dirtied, etc. In the interests of efficiency it's
desirable to allow clients to associate some arbitrary data with the
broadcast message (eg a paint program might include the changed pixels so
the view can do a minimal invalidation). I have been using a struct that
looks like this in the framework:

struct SDocumentMesg {
   uint32 message;
   const void* data;
};

Client code could look like this:

void ImageView::DoUpdate(const SDocumentMesg& mesg)
{
   if (mesg.message == kChangedBits) {
      const XRect* area = reinterpret_cast<const XRect*>(mesg.data);
      this->Invalidate(*area);
   } else
      this->Invalidate();   // invalidate everything
}

Now I can replace the SDocumentMesg::mesg an any. But if I do this client
code will break with no compiler warnings. Is this not a hole in the type
system?

>However, what you're actually suggesting is getting rid of type_info
>altogether?

Yup.

Why would I want to do that? There would be no convenient to
>discover the typeid of the content. In other words, "Hey, any, what do
>you contain?" "Dunno, let's play 20 questions and maybe you can find
>out!" :->

Good point. The examples you posted are also interesting. I'm still not
convinced that this isn't overkill, but I think I'll have to bow to your
experience. :-)

>>Providing three ways to get at the value seemed a bit excessive.
>
>[snip]
>
>If I needed only one I would have only one, but experience with the
>class (and its ancestors) has taught me that these are reasonable
>scenarios to pander to.

If one is too little and three is too many isn't two just right? :-)

  -- Jesse