Re: [Discuss-gnuradio] Order of tags returned by gr::block::get_tags_in_range()/window()

[Marcus Müller]

Hi Martin,
you can, kind of, already do that:
If buffer->get_tags_begin returns a random_access_iterator, you're
dealing with the old deque, if it's just a bidirectional iterator,
you're dealing with the map implementation.
Checking that is um... C++ish and thus very beautiful. If my
understanding of what C++ compilers does is strong enough then the
following will be resolved at compile time:

#include <typeinfo>
#include <iterator>
...

  typedef std::iterator_traits<detail()->input(0)->buffer()->get_tags_begin()> 
traits; //input 0 exists, because where should tags come from if it didn't?
  bool is_sorted =  
!(typeid(traits::iterator_category)==typeid(std::random_access_iterator_tag));


So looking at this...
Yeah. A #define would probably be extremely handy. But since we can't
retroactively change history, people will want to check the GR version,
so it's also kind of redundant to our version numbers.

Cheers,
Marcus

On 06/25/2015 06:27 PM, Martin Braun wrote:
> On 25.06.2015 07:57, Jon Szymaniak wrote:
>> Thank you very much for the additional clarification and details, Doug
>> and Tom!
>>
>> So from what you've said, the ordering is an implementation-specific
>> detail that an API user shall not assume.  To ensure compatibility with
>> past, present, and future GNU Radio versions, the API user is
>> responsible for sorting the returned vector, if that's required. Do you
>> agree?
> Jon,
>
> Tom *did* say that tags are sorted since the multimap change. To be both
> forward- and mostly backward-compatible, what you're saying is true.
>
> I'm wondering if we might add a #define for the multimap change... that
> way, one could conditionally compile in a std::sort if required.
>
> Cheers,
> Martin
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio