Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: smallB on October 23, 2011, 05:57:41 pm

Title: Matching template brackets
Post by: smallB on October 23, 2011, 05:57:41 pm
I think that having matching template brackets highlighted would be quite nice (specially for metaprogramming tasks). Anyway, this would also make Code::Blocks behaving in more unified way:
Why do we highlight:
a) [ and ]
b) ( and )
but not < and >
?
Title: Re: Matching template brackets
Post by: oBFusCATed on October 23, 2011, 06:47:09 pm
Because it is hard to do. e need a semantic highlighting, but we don't have it currently.

Think about this:
Code
if (a<b && b>c)
   ...
This one should not be highlighted, but this:

Code
if (a<int>(5, 10)==5)
  ...
should.

If can describe an algorithm, which works correctly for all the cases, then we can implement it.
Title: Re: Matching template brackets
Post by: smallB on October 24, 2011, 07:46:55 am
How about (for a start only):  
If 'a' is a template then:
1. '<' means start of template parameters,
2. If above applies, then next token must be a type or if a has integral type as a template param then this token must be of this type?
3. If 'a' isn't a template then '<' means less than.
Title: Re: Matching template brackets
Post by: oBFusCATed on October 24, 2011, 11:15:00 am
Quote from: smallB on October 24, 2011, 07:46:55 am
How about (for a start only):  
If 'a' is a template then:
When we do brace matching, we don't know if a is template or not.
The brace matching is done in core, but knowing if a is template is done/stored in CC plugin.
Title: Re: Matching template brackets
Post by: smallB on October 24, 2011, 12:41:05 pm
But surely there must be a way to get this info from CC or get this info in other way?
Title: Re: Matching template brackets
Post by: MortenMacFly on October 24, 2011, 04:27:14 pm
Quote from: smallB on October 24, 2011, 12:41:05 pm
But surely there must be a way to get this info from CC or get this info in other way?
Plugins are generally independent. This means, a plugin must provide an interface to the core to obtain data from it. For brackets / CC internals (i.e. the SearchTree) this is not the case.
Title: Re: Matching template brackets
Post by: Jenna on October 24, 2011, 09:13:39 pm
Quote from: MortenMacFly on October 24, 2011, 04:27:14 pm
Quote from: smallB on October 24, 2011, 12:41:05 pm
But surely there must be a way to get this info from CC or get this info in other way?
Plugins are generally independent. This means, a plugin must provide an interface to the core to obtain data from it. For brackets / CC internals (i.e. the SearchTree) this is not the case.
And what's more the core can not rely on cc, because (as all plugins) the user might have disabled it.
Title: Re: Matching template brackets
Post by: Alpha on October 25, 2011, 12:33:18 am
As a suggestion, would it be possible for the core to query CC (to determine if it is active, and a supported version); then using the result, enable/disable the function to match < >?
In this way the core could take advantage of the existence of CC, with a fallback to its original state (so the core does not become dependent).
Title: Re: Matching template brackets
Post by: oBFusCATed on October 25, 2011, 01:11:03 am
It can probably, but someone should do it.
Title: Re: Matching template brackets
Post by: ollydbg on October 25, 2011, 02:46:57 am
Our parser does not do the semantic analysis, and the C++'s grammar it too complex and context depend, so We can't even give a precise information whether an identifier is a template or not, and it is much depend on the context. (by context, I mean the #include, using directive, #if ....., all the things can change the context information)

So, it is too hard to implement this kind of feature.
Title: Re: Matching template brackets
Post by: Alpha on October 26, 2011, 11:17:51 pm
Quote from: ollydbg on October 25, 2011, 02:46:57 am
... We can't even give a precise information whether an identifier is a template or not...
Does this mean that there are (a few) cases in which CC can guarantee that it has correctly determined if something is a template?  If so, matching could be limited to those cases.

The following algorithm matches some basic cases.  (I do not believe it will give any false positives, but I could be wrong.)
Title: Re: Matching template brackets
Post by: thomas on October 27, 2011, 11:01:24 am
Quote from: Alpha on October 26, 2011, 11:17:51 pm
Does this mean that there are (a few) cases in which CC can guarantee that it has correctly determined if something is a template?  If so, matching could be limited to those cases.
That's certainly not a good idea. Either such a feature should work (to the implementor's ability) 100% or not at all. If it works 50% of the time, it is not only worthless, but actually hindering workflow. People will wonder 50% of the time whether they did something wrong when they didn't, just because a color coding they expect does not show.
Title: Re: Matching template brackets
Post by: Alpha on October 27, 2011, 11:55:31 pm
What about having this as an editor setting that is disabled by default (and with a tool-tip explaining why)?  This way, people who go to the effort of activating it would be the ones who want it enough not to be bothered by sporadic behavior.  Also, it would give a spot for additional algorithms to be added as they become available.
Title: Re: Matching template brackets
Post by: oBFusCATed on October 28, 2011, 12:38:45 am
Because it is a waste of time to implement something which will not work 100% and will be useful to very few people.
Title: Re: Matching template brackets
Post by: smallB on October 28, 2011, 09:41:38 am
@obfuscated although I agree with you that it is rather not satisfactory situation when feature doesn't work 100% I have to take and issue.
Nothing works 100%. To greater or lesser extend.
Look at c::b's smartsense. Does it work for 100% of the time? No. Is it useful? Sure. Would it be good to have it improved? Yes, but you see this is only possible if the feature is at least partially implemented. You cannot improve unimplemented feature.
Again, I also cannot agree with you when you say that only few people would use it. From where this assurance comes from? If anything mass of people would at least try it and give feedback (which in turn would allow to improve this feature and so on and so on). Why do I say mass of people not few like you're saying? My reasoning is simple: I personally don't know a C++ dev who doesn't use templates.
Title: Re: Matching template brackets
Post by: MortenMacFly on October 28, 2011, 10:02:07 am
Quote from: smallB on October 28, 2011, 09:41:38 am
From where this assurance comes from?
Simple: After years you are the first asking for this feature and I don't see many people agree.

However, even if we agree that such an option is useful, there are plenty of others that have higher priority. You can help at most by providing a patch. This would be a real time-saver.
Title: Re: Matching template brackets
Post by: smallB on October 28, 2011, 05:50:25 pm
@Morgen as I've already explained to a obfuscated "I'm not there yet" to work on patches, but you can surely count on me when my time come.
Regards
Title: Re: Matching template brackets
Post by: Alpha on October 28, 2011, 11:13:19 pm
Quote from: oBFusCATed on October 28, 2011, 12:38:45 am
Because it is a waste of time to implement something which will not work 100% and will be useful to very few people.
Thanks for the logic; I had lost sight of the big picture.
Title: Re: Matching template brackets
Post by: chameleon on April 06, 2013, 05:42:40 pm
I come here from a search in google.
Yes.
It is very helpful to highlight template braces.

Especially with C++11

Code
typename std::iterator_traits<typename std::remove_reference<C1>::type::iterator>::value_type();
Title: Re: Matching template brackets
Post by: Alpha on April 07, 2013, 12:57:50 am
Quote from: chameleon on April 06, 2013, 05:42:40 pm
It is very helpful to highlight template braces.
Useful, yes, but very hard to implement.  Do you have ideas of how this could be done?