default values - the good, the bad and the ugly

[Dan Cernat]

Hi there,

A few threads I had a little chat about default values. I am starting this
thread because I want to hear more opinions about the default values of
function parameters. Some say they see no use of them. Others say thar they
are bad. I like them. So, could anyone tell me why they are in the standard?
Are they bad?

I do not intend to start war. Nor am I a troll.

/dan

swap name/domain to reply by mail

 

[Victor Bazarov]

A few threads I had a little chat about default values. I am starting this
thread because I want to hear more opinions about the default values of
function parameters. Some say they see no use of them. Others say thar they
are bad. I like them. So, could anyone tell me why they are in the standard?
Are they bad?

I think those who call any language feature "bad" need to find
the old fable about the fox and the grape. Another analogy
lies in an old saying "Bad dancer's legs always in the way of
his dancing".

I, for one, cannot imagine how much more tedious would code
maintenance be if we didn't have default arguments. If there
is a need to make some minor behaviour adjustment of some
function used all over the code, I can easily add an extra
argument, give it a default value and thus leave the calling
code untouched. Only my new code will use non-default argument
values. That's only one example.

Victor

 

[Victor Bazarov]

A few threads I had a little chat about default values. I am starting this
thread because I want to hear more opinions about the default values of
function parameters. Some say they see no use of them. Others say thar they
are bad. I like them. So, could anyone tell me why they are in the standard?
Are they bad?

I think those who call any language feature "bad" need to find
the old fable about the fox and the grape. Another analogy
lies in an old saying "Bad dancer's legs always in the way of
his dancing".

I, for one, cannot imagine how much more tedious would code
maintenance be if we didn't have default arguments. If there
is a need to make some minor behaviour adjustment of some
function used all over the code, I can easily add an extra
argument, give it a default value and thus leave the calling
code untouched. Only my new code will use non-default argument
values. That's only one example.

Victor

 

[Cy Edmunds]

Hi there,

A few threads I had a little chat about default values. I am starting this
thread because I want to hear more opinions about the default values of
function parameters. Some say they see no use of them. Others say thar they
are bad. I like them. So, could anyone tell me why they are in the standard?
Are they bad?

I do not intend to start war. Nor am I a troll.

/dan

swap name/domain to reply by mail

OK, let's say we do away with default arguments. Then instead of saying:

void f(int x, int y = 0) {..}

we would have to say:

void f(int x, int y) {...}
void f(int x) {f(x, 0);}

So a default argument is basically just shorthand notation for an overload.
Hardly worth hyperventilating about IMHO.

 

[Evan]

Hi there,

A few threads I had a little chat about default values. I am starting this
thread because I want to hear more opinions about the default values of
function parameters. Some say they see no use of them. Others say thar they
are bad. I like them. So, could anyone tell me why they are in the standard?
Are they bad?

As Cy said, some people see them as redundant with the introduction of
overloading. I disagree, and see a couple benefits to using them. I
find
int foo(int bar = 0) { ... }
much more readable than
int foo(int bar) { ... }
int foo() { return foo(0); }
and it's less typing to boot. The latter is also less efficient
(unless the compiler does weird stuff) because of an extra return and
possibly an extra copy being made of the return value (I'm not sure
what the standard requires here). If you're returning a string or
something like that by value, this could be noticable. The latter is
also harder to maintain; say you have a function that takes one
required and one optional parameter and you decide to take the first
as a double rather than an int; with the second, you have to change
two lines.

To answer your question about why it is in the standard, Stroustrup
introduced it before overloading. He noticed there was a "need" for a
mechanism that would reduce the number of functions required, and
default arguments are reasonably easy to implement as language
features go. Without them the above would have had to expand to
int foo1(int bar) { ... }
int foo0() { return foo1(0); }
with different function names. Overloading however was both harder to
implement and harder to define. You have to work out many details of
how it will work even before you try to implement. Like the following
situation:
void foo (int a);
void foo (double a);
...
foo( float(0.0) );
which version does it call? Here it's probably trivial to see that the
double one is a better match, but many cases are not nearly as clear
cut. Stroustrup says that had overloading been done before default
arguments, it's likely that default arguments would not have been
added. But as it worked out, the timing meant that it is a (IMO) very
nice feature of C++.

Evan

 

[Norbert Riedlin]

As others have pointed out, the effect of default arguments can be achived
by overloading e.g.

void f(int, int=0);

is equivalent to

void f(int, int);
void f(int i) {f(i, 0);}

I would like to add that this approach cannot be used for constructors, i.e.
for a given class C:

C::C(int, int=0);

cannot be rewritten as

C::C(int, int);
C::C(int i) : C(i, 0) {} // illegal syntax

So in this respect default arguments add to the language.

Just my 2 ct

Norbert

 

[lilburne]

I, for one, cannot imagine how much more tedious would code
maintenance be if we didn't have default arguments. If there
is a need to make some minor behaviour adjustment of some
function used all over the code, I can easily add an extra
argument, give it a default value and thus leave the calling
code untouched. Only my new code will use non-default argument
values. That's only one example.

Victor

A cautionary tale:

Once upon a time a class was written to hold lines and arcs that formed
closed regions, which could be decorated. As time went on lots of
methods were written that took one of or more of these regions and did
useful processing on them, and the implicit assumption was that all
these regions were closed.

Then one day someone came along and said oh I want a class that consists
of decorated segments made up of lines and arcs but I want it so that I
can have non-closed regions. So they took the 'region' class and added a
flag to say whether the thing could hold closed or non-closed bits, and
they altered the default constructor so that you could create a closed
or non-closed version by giving it a flag, and they made the flag a
default argument so that existing code didn't have to be changed. As
time went on lots of code was written that processed these open-ended
bits of geometry.

Then one day an instance of an 'open' region was handed to some code
that expected closed regions, and the whole ramshackle pack of cards
fell around everyones ears.

Now I'm not bitter but if the diseased brain that originated this hadn't
been able to apply the default argument trick, this god awful fucked up
nondesign could have been halted at its bastard conception.


Compiler fuckups:

I have a piece of code that looks like this

int i = get_int();

myArchiveWriter >> i;

and an old SPARC compiler that upon seeing

class someClass {
public:
someClass(double d, int size = 0);
};

thinks that:

myArchiveWriter& operator>>(myArchiveWriter&, someClass& c);

is the best match.

 

[Howard]

A cautionary tale:

Once upon a time a class was written to hold lines and arcs that formed
closed regions, which could be decorated. As time went on lots of
methods were written that took one of or more of these regions and did
useful processing on them, and the implicit assumption was that all
these regions were closed.

Then one day someone came along and said oh I want a class that consists
of decorated segments made up of lines and arcs but I want it so that I
can have non-closed regions. So they took the 'region' class and added a
flag to say whether the thing could hold closed or non-closed bits, and
they altered the default constructor so that you could create a closed
or non-closed version by giving it a flag, and they made the flag a
default argument so that existing code didn't have to be changed. As
time went on lots of code was written that processed these open-ended
bits of geometry.

Then one day an instance of an 'open' region was handed to some code
that expected closed regions, and the whole ramshackle pack of cards
fell around everyones ears.

Now I'm not bitter but if the diseased brain that originated this hadn't
been able to apply the default argument trick, this god awful fucked up
nondesign could have been halted at its bastard conception.

Well, it's hardly the fault of default parameters. One of two mistakes were
made (if not both): 1) the person who modified the class to allow open
regions did not take into account that some part of the code *required*
closed regions; 2) the person who wrote the code that required closed
regions did not check if the region it was given was closed before trying to
use it.

But the real problem may have been that a new "open region" class was
required, perhaps making both the closed and open region classes descend
from some abstract base class.

Personally, my only beef with default parameters is that sometimes I would
like to have one of the passed parameters be default, and sometimes another.
Of course, that would make it kind of tough on the parser!

-Howard

 

[Dan Cernat]

A cautionary tale:

Once upon a time a class was written to hold lines and arcs that formed
closed regions, which could be decorated. As time went on lots of
methods were written that took one of or more of these regions and did
useful processing on them, and the implicit assumption was that all
these regions were closed.

Then one day someone came along and said oh I want a class that consists
of decorated segments made up of lines and arcs but I want it so that I
can have non-closed regions. So they took the 'region' class and added a
flag to say whether the thing could hold closed or non-closed bits, and
they altered the default constructor so that you could create a closed
or non-closed version by giving it a flag, and they made the flag a
default argument so that existing code didn't have to be changed. As
time went on lots of code was written that processed these open-ended
bits of geometry.

Then one day an instance of an 'open' region was handed to some code
that expected closed regions, and the whole ramshackle pack of cards
fell around everyones ears.

Now I'm not bitter but if the diseased brain that originated this hadn't
been able to apply the default argument trick, this god awful fucked up
nondesign could have been halted at its bastard conception.

The thing is that in your tale, they didn't change only a constructor
(to have some default parameter values), they changed the class
entirely, I mean, they gave a new meanning for the entire class. That
is bad design. They should have had two classes derived from a common
one (that doesn't care about open or closed regions) - I'm sure you
know what I am talking about.
Having a new constructor with the additional parameter would have
helped? No. Someone could have passed the same object (open
region)(correctly constructed this time) to the function that expected
a closed region.

Compiler fuckups:

I have a piece of code that looks like this

int i = get_int();

myArchiveWriter >> i;

and an old SPARC compiler that upon seeing

class someClass {
public:
someClass(double d, int size = 0);
};

thinks that:

myArchiveWriter& operator>>(myArchiveWriter&, someClass& c);

is the best match.

My Turbo C 2.0 doesn't know about templates ergo, templates are bad.
C'mon, let's move forward, change the compiler or don't use the
language's feature if you don't like it. BTW I never used goto in any
of my programs. Should it be removed from language?

/dan

 

[Cy Edmunds]

"Dan Cernat" <[email protected]> wrote in message

As Cy said, some people see them as redundant with the introduction of
overloading. I disagree, and see a couple benefits to using them. I
find
int foo(int bar = 0) { ... }
much more readable than
int foo(int bar) { ... }
int foo() { return foo(0); }
and it's less typing to boot. The latter is also less efficient
(unless the compiler does weird stuff) because of an extra return and
possibly an extra copy being made of the return value (I'm not sure
what the standard requires here).

Efficiency probably isn't the issue because the standard allows the compiler
to perform optimizations so long as the answer is right.

A bigger issue your example brings up is this: does

foo();

have exactly the same effect as

foo(0);

? In the first example you can see that it does by looking at the interface
only. In the second example you have to look at the implementation, which is
bad form and in many practical cases (e.g. code is not inline) may be
impossible. Clearly, the default argument is to be preferred.

[snip]

 

[lilburne]

The thing is that in your tale, they didn't change only a constructor
(to have some default parameter values), they changed the class
entirely, I mean, they gave a new meanning for the entire class. That
is bad design. They should have had two classes derived from a common
one (that doesn't care about open or closed regions) - I'm sure you
know what I am talking about.

That is exactly the point. The class was turned into two
classes, and the thing that made it possible was the
seductive application of a default parameter. This is an
extreme case of bolting on a flag to something that already
exists. In most cases you end up with a method that behaves
differently depending on whether an argument is supplied or not.

Having a new constructor with the additional parameter would have
helped? No. Someone could have passed the same object (open
region)(correctly constructed this time) to the function that expected
a closed region.

Well by the time that the horror blew up lots of code had
been written that was compromised. The act of forcing
everyone to construct the class with a flag like:

Region open(wartOPEN);
Region closed(wartCLOSED);

would have alerted people glancing at the code to the fact
that something smelly was going on. As it was those that
worked primarily with closed 'regions' had little awareness
that the class had been compromised.

The headers of methods that assumed 'closed' regions hadn't
been updated to say "don't call this with open segements".
What the default parameter did was sweep the issue under the
carpet for a number of months, because the originated hadn't
had to raise an API change, it had managed to sneaked past
critical scutiny.

My Turbo C 2.0 doesn't know about templates ergo, templates are bad.
C'mon, let's move forward, change the compiler or don't use the
language's feature if you don't like it. BTW I never used goto in any
of my programs. Should it be removed from language?

The point of this is not that the SPARC compiler gets it
wrong (spectacular as it is) but that you have a class that
can be constructed with a single parameter of inbuilt type.
You ought to also be suspicious of the default argument,
which was bolted on at a later date, again to avoid an API
change. In the specific case the someClass is a container of
geometric curves, 'd' is the c0 continuous tolerance between
adjacent curves, and 'size' the initial capacity of the
container. The container allocates more space as its size
increases.

Now what happens if you don't supply a size? Well as curves
are added the internal buffer resizes, which has a
performance hit, and can result in memory fragmentation. To
avoid having to resize all the time extra slots are
reserved. If this was implemented in terms of std::vector
the capacity reserved would be double the last size. Whilst
you hardly ever want an initial capacity of zero the default
argument encourages its use.

Like a goto, sometimes a well designed default argument will
makes sense (though I've yet to encounter an example). Using
them to avoid an API change, or to make one function look
like 2 or more simply to save clients from typing a few
extra characters, will bite you over time.

 

[Jerry Coffin]

[ ... ]

Now I'm not bitter but if the diseased brain that originated this hadn't
been able to apply the default argument trick, this god awful fucked up
nondesign could have been halted at its bastard conception.

Not true -- if default values hadn't been available, he could have
simply overloaded the ctor instead, having one with no argument, and one
with an argument.

There is no way to idiot-proof a language, and when you try you usually
end up with an abomination that only an idiot would use.

 

[lilburne]

[ ... ]

Now I'm not bitter but if the diseased brain that originated this hadn't
been able to apply the default argument trick, this god awful fucked up
nondesign could have been halted at its bastard conception.

Not true -- if default values hadn't been available, he could have
simply overloaded the ctor instead, having one with no argument, and one
with an argument.

Well there are unlimited ways by which someone can screw up
a system and for whilst some the only safe course is to deny
them access to text editors and source code, for others a
set of working guidelines can be very helpful. An online
book of horrors can also act as a reminder.

When you monitor the cause of bugs and see a pattern
develop, you ought to do something other than say

"oh dear, its happened again."

this case was the culmination of a number of bugs that had
usage of default parameters somewhere in their antecedence.

So in the case of default parameters we discourage their
use. If new occurrences are found then the code gets passed
to others to examine and decide whether the usage is really
justified (none found so far). With about 1000 man years of
C++ development we collectively 'know' that default
arguments are a good source of future bugs, and when added
to existing code an good indication that proper analysis and
or testing hasn't taking place.

There is no way to idiot-proof a language, and when you try you usually
end up with an abomination that only an idiot would use.

Strange enough with our idiot-proofing of the language, and
other systems we have no crises weekend working or late
nights. It seems to work.

 

[Jerry Coffin]

[ ... ]

When you monitor the cause of bugs and see a pattern
develop, you ought to do something other than say

"oh dear, its happened again."

Quite true.

this case was the culmination of a number of bugs that had
usage of default parameters somewhere in their antecedence.

I'll bet all the buggy code also had assignment statements, and most it
also probably contained at least one function call -- I'm pretty sure
none of these (assignments, function calls OR default parameters) is any
more than incidental to the real problem.

I've just spent 20 minutes or so reading through posts you've made here,
and they mostly seem to fall into a simple pattern: you seem to use C++
roughly in the form it existed around the cfront 1.2 era, or so, and
restrict even that to some degree. You distrust and discourage anything
newer, but in most cases your justification is much like in this one:
you blame something that's clearly no more than incidentally related to
the real problem.

So in the case of default parameters we discourage their
use. If new occurrences are found then the code gets passed
to others to examine and decide whether the usage is really
justified (none found so far). With about 1000 man years of
C++ development we collectively 'know' that default
arguments are a good source of future bugs, and when added
to existing code an good indication that proper analysis and
or testing hasn't taking place.

Everything I've seen you post yet (and as I said, I just spent 20 minute
or so reviewing your posts) seems to indicate that you really don't
know, and generally refuse to find out.

Strange enough with our idiot-proofing of the language, and
other systems we have no crises weekend working or late
nights. It seems to work.

I can only go by what I've seen here, of course, but from what you've
posted, I would have guess that was the case -- but not because your
product is so wonderful; rather, because virtually nobody's even paying
a little bit of attention to what you do.

 

[lilburne]

[ ... ]

When you monitor the cause of bugs and see a pattern
develop, you ought to do something other than say

"oh dear, its happened again."

Quite true.

this case was the culmination of a number of bugs that had
usage of default parameters somewhere in their antecedence.

I'll bet all the buggy code also had assignment statements, and most it
also probably contained at least one function call -- I'm pretty sure
none of these (assignments, function calls OR default parameters) is any
more than incidental to the real problem.

I've just spent 20 minutes or so reading through posts you've made here,
and they mostly seem to fall into a simple pattern: you seem to use C++
roughly in the form it existed around the cfront 1.2 era, or so, and
restrict even that to some degree. You distrust and discourage anything
newer, but in most cases your justification is much like in this one:
you blame something that's clearly no more than incidentally related to
the real problem.

Strange. I recall default arguments being part of the
language way back in 1990, over the years experience has
been to distrust their use, and it took sometime before we
fully appreciated the problems that they cause.

Now I've said on a couple of occasions in this thread that
I've yet to see a justified reason for using them, fully
expecting someone to mention the legitimate use in the
standard library, but so far one one has. Arguments that
almost always have one value, but allow the client to supply
an alternative on rare occasions. Like a custom allocator
for the std containers.

Perhaps its because so many are hungup on using default
arguments to 'save-a-bit-of-typing' or to smuggle in an API
change by the backdoor, all the wrong reasons, that they
forget that default arguments are 'defaults'. Writing
constructor like:

Point(double x = 0.0, double y = 0.0);

so that they can code

Point p1;
Point p2(10.0);
Point p3(100.0, 100.0)
Vector vec(p1-p3);

and not realizing that the Vector initialization looks like
a bug. Or adding a default flag parameter:

f(double x, bool flag = false);

and see nothing strange in half the time writing:

f(d);

and the other half of the time writing:

f(d,true);

I can only go by what I've seen here, of course, but from what you've
posted, I would have guess that was the case -- but not because your
product is so wonderful; rather, because virtually nobody's even paying
a little bit of attention to what you do.

Well if I was writing database report programs with 2 or 3
colleagues for internal use, I might have a different
perspective too.

 

[Dan Cernat]

[ ... ]

Or adding a default flag parameter:

f(double x, bool flag = false);

and see nothing strange in half the time writing:

f(d);

and the other half of the time writing:

f(d,true);

it could also be

f(d, booleanVariable);

which I find more useful

That would have happened in the following scenario:

f(double x) // existing old function
{
// do something with x
}

oops, we need to change f so it receives another boolean flag. cannot
possibly change all the existing calls to f so what we do? we keep the olf f
as well (remember? cannot change all the calls, or even worse, f is part of
a library that is already on the market, so changing f signature would break
existing clients).

f(double x, bool flag) // the new f
{
// do something with x *and* flag
}

f(double x) // the old f rewritten to use the new f
{
f(x, true);
}

now, what you said applies here as well: "half the time it will be f(d) and
the other half will be f(d, true)"

isn't it the same thing? without default parameter values this time.

However, there were several responses to the original post and you are the
only one against it. If this is such an issue, certainly others must have
encountered it. Apparently you are the only one complaining. Think about it.
You know, from where I come, there is a saying: "if two people tell you that
you are drunk, better go to sleep"

But enough for now.
/dan

 

[lilburne]

f(d, booleanVariable);

which I find more useful

That would have happened in the following scenario:

f(double x) // existing old function
{
// do something with x
}

oops, we need to change f so it receives another boolean flag. cannot
possibly change all the existing calls to f so what we do? we keep the olf f
as well (remember? cannot change all the calls, or even worse, f is part of
a library that is already on the market, so changing f signature would break
existing clients).

How do you know that the clients aren't already broken? What
prompted the addition of a boolean flag?

The trouble with your approach is that client code continues
to work, although you know that there were problems with the
old API. You have given your clients no help in finding out
whether they need to use the new argument or not. Basically
you've just resorted to cowardice and tried to hide the
problem from them.

However, there were several responses to the original post and you are the
only one against it. If this is such an issue, certainly others must have
encountered it. Apparently you are the only one complaining. Think about it.
You know, from where I come, there is a saying: "if two people tell you that
you are drunk, better go to sleep"

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&[email protected]

 

[Jerry Coffin]

[ ... ]

Strange. I recall default arguments being part of the
language way back in 1990, over the years experience has
been to distrust their use, and it took sometime before we
fully appreciated the problems that they cause.

You sound like an astronomer of the middle ages telling us ignorant
savages about how the earth really IS the center of the universe, and
everything revolves around it in epicycles...

Now I've said on a couple of occasions in this thread that
I've yet to see a justified reason for using them, fully
expecting someone to mention the legitimate use in the
standard library, but so far one one has.

I'm no more likely to give a serious response to your asking for
"justified" uses of default arguments than you would be if I asked for
justification for using assignment statements.

Perhaps its because so many are hungup on using default
arguments to 'save-a-bit-of-typing' or to smuggle in an API
change by the backdoor, all the wrong reasons, that they
forget that default arguments are 'defaults'.

Rather the contrary -- we're simply giving your inane nonsense the
attention it deserves (okay, I'll admit that in this post, I'm giving it
far MORE than it deserves).

Writing constructor like:

Point(double x = 0.0, double y = 0.0);

so that they can code

Point p1;
Point p2(10.0);
Point p3(100.0, 100.0)
Vector vec(p1-p3);

and not realizing that the Vector initialization looks like
a bug. Or adding a default flag parameter:

f(double x, bool flag = false);

and see nothing strange in half the time writing:

f(d);

and the other half of the time writing:

f(d,true);

Based on your other posts, I can believe you routinely DO see code this
bad, and (from what you've said in this thread) even worse. The fact,
however, that your coworkers and apparently you as well, are incompetent
doesn't mean there's anything wrong with default arguments.

[ ... ]

Well if I was writing database report programs with 2 or 3
colleagues for internal use, I might have a different
perspective too.

I can't even guess what you think you're referring to here -- I've seen
nobody in this thread (or any other recent ones) who gives any
indication of writing database report programs for strictly internal
use, or anything like it.

Quite the contrary -- in:

http://www.google.com/groups?selm=bnml28$13pr13$1@ID-
203936.news.uni-berlin.de

you indicate that you work mostly with code written 20-30 years ago.
In:

http://www.google.com/groups?selm=bnuim4$166m63$1@ID-
203936.news.uni-berlin.de

you seem to be saying that where you work, no changes are made to
anything unless it's basically so buggy that it can't even imitate
usefulness as it stands.

In:
http://www.google.com/groups?selm=bnuhfg$166mhl$1@ID-
203936.news.uni-berlin.de

you make a rule that all temporaries must be created explicitly --
thereby making it impossible to do almost any sort of operator
overloading (for one example).

And, in:

http://www.google.com/groups?selm=bmn1ga$ofg72$1@ID-
203936.news.uni-berlin.de

you give what is apparently a reasonable summary of your own skill
set...

In the end, you give every appearance of knowing the syntax and even
(most of) the semantic rules of C++, but your background shows through
all too well: even though you use C++ syntax, what you're working on is
really Fortran code, and ultimately, you're really a Fortran programmer.

 

[lilburne]

[ ... ]

Strange. I recall default arguments being part of the
language way back in 1990, over the years experience has
been to distrust their use, and it took sometime before we
fully appreciated the problems that they cause.

You sound like an astronomer of the middle ages telling us ignorant
savages about how the earth really IS the center of the universe, and
everything revolves around it in epicycles...

Are you saying that default arguments weren't in the
language in 1990?

I'm no more likely to give a serious response to your asking for
"justified" uses of default arguments than you would be if I asked for
justification for using assignment statements.

Well the assignment operator can be over used.

Based on your other posts, I can believe you routinely DO see code this
bad, and (from what you've said in this thread) even worse. The fact,
however, that your coworkers and apparently you as well, are incompetent
doesn't mean there's anything wrong with default arguments.

Oh to be a god amongst gods. Leaves one wondering why, with
such olympian skills, a flag had to be bolted on to the API
for example.

[ ... ]

Well if I was writing database report programs with 2 or 3
colleagues for internal use, I might have a different
perspective too.

I can't even guess what you think you're referring to here -- I've seen
nobody in this thread (or any other recent ones) who gives any
indication of writing database report programs for strictly internal
use, or anything like it.

You seem to have taken offence I don't know why.

Quite the contrary -- in:

http://www.google.com/groups?selm=bnml28$13pr13$1@ID-
203936.news.uni-berlin.de

you indicate that you work mostly with code written 20-30 years ago.

'converted' is such a big word isn't it and terrible hard to
understand, but as a god you really ought to try.

In:
http://www.google.com/groups?selm=bnuim4$166m63$1@ID-
203936.news.uni-berlin.de

you seem to be saying that where you work, no changes are made to
anything unless it's basically so buggy that it can't even imitate
usefulness as it stands.

So you'd be prepared to go into working code and reformat
it, rename the variables, change the data structures, purely
on a whim, no change document, agreement, or planning, that
figures.

Must be real fun if there are two of you with different
ideas of what constitutes 'better'. Damn that Jerry has
changed all the class instance variables to have a m_
prefix, it should be a _m suffix, think I'll change it. Damn
that lilburne has changed all the class instance variables...

"Oh look there is a new 'smart pointer' type by XXX lots
better than the boost one, gotta change the code to use
it."

In:
http://www.google.com/groups?selm=bnuhfg$166mhl$1@ID-
203936.news.uni-berlin.de

you make a rule that all temporaries must be created explicitly --
thereby making it impossible to do almost any sort of operator
overloading (for one example).

The temporaries were potentially being used to assign 200+Mb
of data. In our own case containers typically hold 10-20Mb
which is not something we want being copied via temporaries,
we'd mostly make the assignment and copy constructor private
too. No point it letting some one write a function:

f(std::vector<Point> data);

naturally olympian gods wouldn't write such a thing, so
you've probably never seen the consequences of it.

And, in:

http://www.google.com/groups?selm=bmn1ga$ofg72$1@ID-
203936.news.uni-berlin.de

you give what is apparently a reasonable summary of your own skill
set...

In the end, you give every appearance of knowing the syntax and even
(most of) the semantic rules of C++, but your background shows through
all too well: even though you use C++ syntax, what you're working on is
really Fortran code, and ultimately, you're really a Fortran programmer.

Some recognize that certain constructs ought to be used
judiciously, and maintain a set of guidelines that are
intended to minimize the possibilities of past errors being
repeated. After all only a fool learns from his own
mistakes. Injudicious use of default arguments leads to
problems and examples of such mistakes have been given here,
and in previous posts. You even indicate that you believe
the usage presented is bad code, yet would still provide no
warning against using default arguments despite the fact
that others have 'justified' there use on exactly the same
basis as the 'bad code' above.
http://www.sei.cmu.edu/tsp/psp.html