Author Topic: Freezes when cursor is over the .second of a std::map iterator  (Read 870 times)

rowbearto

  • Senior Community Member
  • Posts: 1662
  • Hero Points: 119
Freezes when cursor is over the .second of a std::map iterator
« on: October 05, 2018, 07:23:14 pm »
I tried to make a small test project to repro it for you, but it doesn't seem to reproduce well that way. My real project is quite large, so maybe large project is needed?

Why I put the cursor on a "second" in mapiterator->second, SE often freezes for 10s of seconds.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2961
  • Hero Points: 440
Re: Freezes when cursor is over the .second of a std::map iterator
« Reply #1 on: October 05, 2018, 07:33:42 pm »
Is "mapiterator" a symbol that is defined in thousands of different classes ?  If you do a Ctrl+. on mapiterator, does SlickEdit clearly know which one to jump to ?

Also, what platform & compiler/version are we talking about here?

rowbearto

  • Senior Community Member
  • Posts: 1662
  • Hero Points: 119
Re: Freezes when cursor is over the .second of a std::map iterator
« Reply #2 on: October 05, 2018, 07:43:03 pm »
Quote
Is "mapiterator" a symbol that is defined in thousands of different classes ?  If you do a Ctrl+. on mapiterator, does SlickEdit clearly know which one to jump to ?

It is not a common symbol, it is a local defined in a "for" loop. Ctrl+. immediately goes to its definition. See example below:

Code: [Select]
  for (TaskStatsMap::iterator currentThreadIt = taskStatsMap_[currentTaskStatsIdx_].begin();
        currentThreadIt != taskStatsMap_[currentTaskStatsIdx_].end();
        ++currentThreadIt)
  {
    const int& pid = currentThreadIt->first;
    TaskStats& currentTaskStats = currentThreadIt->second;
  }

I'm on Linux x64. I'm using gcc (versions 3 (legacy) and 5 (modern)) to build my product.

rowbearto

  • Senior Community Member
  • Posts: 1662
  • Hero Points: 119
Re: Freezes when cursor is over the .second of a std::map iterator
« Reply #3 on: October 05, 2018, 07:44:38 pm »
I also happen to have a few levels of typedef:

Code: [Select]
template <typename _Key, typename _Tp, typename _Compare = std::less<_Key>,
          typename _Alloc = std::allocator<std::pair<const _Key, _Tp> > >
class CmnMap
{
public:
  #ifdef CMN_MAP_USE_STD
  typedef std::map<_Key, _Tp, _Compare, _Alloc> type;
  #else
  typedef boost::container::map<_Key, _Tp, _Compare, _Alloc> type;
  #endif
};

typedef CmnMap<int, TaskStats>::type TaskStatsMap;

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2961
  • Hero Points: 440
Re: Freezes when cursor is over the .second of a std::map iterator
« Reply #4 on: October 05, 2018, 08:10:20 pm »
Do you have CMN_MAP_USE_STD defined in your C/C++ preprocessing ?   Preferably to 1 rather than 0 because boost is so horrid.

rowbearto

  • Senior Community Member
  • Posts: 1662
  • Hero Points: 119
Re: Freezes when cursor is over the .second of a std::map iterator
« Reply #5 on: October 05, 2018, 08:18:08 pm »
I don't have CMN_MAP_USE_STD in the Slick preprocessing. I can try that.

In my real project I have it compiled once with it defined, and once with it not defined, because older versions of our product use an ancient compiler.

But for SlickEdit project, setting it will be fine for code browsing.

rowbearto

  • Senior Community Member
  • Posts: 1662
  • Hero Points: 119
Re: Freezes when cursor is over the .second of a std::map iterator
« Reply #6 on: October 05, 2018, 08:24:09 pm »
Adding that preprocessor symbol seems to have helped, I don't see those freezes :)

rowbearto

  • Senior Community Member
  • Posts: 1662
  • Hero Points: 119
Re: Freezes when cursor is over the .second of a std::map iterator
« Reply #7 on: October 05, 2018, 08:32:12 pm »
My small test workspace did not contain my boost project in its workspace so that is probably why I couldn't reproduce it with that.

Anyway, if it can happen with boost, it could happen with something else - maybe something to look into with lower priority. But I can workaround by defining the preprocessor symbol.