home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 33,177 of 33,346   
   =?windows-1252?Q?Daniel_Kr=FCgler?= to All   
   Re: Is it a bad idea to define private:    
   25 Aug 13 18:58:11   
   
   From: daniel.kruegler@googlemail.com   
      
   Am 25.08.2013 14:43, schrieb DeMarcus:   
   > In books about TDD I've seen various solutions to do White-Box   
   > testing, i.e. test the protected and private parts of classes.   
   >   
   > I came up with an idea that if you do the following it would be easy   
   > to test the internal parts of a class.   
   >   
   > #define protected public   
   > #define private public   
      
   Don't follow this dark path, Luke.   
      
   1) Doing so is undefined behaviour as of [macro.names] p2:   
      
   "A translation unit shall not #define or #undef names lexically   
   identical to keywords, to the identifiers listed in Table 3, or to the   
   attribute-tokens described in 7.6."   
      
   2) Even more so in the concrete example you present it also easily (if   
   not always in a realistic program) violates the one-definition rule (3.2   
   p6) as part of the core language, because there are two different   
   definitions of class PrintClass present in the program.   
      
   3) As of C++11 doing so has the potential to influence overload   
   resolution of function template, because access checking is now part of   
   the template substitution process.   
      
   > Here's an example that compiles with gcc 4.7.2.   
   >   
   > // PrintClass.h   
   > #include    
   >   
   > class PrintClass   
   > {   
   > public:   
   >      std::string print() { return "Printing"; }   
   > private:   
   >      std::string privatePrinting() { return "Printing private"; }   
   > };   
   >   
   >   
   > // main.cpp   
   > #include    
   >   
   > #define protected public   
   > #define private public   
   >   
   > #include "PrintClass.h"   
   >   
   > void whiteBoxTest()   
   > {   
   >      PrintClass pc;   
   >      std::cout << pc.privatePrinting() << std::endl;   
   > }   
   >   
   > int main()   
   > {   
   >      whiteBoxTest();   
   >      return 0;   
   > }   
   >   
   > My question is: is this a bad idea?   
      
   Yes indeed, see above why.   
      
   > I can't really see the bad consequences but I guess things like SFINAE   
   > could break.   
      
   Indeed.   
      
   They are much easier way to realize white box testing: Just declare a   
   Test class as friend, e.g.   
      
   #include    
      
   class PrintClass   
   {   
   public:   
       std::string print() { return "Printing"; }   
   private:   
       std::string privatePrinting() { return "Printing private"; }   
       friend class Tester;   
   };   
      
      
   // main.cpp   
   #include    
      
   #include "PrintClass.h"   
      
   struct Tester {   
     static std::string privatePrinting(PrintClass& pc)   
     {   
       return pc.privatePrinting();   
     }   
   };   
      
   void whiteBoxTest()   
   {   
       PrintClass pc;   
       std::cout << Tester::privatePrinting(pc) << std::endl;   
   }   
      
   int main()   
   {   
       whiteBoxTest();   
       return 0;   
   }   
      
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca