I've got a problem with gcc 3.4.2, which I suspect uses sgi's stl.

I'm trying to write a method that can identify duplicates in a container that stores an Edge object.  This object has a m_source and m_target attributes that need to be referenced in its compare function.

This edge comes from a third-party package and doesn't have an operator< method, so I've written a compare functor.

The method and its compare functor are:

struct ltSubgraph : public std::binary_function<DataEdge,DataEdge,bool>
{
  bool operator() (const DataEdge& s1, const DataEdge& s2) const
  {
    	return s1.m_source < s2.m_source || (!(s1.m_source < s2.m_source) && s1.m_target < s2.m_target);
  }
};


void
DataGraph::handleParallelEdges(void)
{
  typedef multiset<Edge,ltSubgraph> Edges;
  Edges edges;
  boost::graph_traits<GraphT>::edge_iterator ei,ei_end;
  for (tie(ei,ei_end)=boost::edges(dataGraph_);ei!=ei_end;++ei)
    edges.insert(*ei);
  for (Edges::const_iterator iter1 = edges.begin(); iter1 != edges.end(); advance(iter1,edges.count(*iter1)))
    if (edges.count(*iter1)>1) {
      cout << "See duplicate" << endl;
    }


As coded this routine hangs up when multiset.count is entered.
While it is in this state, I can see that my ltSubgraph functor is being continuously called.

If I replace Edge with std::pair, it works as expected.
However, I need the Edge object instead of a std::pair to actually implement this method (instead of printing to cout)

Can anybody explain this strange behavior?

Note that I've tried recoding ltSubgraph::operator() to recognize equality and return a hardcoded true, and then false.  The hang condition did not change.

Found my problem!
It was my ltSubgraph functor.
Instead of:
  return s1.m_source < s2.m_source ||
      (!(s1.m_source < s2.m_source) && s1.m_target < s2.m_target);
It needed to be:
  return s1.m_source < s2.m_source ||
      (!(s2.m_source < s1.m_source) && s1.m_target < s2.m_target);


user@domain.invalid wrote:
> I've got a problem with gcc 3.4.2, which I suspect uses sgi's stl.
> 
> I'm trying to write a method that can identify duplicates in a container that stores an Edge object.  This object has a m_source and m_target attributes that need to be referenced in its compare function.
> 
> This edge comes from a third-party package and doesn't have an operator< method, so I've written a compare functor.
> 
> The method and its compare functor are:
> 
> struct ltSubgraph : public std::binary_function<DataEdge,DataEdge,bool>
> {
>   bool operator() (const DataEdge& s1, const DataEdge& s2) const
>   {
>         return s1.m_source < s2.m_source || (!(s1.m_source < s2.m_source) && s1.m_target < s2.m_target);
>   }
> };
> 
> 
> void
> DataGraph::handleParallelEdges(void)
> {
>   typedef multiset<Edge,ltSubgraph> Edges;
>   Edges edges;
>   boost::graph_traits<GraphT>::edge_iterator ei,ei_end;
>   for (tie(ei,ei_end)=boost::edges(dataGraph_);ei!=ei_end;++ei)
>     edges.insert(*ei);
>   for (Edges::const_iterator iter1 = edges.begin(); iter1 != edges.end(); advance(iter1,edges.count(*iter1)))
>     if (edges.count(*iter1)>1) {
>       cout << "See duplicate" << endl;
>     }
> 
> 
> As coded this routine hangs up when multiset.count is entered.
> While it is in this state, I can see that my ltSubgraph functor is being continuously called.
> 
> If I replace Edge with std::pair, it works as expected.
> However, I need the Edge object instead of a std::pair to actually implement this method (instead of printing to cout)
> 
> Can anybody explain this strange behavior?
> 
> Note that I've tried recoding ltSubgraph::operator() to recognize equality and return a hardcoded true, and then false.  The hang condition did not change.

On Thursday, 23 September 2004 at 03:07:38 UTC, user wrote:
> Found my problem!
> It was my ltSubgraph functor.
> Instead of:
>   return s1.m_source < s2.m_source ||
>       (!(s1.m_source < s2.m_source) && s1.m_target < s2.m_target);
> It needed to be:
>   return s1.m_source < s2.m_source ||
>       (!(s2.m_source < s1.m_source) && s1.m_target < s2.m_target);
>
>
> user@domain.invalid wrote:
>> [...]

This is a very common problem and I have also reviewed this. So, I would simply suggest you visit https://supportphonenumberaustralia.com/snapchat-support-phone-number/ for the detailed information regarding this problem.