Author Topic: Suggestions on how to deal with inlined definitions within a namespace  (Read 1871 times)

b

  • Senior Community Member
  • Posts: 320
  • Hero Points: 26

I'm working on a large source base, which I'm trying to set up SE to tag.   However, I've noticed that the first miss on an interpreted tag can cause subsequent failures (even when they exist).


Regardless, I'm seeing the following pattern that I'm not sure how to coax SE to interpret.  Again, this is a preexisting large source base, so changing this everywhere is not an option.


The inclusion of variables, et al. into a namespace via another include appears to be tripping up SE.   The following is a pretty minimal basic implementation of the preexisting pattern.


foo.cpp:
Code: [Select]
#include "bar.h"
namespace a {
   some_reference_to = b::c::SOMEVAR;
}


bar.h:
Code: [Select]
#include "barType"
namespace a {
namespace b {
namespace c {
#include "baz.inl"
}}}


baz.inl:
Code: [Select]
const b::bType SOMEVAR = 1;



barType.h:
Code: [Select]
namespace a {
namespace b {
typedef uint32_t bType;
}}

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3234
  • Hero Points: 460
Re: Suggestions on how to deal with inlined definitions within a namespace
« Reply #1 on: October 16, 2019, 03:21:12 pm »
Yep, we can't handle that unless we did full preprocessing (recursively parsing #includes).

There is some trickery you could play with preprocessing, but it would amount to about the same amount of work as fixing the unruly source code.

b

  • Senior Community Member
  • Posts: 320
  • Hero Points: 26
Re: Suggestions on how to deal with inlined definitions within a namespace
« Reply #2 on: October 16, 2019, 04:18:19 pm »
Yep, we can't handle that unless we did full preprocessing (recursively parsing #includes).

There is some trickery you could play with preprocessing, but it would amount to about the same amount of work as fixing the unruly source code.

I'd still be interested as I may not be able to push a change of the source (impacts too many product lines and the code has been validated).


The push back I get is to use the native tools (Vivado) or VS.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 3234
  • Hero Points: 460
Re: Suggestions on how to deal with inlined definitions within a namespace
« Reply #3 on: October 16, 2019, 04:47:14 pm »
If the main area where this is an issue is Symbol Coloring, you could select the "Use fast, simplistic symbol lookup algorithm" (Document > C/C++ Options... > View), which identifies symbols simply by their name, then you won't get a bunch of symbols colored as "Unidentified", but obviously, Symbol Coloring will not be as accurate using this option.

Tag Navigation will still be able to find those symbols if you have the ".inl" files in your workspace so that they are tagged.  You might have to pick through a few choices if there are duplicates, so that is mainly an inconvenience.  References might work well enough also, because as far as it knows the symbols in the inline are still found in an outer namespace, and where it can not resolve the prefix qualification, they will still show up as unidentified references.

The main area where you will be at a roadblock is symbol completion (list-members), because the data is just not there.

I will add it to my list for 24.0.1 to investigate adding a #include preprocessing option (default off for performance) for C/C++ tagging.  We do this sort of thing for COBOL and Verilog where this sort of inane code is the norm, so it definitely is possible to implement, we have just held off because generally you do not see this pattern very frequently in C and C++ code so we did not want to introduce a feature that could be potentially harmful to performance for no good reason.

b

  • Senior Community Member
  • Posts: 320
  • Hero Points: 26
Re: Suggestions on how to deal with inlined definitions within a namespace
« Reply #4 on: October 16, 2019, 05:00:18 pm »

+1 on the feature.   


I agree it is not a pattern that I like as it obfuscates the code, but that's why I use SE to begin with--to reveal the linkages not apparent in unfamiliar source.   I like the idea of leaving it as a choice to take the performance hit.  In my case, I'd rather take the hit and be chase the linkages than all the bookmarks and hand scribblings I'm doing now.

rowbearto

  • Senior Community Member
  • Posts: 1875
  • Hero Points: 122
Re: Suggestions on how to deal with inlined definitions within a namespace
« Reply #5 on: October 16, 2019, 06:02:31 pm »
I use "language server protocol" (LSP) code browsers along with SlickEdit to accomplish this kind of code browsing. I've been using "ccls" (and trying out "clangd"). I had to write my own macro/Python scripts for the glue for SlickEdit to speak "language server protocol" to interact with ccls/clangd - it is not in a state to be shared though.

These LSP code browsers also work with many other IDEs/editors like VS, Vim, Emacs, etc. I've made a feature request for SlickEdit to provide an LSP client before.

But I've also found that ccls is missing some things that the SlickEdit tagging engine finds, also vice versa. They are a good complement to each other.

Having an LSP client would make SlickEdit on par for this type of code browsing with the other IDEs/editors. And pile Slicks own tagging engine on top of that and it is a super powerful tool.

b

  • Senior Community Member
  • Posts: 320
  • Hero Points: 26
Re: Suggestions on how to deal with inlined definitions within a namespace
« Reply #6 on: October 16, 2019, 06:12:33 pm »
@rowbearto thanks for the tip. 

b

  • Senior Community Member
  • Posts: 320
  • Hero Points: 26
Re: Suggestions on how to deal with inlined definitions within a namespace
« Reply #7 on: October 18, 2019, 12:11:21 am »
If the main area where this is an issue is Symbol Coloring, you could select the "Use fast, simplistic symbol lookup algorithm" (Document > C/C++ Options... > View), which identifies symbols simply by their name, then you won't get a bunch of symbols colored as "Unidentified", but obviously, Symbol Coloring will not be as accurate using this option.



I actually discovered that this makes things worse.    I haven't really seen a discernable difference (other than screen coloring time) between the strict and relaxed symbol look up options.