Default Constructor Parameters Question

Suppose I have a simple class CColor that defines a "color" as follows:

typedef unsigned long tCOLOR;
typedef struct
{
 tCOLOR Red;
 tCOLOR Green;
 tCOLOR Blue;
} tRGB;

class CColor
{
public:
 CColor( tRGB &RGB = ColorBlack ) : mRGB(RGB){};
private:
 tRGB mRGB;
};


Now, suppose I want to define another class that takes as
and OPTIONAL parameter to its constructor a CColor:

CColor ColorBlack;  // THIS WHAT I WANT TO AVOID

class CBorder
{
public:
 CBorder( CColor &Color = ColorBlack ) : mColor(Color)  {};

private:
 CColor  mColor;
};

My question is this: How do I declare the CBorder class and its constructor
such that I do not have to have a global class defined such as I have
done above with "ColorBlack"?

I want to avoid the global and all its associated ugliness.  Actually, I'd like to completely
dispense with the tRGB type altogether.  It's just a bandaid too.
Any ideas would be appreciated.

Thanks
staggartAsked:
Who is Participating?
 
nietodConnect With a Mentor Commented:
The solution I would use is to give the tColor class a constructor (default or not)  then you can specify a tempoary tColor object as the default to CColor class.  Like

struct  tRGB
 {
     tCOLOR Red;
     tCOLOR Green;
     tCOLOR Blue;
    tRGB(tCOLOR R = 0,tCOLOR G = 0, tCOLOR B= 0) : Red(R),Green(G),Blue(B) {};
};


class CColor
     {
     public:
     CColor( tRGB &RGB = tRGB()) : mRGB(RGB){};  // Note use temp tRGB;
     private:
     tRGB mRGB;
     };



     class CBorder
     {
     public:
     CBorder( CColor &Color = CColor()) : mColor(Color)  {};  // Use temp her to.

     private:
     CColor mColor;
     };


let me know if you have questions.
0
 
staggartAuthor Commented:
I left out a declaration and one other thing.  Here's the correct code my question refers to:

typedef unsigned long      tCOLOR;
typedef struct                  
{
      tCOLOR Red;
      tCOLOR Green;
      tCOLOR Blue;
} tRGB;

tRGB                  ColorBlack = { 0, 0, 0 };

class CColor
{
public:
      CColor( tRGB &RGB = ColorBlack ) : mRGB(RGB){};
private:
      tRGB      mRGB;
};


Now, suppose I want to define another class that takes as
and OPTIONAL parameter to its constructor a CColor:

CColor CColorBlack;            // THIS WHAT I WANT TO AVOID

class CBorder
{
public:
      CBorder( CColor &Color = CColorBlack ) : mColor(Color)  {};

private:
      CColor            mColor;
};
0
 
MithanderCommented:
What I would do is completely take out the tRGB struct.  Then redo the CColor class like this:

class CColor
{
private:
long Red;
long Green;
long Blue;
public:
CColor():Red(0),Green(0),Blue(0){};
CColor(long R, long G, long B):Red(R),Green(G),Blue(B){};
};

that way there is two constructors.  If you type
CColor Color;
Color is defined as black.  If you type
CColor Color(255,255,255);
then Color is white.  Now you can just do CBorder like this

class CBorder
{
private:
CColor mColor;
public:
CBorder(){};
CBorder(CColor Color):mColor(Color){};  //To do this you need to define a copy constructor.
CBorder(long R,long G, long B):mColor(R,G,B){};
};

Hope this helps
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
staggartAuthor Commented:
Thanks, nice, succinct answer.

Scott
0
 
staggartAuthor Commented:
Actually,  Mithander, your answer is good (maybe better) too.  Thanks for your input.

Scott

0
 
nietodCommented:
Personally, I think my answer is better, but in the future if you believe that an answer placed in a comment is better than the official answer, you should reject the official answer and ask the person who commented to submit a "dummy" answer.

The reason I liked my answer is that it is a small change that allows you to keep your program organization almost the same.  More importantly, this sort of approach can help minimize the number of constructors to a class.  For the CColor and CBorder class mithander was forced to have two constructors while I only had one.  Not a big savings but as a class hierarchy grows this difference becomes more significant.
0
 
staggartAuthor Commented:
Glad you got that off your chest.

I gave you the points because you answered first, and I desire to not get into a pissing contest over something as mudane as this.  I 'personally' like Mithander's answer because it gets rid of a type (tRGB) and keeps things in classes where they generally belong.  And, I think your call of a constructor to create a "temp", is somewhat non-standard...
0
 
nietodCommented:
As to which is better, its 6 of one or half-dozen of the other.  

However the use of temporary variables in C++ is not non-standard.  First of all, temporary objects are implicily created by the compiler in numerious cases that you may not ever realize.  For example, whenever you return an object by value a temporary has to be created.  (And there are many others.)  However explicit use of temporaries It is a very important technique that is at the heart of many advanced mechanisms (proxy classes and conversions, for example).  
0
 
staggartAuthor Commented:
Thanks for your input.  I have been recetly reading the Lippman book "Inside the C++ Object Model" and, yes, you are correct - the compiler does do a lot of behind the scenes stuff.

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.