SomeClass

[Eric]

Maybe I should have made this more clear the first time, I am working on a
quiz and am not sure what the answer to this is. My friend was telling me
that the answer is C. Any agreements/disagreements? Eric


//Suppose that the class declaration of SomeClass
//includes the following function prototype

Boolean LessThan (/*in*/ SomeClass another Object);

//Which of the following tests in the client code
//correctly compares two class objects alpha and beta?

//a. if(alpha < beta)
//b. if(alpha.LessThan(beta))
//c. if(LessThan(alpha, beta))
//d. if(alpha.LessThan.beta)
//e. if(LessThan(alpha).beta)

[ralph]

"Eric" <etimesthree@t-online.de> wrote:
>
>Maybe I should have made this more clear the first time, I am working on
a
>quiz and am not sure what the answer to this is. My friend was telling
me
>that the answer is C. Any agreements/disagreements? Eric
>
>
>//Suppose that the class declaration of SomeClass
>//includes the following function prototype
>
> Boolean LessThan (/*in*/ SomeClass another Object);
>
>//Which of the following tests in the client code
>//correctly compares two class objects alpha and beta?
>
>//a. if(alpha < beta)
>//b. if(alpha.LessThan(beta))
>//c. if(LessThan(alpha, beta))
>//d. if(alpha.LessThan.beta)
>//e. if(LessThan(alpha).beta)

b

[Danny Kalev]

Eric wrote:
>
> Maybe I should have made this more clear the first time, I am working on a
> quiz and am not sure what the answer to this is. My friend was telling me
> that the answer is C. Any agreements/disagreements? Eric
>
> //Suppose that the class declaration of SomeClass
> //includes the following function prototype

This is probably one of the questions that should be taken out and shot.
It's poorly phrased and relies on programming techniques that might
apply to Java but not C++. More below.
>
> Boolean LessThan (/*in*/ SomeClass another Object);

Boolean isn't a C++ type. There's bool. Secondly, no one indicates in
out parameters in a function's parameter list. You simply use const to
indicate a read only value an a non-const value to indicate a value that
the function might alter, *as long as* it is passed by reference. In
this case, the parameter is passed by value which is usually an error.
Finally, no sane C++ programmer would call a function LessThan. Don't we
have operator overloading for this very purpose? Finally, from the
introduction above, I'm not sure whether LessThan is member function of
class or a global function. I'll assume the former.

>
> //Which of the following tests in the client code
> //correctly compares two class objects alpha and beta?
>
> //a. if(alpha < beta)
> //b. if(alpha.LessThan(beta))

This one is correct. It doesn't compare equality but whether alpha is
less than beta.

Danny

> //c. if(LessThan(alpha, beta))
> //d. if(alpha.LessThan.beta)
> //e. if(LessThan(alpha).beta)

[novice]

BTW I have seen COM code using /*in*/ and /*out*/ when declaring functions.

[Danny Kalev]

novice wrote:
>
> BTW I have seen COM code using /*in*/ and /*out*/ when declaring functions.

COM isn't exactly C++. It also includes VB, in which the documentation
of in/out parameters is more meaningful than in C++. It certainly
doesn't hurt to use these comments, except than in C++ is totally
superfluous.

Danny

[ralph]

Danny Kalev <dannykk@inter.net.il> wrote:
>
>
>novice wrote:
>>
>> BTW I have seen COM code using /*in*/ and /*out*/ when declaring functions.
>
>COM isn't exactly C++. It also includes VB, in which the documentation
>of in/out parameters is more meaningful than in C++. It certainly
>doesn't hurt to use these comments, except than in C++ is totally
>superfluous.
>
>Danny

You should tell him "Why" it is superfluous. <g>

In COM, RPC, and other "marshelling" technologies using 'in' and 'out' is
a good practice since it provides information for the intermediate code constructors
to more efficiently manage memory and transfer of information. (If something
is only going "in" then I don't have to provide any mechanism for reading
it back.)

This is also a very good practice during initial design of 'classes' and
objects. In your UML when you are working on interfaces, but not yet creating
full signatures. It helps to make it very clear what your intentions are.

It is consider superfluous in C++ because you can more or less enforce this
kind of behavior through the compiler by using references/by value and const.
But I still like the 'clarity' of spelling it out, for those that come later,
or for myself. Personally I think it is a good professional practice in documenting
any public interface. (Not all code - just that providing the service interface.)

I even go so far as to commit REAL heresy, by defining...
#define IN
#define OUT
#define INOUT
in a project file. <g>