Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

CC enhancements/alternatives

(1/3) > >>

MortenMacFly:

--- Quote from: thomas on February 06, 2012, 03:58:51 pm ---Hopefully we don't ever declare a local variable somewhere after a CC_LOCK then.

--- End quote ---
So what? The worst that can happen is a compiler error in that case... or am I missing something?!


--- Quote from: thomas on February 06, 2012, 03:58:51 pm ---And lastly, hopefully you'll get rid of 90% of these locks (which is the entire point).

--- End quote ---
Well that's the point, my intention on doing this was to understand why and where all these locks are needed. And in fact, I am a bit frustrated now. So, we need to protect the parser, the tokens tree and the class browser thread from cross-use. therefore three mutexes are floating around. However, accessing the tokens tree and its content is really scattered (for various reason) and I don't see a good way how this could be done better. There are a lot of cases where you need to access the tree and/or the parser in different ways from different sources or you loose CC capabilities.

How on earth could this be done better? We can start a discussion...

BTW: In theory, the construct should be robust enough that we could try 2 or more parsing threads now IMHO.

oBFusCATed:

--- Quote from: MortenMacFly on February 06, 2012, 08:00:28 pm ---However, accessing the tokens tree and its content is really scattered (for various reason) and I don't see a good way how this could be done better.

--- End quote ---
Have you thought of defining simple public interface?
An interface which have all the features needed by the outside world and not exposing the guts for the parser.

BTW: Is there any actual reason to continue working on our parser? Have you tried the clangs plugin? (I've not, but I think this is the only reasonable direction we should take, when talking about the CC)

MortenMacFly:

--- Quote from: oBFusCATed on February 06, 2012, 08:12:38 pm ---Have you thought of defining simple public interface?

--- End quote ---
Hehe - sure. That was also the original intention, but you have just way too many interfaces you need. That's the point here.


--- Quote from: oBFusCATed on February 06, 2012, 08:12:38 pm ---Is there any actual reason to continue working on our parser? Have you tried the clangs plugin? (I've not, but I think this is the only reasonable direction we should take, when talking about the CC)

--- End quote ---
I think it's still quite good and fast. The only alternative I see is to make use of Eran's CodeLite and wrap it in a plugin. Instead of wrapping Clang itself this would have been a way better choice (not that I don't like the clang plugin though). However, I don't have time for this and I know it not well enough to honest, so I cannot measure the effort it needs. I already asked in the forums for people willing to try, but nobody responded so far. :-(

Maybe if Eran could give a starter this would be of help (he is interested in it, too)...?!

oBFusCATed:
I have some little interest, but I fear that I'll get trapped in a major refactoring similar to the one related to the debugger, so I restrain myself from thinking too much about CC :)

ollydbg:

--- Quote from: MortenMacFly on February 06, 2012, 08:30:04 pm ---I think it's still quite good and fast. The only alternative I see is to make use of Eran's CodeLite and wrap it in a plugin.

--- End quote ---
CodeLite now integrates the Clang codecompletion feature.
You want to wrap Codelite's CC, do you mean the "original CC in Codelite" or "the total thing" (include Clang cc in Codelite) ?

Navigation

[0] Message Index

[#] Next page