access-modifiers

I have some protocols LoginStrategy public protocol LoginStrategy { func login(_ viewController: UIViewController) func getUserInfo(withCompletionHandler completionHandler: @escaping (_ userInfo: [String: Any]?) -> ()) func createLoginButton(_ frame: CGRect, withCompletionHandler completionHandler: @escaping (_ loginButton: UIView) -> ()) func getUserId() -> String } and two classes: LoginProvider public class LoginProvider { public let strategy: LoginStrategy public func login(_ viewController: UIViewController) { return self.strategy.login(viewController) } public func getUserInfo

Comeau, g++ ( ideone ) and EDG accept the following code without diagnostic. Visual C++ compiles successfully, albeit with warning C4624. class indestructible_base { ~indestructible_base(); }; class T : indestructible_base { public: //T() {} }; int main(void) { new T(); } Uncomment the constructor and it no longer compiles. Perhaps it's the rule that if an exception occurs inside the constructor, subobjects must be destroyed? Seems odd, since the body is empty and can't cause an exception. Even so, add an exception-specification vouching for the fact that no exception will be thrown ( throw()

In Java the private access modifier consider as safe since it is not visible outside of the class. Then outside world doesn't know about that method either. But I thought Java reflection can use to break this rule. Consider following case: public class ProtectedPrivacy{ private String getInfo(){ return "confidential"; } } Now from another class I am going to get Info: public class BreakPrivacy{ public static void main(String[] args) throws Exception { ProtectedPrivacy protectedPrivacy = new ProtectedPrivacy(); Method method = protectedPrivacy.getClass().getDeclaredMethod("getInfo", null);

This question already has an answer here: Why does the “protected” modifier in Java allow access to other classes in same package? 6 answers I had to shorten the title a bit. Here's the full question: In Java which access modifier allows a member to be accessed only by the subclasses in other package or any class within the package of that member's class? I am thinking protected but my office mate says the answer is private . In Java which access modifier allows a member to be accessed only by the subclasses in other package or any class within the package of that member's class? see this

In java programming, method level access modifiers using protected or public where private can be used will affect the performance in any way? if so in what what way it affects the run time performance. lexicore Quoting erickson from the following answer : The access modifier on the field doesn't make any difference in speed, but invoking the accessor method does . ps. Please upvote the original answer instead of this one. Even if there is a theoretical difference, I doubt that there is a measurable diffrence. At least in any sensible Java runtime 来源： https://stackoverflow.com/questions

Iam preparing for SCJP , also i came to know that protected members scope is within the package as well as in other package with some conditions like possible only with inheritance. For example : i have three classes as Parentclass Childclass Friendclass package x.parent; class Parentclass{ protected int x=10; ............... } package x.child; class Childlass extends Parentclass{ super.x=20; ............... } package x.child; import x.parent.Parentclass; class Friendclass{ Parentclass pc = new Parentclass(); pc.x=30; ............... } Whats the reason behind that, in Friendclass the member x

I'm encountering a rather odd behavior, and not sure if this is a Java issue or just something with Eclipse. Take the following code: class Foo { private String text; public void doStuff(Foo f) { System.out.println(f.text); } } The problem here is, why is f.text accessible? It's a private field, so by my logic, it shouldn't be, but the IDE seems to think it is. This is by design. Private fields are accessible within the same class, even if a different instance . See here for more details and an official statement from Oracle on this. Since doStuff is a member of Foo , any private fields of Foo