Iterator initialization problem...

[John E]

This code apparently compiles with gcc but is giving me a compiler error with MSVC:-

namespace {
struct id_compare
{
	bool operator()(const boost::shared_ptr<Playlist>& p1, const boost::shared_ptr<Playlist>& p2)
	{
		return p1->id () < p2->id ();
	}
};

typedef std::set<boost::shared_ptr<Playlist> > List;
typedef std::set<boost::shared_ptr<Playlist>, id_compare> IDSortedList;

static void
get_id_sorted_playlists (const List& playlists, IDSortedList& id_sorted_playlists)
{
	for (List::const_iterator i = playlists.begin(); i != playlists.end(); ++i) {
		id_sorted_playlists.insert(*i);
	}
}

} // anonymous namespace

void
SessionPlaylists::add_state (XMLNode* node, bool full_state)
{
	IDSortedList id_sorted_playlists;
	get_id_sorted_playlists (playlists, id_sorted_playlists);

	List::iterator i = id_sorted_playlists.begin (); // <--- ERROR HERE !!

	// Do some stuff
}

I see this error at the indicated line:-

error C2440: 'initializing' : cannot convert from 'std::_Tree<_Traits>::iterator' to 'std::_Tree<_Traits>::iterator'
        with
        [
            _Traits=std::_Tset_traits<boost::shared_ptr<ARDOUR::Playlist>,`anonymous-namespace'::id_compare,std::allocator<boost::shared_ptr<ARDOUR::Playlist>>,false>
        ]
        and
        [
            _Traits=std::_Tset_traits<boost::shared_ptr<ARDOUR::Playlist>,std::less<boost::shared_ptr<ARDOUR::Playlist>>,std::allocator<boost::shared_ptr<ARDOUR::Playlist>>,false>
        ]

        No constructor could take the source type, or constructor overload resolution was ambiguous

Can anyone explain what's wrong here..?

[John E]

Taking id_compare out of the equation seems to make it compile - i.e. if I declare IdSortedList like this:-

typedef std::set<boost::shared_ptr<Playlist> > IDSortedList;

I visited MSDN and realised that for std::set, VS2013 has a lot more c'tors than VS2005 which I'm using. So is this maybe a C++11 extension or something like that?

[2kaud]

For

List::iterator i = id_sorted_playlists.begin (); // <--- ERROR HERE !!

try

IDSortedList::iterator i = id_sorted_playlists.begin (); // <--- ERROR HERE !!

This is where auto type comes in handy!

[John E]

Thanks 2kaud, you just beat me to it. I literally figured it out about 10 seconds ago !!

Interesting (again...) that it compiles with gcc !

[superbonzo]

Interesting (again...) that it compiles with gcc !

this is an example of a SCARY iterator assignment ( see this paper for example ), it's always been perfectly legal for a compiler to not diagnose such cases because iterators of different containers have never been required to be different types under the hood.

That said, gcc behaviour is explicitly allowed since c++11, and it may be standardized as required in the future.

[John E]

Thanks Superbonzo. Just out of curiosity...

What would be the advantage of using an iterator that's different from the type of objects being iterated? e.g. in this case, using List::iterator to iterate over objects of type IDSortedList? I guess one advantage is that it might facilitate different sorting methods (i.e. different criteria for deciding greater than / less than). Any other advantages?

[superbonzo]

the idea behind scary iterators is general.

Consider a class template foo<T1,T2,...> and a member type foo<...>::bar_type

now, the claim behind the SCARY iterator proposal is that whenever some Ti is conceptually indipendent from bar_type, then the latter should not change whenever the former changes, type wise.
why, correctness aside ? because in this way you can exploit static polymorphism and pass around bar_type's instances coming from possibly different foo<>'s without harm ( for the aforementioned reasons) nor performance penalty ( you'd need dynamic polymorphism otherwise ).

In the container case, a container iterator serves two purposes, it gives a view of some container element ( via dereferencing ) and provides a way to step to its neighbours ( via incrementing ); both operations are independent from things like allocators, comparators, etc... and hence should not depend on them ( of course, comparators do influence the way elements are iterated, but this is not a responsability of the iterator, but of the container accessors that commit them ).