Re: Sanity check: public/private
Carlos Moreno wrote:
Jiang wrote:
Actually I do not known any compilers really treat
private and public member differently, because
access specifiers are purely logical constructs.
But I do not have a good reason to do such a
replacement. :-)
[...]
What I have in mind is debugging/testing (QA kind of
testing). Having client code (the "test protocol")
access to private data members gives you more flexibilty
in terms of easily creating test case scenarios.
You may encounter problems at least with Visual C++ (other compilers
may behave this way): it uses different name linkage for private
functions. In particular, the following program will not link:
----------------------------------------------- A.h
class A {
private:
void f();
};
----------------------------------------------- A.cpp
#include "A.h"
void A::f() { } // linker symbol "private: void A::f()"
----------------------------------------------- main.cpp
#define private public
#include "A.h"
int main()
{
A a;
a.f(); // linker: unresolved "public: void A::f()"
}
-----------------------------------------------
In particular, changing all the private to public
is about the worst possible idea!!
I agree, you are to use public interfaces in your tests.
The recommendation is a more granular design: every unit is rather
small and has testable public interface, even if some units are
private for casual user. E.g. we can use forward declarations to make
some classes privately declared. Or we can use "pimpl" idiom to hide
private dependencies with their declarations.
--
Andrei Polushin
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]