The Principal Of Least Priviliged ?

I find myself having a hard time deciding when and how to use member functions within a class.

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; ?


Situation B: (this will make more since after looking at the code)
i have a class which evaluates regular expressions.
i have a private member 'vector<int> regex' and a constructor
'myclass(const string &)'. a private method 'convert(const string &)' which converts a string into a vector of integers. there is another private member called 'makeValid(???)' which ensures a regular expression is valid by adding various characters to it. (ex: closing a group with ')' ) ...and then another private method which is called 'prepare(const string &)'

should i pass regex into these functions and then return regex?
like so

Code:

myclass::myclass(void){ prepare(); }
void myclass::prepare(const string &source)
{
	regex = convert(source);
	regex = makeValid(regex);
        //theres quite a few more function that will manipulate
        //regex the same way makeValid does
}

or just let the methods take care of it

Code:

myclass::myclass(void){ prepare(); }
void myclass::prepare(const string &source)
{
	convert(source);                     //accesses regex directly
	makeValid(void);                 //ditto
        //theres quite a few more function that will manipulate
        //regex the same way makeValid does
}

i know this seems like a trivial question, but all my classes eventually turn into spaghetti no matter how i implement them

For situation A, use the accessor. This way, every place that uses the variable will automatically pick up things such as bounds checking or alternate storage locations.

For situation B...
The makeValid function name somehow makes me think that it shouldn't get passed a regex at all, since the name implies that the object is not valid before being processed, so...
But concerning the actual question, if 'myclass' is supposed to be the regular expression (with regex just being internal storage), then don't let the functions take parameters.
Or, if you think you might at one point need parameter versions, make them take parameters, but overload to take no parameters and make the overloads just call the parametered versions passing the member variables.

so it's a matter of design rather than convention?

Originally Posted by CornedBee

For situation B...
The makeValid function name somehow makes me think that it shouldn't get passed a regex at all, since the name implies that the object is not valid before being processed, so...

my idea was to force it to evaluate the expression that best that it could but turn on some sort of flag that could be checked to see if there was a 'syntax' error and let programmer choose to have 'regex.match(string expression, string compareString)' return the best solution or "" if the 'syntax' was invalid. the problem is that if it returns "" then there is no way to distinguish between an invalid expression or if there was just no match at all. perhaps there's a better alternative?

Have it throw an exception?

considered it, but Mister Dietel and Mister Dietel say exceptions should be kept to bad allocation, seg. faults, etc.

I disagree. I think exceptions should be generated when a function cannot do what it is supposed to do. For example, matching a string against a regexp cannot be done if the regexp is invalid. On the other hand, it can be done if the string simply doesn't match, in that case you get an empty result.

i guess i can't believe everything i read...
thanks for the advice

The point is you shouldn't use exception to control the flow of the program. Exceptions should be used to report (strangelly enough) exceptional situations such as an invalid regular expression (unless you expect your users to keep on giving you erroneus ones).

Another way to report the error would be to have an additional method regex.status() that returns the status of the last matched expression (matched, no match, invalid expression, etc...)

The exception would be more appropriate though.

Truthfully I think exceptions are very under-used. To me an exception makes much more sense than even returning some sort of error code. There will always be people who do not favor the idea since it may seem sloppy to someone used to error codes. But in my opinion its much cleaner as error codes use different types of errors across the board (i.e. functionA() may return -1 as an error, functionB() may return 360 as an error) and not only that, but not all functions are capable of expressing something went wrong through an error code that can be returned.

For example, what if you have a function that copies strings and returns the number of characters copied. If sed function only copies part of a string because the input buffer got full it would also be nice to know that whole string wasn't copied as well as how many characters were copied. Oh no! what do we do now!? Well exceptions save the day once again. You can have an exception thrown that flags the programmer that they did indeed have a small buffer, but it also returns how many chars were copied, just as the programmer had wanted.

@master5001

I agree wholeheartedly, but it's always good to look at all the options before making a choice.

(And if you happen to be working in Java sometimes they are just a total pain)

I do have to agree with that statement when taking java into account. Exceptions should be your friend, not hunt you down waiting to kick you in the forehead next time you trip and fall.

Originally Posted by master5001

I do have to agree with that statement when taking java into account. Exceptions should be your friend, not hunt you down waiting to kick you in the forehead next time you trip and fall.

I find they kick me mostly when I'm trying to write a quick snippet of code and get loads of compiler errors cause I'm not catching them all or forgetting to declare that a mehtod coudl throw a few of them.

I'm not surprised my Java lecturer dedicated less then 20 minutes to excpetions so we wouldn't start asking too many questions.

Strange - I find the details of exceptions in Java far less confusing than in C++. (Of course, there's no such thing as details in Java ). The worst problem with them is that RAII is not implementable, which means that I always need a finally - 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 I know that sort of error all too well. Additionally the java compiler is so gay about letting you see errors that there are times when you have to recompile even though you know compile-time errors still exist, just to see the rest of the errors.

Originally Posted by master5001

Yes I know that sort of error all too well. Additionally the java compiler is so gay about letting you see errors that there are times when you have to recompile even though you know compile-time errors still exist, just to see the rest of the errors.

And that's why you use IDEs like Forte or Eclipse that do syntax checking on the fly while you type.

@cornedbee: how I miss destructors in Java...