Thread: The Principal Of Least Priviliged ?

  1. #16
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    >isn't it weird how these languages (Java, C#) promote finally as an advantage when it's really a hack to overcome the lack of scoped destructors

    YES!!!!!!! It amazes me how weird a direction those languages have spun off into. Another gripe is code like this:

    Example:
    Code:
    bool IsTrue() {
      if(value) {
        return true;
      } else {
        return false;
      }
    }
    This shouldn't be flagged as erroneous.

  2. #17
    Registered User
    Join Date
    Dec 2004
    Location
    UK
    Posts
    109
    Quote Originally Posted by master5001
    >isn't it weird how these languages (Java, C#) promote finally as an advantage when it's really a hack to overcome the lack of scoped destructors

    YES!!!!!!! It amazes me how weird a direction those languages have spun off into. Another gripe is code like this:

    Example:
    Code:
    bool IsTrue() {
      if(value) {
        return true;
      } else {
        return false;
      }
    }
    This shouldn't be flagged as erroneous.
    It's in preparation for the 3 state logic extension. When you'll have true,false and maybe. Of course before it is implemented we'll need o wait for ternary computers, but you have to be prepered for futere developments.

  3. #18
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Yeah, sure. And it will only break 100% of the programs out there. Sounds like a likely language change.

    No, if there's a tristate bool (the very name is an oxymoron!), it needs to be a new type, like Boost's Tribool. (Have I mentioned that that the name is an oxymoron?)
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #19
    Registered User
    Join Date
    Dec 2004
    Location
    UK
    Posts
    109
    Tristate boolean logic is not really an oxymoron. Bool doesn't mean anything it's just the name of the guy who developed the 2 value logic algebra. And even though it is unlikely to be adopted in computers (it was meant to be a joke on my part) tri state logic is used in philosophy (the usual values are true, false and undefined but the third value varies depending on the speicific use).

  5. #20
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Well the fact of the matter is that this sort of code has broken these languages for years now. C and its family, Pascal, Visual Basic, ...the list goes on, all do some sort of basic logic tests. Java should check for areas where something will never be returned, not focus on the possibility that it might not return based on a condition that proves wrong.

  6. #21
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    The guy was called Boole, interestingly enough - so all the languages get it wrong. Anyway, boolean logic is the logic that handles two values, true and false. Thus, tristate boolean logic is either a bad new name (because it's confusing), or, if boolean is to be interpreted not as a name reference but as a reference to classic boolean logic, an oxymoron.

    On a side note, I just successfully compiled this Java program, so perhaps your Java compiler has a broken flow analyzer?
    Code:
    public class Huh
    {
    	public static boolean b = true;
    
    	public static void main(String[] args) {
    		whee();
    	}
    
    	public static boolean whee() {
    		if(b) {
    			return true;
    		} else {
    			return false;
    		}
    	}
    }
    My, we're getting off-topic...
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #22
    Registered User
    Join Date
    Dec 2004
    Location
    UK
    Posts
    109
    Quote Originally Posted by CornedBee
    The guy was called Boole
    My bad.

    Boole developed the algebra used in 2 state logic, which ca be extended to a 3 or more state logic by removing just one of the postulates on which it is based (kind of like moving from euclidian geometry to non euclidian ones), the "law of exluded middle" or "tertium non datur" if you prefer latin names.
    Of course once you remove that postulate many of the derived laws collapse but the basic operators (and, or and not) still work in almost exactly the same way (except not(not(a)) != a)

  8. #23
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    But it no longer makes sense to call it Boolean logic, then. You don't call a non-euclidian geometry "Manhattan Euclidian Geometry", you call it "Manhattan Geometry".
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #24
    Registered User
    Join Date
    Dec 2004
    Location
    UK
    Posts
    109
    Yeah, I know.

    Sorry about that. Yesterday evening I must have been practicing typing out of my backside.

  10. #25
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    I agree 100% with CornedBee on this one. Since in all the above examples the original rule structures were named after their authors, why would you name a variation after the author? Particularly when with the above examples I assure you the authors were aware of the possibility of the alternatives that are practiced and would have most likely not wanted their name associated with something that doesn't conform to the systems they painstakingly wrote.

  11. #26
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    I'd like to weight in on a couple points:
    Code:
    Situation A: 
    i have a private member 'int x', and a method setX(int n){ x = n; }.
    within a private member 'do_something(void)' i need to change the value of x...do i use setX() or simply x = a_number; ?
    You could also do something as such:
    Code:
    class Foo {
      int x_;
      int& x() { return x_; }
      public:
        Foo();
        int setX(int);
    };
    Now inside of your other member functions you can do things such as:
    Code:
    int Foo::setX(int j) {
      x() = j;
      return x();
    }
    Now returning a non const reference has one draw back over the set function method. There is no way to range check the value. So say x can only range from 0 to 100, using the non const reference method the user could set it to 101 where in the set function method you can ensure that value never gets assigned.
    However by making it private (or even protected if you want derived classes to be able to use it) you make it so that you can use it but no one else. It can make it easier for you when you are writing your other functions.

    I also note that most people write their set functions with a void return type. Please for the love of sake return the value so that I can chain them together if I so choose.

    On exceptions:
    I think one reason people don't use them a lot is because they bulker then return value errors. They can also make it harder to read the code if you are dealing with a lot of possible thrown errors. Another difficulty is having to know the type name of the object being thrown.
    As a general rule I like exceptions even when it can be a pain in the arse to use. I will however quote someone with far more knowledge on the subject then I:
    Bjarne Stroustrup: C++ Programming Lnguage 3rd Edition page 386
    Use exceptions for error handling
    Don't use exceptions where more local control structures will suffice
    Edit: I'm note a huge fan of the setX(), getX() methods. I much prefer the single name overloaded method:
    Code:
    class Foo {
      int x_;
      public:
        int x() const { return x_; }
        int x(int j) { /* insert range checking */ return x_ = j;}
    };
    Last edited by Thantos; 12-18-2004 at 07:47 PM.

  12. #27
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Stephen C. Dewhurst is very explicit in his C++ Gotchas. He claims that the only correct way to write getters and setters is this:
    Code:
    T getM();
    void setM(const T  &);
    Naming is optional. You can call both methods 'm' if you wish.

    I rather like his arguments.

    Code:
    T& m()
    The problems here are many. Exposing such a function to the public is madness, because it allows direct and unchecked access to the member. It's nearly equivalent with having the member variables public in the first place. You cannot use different storage, as you need a real variable to return a reference to. The only thing you could do would be to change the return type to a proxy object, but that means a change to the interface, and anyway, there is no proxy that can fully emulate a reference - for instance, it is not possible to properly implement the address-of operator. Finally, proxy objects can be slow on frequent access.

    The problem with the setter returning a value is very simple. Since return values have no name, there is no way in code to communicate what is returned.
    Code:
    T setM(const T& p);
    Unfortunately, you simply don't know which of the following two implementations the author chose.
    Code:
    T Class::setM(const T& p) {
      return m_ = p;
    }
    // or
    T Class::setM(const T& p) {
      T old = m_;
      m_ = p;
      return old;
    }
    And you will agree that the difference is quite important. Both methods make sense. The first emulates the behaviour of the = operator. The second follows the "push something in, something must go out to make space" principle that is very intuitive especially to less experienced programmers.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #28
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Oh I agree T& m() in the public is pretty much gonna be a bad thing. I view setter functions much like I view operator=, they should return the new value. Of course I have a tendicy to use const T& returns instead of T returns (when allowed).

    I'm not fimilar with Stephen C. Dewhurst, who is he and why should I care about his opinion? Yours I do care about though CornedBee

  14. #29
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    This is what the back cover says about Dewhurst:
    About the Author
    Stephen C. Dewhurst was among the first users of C++ at Bell Labs. He has more than eighteen years of experience in applying C++ to problem areas such as compiler design, derivative securities trading, e-commerce, and embedded telecommunications. He is the coauthor of Programming in C++ (Prentice Hall, 1989), a contributing editor for C/C++ Users Journal, and a former columnist for C++ Report. Steve is also the author of two C++ compilers and numerous articles on compiler design and C++ programming techniques.
    I can fully understand why you prefer the setter to return a value. The problem, as I see it, is that other people might expect it to return a value too, but a different one. (If a setter returned a value, I, for example, would expect it to be the old one.) Thus, in code that may be used by a variety of people (and I think you should always code with this possibility in mind), the best practice is to avoid this ambiguity by returning nothing.

    Here's the Amazon page:
    http://www.amazon.com/exec/obidos/tg...books&n=507846

    Here's Amazon's review collection:
    http://www.amazon.com/gp/product/pro...=UTF8&n=507846
    Last edited by CornedBee; 12-19-2004 at 11:33 AM.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #30
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Thanks for the info on Stevy.
    Why would you expect the old value on what is pretty much an assignment operation?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Newbie to C++ needs help plz!!
    By xuder in forum C++ Programming
    Replies: 11
    Last Post: 01-23-2008, 08:36 AM
  2. while loop help
    By bliznags in forum C Programming
    Replies: 5
    Last Post: 03-20-2005, 12:30 AM
  3. Principal of least privilege
    By carlin70 in forum C++ Programming
    Replies: 2
    Last Post: 02-22-2003, 08:15 PM
  4. Loan calculation formula
    By C++Nerd in forum C++ Programming
    Replies: 1
    Last Post: 10-06-2002, 12:57 PM