Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!brunix!cslab7f.cs.brown.edu!cs132093
From: cs132093@cslab7f.cs.brown.edu (Dan Bornstein)
Newsgroups: comp.lang.c++
Subject: Re: default argument discussion
Message-ID: <32127@brunix.UUCP>
Date: 9 Mar 90 17:59:11 GMT
References: <1006@xyzzy.UUCP>
Sender: news@brunix.UUCP
Reply-To: cs132093@cslab7f.cs.brown.edu (Dan Bornstein)
Organization: Brown Computer Science Dept.
Lines: 83


In article <1006@xyzzy.UUCP>, langley@bigbird.rtp.dg.com (Mark L
Langley) writes:
> [lots-o-stuff deleted]
> 
> Now I wouldn't really expect someone to put
> 	foo(int x=i+j) {}
> in the function definition -- this would probably be a misuse.  Rather, I 
> would more expect some user of foo (a regular user at that) to supply some 
> more appropriate value than the generic default.  Consider this
> 
> 	// foo.h
> 	void foo(int operation_type=0);
> 		...
> 	// Delete.h
> 	#include foo.h
> 	enum MajorOptype { Noop, Insert=100, Delete=200 };
> 	void foo(int operation_type=Delete);
> 
> 	// application.c
> 	#include Delete.h
> 	enum MinorOptype { Paragraph, Word, Line, Column };
> 
> 	// big function bar with LOTS of calls to foo
> 	insert_from_deleted_buffer() {
> 	extern void foo(int operation_type=major_operation + minor_operation);
> 	const int major_operation=Insert;
> 	enum MinorOptype minor_operation;
> 	  <code that sets minor_operation>
> 	foo();
> 	}

Whoah! This could lead to some strange bugs. Remember that many .h files have
an #ifdef NAME and #endif surrounding their bodies. So, take this situation:

// foo.h
#ifndef FOO
#define FOO
void foo (int op=0);
#endif

// bar.h
#ifndef BAR
#define BAR
#include "foo.h"
const Bar = 100;
void foo (int op=Bar);
inline void bar (void)
{
  // stuff
  foo ();
  // more stuff
}
#endif

// baz.h
#ifndef BAZ
#define BAZ
#include "foo.h"
inline void baz (void)
{
  // stuff
  foo (); // using foo()'s original default.
  // more stuff
}
#endif

Now, foon wants to use bar() and baz(), so we have: 

// foon.c
#include "bar.h"
#include "baz.h"

Now, the problem is that baz() will be defined incorrectly since after bar.h
is included, the #defines keep the old foo() declaration from being
encountered. This could be a real problem when bar and baz are not originally
part of the same project and therefore the original author(s) didn't realize
the ugly possibility.

In other words, baz() behaves differently depending on whether or not bar.h
has been included first. This seems to defeat modularity.

-dan