does anyone else notice this works?
make a class with private fields, and include the define
then you can access the private fields no problem from outside the class. i thought private was a protected keyword....?
does anyone else notice this works?
make a class with private fields, and include the define
then you can access the private fields no problem from outside the class. i thought private was a protected keyword....?
It's a macro, macros are evil, the pre-processor knows nothing of C or C++
It is, but how said grib the preprocessor is who cares about macros. To the preprocessor there are no keywords. He simply changes words...
Nothing more to tell about me...
Happy day =)
The preprocessor doesn't care about the C++ language. It is in fact, run before the compiler. Basically, what your #define does is tells the preprocessor to look up every instance of the string 'private' and replace it with the string 'public' in your code. You can do ridiculous things with it. For example:
As you can see, ridiculous. Avoid that sort of thing in programs. It will only make your life harder when you start getting errors on code that seems (and in fact is) correct because a substitution was being made before the code was compiled.Code:#define class int class main(class argc, char** argv) { ... }
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
At first I thought that coding this would be absurd, but believe it or not, this actually came in handy today! What could possibly make "#define private public" useful, you ask?
Unit testing! I had to unit test a class, and one public method that I was testing results in a member variable of an object changing. There's no way of testing that the method was successful, without directly verifying that this private member variable was updated to the new value I was expecting.
So all I did was #define private public, and now I can check the member variable directly! The #define is in the unit test itself, so it of course doesn't affect any "real" code.
And to think that I've actually seen people declare their unit test classes as friends of the class they're testing - just to make unit testing easier. Well, now they don't have to with this trick - which is certainly better than changes to the actual code being tested.
Just
"C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement."
- Drew Olbrich
I prefer just to put my publics first, then I can just comment out the private: line when I want to expose my privates to the world.Originally posted by Just
At first I thought that coding this would be absurd, but believe it or not, this actually came in handy today! What could possibly make "#define private public" useful, you ask?
Unit testing! I had to unit test a class, and one public method that I was testing results in a member variable of an object changing. There's no way of testing that the method was successful, without directly verifying that this private member variable was updated to the new value I was expecting.
So all I did was #define private public, and now I can check the member variable directly! The #define is in the unit test itself, so it of course doesn't affect any "real" code.
And to think that I've actually seen people declare their unit test classes as friends of the class they're testing - just to make unit testing easier. Well, now they don't have to with this trick - which is certainly better than changes to the actual code being tested.
Just
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
For big projects coud be useful. However, the private should be used to avoid unpredictable changes, the programmer should be able to control these variables.
Nothing more to tell about me...
Happy day =)
I can see it usefull only when you can see the header and not the .cpp part of the class, but then again all you need to do is comment out the private: line... then again it would seem interesting to have your co-workers start asking why you're directly accessing the private data members of the class without using any methods
Join is in our Unofficial Cprog IRC channel
Server: irc.phoenixradio.org
Channel: #Tech
Team Cprog Folding@Home: Team #43476
Download it Here
Detailed Stats Here
More Detailed Stats
52 Members so far, are YOU a member?
Current team score: 1223226 (ranked 374 of 45152)
The CBoard team is doing better than 99.16% of the other teams
Top 5 Members: Xterria(518175), pianorain(118517), Bennet(64957), JaWiB(55610), alphaoide(44374)
Last Updated on: Wed, 30 Aug, 2006 @ 2:30 PM EDT
Making your tests friends emphasises that your tests are actually part of the program rather than truely independant. You already have the problem that you have two classes of privates, those that are implementation details and those that are requrements. You still want the protection that no-one but methods and friends are modifying a particluar private, but that private is no longer just the buisness of the class. I would probably do something like.
This way it's clear that a programmer can modify stuffotron to use a vector as it's means of keeping a buffer, but that even if you did so, you still have the responsibilty to keep track of size independantly, and that size must be a signed int.Code:#ifdef WHITE_TEST #define requirement public #else #define requirement private #endif class stuffotron { char* buffer; requirement: int size; public: ... };
You also want even whitebox testing to be as simmular to your release canidate as possible.
Originally posted by Cat
I prefer just to put my publics first, then I can just comment out the private: line when I want to expose my privates to the world.But the beauty of this is that actual code doesn't need to be touched at all. Yes, you could comment out the private: line, but that creates other problems. What happens when I check in my unit tests into a CVS server, and someone (manager/team leader) checks them out and expects to see my unit tests passing? The tests will fail because they won't know to change the actual code.Originally posted by major_small
I can see it usefull only when you can see the header and not the .cpp part of the class, but then again all you need to do is comment out the private: line... then again it would seem interesting to have your co-workers start
That, and actually editing "real" code (whether it's commenting out "private:", or making the tester class a friend) just for the purposes of unit tests doesn't sit well with me.
Just
"C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement."
- Drew Olbrich
"public" and "private" are keywords in C++. I don't think it's legal to use them in macros.Originally posted by revelation437
does anyone else notice this works?
make a class with private fields, and include the define
then you can access the private fields no problem from outside the class. i thought private was a protected keyword....?
Hmmmm.Originally posted by Omnius
"public" and "private" are keywords in C++. I don't think it's legal to use them in macros.
I usually read the thread before posting.
gg
That's a good habit, Codeplug. I do the same thing myself. If you have a point to make, please make it. If I missed something I'll be glad to hold my hands up and say so.Originally posted by Codeplug
Hmmmm.
I usually read the thread before posting.
gg
I assumed your definition of "legal" as "being able to compile".
And by that definition, it is perfectly legal.
gg
That depends on your definition of "being able to compile" - whether that's according to the C++ standard or compiler XYZ. In this case, if the C++ standard does forbid the redefinition of keywords using macros, then such code would be ill-formed and the compiler would be required to issue a diagnostic.Originally posted by Codeplug
I assumed your definition of "legal" as "being able to compile".
And by that definition, it is perfectly legal.
gg