Community
Participate
Working Groups
Build Identifier: I20110310-1119 Hi, CDT Term!! I found CDT has a powerful parser. I am using CDT 8.0 with MSVC 2010, The build system is CMake. And it's works so well!! But now I found a issue, here is the test code. --- void testA(char* s) {} void testW(wchar_t* ws) {} #ifdef UNICODE #define test testW typedef wchar_t Char; #else #define test testA typedef char Char; #endif class A { public: void test(Char* str) {} }; int main() { A a; a. // issue occured here return 0; } --- When I typing "a.", There not have "test" member function, instead of "testA" If pre-defined macro "UNICODE" using: #define UNICODE .... Then the A::test changed to A::testW So, I think this should be a index bug. If you find some time, Please fix it. In ATL/WTL, There are many define like this. e.g. CWindow::MessageBox CWindow::SendMessage ... Many thanks!! Reproducible: Always
Created attachment 192886 [details] Screenshot for this issue
The proposal provided by CDT is correct: Depending on 'UNICODE' the member is actually named either 'testW' or 'testA'. It is understandable that you'd like to see the macro 'test' in the list of proposals.
(In reply to comment #2) > The proposal provided by CDT is correct: Depending on 'UNICODE' the member is > actually named either 'testW' or 'testA'. It is understandable that you'd like > to see the macro 'test' in the list of proposals. But in fact, class A, member function name: test, rather than testA or testW. CDT can not be distinguished here. This usage in Windows programming, it is very common. Hope to have a better solution.
(In reply to comment #3) > (In reply to comment #2) > > The proposal provided by CDT is correct: Depending on 'UNICODE' the member is > > actually named either 'testW' or 'testA'. It is understandable that you'd like > > to see the macro 'test' in the list of proposals. > > But in fact, class A, member function name: test, rather than testA or testW. > CDT can not be distinguished here. > This usage in Windows programming, it is very common. > Hope to have a better solution. Very difficult to solve this problem? Any comments？
