Is the following code Standard compliant ?

This is a discussion on Is the following code Standard compliant ? within the C++ Programming forums, part of the General Programming Boards category; Code: #include<iostream> using namespace std; class X { private: int x; public: void d(){cout<<x;}; void test(X p) { p.x = ...

  1. #1
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498

    Is the following code Standard compliant ?

    Code:
    #include<iostream>
    using namespace std;
    class X
    {
        private:
        int x;
        public:
        void d(){cout<<x;};
        void test(X p)
        {
            p.x = 10;
            this->x = p.x;
        };
    };
    int main()
    {
        X a,b;
        a.test(b);
    }
    My question is about the bold lines... Can a member function called by another object 'see' the private members of the object in the argument?
    It is compiling in gcc ....but I'd like to know if it is totally 'legal' ?
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,246
    It is legal. All member functions of class X can access private members of any instance of class X.
    Right 98% of the time, and don't care about the other 3%.

  3. #3
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,214
    Code:
    test(X p)
    It is legal, but that may not be what you intended.

    Soma

  4. #4
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    ..I just wrote this example for illustrating the point...I wanted a member function called from one object to try and access private members of another..
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  5. #5
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    It is legal, however confusing, and might be indicative of poor design in a larger system.

  6. #6
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Would it be poor design if used in overloading operators ...when there are lots of private members ?
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  7. #7
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    It isn't confusing, or unusual. This is a normative way of restricting how a member variable is used. For example, you may to allow access to the value of a non-const variable, so that it can only be changed by internal methods. So you make the variable private and have a public getter.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  8. #8
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,299
    The use of the 'private' keyword is to prevent something or someone other than the implementor of the class, from directly seeing or changing certain things. It's not there to make one instance be oblivious to how another instance of the same class works. In this way, it isn't like 'const'.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  9. #9
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,538
    It also stops people from deriving the class, usually. Because of this, I tend to use protected unless private is really necessary.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    Registered User
    Join Date
    May 2011
    Posts
    19
    Code:
    #include<iostream>
    using namespace std;
    class X
    {
    private:
    	int x;
    public:
    	X():x(){};
    	void d(){cout<<x;};
    	void test(X p)
    	{
    		p.x = 10;
    		this->x = p.x;
    	};
    };
    int main()
    {
    	X a,b;
    	a.test(b);
    }
    you can just add a default constructor, then ok !

  11. #11
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    This surprised me too when I first learned of it. Strange that one object (albeit the same class) can access another's private members without being friends or something. But when you think about it, it makes sense. The compiler has to do static typechecking to see if you have permissions to access members instead of dynamic typechecking at runtime (since you want a compiler error when this happens, not a runtime one).

    And it would take a lot of effort on the compiler's part to see if some member that you're accessing really belongs to the same object, and not another object of the same class. The compiler would have to track any pointer arithmetic you might be doing to try to fool it, to make sure the this pointer you end up with is the correct one. For example:
    Code:
    class Something {
        int x;
    public:
        void f() {
            // if I know that x is always zero:
            (this + x)->x = 0;  // what is the compiler supposed to think of this?
        }
    };
    Since C++ classes are actually low-level, just functions associated with structures that always take a this* parameter, the compiler can't really do any better than this. And if I start using function pointers to member functions then the compiler's job just got even harder.

    By the way -- it's not necessary to put a semicolon after the closing brace of functions and constructors etc. Just after the class definition itself (and after member variables, of course).
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Can vc++2005eebe set up to be ansi C compliant
    By MickD in forum C Programming
    Replies: 4
    Last Post: 08-29-2006, 05:53 PM
  2. Where to find the code that defines standard Functions?
    By hammer1234 in forum C Programming
    Replies: 7
    Last Post: 04-21-2006, 02:37 AM
  3. How to make Dev-C++ more C99 compliant ??
    By Antigloss in forum C Programming
    Replies: 13
    Last Post: 10-06-2005, 02:13 PM
  4. Problems with standard WIN32 Code
    By BruceLeroy in forum Windows Programming
    Replies: 6
    Last Post: 08-24-2004, 09:20 AM
  5. Source code of C standard library...
    By Nutshell in forum C Programming
    Replies: 3
    Last Post: 01-26-2002, 05:35 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21