Re: Bug in cpp iterator begin ?

Les Spiro

You can’t redefine the behaviour of a method that people are using. 

The primary point of OpenMama at the moment is to provide access to various Platforms and Middleware’s to applications and developers using the OpenMama API. In that context existing applications and developers who are already experienced in the API make up the overwhelming majority of the who we are targeting.

If we want more ’standard' behaviour in an Iterator, then I think we have to define a new iterator with the desired behaviour and possibly deprecate the current standard over time.

Leslie Spiro

From: Benjamin Taieb <benjamin.taieb@...>
Date: Tuesday, 21 January 2014 17:02
To: Damian Maguire <DMaguire@...>, "openmama-dev@..." <openmama-dev@...>
Subject: Re: [Openmama-dev] Bug in cpp iterator begin ?

Hi Damian,

That is very unfortunate indeed. That mean that every single payload will have to implement that, making it even further difficult to migrate back to the right thing.

May I suggest we look to have a mama properties to control that behaviour, allowing people to code "the right thing" in their payload, yet retaining backward compatibility and backward compatibility being the default ?


If others on the list have develop payload bridge, would like to hear their thoughts...




From: Damian Maguire [mailto:DMaguire@...]
Sent: 21 January 2014 14:42
To: Benjamin Taieb; openmama-dev@...
Subject: Re: [Openmama-dev] Bug in cpp iterator begin ?


Hey Benjamin, 


What you're seeing is unfortunately a legacy behavior within the underlying C level message iterators, which exists as something of a historical artifact of OpenMAMA's development. Essentially, the begin function call should point to the point before the first element (while also returning that element). A subsequent call to next should then step through to the first element, returning it again. If you check out the qpidmsgPayloadIter_begin code (in mama/c_cpp/src/c/payload/qpidmsg/iterator.c) you'll see how the Qpid bridge handles this case.


Tidying up the entire iterator interface is something we've wanted to do for a while – ideally something that at a C++ level fits much more neatly with the STL semantics, while maintaining performance through the MAMA layer. Unfortunately this sort of change is likely to alter the behavior a large number of our users expect (keeping in mind that MAMA has over 9 years production usage), which makes it a non-trivial change. That said, I think this is a likely goal for an OpenMAMA 3.0 release. I'm looking to start documenting these sorts of inconsistencies in near future, so we can consider planning the next major release.


Any questions let me know.






Damian Maguire – Senior R&D and OpenMAMA Specialist

IntercontinentalExchange | NYSE Technologies

24-26 Adelaide Exchange | Belfast, BT2 8GD

Tel: +44 2890 822 282 (ext: 452161) | Mob: +44 7540 204 077


From: Benjamin Taieb <benjamin.taieb@...>
Date: Tuesday, January 21, 2014 10:19 AM
To: "openmama-dev@..." <openmama-dev@...>
Subject: [Openmama-dev] Bug in cpp iterator begin ?


Hi list,

When doing some test withh cpp iterator, we have a problem with the first field being missed. This can be traced back to the below function in MamaMsg.cpp :


MamaMsgField& MamaMsg::begin (MamaMsgIterator& theiterator) const






        mamaMsgIterator_begin (



        theiterator.mMsgField.set (



        return (theiterator.mMsgField);



To me, it seems that by calling mamaMsgIterator_begin and mamaMsgIterator_next, you're now positioned and will return the 2nd field.


Let me know if I'm missing something.

Happy to submit a patch if confirmed as a bug.


Benjamin Taieb.

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange Group, Inc. (ICE), NYSE Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

Join to automatically receive all group messages.