(*** This bug was imported into bugs.kde.org ***) Package: kdevelop Version: 2.1 (using KDE 3.0.0 ) Severity: normal Installed from: SuSE Compiler: gcc version 2.95.3 20010315 (SuSE) OS: Linux (i686) release 2.4.18-4GB OS/Compiler notes: The code: #ifdef LEAK_DETECTION #define GC_DEBUG #define SAVE_CALL_CHAIN #include <gc_cpp.h> class Network : public gc { #else class Network { #endif // LEAK_DETECTION causes the tree view to show class Network as a private class of Network. It doesn't appear to see that only one declaration can be active. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
This bug still persists. Anyone want to comment?? This seems more like a bad way of coding more than a class parsing bug.
No comments - I personally think this is a bad way of coding and I don't know if anyone would want to extend the class parser to handle something like this.
Subject: Re: #ifdef causes the class tree view to show private class The reason for this was that I used the Boehm garbage collector as a leak detector. I wanted to derive classes from class GC only in case of leak tracking. At that time I had no knowledge of another leak detector that did a decent job AND ran on Linux. That issue is now resolved. At any rate, it's conceivable that there are other reasons to derive from a base class only if certain conditions are given without that being bad coding. But you may be right, there are probably always more urgent issues Thanks -Rudiger --- Caleb Tennis <caleb@aei-tech.com> wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=42769 > caleb@aei-tech.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |WONTFIX > > > > ------- Additional Comments From caleb@aei-tech.com 2003-01-01 04:24 > ------- > No comments - I personally think this is a bad way of coding and I > don't know > if anyone would want to extend the class parser to handle something > like this.