Author Topic: too many lockers in CC's code  (Read 6166 times)

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5721
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
too many lockers in CC's code
« on: August 30, 2011, 07:37:23 am »
I just compare with codelite's cc code, and only 4-5 critical sections lockers there.
In codeblocks' cc code, there are many many lockers.

So, I suspect there are some design errors.

What I would say is: Use TokensTree when it is ready, don't use it when some parserthread is running.

what's your opinion? morten? loaden?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5721
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: too many lockers in CC's code
« Reply #1 on: September 06, 2011, 03:22:40 am »
Since no one has the option, I continue give more evidence from my point.

1, use locker in any access to Tokenstree/Token/TokenIdx is really ugly and bad design.

If you search all the CC's source code by the keyword "Token", you should notice that most usage is a "Token*" which point to data in TokensTree, then every place where you have "Token*" should/must have a locker or a high level locker.

If you search the Tokenstree or other Token related data, you also need an locker.

The whole Tokenstree is dynamically changing (thus it is violate) when you are running the parserthread. The Token contents can be changed/updated, the TokenIdx can be changed even some Tokens will be deleted.

2, Using a lot of locker objects is really ugly. The whole CC's source code is polluted by such mechanism. :(


If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.