Private Access

[shouvik.d]

Say if we ve certain private methods along with private data members and public methods.
other than friend function is thr any other way we access these members(they being private only) directly. its one of the requirements in a project of mine.
The real prob comes when accessing function.
say we've classes ported to us in .obj format. then going for DMA using pointers is a risky n unreliable job.

class x
{
private:
void meth1()
{
cout<<"Meth1";
}
void meth2()
{
cout<<"meth 2";
}
};
class xduplicate
{
public:
void virtual meth1();
void virtual meth2();
};
main()
{
x obj;
xduplicate *obj1;
obj1=(xduplicate *)&obj;
obj1->meth1();
}

we can access meth1 only if in class x it is virtual. i.e. the entry is in the virtual table.
But now i cant jst change the native code ported to us. i've to anyhow access the private methods without any change in native code.
wht we're plannin is x will be the producer class n xduplicate the consumer class.
x will be available as .obj along with .h file
so how can 1.

though one of the cheap n unprofesssional sol is

#define private public

but this unwantedly unveals many non required methods toopen arena

plz hlp

[Ravalon]

Say if we ve certain private methods along with private data members and public methods.
other than friend function is thr any other way we access these members(they being private only) directly. its one of the requirements in a project of mine.

The only other safe way is a member function of a friend class. I can think of three unsafe ways to do it, but they're all hit or miss and they all break something serious. I think you might be misunderstanding the requirement for your project.

though one of the cheap n unprofesssional sol is

#define private public

but this unwantedly unveals many non required methods toopen arena

It's also not allowed. The language standard doesn't let you redefine keywords. It's also not sure to work if the private section isn't explicit. For example.

class x
{
  void meth1()
  {
    cout<<"Meth1";
  }
  void meth2()
  {
    cout<<"meth 2";
  }
};

The default access level of a class is private, but your trick won't work with the above class because it doesn't use the private keyword explicitly. It also won't work if you don't have access to the source code because by the time a class is compiled to object code, the keywords are long gone and the preprocessor from client code won't be able to touch it.

The simple answer is that you can't do what you're asking. The complicated answer is that you can do anything if you have sufficient knowledge of how the internals of the compiler work, but it's not portable and it's more likely to seriously screw something up than do any good. ;)

[Bench]

It's also not allowed. The language standard doesn't let you redefine keywords.

Actually, I don't think there's anything which stops it. Consider the following code

#undef private
#define private public

int main()
{
}

On at least 2 different compilers in strict mode, this compiles without error nor warnings.

Although i still think its a very bad idea. And, as you correctly mention, this doesn't change the fact that a class defaults all its members to private.

for the OP - Re-read the requirements of your problem. It sounds to me as if you've probably misinterpreted it.

[Ravalon]

Actually, I don't think there's anything which stops it. Consider the following code

#undef private
#define private public

int main()
{
}

On at least 2 different compilers in strict mode, this compiles without error nor warnings.

The compilers might let it slide, but the language standard says it's undefined behaviour. That's legalese for 'not allowed'. ;)

[Bench]

The compilers might let it slide, but the language standard says it's undefined behaviour. That's legalese for 'not allowed'. ;)

In which case I stand corrected :) I haven't got access to a copy of the standard right now - although i'm somewhat surprised that Comeau allowed that through without even throwing a warning.

[Ravalon]

I haven't got access to a copy of the standard right now

Me neither. I'm just going by memory, and I could very well be wrong. ;)

although i'm somewhat surprised that Comeau allowed that through without even throwing a warning.

If I remember correctly, redefining a keyword is undefined if a header is included but nothing is said about when a header isn't included. So your snippet might be well defined but pretty much any practical use is not. That might be hard to check for and the reason why Comeau was silent. It doesn't throw a warning if you include a header either.

[shouvik.d]

I couldn't make private definition to public
as it threw the followind error in VC++ 6.0

LIBCD.lib(wincrt0.obj) : error LNK2001: unresolved external symbol [EMAIL="_WinMain@16"]_WinMain@16[/EMAIL]
Debug/pvt.exe : fatal error LNK1120: 1 unresolved externals

[Ravalon]

I couldn't make private definition to public
as it threw the followind error in VC++ 6.0

LIBCD.lib(wincrt0.obj) : error LNK2001: unresolved external symbol [EMAIL="_WinMain@16"]_WinMain@16[/EMAIL]
Debug/pvt.exe : fatal error LNK1120: 1 unresolved externals

That looks like a different problem, you're using console mode code in a Win32 mode project. It expects WinMain() as the entry point instead of main().

[shouvik.d]

it isn't a console based application.

Simple win32 appl. and main() itself is working as an entry point if i remove the lines

#undef private
#define private public

[Ravalon]

it isn't a console based application.

Simple win32 appl. and main() itself is working as an entry point if i remove the lines

#undef private
#define private public

Right. You're using main() as the entry point, like this.

int main()
{
  return 0;
}

But because it's a Win32 application, the runtime code is looking for WinMain() and not main().

#include <windows.h>

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
{
  return 0;
}

The linker throws that error to tell you that it can't find WinMain.

[John A]

it isn't a console based application.

Sure looks like one to me... ;)

Simple win32 appl. and main() itself is working as an entry point if i remove the lines

#undef private
#define private public

Don't know about that, but I would first suggest you try recreating your project file and make sure it's a console-based application. Since you aren't using windows in your app, it makes it a console application. And the compiler is obviously searching for a WinMain() function, so that's why the error occurs.

[shouvik.d]

#include <iostream.h>
#undef private
#define private public
class pvt
{
private: 
 void hi()
 {
  cout<<endl<<"hi there";
 }
};
 
void main()
{
 pvt o;
 o.hi();
}

Compiling...
x.cpp
Linking...
x.exe - 0 error(s), 0 warning(s)

in VC++ 6.0
works fine u see.

[John A]

Ugh.

Use int main(), not void main. See my signature if you have any doubts.

You should replace #include <iostream.h> with:

#include <iostream>
using namespace std;

And then it will compile on a "real" compiler. VC++ 6.0 is far too outdated anyway - go grab VS Express 2005 or Code::Blocks.

[shouvik.d]

Except ur request to switch to a new compiler like VS 2005 etc. I did wat u aksed.

No errors no warnings works fine. it did compile on the real VC++ compiler

[John A]

Just to prove it, I took the code you posted originally and put it into my compiler - it compiled fine, both with and without the "private" keyword redefined to public, and I was able to access the member functions as if they were public. And that's on gcc.

So although it proves that a standard compiler allows you to do such a thing, I still don't think it's a good idea.

No errors no warnings works fine. it did compile on the real VC++ compiler

I don't consider VC++ 6.0 to be a real compiler. It lets things such as iostream.h and void main slip by without even a warning, when a good compiler should absoloutely refuse code like that.

[shouvik.d]

no this doesn't hold good for VC++6.0

i need to redefine the keyword.

[shouvik.d]

Now this way what has happened is i've deviated from my main subject. I'm in dire necessity to really access the private members keeping VC++ 6.0 as my native platform as that falls under the requiremen specification of the project.

plz help

[Ravalon]

Now this way what has happened is i've deviated from my main subject. I'm in dire necessity to really access the private members keeping VC++ 6.0 as my native platform as that falls under the requiremen specification of the project.

plz help

Can you post the actual requirements that you're working from? What you're trying to do doesn't make sense for any reasonable project.

[shouvik.d]

Can you post the actual requirements that you're working from? What you're trying to do doesn't make sense for any reasonable project.

The above requirements alone. i cant chng anything in the lib/obj files given to me only the header will be given along. so all i need is to access the private members in those classes in my appl.

i'd be linking those files with my application.

hope i answer ur queries

[John A]

The above requirements alone. i cant chng anything in the lib/obj files given to me only the header will be given along. so all i need is to access the private members in those classes in my appl.

i'd be linking those files with my application.

Ravalon's right; this doesn't seem reasonable. Can you tell us exactly why you need to be able to access these member functions? If necessary, contact the project's head programmer. Because I think this is a sign of bad program design.

[shouvik.d]

See that's only i can say. rest is out of my scope too. let it be bad but its the basic requirement

[shouvik.d]

Is this the end? plz help

[shouvik.d]

is this the end? plz help

[WaltP]

OK, here's the synopsis of the problem
1) you have private values in a class and you cannot change the class
2) private values cannot be accessed in a class without the class allowing access
3) if the class does not have methods created that allow access, you cannot access the private values

Final result:
You cannot access private values. They are protected. That's why they are private -- so you can't access them and mess something up.

[shouvik.d]

we can access them if we know the binary layout of the object...just making it private doesn't assure that the data is completely isolated from open access. but then i just cant take any risk of having errors such as dangling pointers so i want to use a more= full proof method

[Ancient Dragon]

there is no full-proof method to do what you want. Private members are private for a reason -- to keep hackers like you from accessing them. If you need access then your program should be redesigned. If you are unwilling to do that, then you are just SOL.

[shouvik.d]

how do u presume i'm a hacker :(

[Ancient Dragon]

how do u presume i'm a hacker :(

people who try to circumvent the c++ standards and the system are hackers (in my opinion). Follow the rules -- that's what they are for. When someone creates a class with private members he/she has no intention of allowing outsiders to screw around with the data or call private methods. If you do do that then you are on your own and do it at your own risk. Does "undefined behavior" ring any bells?

[shouvik.d]

eh! i dint take it that way...its fine..but neither of wht u're assuming is true...the fact is its really a requirement...that's how much i can say for now...

the world is full of exception a reuirement too comes that way at times defying the laws of C++

[John A]

the world is full of exception a reuirement too comes that way at times defying the laws of C++

The stupid thing is, why can't you use "public"? When you redefine the keyword private , you no longer have private members. It just looks that way. Internally they are actually public, so you're not even meeting the requirement by doing this. Plus you take risks by redefining a C++ keyword, to quote Ancient Dragon, "undefined behaviour".