Can pvt members of base class be inherited n accessed by derived class.  whtz d diff. btwn pvt n protectd memb
98078
A PRIVATE member can NOT be accessed extrenally and can NOT be accessed by a derived class.\n\nA PROTECTED member can NOT be accessed extrenally BUT CAN be accessed by a derived class.
344305
Yes Virtual methods in C++ can have implementations.
74620
Given the architecture of the JVM, you need only be concerned with instance and class variables when you worry about thread safety. Because all threads share the same heap, and the heap is where all instance variables are stored, multiple threads can attempt to use the same object's instance variables concurrently. Likewise, because all threads share the same method area, and the method area is where all class variables are stored, multiple threads can attempt to use the same class variables concurrently. When you do choose to make a class thread-safe, your goal is to guarantee the integrity -- in a multithreaded environment -- of instance and class variables declared in that class. \n\nYou needn't worry about multithreaded access to local variables, method parameters, and return values, because these variables reside on the Java stack. In the JVM, each thread is awarded its own Java stack. No thread can see or use any local variables, return values, or parameters belonging to another thread.
519976
Take a look at this  www.classco.com/excieo/news/PEIPSM031009.PDF
108544
Your object will be passed by reference because\nthat's how Java passes all objects.  Only the\nprimitive types like "int" are passed by value.
587233
More details pls.\nGo to the source:\nhttp://www.java.com/en
1155117
Dynamic Versus Static Binding\nNot every call of a virtual function is resolved dynamically. In fact, in many cases the compiler resolves the call statically, even if the function is declared virtual. For example: \n \n  class A\n  {\n  public:\n    virtual void func() {/*..*/}\n  };\n  int main()\n  {\n    A a;\n    A.func(); // resolved at compile time\n  }\n\nDynamic binding applies in two cases: when calling a virtual function through a pointer to a polymorphic object, and when calling a virtual function through a reference to a polymorphic object (a polymorphic object is one that declares or inherits at least one virtual member function). For example.: \n \n  void f(A & ref, A* pa)\n  {\n     ref.func(); // resolved dynamically\n     pa->func(); // resolved dynamically\n  }\n\n  int main()\n  {\n    A a;\n    f(a, &a);    \n  }\n\nYou can bypass the dynamic binding mechanism by using explicit qualification with the scope operator: \n \n  pa->A::func(); // resolved statically\n\nWith Regards,\nK.SivaKumar.\nhttp://www.indianbabycare.com\nhttp://www.tamilmasala.net
817515
Is your object class the one that manage both creation and destruction of instances? \n\nYou could have both a static Create method and a static Destroy method.  Destroy would push instances into an 'unused instances' stack and Create would pop the first instance of that stack and assign new values to it as needed.\n\nThat way you save memory allocation/desallocation.
243434
I am assuming you are talking about files and folders inheriting the permissions of their parent folders.  If you are talking about inheritance as in inheriting money from someone, you're in the wrong area.\n\nThe advantage of inheritance with files and folders is that you can set up the permissions in the parent folder and all child folders will have those same permissions by default.  This way you do not have to go in and set up permissions for each and every folder if all child folders are to carry the same persmissions.\n\nThe disadvantage is that many people (actually, most people) forget about these permissions, or have them set so loosely as to be wide open, and do no change the permissions when the create new sub-folders, even if those folders should have limited rights and permissions.  This creates possible security issues, and at the very least can result in people having access to information they really have no need for.
1075666
"this" is a reference to the current class or object. It's frequently used in that way:\n\nclass Foo {\n    int x;\n\n    void setX(int x) {\n          this.x = x;\n    }\n}\n\nThis way you can access the field x though it's overridden by the use of the identifier x as a function parameter.
373481
If you are appearing for SCJP 1.4 try the book by khalid mughal, most of the question are similar\n\nand for SCJP 1.5, try the book by Kathy Sierra. Focus on Generics, enums, boxing, etc and the stuff added in 1.5 and which was not there in 1.4. must read this book if you need to pass with atleast 70% marks
89402
Code:\npublic class BTNode \n{\n    private Object data;\n    private BTNode left, right;\n    public BTNode(Object initialData, BTNode initialLeft, BTNode initialRight)\n        { \n            data = initialData;\n            left = initialLeft;\n            right = initialRight;\n        }\n    public BTNode()\n            { this(null, null, null); }\n    \n    public BTNode(Object newdata)\n            { this(newdata, null, null); }\n    \n    //NODE methods\n    public Object getData()                     //return and set data in node\n            {return data;}\n    \n    public void setData(Object data)\n            {this.data = data; }\n    \n    public BTNode getLeft()                 //return and set left child\n            {return left; }\n    \n    public void setLeft(BTNode left)\n            {this.left = left; }\n    \n    public BTNode getRight()                //return and set right child\n            {return right; }\n    \n    public void setRight(BTNode right)\n            {this.right = right; }\n    \n    public boolean isLeaf()                 //return true if this is leaf node\n            {return (left == null)&&(right == null); }\n \n// TREE Methods - for tree starting at this node\n// get specific data from a tree\n    \n        public Object getLeftmostData()\n        { if(left == null)\n               return data;\n          else \n              return left.getLeftmostData(); }\n        \n        public Object getRightmostData()\n              { if(right == null)\n               return data;\n          else \n              return right.getRightmostData(); }\n// print data in a tree\n        public void inorderPrint()\n                {\n                    if (left != null)\n                        left.inorderPrint( );\n                    System.out.print(data+"&#92;t");\n                    if (right != null)\n                        right.inorderPrint( ); }\n        \n        public void preorderPrint()\n                {\n                    System.out.print(data+"&#92;t");\n                    if (left != null)\n                        left.preorderPrint( );\n                    if (right != null)\n                        right.preorderPrint( ); }\n        \n        public void postorderPrint()\n                {\n                    if (left != null)\n                        left.postorderPrint( );\n                    if (right != null)\n                        right.postorderPrint( );\n                    System.out.print(data+"&#92;t"); }\n        \n// pretty print a tree\n        //public void print(int depth);\n \n//Interface for Nodes in Binary Tree (3)\n//removing nodes from a tree\n//returns reference to tree after removal of node\n        public BTNode removeLeftmost()\n              {\n                    if (left == null)                               // we are as deep as we can get\n                        return right;                               // remove this node by returning right subt ree\n                    else\n                        {                                           // keep going down recursively\n                            left = left.removeLeftmost( );\n                                                                    // when done, return node that act ivated this\n                                                                    // method as root of t ree\n                            return this; }}\n        \n        public BTNode removeRightmost()\n        {\n                    if (right == null)                               // we are as deep as we can get\n                        return left;                               // remove this node by returning left subt ree\n                    else\n                        {                                           // keep going down recursively\n                            right = right.removeRightmost( );\n
496646
Pointer to a reference ?? You are basically passing the address the refence is stored at. You could have done \nint someMethod(BaseClass* myVariable) as well but I think this is substandard code. While most compilers would compile it, you are "not supposed" to write things like that.\nAlternatively, you could have done:\nint someMethod( BaseClass& myVariable )\n{\n   BaseClass* p=&myVariable;\n}\n\nHowever references are const pointers so assigning it in that fassion to non const pointer would break the constantness of the reference and result in compilation error. Thats why you do *&.
98158
OOP languages have extra language features - e.g. encapsulation, polymorphism, and inheritance are object behaviours that don't have a direct procedural equivalent.\n\nFor making setup files, there are commercial solutions like InstallShield, but for free, consider NSIS: http://nsis.sourceforge.net/Main_Page
642028
try this it might help you\n\nhttp://techweb.konicabt.com/scripts/web_access.cgi?FUNC=LOGIN&LOGIN_USER_ID=kmweb&LOGIN_PASSWORD=enduseru! \n\n\n\n Visual C++ Concepts: Building a C/C++ Program   \n\nCompiler Error C2351\nobsolete C++ constructor initialization syntax\n\nIn a new-style initialization list for a constructor, you must explicitly name each direct base class, even if it is the only base class.\n\nThe following sample generates C2351:\n\n// C2351.cpp\nclass B\n{\npublic:\n   B() : ()   // C2351\n   {\n   }\n\n   // use the following syntax instead\n   /*\n   B()\n   {\n   }\n   */\n};\n\nint main()\n{\n}\n\n\n\n\nCompiler Error C2351\nobsolete C++ constructor initialization syntax\n\nA direct base class was not named in the constructor.\n\nThe new-style initialization list for a constructor member requires each direct base class to be explicitly named, even if it is the only base class in the list.\n\nThe following is an example of this error:\n\nclass B\n{\npublic:\n   B();\n   B( int );\n};\nclass D : public B\n{\npublic:\n   D( int i ) : ( i ) {}   // error, B was not named\n   D( int i ) : B( i ) {}  // OK\n};\n\n\n\nI sure hope some of this helps you and Good Luck!
78985
No it does not.\n\nSometimes it's appropriate to have exactly one instance of a class: window managers, print spoolers, and filesystems are prototypical examples. Typically, those types of objects—known as singletons—are accessed by disparate objects throughout a software system, and therefore require a global point of access. Of course, just when you're certain you will never need more than one instance, it's a good bet you'll change your mind.\n\nThe Singleton design pattern addresses all of the previous paragraph's concerns. With the Singleton design pattern you can:\n\n    * Ensure that only one instance of a class is created\n    * Provide a global point of access to the object\n    * Allow multiple instances in the future without affecting a singleton class's clients\n\nAlthough the Singleton design pattern—as evidenced below by the figure below—is one of the simplest design patterns, it presents a number of pitfalls for the unwary Java developer. This article discusses the Singleton design pattern and addresses those pitfalls. \n\n Example 1. The classic singleton\n\npublic class ClassicSingleton {\n   private static ClassicSingleton instance = null;\n\n   protected ClassicSingleton() {\n      // Exists only to defeat instantiation.\n   }\n   public static ClassicSingleton getInstance() {\n      if(instance == null) {\n         instance = new ClassicSingleton();\n      }\n      return instance;\n   }\n}\n\nThe singleton implemented in Example 1 is easy to understand. The ClassicSingleton class maintains a static reference to the lone singleton instance and returns that reference from the static getInstance() method.\n\nThere are several interesting points concerning the ClassicSingleton class. First, ClassicSingleton employs a technique known as lazy instantiation to create the singleton; as a result, the singleton instance is not created until the getInstance() method is called for the first time. This technique ensures that singleton instances are created only when needed.\n\nSecond, notice that ClassicSingleton implements a protected constructor so clients cannot instantiate ClassicSingleton instances; however, you may be surprised to discover that the following code is perfectly legal:\n\npublic class SingletonInstantiator {\n  public SingletonInstantiator() {\n   ClassicSingleton instance = ClassicSingleton.getInstance();\nClassicSingleton anotherInstance =\nnew ClassicSingleton();\n       ...\n  }\n}\n\nHow can the class in the preceding code fragment—which does not extend ClassicSingleton—create a ClassicSingleton instance if the ClassicSingleton constructor is protected? The answer is that protected constructors can be called by subclasses and by other classes in the same package. Because ClassicSingleton and SingletonInstantiator are in the same package (the default package), SingletonInstantiator() methods can create ClassicSingleton instances. This dilemma has two solutions: You can make the ClassicSingleton constructor private so that only ClassicSingleton() methods call it; however, that means ClassicSingleton cannot be subclassed. Sometimes, that is a desirable solution; if so, it's a good idea to declare your singleton class final, which makes that intention explicit and allows the compiler to apply performance optimizations. The other solution is to put your singleton class in an explicit package, so classes in other packages (including the default package) cannot instantiate singleton instances.\n\nA third interesting point about ClassicSingleton: it's possible to have multiple singleton instances if classes loaded by different classloaders access a singleton. That scenario is not so far-fetched; for example, some servlet containers use distinct classloaders for each servlet, so if two servlets access a singleton, they will each have their own instance.\n\nFourth, if ClassicSingleton implements the java.io.Serializable interface, the class's instances can
532980
I'm sorry but did you see this in My_Computer properties?\n\n\n\n--- ► λ ◄ \n\nN.B. I'm still a learner.