Set and Get and OOP

[Bruce Peaslee]

I have a couple of questions regarding OOP. The books I have been reading on the subject seem to want me to write methods for each class variable that "set" and "get" the value. Accessor methods. Not hard of course, but lots of tedious typing. Will we have some sort of inline implementation for the Get part?

What's the best practice for coding classes? If they are to be reusable, I would assume you would put them into an include file.

[Parker]

Even with properties, you'd have to do something like this

Code Select Expand

propertyget myclass::myprop(),int
{
    return m_somevalue;
}

propertyset myclass::myprop(int value)
{
    m_somevalue = value;
}

I think most classes have their own Get and Set methods for properties that you can do that. IDL (interface definition language, for generating C++ COM interfaces) lets you use the [get] and [put] or [set], I can't remember which, where it will append that to the final method name. [get] someProperty will become get_someProperty.

Yep, the class definitions should probably be put in include files. Look at how the GUI library and CCL are organized

In the end though, it's really up to you and how you want to organize your stuff. If you're not releasing the classes don't feel obligated to make get and set wrappers. And generally you won't write them if they're only being used by that class.

[Ionic Wind Support Team]

I'll add a bit here.

Classes are derived from structures (UDT's).  Member variables are in essence the same as the elements of a structure.  With that said the same 'gotchas' apply.  When you define a class on the stack (within a subroutine) the member variables are guaranteed to have random information in them.

Classes that contain member variables should always have a constructor that will initialize the variables to a known value.

class MyClass
{
MyClass();
SomeMethod(),int;
//member variables
int m_nCount;
byte *m_pArray;
}

MyClass::MyClass()
{
m_nCount = 0;
m_pArray = NULL;
}

This ensures that when you use the class in a subroutine that the member variables are initialized.

sub somesub()
{
MyClass cl; //constructor initialized m_nCount and m_pArray here;
}

When using NEW all member variables will be set to 0 so a constructor isn't absolutely necessary.  But you should do it anyway since you never know how the class will be used in the future.

Now onto the subject at hand.  Accessor functions are only useful if the data from a variable being retrieved depends on some condition.  For example lets say you have a communication class with a threaded subroutines that listens on a port.  You wouldn't want any outside influences on the port handle while data was being read.

MyCom::GetReadHandle(),int
{
  if (m_bBusy) // the read thread is using the handle
  {
  ....WaitForSingleObject  //wait for the thread to finish
  }
  return m_hReadHandle;
}

C++ uses the keywords protected and private to indicate that a member variable or method cannot be accessed directly by code outside of the class.  m_hReadHandle above would be a good candidate for a protected variable.

If all your doing is writing accessor functions that do this:

MyClass::GetCount(),int
{
return m_nCount;
}

You might as well just access it directly.

a = cl.m_nCount;

Paul.

[Bruce Peaslee]

Good advice - thanks to both.

I have been busy moving stuff into include files and get this error:

#IFNDEF IDCANCEL
#DEFINE IDCANCEL 0
#ENDIF

"constant already defined"

It's true, it was defined elsewhere with the same construction, but I thought this was the way to avoid duplication.

[Parker]

#define is currently an alias for CONST. In my opinion this should be fixed and #define should be changed to just store a list of tokens that's substituted when that define is encountered, more like how C does it. Then we can also have #undef, #if, #elseif. I'm really hoping this method is just temporary.

[Bruce Peaslee]

This seems to work (so far):

#IFNDEF BN_CLICKED
#DEFINE BN_CLICKED
const BN_CLICKED = 0;
#ENDIF

[Parker]

That would because
#define IDENTIFIER
is different than
#define IDENTIFIER expression
they use two different tables. Again though, I hope that will be fixed.

[Bruce Peaslee]

Everything compiles now, but the linker is mad at meÂÃ,  ÂÃ, 

Duplicate public symbol StaticLink@OnMouseMove

One error message for each overridden or new class method.

Edit: I removed the include files from the project and now everything is working.

[Parker]

Yes, include files can't be in a project. I hope that too will be fixed soon but currently all files listed there are compiled.

[Ionic Wind Support Team]

There is nothing to 'fix'.  Projects are supposed to contain source files only.  Include files are meant to be included where they are needed with the #included statement.

[Bruce Peaslee]

There is nothing to 'fix'.ÂÃ,  Projects are supposed to contain source files only.ÂÃ,  Include files are meant to be included where they are needed with the #included statement.

Got it. I was using the project to keep track of other files I was working on, like the include files. Just lazy I guess. Now I know better.

[Parker]

What I mean by fix is add non-compile sections like Visual Studio has, so it's easy to see and open the includes, images, resources, etc.

[Rock Ridge Farm (Larry)]

Earlier in this thread you wrote:


<sup>If all your doing is writing accessor functions that do this:

MyClass::GetCount(),int
{
return m_nCount;
}

You might as well just access it directly.

a = cl.m_nCount;</sup>


I was doing OK till the cl.m_ncount.
How does the 'cl' shorthand know which class you are referencing?

[Ionic Wind Support Team]

It's just the variable name.

MyClass cl;

[Ionic Wind Support Team]

What I mean by fix is add non-compile sections like Visual Studio has, so it's easy to see and open the includes, images, resources, etc.

Yes we will have a list of include files too.  In the middle of ripping apart the IDE code now