Thread: A Class question.

Ummm, okay, that's just weird. Why the hell wouldn't a compiler warn about signed -> unsigned conversion?

I'd guess that it's because you're not losing any bits, just changing the interpretation of the MSB.

Which can lead to way inaccurate data, so that's not a good reason.

ok, real sorry i didnt reply earlier but i lost my internet conenction for a while (heavy rains and stuff)

ok to reply to you all now:

Originally Posted by manasij7479

Looks Ok, except for some conceptual gotchas.
The member functions have access to the private members. So you don't need to get anything there. I also noticed that you are using the get functions but not using their values.

Also, you could consider initializing AccBal and AccHolder by a member initialization list. (...I found that Tip in Effective C++, but can't recall the reason...Anyone else with more RAM ? )

[And w.r.t my earlier point, you don't actually need to prefix Account:: even in the implementation...(I didn't even know it was allowed except for static members...but the compiler seems to accept it.)]

the member functions have access, but I was told to avoid accessing it directly. So i was trying to find a way to use the set and get functions to do the functions in the implementation.

Originally Posted by Elysia

In case you've learned exceptions and are allowed to use them, you should throw an exception is Amt <= 0 instead of printing an error message.
Furthermore, you don't want to continue if this error occurs, so you have to put a return in there, as well, so you don't call setAccBal, etc.
If an error occurs, the object will basically be in an error state, but I think you can ignore that fact for now. It is just a little something to keep in mind (that's why throwing an exception is a good idea).

I was told to do it like this and we haven't learned exceptions yet as well so yeah

Originally Posted by whiteflags

Why is taking a negative balance and making it zero an error state? Because you say so? Do you know that's not what's supposed to happen?

Also, about the scope operator, the class name is used for name lookup and is treated as a public member of the class. It is not a namespace.

same as above, it was mostly structured in that we were given the basic premise, the code for the tester.cpp and we were to write the class header and cpp file to make the output the same as the one given to us.

Actually it depends on where you want to do that. Your teacher is right, since you can't access private member data, you have to use a public member function in code that uses the class. However, member functions will always have access to at least one set of data. For example:

myAccount.setAccBal(Amt);

Member function setAccBal will always have access to the data of the object it is called with, called this object by the implementation. Additionally, member functions will also have access to data members of other objects of the same class, if you pass them in as arguments.

i know the member functions of a class can access the private data members but my teacher personally prohibits us from accessing it directly for his class even though he told it it does work.

The getAccBal here does absolutely nothing. This get function is supposed to enable the outside to access the account balance, and returns that. So you would have to store that balance in some variable to use it.
Nevertheless, getAccBal simply returns the private member that contains the balance which you have access to since you are inside the class implementation, so you could use that instead if you want.

@Elysia: I figured this much but how can you put the value that the get function in another variable without the direct access to the data member? I am trying not to use the data member itself but using the set and get to manipulate the value if possible. i could just do something like this:

int X;
Account::getAccBal();
X = AccBal;

but that would be accessing the data member directly? or is there another way?

Originally Posted by program

ok, i feel like i am getting a bit confused...

in what i said before with:

Amt = Amt + AccBal;

would that be directly accessing the private data member "AccBal" ?

I think you guys answered it but I am not sure lol.

Yes, that would be accessing AccBal directly (I assume AccBal is a member variable).
If you absolutely need to avoid accessing it directly, then substitute it for the get function.
Something like

Amt += GetBalance();

a += b <==> a = a + b

Originally Posted by Elysia

Which can lead to way inaccurate data, so that's not a good reason.

Inaccurate,but not lost. I agree with you that a compiler should, logically, emit a warning for this, but it doesn't and I was guessing at the rationale for why.