Re: destructor implementation picked up instead of class

[Brendan Miller]

GTAGSFORCECPP is ok.

Maybe, you could mention it in the "2.1 Preparation" section of the
manual, since this is a common option for C++ users.

I do get the same problem with typedefs and destructors with
GTAGSFORCECPP enabled. Actually, some of my typedefs are in .cpp
files.

With GTAGSFORCECPP it does find the class, but it also comes back with
a very long list of typedefs like:
CCsString         101
vobs/un_Core2/CsDBL/SrcInternal/CsDBLLCacheMemberLoadEnv.cpp typedef
std::map<CCsString, CCsString> NVPairs;

On Mon, Apr 5, 2010 at 6:37 PM, Shigio YAMAGUCHI <address@hidden> wrote:
> Hi,
> You might not set environment variable GTAGSFORCECPP.
> GLOBAL treats each *.h file as a C source file by default.
>
> This specification seems to bring confusions to C++ users.
> I want to find a better solution. If you have a better idea,
> please tell me. Thank you.
>
>> CCsString is the name of a class in our code base. If I enter this command:
>>
>> global -x CCsString
>>
>> I get this as a result:
>>
>> CCsString          81 vobs/un_General/libCommon/Src/CsString.cpp
>> CCsString::~CCsString()
>>
>> Global seems to think that the implementation of the destructor is a
>> definition, and tags it. This happens for other classes as well, aside
>> from the example CCsString class.
> --
> Shigio YAMAGUCHI <address@hidden>
> PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3
>