Programming Forums > Application Development > C++

Eoin · Sep 15th, 2007, 4:46 PM

Hi, I've a question for the gurus here, I'm hoping there is a simple answer which I just keep missing. The "Don't Repeat Yourself" principle, or DRY, is a fairly standard rule you should usually follow. But I'm really not sure what the best way is to apply it to constructor initialization lists short of using a common base member.

Here is what I'm currently using:

 cpp Syntax (Toggle Plain Text) 
class Foo
{
public:
	#define FOO_DRY \
		one(1), \
		two(2), \
		three(3)
 
	Foo() :	
		FOO_DRY,		
		four(4)
	{}
 
	Foo(int f) :	
		FOO_DRY,		
		four(f)
	{}
 
	#undef FOO_DRY
 
private:
	int one, two, three, four;
};
class Foo
{
public:
	#define FOO_DRY \
		one(1), \
		two(2), \
		three(3)
		
	Foo() :	
		FOO_DRY,		
		four(4)
	{}
	
	Foo(int f) :	
		FOO_DRY,		
		four(f)
	{}
	
	#undef FOO_DRY
	
private:
	int one, two, three, four;
};

Would anyone know of a better way to do this?

DaWei · Sep 15th, 2007, 5:42 PM

I'm not sure what you're getting at. Suppose you need to use an algorithm lebenty-four times. You don't copy and paste the algorithm, but write a function. You still need to repeat the call.

Is your concern with footprint, execution speed, or satisfying some dictum proposed by some phoney high-priest looking for acolytes?

Incidentally, a #define provides little beyond readability and a single site of modification. The definition is substituted everywhere it's encountered, before the compiler sees the file.

Eoin · Sep 15th, 2007, 5:54 PM

Of your three options I think satisfying a phoney high-priest is the best fit.

In some cases, say if you have a member which is a reference, then it needs to be set in an initialization list.

But even then it is hard to come up with an example (even a very contrived one) where what I was thinking about would really be beneficial.

Perhaps this thread is best written off as a misguided academic exercise.

Cache · Sep 16th, 2007, 3:59 PM

Proposal for C++0x Delegating Constructors:
http://www.open-std.org/JTC1/SC22/WG...2006/n1986.pdf (pdf)

You might find that interesting. I wouldn't take it as a justification for your macro hack job, though.

Game_Ender · Sep 20th, 2007, 1:08 AM

I too am trying to figure out weather its better to use the Macro here or not. When a class gathers members (up to around 10) the list can get hard to maintain and using something like the macro can help. Of course there is an argument to be made the class is getting large enough that this becomes and issue you to take another look at the class.

Jessehk · Sep 20th, 2007, 7:37 PM

Well, I don't know if this really applies (or even if it was a good idea), but in my tic-tac-toe game (with some code inspired by DaWei's contributions) there was some really repetitive stuff. Mostly it was "move x to y" for 8-9 unrelated values. Well, actually, there was a pattern, but the work in abstracting it would have been more than just doing it the easy way and with very little return.

Instead of

(Toggle Plain Text)

fill( Spot( 0, 1, src.spotAt( 2, 1 ).icon() ) )

9 times, I wrote a macro:

(Toggle Plain Text)

#define FILL_AT_FROM( src, x1, y1, x2, y2 ) \
    fill( Spot( (x1), (y1), src.spotAt( (x2), (y2) ).icon() ) )

And now it lookes like this:

(Toggle Plain Text)

    void Board::rotateLeft() {
        Board b( *this );
        clear();
        
        FILL_AT_FROM( b, 0, 0, 2, 0 );
        FILL_AT_FROM( b, 1, 0, 2, 1 );
        FILL_AT_FROM( b, 2, 0, 2, 2 );
        FILL_AT_FROM( b, 0, 1, 1, 0 );
        FILL_AT_FROM( b, 2, 1, 1, 2 );
        FILL_AT_FROM( b, 0, 2, 0, 0 );
        FILL_AT_FROM( b, 1, 2, 0, 1 );
        FILL_AT_FROM( b, 2, 2, 0, 2 );
    }

I think it's better.

DaWei · Sep 20th, 2007, 11:43 PM

On the other hand, my rotate left looked like this, not a macro in sight:

(Toggle Plain Text)

def rotateL (p):
    '''
    Rotate a pattern counterclockwise by 90 degrees
    '''
    a = p [:]
    a [6] = p [0]
    a [0] = p [2]
    a [2] = p [8]
    a [8] = p [6]
    a [3] = p [1]
    a [1] = p [5]
    a [5] = p [7]
    a [7] = p [3]
    return a

Sep 15th, 2007, 4:46 PM	#1
Eoin Hobbyist Programmer Join Date: Jun 2006 Location: Ireland Posts: 152 Rep Power: 3	Don't Repeat Yourself principle for Initialization lists. Hi, I've a question for the gurus here, I'm hoping there is a simple answer which I just keep missing. The "Don't Repeat Yourself" principle, or DRY, is a fairly standard rule you should usually follow. But I'm really not sure what the best way is to apply it to constructor initialization lists short of using a common base member. Here is what I'm currently using: cpp Syntax (Toggle Plain Text) class Foo { public: #define FOO_DRY \ one(1), \ two(2), \ three(3) Foo() : FOO_DRY, four(4) {} Foo(int f) : FOO_DRY, four(f) {} #undef FOO_DRY private: int one, two, three, four; }; class Foo { public: #define FOO_DRY \ one(1), \ two(2), \ three(3) Foo() : FOO_DRY, four(4) {} Foo(int f) : FOO_DRY, four(f) {} #undef FOO_DRY private: int one, two, three, four; }; Would anyone know of a better way to do this? __________________ Visit my website BinaryNotions.

Sep 15th, 2007, 5:42 PM	#2
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	I'm not sure what you're getting at. Suppose you need to use an algorithm lebenty-four times. You don't copy and paste the algorithm, but write a function. You still need to repeat the call. Is your concern with footprint, execution speed, or satisfying some dictum proposed by some phoney high-priest looking for acolytes? Incidentally, a #define provides little beyond readability and a single site of modification. The definition is substituted everywhere it's encountered, before the compiler sees the file. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Sep 15th, 2007, 5:54 PM	#3
Eoin Hobbyist Programmer Join Date: Jun 2006 Location: Ireland Posts: 152 Rep Power: 3	Of your three options I think satisfying a phoney high-priest is the best fit. In some cases, say if you have a member which is a reference, then it needs to be set in an initialization list. But even then it is hard to come up with an example (even a very contrived one) where what I was thinking about would really be beneficial. Perhaps this thread is best written off as a misguided academic exercise. __________________ Visit my website BinaryNotions.

Sep 20th, 2007, 1:08 AM	#5
Game_Ender Professional Programmer Join Date: May 2006 Location: Maryland, USA Posts: 306 Rep Power: 3	I too am trying to figure out weather its better to use the Macro here or not. When a class gathers members (up to around 10) the list can get hard to maintain and using something like the macro can help. Of course there is an argument to be made the class is getting large enough that this becomes and issue you to take another look at the class. __________________ Robotics @ Maryland AUV Team - Software Lead

Sep 20th, 2007, 7:37 PM	#6
Jessehk The Oblivious One Join Date: May 2005 Location: Ontario, Canada Posts: 646 Rep Power: 4	Well, I don't know if this really applies (or even if it was a good idea), but in my tic-tac-toe game (with some code inspired by DaWei's contributions) there was some really repetitive stuff. Mostly it was "move x to y" for 8-9 unrelated values. Well, actually, there was a pattern, but the work in abstracting it would have been more than just doing it the easy way and with very little return. Instead of (Toggle Plain Text) fill( Spot( 0, 1, src.spotAt( 2, 1 ).icon() ) ) fill( Spot( 0, 1, src.spotAt( 2, 1 ).icon() ) ) 9 times, I wrote a macro: (Toggle Plain Text) #define FILL_AT_FROM( src, x1, y1, x2, y2 ) \ fill( Spot( (x1), (y1), src.spotAt( (x2), (y2) ).icon() ) ) #define FILL_AT_FROM( src, x1, y1, x2, y2 ) \ fill( Spot( (x1), (y1), src.spotAt( (x2), (y2) ).icon() ) ) And now it lookes like this: (Toggle Plain Text) void Board::rotateLeft() { Board b( this ); clear(); FILL_AT_FROM( b, 0, 0, 2, 0 ); FILL_AT_FROM( b, 1, 0, 2, 1 ); FILL_AT_FROM( b, 2, 0, 2, 2 ); FILL_AT_FROM( b, 0, 1, 1, 0 ); FILL_AT_FROM( b, 2, 1, 1, 2 ); FILL_AT_FROM( b, 0, 2, 0, 0 ); FILL_AT_FROM( b, 1, 2, 0, 1 ); FILL_AT_FROM( b, 2, 2, 0, 2 ); } void Board::rotateLeft() { Board b( this ); clear(); FILL_AT_FROM( b, 0, 0, 2, 0 ); FILL_AT_FROM( b, 1, 0, 2, 1 ); FILL_AT_FROM( b, 2, 0, 2, 2 ); FILL_AT_FROM( b, 0, 1, 1, 0 ); FILL_AT_FROM( b, 2, 1, 1, 2 ); FILL_AT_FROM( b, 0, 2, 0, 0 ); FILL_AT_FROM( b, 1, 2, 0, 1 ); FILL_AT_FROM( b, 2, 2, 0, 2 ); } I think it's better. __________________ Dr. Zoidberg: [ecstatic] I'm going to a movie... with FRIENDS!

Sep 16th, 2007, 3:59 PM	#4
Cache Hobbyist Join Date: Sep 2005 Posts: 266 Rep Power: 4	Proposal for C++0x Delegating Constructors: http://www.open-std.org/JTC1/SC22/WG...2006/n1986.pdf (pdf) You might find that interesting. I wouldn't take it as a justification for your macro hack job, though.

Sep 20th, 2007, 11:43 PM	#7
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	On the other hand, my rotate left looked like this, not a macro in sight: (Toggle Plain Text) def rotateL (p): ''' Rotate a pattern counterclockwise by 90 degrees ''' a = p [:] a [6] = p [0] a [0] = p [2] a [2] = p [8] a [8] = p [6] a [3] = p [1] a [1] = p [5] a [5] = p [7] a [7] = p [3] return a def rotateL (p): ''' Rotate a pattern counterclockwise by 90 degrees ''' a = p [:] a [6] = p [0] a [0] = p [2] a [2] = p [8] a [8] = p [6] a [3] = p [1] a [1] = p [5] a [5] = p [7] a [7] = p [3] return a __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Assigning an array of lists	deanosrs	C	42	Apr 13th, 2006 2:35 PM
Linked Lists	Eric the Red	C++	6	Mar 19th, 2006 1:47 AM
Nested Lists	Mjordan2nd	Python	2	Oct 22nd, 2005 4:41 PM

Programming Forums > Application Development > C++

Don't Repeat Yourself principle for Initialization lists.