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 |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca