On Sat, Mar 26, 2005 at 03:50:39AM -1000, Joshua Blocher wrote:
Hi,
As a few of you know from jabber i have been working on deforming paths. I have finished one function and starting a write the second. before i get much further i need help figuring out what a deform class has to/needs to/ should have in it.
here is what i have so far but, they are not all implemented mind you. comments and input more than welcome.
class Deform;
NR:Point CoordDiff( NR:Point, NR:Point ); NR:Point AdvCoordDiff(); int DeformPath(); int DeformObject();
public: NR:Point GetCoordDiff( NR:Point, NR:Point ); NR:Point GetAdvCoordDiff(); int DoPathDeform(); int DoDeformObject();
Here's some suggestions... First, read through the CodingStyle guidelines in Wiki. That will give some ideas on guidance and so forth.
Second, here is the general style of how classes should be done. Use this as a starting point:
/* * \brief My Class Name * * Description here * * Authors: * Your Name * * Copyright (C) 2005 Authors * * Released under GNU GPL. Read the file 'COPYING' for more info. */
#ifndef INKSCAPE_MY_CLASS_H #define INKSCAPE_MY_CLASS_H
#include "foo.h"
namespace Inkscape {
class MyClass { public: MyClass(); virtual ~MyClass();
Glib::ustring myFunction() const;
protected: guint my_data;
private: MyClass(MyClass const &); MyClass operator=(MyClass const &); }
} // namespace Inkscape
#endif // INKSCAPE_MY_CLASS_H
Third, use 'const' variables in every place where you know you won't need to modify the data. For instance:
NR:Point CoordDiff( NR:Point, NR:Point );
Probably could be:
NR:Point CoordDiff( const NR:Point&, const NR:Point& );
This approach (using const and ref's) is both safer (prevents bugs from creeping in) and more efficient (avoids overhead of copying the input parameters). Learn more about why this is good, so you understand it, and adopt it as a habit in all of your C++ coding. :-)
Fourth, in C++ classes are more than just collections of functions. If the functions in a class are stand-alone, there's little reason to put them into a class. Where you want to create a class is when you distinctly have an "object" that contains some sort of internal data that the member functions manipulate.
For instance, d = CoordDiff(a,b) sounds like it could be pretty much stand alone. Give it two points, it returns a diff. It quite likely wouldn't need to share data with other functions, and if so there'd be little need to put it into a class.
On the other hand, doFoobar() type routines tend to make sense as member routines. They imply that there is something inside the object, and these routines allow you to poke and manipulate it to do different things. Some might argue that the 'do' is rendundant in such a case, since in a typical class all member routines are 'doing' something to the data. ;-)
Hope this helps, Bryce