class properties in c++

[Rob Wehrli]

> I don't know what I was thinking - perhaps I should've poked around my
> reference books before throwing that one out.
>
> But what I was originally thinking was for [class, object] "properties" -
> getting/setting values in a [class, object] for its contained data types -
> the [method, function, contract] that "gets" the value would have a return
> type of the data type it was retrieving, while the "set" would be a void
> that passes in the value of the data type being set. Neither one of the
> [functions, methods, contracts] would return any error-related values
> because it would be handled within the calling[function, method,
contract].
>

Yes.  The return type of a getter is the type it returns.  How else would
you "get" it? :)  Naturally, you could implement a "getter" using a "pass by
reference" of the type you're expecting and use the return type (typically
an int in such implementations) to flag errors rather than force C++ style
exception handling.  This is very commonplace in Win32.  Setters do,
oftentimes, return void, especially in Java.  In my C++ code, I tend to
always return a value (typically an int) where others might choose a void.
The idea is that  if( ret_val ), I'll do something, perhaps calling "errno",
"GetLastError" or whatever appropriate function.  The idea in C++ is,
however, to throw an error whenever the contract of the function can not be
delivered upon.  Then, wrapping the function call in try/catch handlers will
allow for useful ret_val processing through exception types, assuming
they're used.  Problems tend to arrise when no implementation properly
catches the thrown exception, leaving instead, the default exception
propagation and response mechanism to handle it, typically inappropriately
for the needs of a more robust application implementation.  That is why
you'll often see:

try
{
    func( );
}

catch( MyExceptionTypeA )
{...}

catch( MyExceptionTypeB )
{...}

catch( ... )
{
    // last chance gas handling/recovery
}

>
>
>
> This goes back to my original question - do I set up my properties as
> SetXX() and GetXX() [functions, methods, contracts]? The MS platform
defines
> them as [functions, methods, contracts] with a get_ and put_ prefix.

Generally, yes.  You may choose whatever naming convention fits your
personal style as long as it blends well with the code you're
modifying/creating.  If you're working from a starting point of some other
code, it may be better to lean toward that style first.  It gives current
users of the current release version (and presumably previous versions) a
better starting point for integrating your changes.  I think that you'll
tend to find most of the MS platform code that is MS "specific" follows a
fairly consistent convention.  Win32 API will use GetLastError, GetDC,
GetWindowLong, etc.  MFC tends to use GetDocument, GetPinCount, etc., which
follows the convention.  Typically when you see lowercase function names,
they are homed in the C library/runtime.  The seemingly ever-present
exception to this "rule" is that of COM.  COM interfaces are "all over the
board" in many ways, however, there are weird methods to their madness.  It
is not uncommon to find get_ and get__ in COM implementations of interface
implementations.  An example of this would be:

HRESULT get__NewEnum(
  IUnknown **ppUnk
);

...which, as you can probably guess, "returns" an indirect pointer to the
ever-present IUnknown interface.


This is another example where the actual return type is really an "error
code," or in MS' case, an HRESULT.  If an HRESULT return value is not equal
to S_OK, then you won't want to use the pointer "returned" as it is very
probably invalid and likely "undefined."  Additional information may be
present in the HRESULT returned, and may help you determine a course of
action suitable for the work you're doing.

To make matters worse, sometimes get_ is followed by a capital letter and
other times it is followed by a lowercase letter...for example:

get_doctype (part of the IXMLDocument interface).

Others such as IHTMLCurrentStyle::get_backgroundPositionX  ...only further
the confusion when "conventioning" is applied.  I think that the problem
with MS (generally, regarding naming conventions) was that they ended up
having a bazillion different functions/methods/whatever.  Once you get a
really large code base grown, it is really hard to follow any convention
that truly works without watching the right side of the screen disappear as
you type:
GetNewMethodFromHellBecauseWeRanOutOfUsefulNamesYearsAndYearsAgoAndMillionsU
ponMillionsOfLinesOfCodeAgo( );

:)


BTW...Microsoft's glossary defines a function as follows:

function
1: A block of code, consisting of a return type, function name, optional
parameters, and statements, that performs one or more specific tasks within
the source program and returns a value to the caller.


2: The purpose of or the action carried out by a program, routine, or other
object.


...interestingly enough, their glossary also has a definition for method:

method
In object-oriented programming, a procedure that provides access to an
object's data. In C++, public member functions are the equivalent of
methods.


...and, I'm sure, MS didn't invent these names and definitions all by
themselves.  They are very likely taken from consistent use throughout the
industry.

This is quite a departure from an earlier posted:

> First of all it is not a function, it is a method. A function is part of
> structural programming where a method is part of object oriented. This is
> because functions live in libraries and methods live in objects.

Of course, you don't have to take my word for it:

http://msdn.microsoft.com/library/devprods/vs6/visualc/glossary/_gloss_gloss
ary_f.htm
http://msdn.microsoft.com/library/devprods/vs6/visualc/glossary/_gloss_gloss
ary_m.htm

...of course, what does Microsoft know about writing code?  They happen to
be the most "successful" software company in the world.  I think that as
Linux programmers and aspiring Linux programmers, we can learn many lessons
from "the dark side."  MS has a lot of very strong, very good talent many
who write excellent code.  (Consider the origins of Code Complete and the
fact that it is a MS Press book, if my memory serves me well...of course, I
could check on Amazon or MSPress, but I'm reasonably sure the book comes
from MSP....OK, so I'll check, just to be accurate for everyone...)

Paperback - 857 pages (May 1993)
Microsoft Press; ISBN: 1556154844 ; Dimensions (in inches): 1.79 x 9.17 x
7.38

>
>
> thanks,
>
> Lucas


Take Care.

Rob!