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 <[email protected]> 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 <[email protected]> > PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 > _______________________________________________ Bug-global mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-global
