Re: [Boost-users] [test] testing protected/private methods out of test suits
Hi,
I'm not sure I understand the problem. This hack works regardless of the library decomposition. Visibility is purely a source-code concern, just include #defines and the header declaring the class and you can access anything even if it is in a different library.
I don't believe this is true for all compilers or in all cases. For example, >changing the member visibility in a class I worked on broke binary >compatibility in a library I built with MSVC++ 8. Similar complications may >arise when using symbol hiding techniques, such as compiler-specific symbol >visibility support, link scripts, etc
I've exactly that problem with MSVC++7.x. Compiling the class_to_test in the library with protected methods and trying to access this methods out from the test_case_class by including the header and #define protected public, gives me a "symbol not found compiler error". :-/
Hi ! On Friday 19 September 2008 21:37:01 trashing@gmx.net wrote:
I've exactly that problem with MSVC++7.x. Compiling the class_to_test in the library with protected methods and trying to access this methods out from the test_case_class by including the header and #define protected public, gives me a "symbol not found compiler error". :-/
Yes, that trick will not work with msvc because the access specifiers (public, protected, private) get into the mangled name in the lib. So you are out of luck here ;-(( Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
On Sun, Sep 21, 2008 at 2:23 AM, Juergen Hunold <juergen.hunold@ivembh.de>wrote:
On Friday 19 September 2008 21:37:01 trashing@gmx.net wrote:
I've exactly that problem with MSVC++7.x. Compiling the class_to_test in the library with protected methods and trying to access this methods out from the test_case_class by including the header and #define protected public, gives me a "symbol not found compiler error". :-/
Yes, that trick will not work with msvc because the access specifiers (public, protected, private) get into the mangled name in the lib. So you are out of luck here ;-((
The '#define private public' trick works for me using MSVS 2005 and static libraries. Jon
Jonathan Franklin writes:
On Friday 19 September 2008 21:37:01 trashing@gmx.net wrote:
I've exactly that problem with MSVC++7.x. Compiling the class_to_test in the library with protected methods and trying to access this methods out from the test_case_class by including the header and #define protected public, gives me a "symbol not found compiler error". :-/
Yes, that trick will not work with msvc because the access specifiers (public, protected, private) get into the mangled name in the lib. So you are out of luck here ;-((
The '#define private public' trick works for me using MSVS 2005 and static libraries.
I would swear that the standard indicated that public/private had no effect on visibility, just accessibility. That is, changing a symbol's access from private to public did not change the meaning of a program. Stroustrup uses such language in the D&E of C++. Obviously, Microsoft thinks differently. Cheers, -- Robert
AMDG Robert Mecklenburg wrote:
I would swear that the standard indicated that public/private had no effect on visibility, just accessibility. That is, changing a symbol's access from private to public did not change the meaning of a program. Stroustrup uses such language in the D&E of C++.
If it is public in some places and private in others, it violates the one definition rule and all bets are off. In Christ, Steven Watanabe
On Mon, Sep 22, 2008 at 12:44:01PM -0600, Robert Mecklenburg wrote:
I would swear that the standard indicated that public/private had no effect on visibility, just accessibility. That is, changing a symbol's access from private to public did not change the meaning of a program. Stroustrup uses such language in the D&E of C++.
I recall somewhat vaguely a similar discussion on comp.lang.c++.moderated where the conclusion was that redefining keywords such as public/private via preprocessor macros leads to undefined behavior. I don't think that MS violates the standard with this particular behavior.
Zeljko Vrba wrote:
On Mon, Sep 22, 2008 at 12:44:01PM -0600, Robert Mecklenburg wrote:
I would swear that the standard indicated that public/private had no effect on visibility, just accessibility. That is, changing a symbol's access from private to public did not change the meaning of a program. Stroustrup uses such language in the D&E of C++.
I recall somewhat vaguely a similar discussion on comp.lang.c++.moderated where the conclusion was that redefining keywords such as public/private via preprocessor macros leads to undefined behavior. I don't think that MS violates the standard with this particular behavior.
Correct. This is worded in C++03, [lib.macro.names]/2: "[..] Nor shall such a translation unit define macros for names lexically identical to keywords." The current working paper has refined this in [macro.names]/2: "A translation unit shall not #define or #undef names lexically identical to keywords." Greetings from Bremen, Daniel
On Mon, Sep 22, 2008 at 11:32 AM, Jonathan Franklin < franklin.jonathan@gmail.com> wrote:
The '#define private public' trick works for me using MSVS 2005 and static libraries.
Turns out that it only worked for me when building Debug. The Release build generated undefined symbol errors at link-time. Jon
participants (7)
-
Daniel Krügler -
Jonathan Franklin -
Juergen Hunold -
Robert Mecklenburg -
Steven Watanabe -
trashing＠gmx.net -
Zeljko Vrba