[thedixon]

Actually clang 3.4 also compiles it just fine. Are you having an even older version?

[thedixon]

Update. This is not just boost. This particular type of template code produces the same complaint about protected member. Compiles just fine with gcc 5.4. Is that due to c++14 changes? If yes – any workaround short of waiting for the updated visual gdb with (hopefully) new clang?

 

enum BookEnum
{
 f = 1,
 s = 2
};

template <typename Derived>
 class CreatorHelper 
 {
 public:

 protected:
 template <BookEnum BOOK_TYPE>
 void* test();
 };

template <typename Derived>
 class FCreatorHelper
 :
 public CreatorHelper<Derived>
 {

 protected:
 Derived* derived() { return static_cast<Derived*>(this); }
 virtual void* foo();

 };

template <typename Derived>
void* FCreatorHelper<Derived>::foo()
{
 return derived()->template test<f>();
}

template <typename PipelineTraits>
 class RealCreator
 :
 public FCreatorHelper<RealCreator<PipelineTraits> >
 {
 };

class Traits
{
 
};
void foo1() {
 RealCreator<Traits> h;
 
}

Severity Code Description Project File Line Suppression State
Error [Clang IntelliSense] Error: ‘test’ is a protected member of ‘CreatorHelper<RealCreator<Traits> >’ Miscellaneous Files Header1.h 32
Message [Clang IntelliSense] declared protected here Miscellaneous Files Header1.h 14
Message [Clang IntelliSense] in instantiation of member function ‘FCreatorHelper<RealCreator<Traits> >::foo’ requested here Miscellaneous Files Header1.h 36

• This reply was modified 7 years, 7 months ago by thedixon.

[thedixon]

I’ve tried putting c:\path_to_solution in the relative path, had no effect, still produced

c:\path_to_solution\projectA\projectA\source.cpp some_error

which kinda makes sense, if what is said in the description of the relative path is true – “for files with no mapping”. Since it was mapping those paths to somewhere, I guess some other mapping rule was active?

[thedixon]

Confirmed as fixed. I have to say, I’m extremely impressed with support quality and responsiveness!

[thedixon]

Ah, replied without noticing your reply. Where is “preprocessor macros” field in the VisualGDB Project properties? I’m unable to find it for some reason. I’m using “custom build” type if it’s relevant

[thedixon]

I’m also seemingly unable to get rid of that define. I deleted DEBUG defines from all gcc_Debug.h that I could find, and intellisense still thinks it’s defined.

[thedixon]

I wasn’t getting any error messages, visualgdb would download files, and then would just hang in the “creating the project” phase, with a spinning cursor, until I kill visual studio. removing the symlink on linux and re-adding the project worked fine. I had multiple projects with similar symlinks inside, and the behavior was consistent everywhere. If there’re some log files or something that I can produce for you – I can do it.

ps. One thing that comes to mind is I’m not running with administrator rights on windows as per company policy. Proper symlink creation on win 7 require admin rights. Could it be related?

[thedixon]

There’s another problem with importing that I found. For some legacy reasons our git repo has symlinks in it. For example

project/src

project/project -> project/src

Importing projects like that from linux box would fail, until I would remove the symlink and re-import. Perhaps an option to be added not to follow symlinks.

[thedixon]

I did mean VisualGDB. Here’s the reason for the transfer from the verbose output:

1> C:\Users\dnikitin\riemann\tte\gcc_Debug.h was previously not transferred and will be transferred now

This is for every file. Seems rather strange, when I just created a project, and VisualGDB downloaded sources itself, and then decided to upload it. On top of being strange, it messed up git repo on a linux box, where I created a project from – every file had a timestamp updated, so git thought it was a giant change. I don’t think it’s quite correct behavior here.

On a subsequent builds it does behave properly though.

[Author]

Posts