You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Motl <mo...@orcsoftware.com> on 2007/09/21 11:20:57 UTC
BytesMessage constness
Hi,
I once asked you why readBytes() and other read methods aren't const:
http://www.nabble.com/BytesMessage-methods-tf3833767s2354.html#a10853672
But if only the stream pointer is updated, I suppose we could have another
solution here, i.e.
declare inputStream field as 'mutable':
mutable io::ByteArrayInputStream inputStream;
In that case we could keep read methods const.
I am requesting for that because at the moment such non-const API forces app
level either always deal with non-const objects or make
const_cast<cms::BytesMessage *>(), that's not good.
--
View this message in context: http://www.nabble.com/BytesMessage-constness-tf4492790s2354.html#a12813490
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: BytesMessage constness
Posted by Nathan Mittler <na...@gmail.com>.
Sounds fine to me.
+1
On 9/21/07, Albert Strasheim <fu...@gmail.com> wrote:
>
> Hello
>
> Maybe MessageListener::onMessage should be fixed to pass a non-const
> Message
> instead of pretending that BytesMessage::read is const when it isn't (also
> consider something like std::istream::read, which isn't const).
>
> In my experience mutable is typically used when you have a getter that is
> const but updates some kind of internal cache in the object. I think the
> BytesMessage::read situation is more like std::istream::read than it is
> like
> this case.
>
> Cheers,
>
> Albert
>
> ----- Original Message -----
> From: "Motl" <mo...@orcsoftware.com>
> To: <us...@activemq.apache.org>
> Sent: Friday, September 21, 2007 1:45 PM
> Subject: Re: BytesMessage constness
>
>
> > Done.
> >
> > https://issues.apache.org/activemq/browse/AMQCPP-143
> >
> >
> > nmittler wrote:
> >>
> >> I agree, this definitely would be a pain since the onMessage method
> gives
> >> you a const Message. Could you capture this issue in JIRA?
> >> http://issues.apache.org/activemq/browse/AMQCPP
> >>
> >> Thanks,
> >> Nate
> >>
> >>
> >> On 9/21/07, Motl <mo...@orcsoftware.com> wrote:
> >>>
> >>>
> >>> Hi,
> >>> I once asked you why readBytes() and other read methods aren't const:
> >>>
> >>>
> http://www.nabble.com/BytesMessage-methods-tf3833767s2354.html#a10853672
> >>>
> >>> But if only the stream pointer is updated, I suppose we could have
> >>> another
> >>> solution here, i.e.
> >>> declare inputStream field as 'mutable':
> >>>
> >>> mutable io::ByteArrayInputStream inputStream;
> >>>
> >>> In that case we could keep read methods const.
> >>>
> >>> I am requesting for that because at the moment such non-const API
> forces
> >>> app
> >>> level either always deal with non-const objects or make
> >>> const_cast<cms::BytesMessage *>(), that's not good.
>
>
>
Re: BytesMessage constness
Posted by Albert Strasheim <fu...@gmail.com>.
Hello
Maybe MessageListener::onMessage should be fixed to pass a non-const Message
instead of pretending that BytesMessage::read is const when it isn't (also
consider something like std::istream::read, which isn't const).
In my experience mutable is typically used when you have a getter that is
const but updates some kind of internal cache in the object. I think the
BytesMessage::read situation is more like std::istream::read than it is like
this case.
Cheers,
Albert
----- Original Message -----
From: "Motl" <mo...@orcsoftware.com>
To: <us...@activemq.apache.org>
Sent: Friday, September 21, 2007 1:45 PM
Subject: Re: BytesMessage constness
> Done.
>
> https://issues.apache.org/activemq/browse/AMQCPP-143
>
>
> nmittler wrote:
>>
>> I agree, this definitely would be a pain since the onMessage method gives
>> you a const Message. Could you capture this issue in JIRA?
>> http://issues.apache.org/activemq/browse/AMQCPP
>>
>> Thanks,
>> Nate
>>
>>
>> On 9/21/07, Motl <mo...@orcsoftware.com> wrote:
>>>
>>>
>>> Hi,
>>> I once asked you why readBytes() and other read methods aren't const:
>>>
>>> http://www.nabble.com/BytesMessage-methods-tf3833767s2354.html#a10853672
>>>
>>> But if only the stream pointer is updated, I suppose we could have
>>> another
>>> solution here, i.e.
>>> declare inputStream field as 'mutable':
>>>
>>> mutable io::ByteArrayInputStream inputStream;
>>>
>>> In that case we could keep read methods const.
>>>
>>> I am requesting for that because at the moment such non-const API forces
>>> app
>>> level either always deal with non-const objects or make
>>> const_cast<cms::BytesMessage *>(), that's not good.
Re: BytesMessage constness
Posted by Motl <mo...@orcsoftware.com>.
Done.
https://issues.apache.org/activemq/browse/AMQCPP-143
nmittler wrote:
>
> I agree, this definitely would be a pain since the onMessage method gives
> you a const Message. Could you capture this issue in JIRA?
> http://issues.apache.org/activemq/browse/AMQCPP
>
> Thanks,
> Nate
>
>
> On 9/21/07, Motl <mo...@orcsoftware.com> wrote:
>>
>>
>> Hi,
>> I once asked you why readBytes() and other read methods aren't const:
>>
>> http://www.nabble.com/BytesMessage-methods-tf3833767s2354.html#a10853672
>>
>> But if only the stream pointer is updated, I suppose we could have
>> another
>> solution here, i.e.
>> declare inputStream field as 'mutable':
>>
>> mutable io::ByteArrayInputStream inputStream;
>>
>> In that case we could keep read methods const.
>>
>> I am requesting for that because at the moment such non-const API forces
>> app
>> level either always deal with non-const objects or make
>> const_cast<cms::BytesMessage *>(), that's not good.
>>
>> --
>> View this message in context:
>> http://www.nabble.com/BytesMessage-constness-tf4492790s2354.html#a12813490
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/BytesMessage-constness-tf4492790s2354.html#a12815039
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: BytesMessage constness
Posted by Motl <mo...@orcsoftware.com>.
Done.
https://issues.apache.org/activemq/browse/AMQCPP-143
nmittler wrote:
>
> I agree, this definitely would be a pain since the onMessage method gives
> you a const Message. Could you capture this issue in JIRA?
> http://issues.apache.org/activemq/browse/AMQCPP
>
> Thanks,
> Nate
>
>
> On 9/21/07, Motl <mo...@orcsoftware.com> wrote:
>>
>>
>> Hi,
>> I once asked you why readBytes() and other read methods aren't const:
>>
>> http://www.nabble.com/BytesMessage-methods-tf3833767s2354.html#a10853672
>>
>> But if only the stream pointer is updated, I suppose we could have
>> another
>> solution here, i.e.
>> declare inputStream field as 'mutable':
>>
>> mutable io::ByteArrayInputStream inputStream;
>>
>> In that case we could keep read methods const.
>>
>> I am requesting for that because at the moment such non-const API forces
>> app
>> level either always deal with non-const objects or make
>> const_cast<cms::BytesMessage *>(), that's not good.
>>
>> --
>> View this message in context:
>> http://www.nabble.com/BytesMessage-constness-tf4492790s2354.html#a12813490
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/BytesMessage-constness-tf4492790s2354.html#a12815039
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: BytesMessage constness
Posted by Nathan Mittler <na...@gmail.com>.
I agree, this definitely would be a pain since the onMessage method gives
you a const Message. Could you capture this issue in JIRA?
http://issues.apache.org/activemq/browse/AMQCPP
Thanks,
Nate
On 9/21/07, Motl <mo...@orcsoftware.com> wrote:
>
>
> Hi,
> I once asked you why readBytes() and other read methods aren't const:
>
> http://www.nabble.com/BytesMessage-methods-tf3833767s2354.html#a10853672
>
> But if only the stream pointer is updated, I suppose we could have another
> solution here, i.e.
> declare inputStream field as 'mutable':
>
> mutable io::ByteArrayInputStream inputStream;
>
> In that case we could keep read methods const.
>
> I am requesting for that because at the moment such non-const API forces
> app
> level either always deal with non-const objects or make
> const_cast<cms::BytesMessage *>(), that's not good.
>
> --
> View this message in context:
> http://www.nabble.com/BytesMessage-constness-tf4492790s2354.html#a12813490
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>