the responses are relevant, and it is not a feature. it is coincidence, and should not be relied on.
the general idea is that when you mark something as private or protected, it is so other programmers get a compile error if they try to directly access those private/protected members. if they deliberately circumvent those safety measures, it is their own damn fault when their program breaks. as someone who wants to publish their code/library/whatever, why should you care if someone goes out of their way to use it incorrectly and screws themself over?
C++ access specifiers are binaries????
Quote:Original post by WISMAK
In my opinion it's a very strong MS Visual C++ feature and it's not about name mangling.
Read my post from before. This is an easy mechanism to hack through. IT IS NOT INTENDED FOR SECURITY.
Quote:It's about binary level protection mechanism which should be part of the standard.
C++ access protection is NOT INTENDED FOR SECURITY.
Quote:Original post by WISMAK
No it does not offend me at all, but all the answers are totally irrelevant to the question.
In my opinion it's a very strong MS Visual C++ feature and it's not about name mangling.
It's about binary level protection mechanism which should be part of the standard.
1) The answers are indeed relevant, although you are apparently unable to see that due to your own overbearing opinion which blinds you to those of others. You state yours, I state mine, you then appear to get huffy.
2) Your opinion that it's a very strong feature seems to center around the fact that you consider it a "protection mechanism". Protection from WHAT, may I ask? I'm asking you to clarify, because I explained how it dosn't protect you from yourself, nor does it protect you or your data from others, and you've deemed both these points to be irrelevant. These are the only things that spring to mind, so I'm left drawing a blank.
3) It most certainly should not be part of "the standard", regardless of wheither or not it's a strong feature. The last thing we need to do is to bog down the standard with forced features when the standard itself STILL hasn't been completely implemented on industry standard compilers (extern templates anyone?).
What about common binary languages, how is a language with no concept of a private/protected/public scope supposed to know which symbol to link against when there's 3+ different identifiers that it MIGHT link to? GCC supports more languages than Microsoft's compilers, placing such arbitrary requirements could break otherwise working systems.
Author
Okay okay we're not fighting here! calm down!
What if there's a supposedly privated variable in the class which I don't want any client to access it's content directly without using the specified restricted get*** memebr functions because if they were able they could hack into the library and do good things from their perspectives not mine or even be able to know working internals of the library.
Design patterns? May solve the problem. But Finding that FEATURE in the great compiler of the great company is something awsome and solves my problem.
What if there's a supposedly privated variable in the class which I don't want any client to access it's content directly without using the specified restricted get*** memebr functions because if they were able they could hack into the library and do good things from their perspectives not mine or even be able to know working internals of the library.
Design patterns? May solve the problem. But Finding that FEATURE in the great compiler of the great company is something awsome and solves my problem.
Quote:Original post by WISMAK
Design patterns? May solve the problem. But Finding that FEATURE in the great compiler of the great company is something awsome and solves my problem.
Alright, I'm going to say this in boldface. MICROSOFT VISUAL C++ DOES NOT HAVE ANY FEATURE WHICH PROTECTS PRIVATE MEMBER VARIABLES IN DLL CLASSES FROM BEING ACCESSED BY ATTACKERS. Does not have it. If you release a DLL with a class which has a private member variable, I can write a program which will access that private member variable. There is NO SECURITY BEING OFFERED. If you need the private member to remain private, THIS WILL NOT HELP YOU. It DOES NOT DO WHAT YOU THINK IT DOES.
Got it? [smile]
Quote:Original post by WISMAK
What if there's a supposedly privated variable in the class which I don't want any client to access it's content directly without using the specified restricted get*** memebr functions because if they were able they could hack into the library and do good things from their perspectives not mine or even be able to know working internals of the library.
Then they can do it all the same, even with your Visual C++ Compiler. I mentioned this in Q3, and I showed you how to break it in the first post of this thread. Prehaps I need to break it down more for you?:
//dll_header.hhclass foo {private: int bar;public: void set_bar( int new_bar ) { bar = new_bar; }};foo * get_me_a_foo();//dll_source.cpp#include "dll_header.hh"foo my_foo;foo * get_me_a_foo() { my_foo.set_bar( 42 ); return &my_foo;}//evil_program_of_doom.hhclass foo {public: int bar;};foo * get_me_a_foo();//evil_program_of_doom.ccint main () { foo * the_foo = get_me_a_foo(); std::cout << the_foo->bar << std::endl; //prints 42, even though our DLL is built with bar as "private".}
^^^^ me, silly thing logged me out :( ^^^^
evil_program_of_doom.cc should include evil_program_of_doom.hh
Further, I am quite calm. Confused by you, but calm nonetheless. I've only posted fact, request for clarification on what we're talking about soas to address your misbelief with regards to this otherwise irrelevant compiler implementation detail, and my beliefs drawn from your defensive nature and seeming unwillingness to attempt to understand what's being said when it seems to conflict with what you think you know, which I state only to attempt to confirm, deny, or make yourself aware of such a possibility.
Besides, today was a beautiful day, not a cloud in the sky, nice and hot, and accompanied by tasty doses of caffeine. How could I not be calm? Well, except for the fact that I have no plunger and my toilet has clogged badly after shitting [lol]... (I suppose I should go out and buy one tomorrow... speaking of which, what does one usually do after plunging a shit filled toilet? Wash off said plunger with a hose?)
[Edited by - MaulingMonkey on July 19, 2005 12:40:58 AM]
evil_program_of_doom.cc should include evil_program_of_doom.hh
Further, I am quite calm. Confused by you, but calm nonetheless. I've only posted fact, request for clarification on what we're talking about soas to address your misbelief with regards to this otherwise irrelevant compiler implementation detail, and my beliefs drawn from your defensive nature and seeming unwillingness to attempt to understand what's being said when it seems to conflict with what you think you know, which I state only to attempt to confirm, deny, or make yourself aware of such a possibility.
Besides, today was a beautiful day, not a cloud in the sky, nice and hot, and accompanied by tasty doses of caffeine. How could I not be calm? Well, except for the fact that I have no plunger and my toilet has clogged badly after shitting [lol]... (I suppose I should go out and buy one tomorrow... speaking of which, what does one usually do after plunging a shit filled toilet? Wash off said plunger with a hose?)
[Edited by - MaulingMonkey on July 19, 2005 12:40:58 AM]
Author
And what does this have to do with my question?
Is there any option in GNU gcc or icc that forces memebr access protection to be binary like in Visual C++?
Thanks.
Is there any option in GNU gcc or icc that forces memebr access protection to be binary like in Visual C++?
Thanks.
Visual C++ doesn't "force access protection to be binary." Most likely what happened in your case is that the difference in class definition caused name mangling to be different which made it seem like MSVC had some sort of binary protection. But it doesn't. You're trying to duplicate non existant functionality.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
