The fear of new things... 3 ideas for C++.

[Alf P. Steinbach]

I wonder why we, or at least I, react with so much fear to new ideas.

Or even old ideas!

In my time I have, in various Usenet groups, even called people bad things for
promoting the following ideas, which I now see very little wrong with, at least
when they're not abused for problems they're not applicable to:

* Post-constructors and pre-destructors.
Advanced by Andrei over in clc++m. He thought it would help especially
with X-windows programming. I then thought it was ridiculous, fearing
an escalation to N-phase initialization -- instead of looking for
solutions to the bad-usage problems I envisioned.

* Exception-free programming.
Advanced by someone I don't recall in [no.it.programmering.c++]. I think
I called that person "brain-dead" or something like that. But the fact is
that many shops do exception-free C++ programming, e.g. at Opera (which is
about 16 minutes' walk from where I live), not to mention Google. It's just
that it isn't C++ as I know it. It's their kind of C++.

* Oh, sorry.
I had three ideas in mind when I started to write this but the third one
disappeared. I can't recall. Perhaps I feared that one so much that Mr.
Freud's "forgetfulness" has kicked in.

Anyways... Oh yes, I could have written up using 'signed' for non-negative value
ranges, because I once agreed with the position of using 'unsigned' and argued
vociferously against anyone suggesting using 'signed', but it's been a long time
since I changed my mind about that. It was not the third idea above.

But I'm sure that there must be many more ideas like these, ideas that we shoot
down almost instinctively because they at first appear to be so different, so
alien, so /non-conforming/, that they must be wrong, somehow.

And then, after shooting down the idea, taking years to realize that it's
perhaps not so stupid and dangerous after all. And when one does, one wonders
why that should take years? I'm guessing some people don't change their minds at
all, though, happily deluding themselves about not having been wrong.


Cheers,

- Alf (introspective)

 

[Victor Bazarov]

[..]
And then, after shooting down the idea, taking years to realize that
it's perhaps not so stupid and dangerous after all. And when one does,
one wonders why that should take years? [..]

Not at all related to C++, but my general observation is that with time
passing, if I appear to have changed my mind about something I used to
oppose, it's not necessarily because I now agree with it, it's most
likely because I just don't give a sh!t anymore. Disagreeing and
arguing takes precious time and energy. There are just more important
things in life for which I have less and less time. Let stupid ideas
take care of shooting themselves down: natural consequences.

V

 

[Öö Tiib]

I wonder why we, or at least I, react with so much fear to new ideas.

Or even old ideas!

Most things can not be 100% concluded in one way or other. Initially
you did pick one side one day and had long nasty debates. Now you pick
other side to show yourself that you can tolerate either way and know
every bone of the issue. You can argue for each side better than most
if you so want since you have read the opinions to death. But ... you
do not care.

That signed versus unsigned, public versus protected virtuals,
exceptions versus return codes, exceptions versus asserts, binary
versus text files, native versus smart pointers, recursion versus
cycles and so on. All it soon feels like "goto" ... discussing
what ... you quickly start to talk about everything but "goto".

Nirvana.

 

[Jerry Coffin]

[ ... ]

* Post-constructors and pre-destructors.
Advanced by Andrei over in clc++m. He thought it would help
especially with X-windows programming. I then thought it was
ridiculous, fearing an escalation to N-phase initialization
-- instead of looking for solutions to the bad-usage
problems I envisioned.

If memory serves, Bjarne has said these were included in some really
early versions of C++ (or perhaps it was still C with Classes at the
time) but dropped because he was the only one who used them, and he
was having a hard time explaining why/how they were needed or useful,
and nobody else used them. Furthermore, I believe he said at the time
he was using them in only one library (the task library, if memory
serves).

I have to say that I'm not sure you weren't right about this one
though. What I'd personally prefer is a more general framework for
specifying that function X will be automatically invoked in response
to event Y -- where there are a number of predefined events including
those above, as well as the ability to define and invoke new events.

Defining this well would probably be quite difficult though -- the
general idea is pretty similar to Unix 'signal's, which have been
difficult to specify in a way that's portable to other systems (even
in C) and seem to "play" poorly with quite a bit of C++ as well.

* Exception-free programming.
Advanced by someone I don't recall in [no.it.programmering.c++]. I think
I called that person "brain-dead" or something like that. But the fact is
that many shops do exception-free C++ programming, e.g. at Opera (which is
about 16 minutes' walk from where I live), not to mention Google. It's just
that it isn't C++ as I know it. It's their kind of C++.

You're certainly right that this idea isn't new. Way back when,
Niklaus Wirth commented something to the effect that "anybody who
thinks they need exception handling really needs to learn how to
program."

I can't say I agree with him on that -- I suspect a great deal of his
aversion to exception handling stemmed from its early use in
languages like PL/I, where it was used for (IMO) inappropriate
purposes like dealing with the end of a file (did somebody really
think reaching the end of a file was unexpected?)

[ ... ]

But I'm sure that there must be many more ideas like these, ideas
that we shoot down almost instinctively because they at first
appear to be so different, so alien, so /non-conforming/, that they
must be wrong, somehow.

I can't say that I shot them down, but a couple of ideas Andrei has
advanced over the years have raised that kind of reaction from me --
so different that my immediate reaction was that they just had to be
wrong, even though rationally I couldn't point to a real problem they
would create. In most cases, I've managed to restrain my immediate
reaction, and at least *attempted* to consider them with an open mind
-- but (like you) I often find it at least somewhat difficult.

As to why that is, I think it's probably a question more for a
newsgroup devoted to basic psychology than programming -- I do seem
to vaguely recall some mention of such things in a psychology class I
had to take in college, but that was long enough ago that 1) I
wouldn't remember it very well at best, and 2) from what I recall, my
attendance in that class wasn't the best anyway...

 

[Jorgen Grahn]

[..]
And then, after shooting down the idea, taking years to realize that
it's perhaps not so stupid and dangerous after all. And when one does,
one wonders why that should take years? [..]

Not at all related to C++, but my general observation is that with time
passing, if I appear to have changed my mind about something I used to
oppose, it's not necessarily because I now agree with it, it's most
likely because I just don't give a sh!t anymore. Disagreeing and
arguing takes precious time and energy. There are just more important
things in life for which I have less and less time. Let stupid ideas
take care of shooting themselves down: natural consequences.

Judging from the production code I see, there is no such Darwin
effect. You can get away with really stupid practices, and noone
outside the group will expose you. The Daily WTF is just the tip of
the iceberg.

For example, I once heard of an embedded system which did numerical
calculations. Except instead of +, -, /, sin() and so on, they had
CORBA or COM interfaces. To calculate a + b, you packed them into a
message and passed them to the "addition server". Then if you wanted
(a+b)/c, you passed a message to the "division server".

I bet that if that project went over budget or had quality issues,
those on the outside thought it was because their task was really
hard. Not because they had Groucho Marx as their architect.

/Jorgen

 

[Robert Hairgrove]

I wonder why we, or at least I, react with so much fear to new ideas.

In Germany, there is a saying: "The farmer won't eat something
unfamiliar to him" (i.e., "Was der Bauer nicht kennt, det frisst er net...")

Or even old ideas!
ditto...

[snip]

* Post-constructors and pre-destructors.
Advanced by Andrei over in clc++m. He thought it would help especially
with X-windows programming. I then thought it was ridiculous, fearing
an escalation to N-phase initialization -- instead of looking for
solutions to the bad-usage problems I envisioned.

Do you have a link to that thread? I have often encountered situations
where I would like to have special initializations performed after the
constructor has run because the constructor has no access to overrides
in the derived class while it is still running. This can be implemented
using a member object with type of some helper class which can be
customized on a per-class basis. Unfortunately, it is next to impossible
to call member functions of such data members except as the last line in
the constructor body, which means that there are still similar
limitations as to which functions one may safely call because the
constructor hasn't finished yet... Post-constructors might come in handy
here.

* Exception-free programming.

Well, this is certainly easy enough to implement as long as you don't
use libraries which throw.

 

[Keith H Duggar]

I wonder why we, or at least I, react with so much fear to new ideas.

In Germany, there is a saying: "The farmer won't eat something
unfamiliar to him" (i.e., "Was der Bauer nicht kennt, det frisst er net....")

Or even old ideas!
ditto...

[snip]

  * Post-constructors and pre-destructors.
    Advanced by Andrei over in clc++m. He thought it would help especially
    with X-windows programming. I then thought it was ridiculous, fearing
    an escalation to N-phase initialization  --  instead of looking for
    solutions to the bad-usage problems I envisioned.

Do you have a link to that thread? I have often encountered situations
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/ab1a749b744e6601

where I would like to have special initializations performed after the
constructor has run because the constructor has no access to overrides
in the derived class while it is still running. This can be implemented
using a member object with type of some helper class which can be
customized on a per-class basis. Unfortunately, it is next to impossible
to call member functions of such data members except as the last line in
the constructor body, which means that there are still similar
limitations as to which functions one may safely call because the
constructor hasn't finished yet... Post-constructors might come in handy
here.

KHD

 

[Alf P. Steinbach]

* Robert Hairgrove:

I wonder why we, or at least I, react with so much fear to new ideas.

In Germany, there is a saying: "The farmer won't eat something
unfamiliar to him" (i.e., "Was der Bauer nicht kennt, det frisst er
net...")

Or even old ideas!
ditto...

[snip]

* Post-constructors and pre-destructors.
Advanced by Andrei over in clc++m. He thought it would help especially
with X-windows programming. I then thought it was ridiculous, fearing
an escalation to N-phase initialization -- instead of looking for
solutions to the bad-usage problems I envisioned.

Do you have a link to that thread?

I see Keith Duggar has provided one, if it is that thread. I would be reluctant
to provide such link because as I recall that thread reflected so extremely
poorly on me, resorting to really bad & inexcusable ad hominem argumentation. On
the other hand, perhaps that behavior proves that I'm human, not a furry ALF
from Tralfamadore or wherever (of course I'm just pretending to not remember...).

I have often encountered situations
where I would like to have special initializations performed after the
constructor has run because the constructor has no access to overrides
in the derived class while it is still running. This can be implemented
using a member object with type of some helper class which can be
customized on a per-class basis. Unfortunately, it is next to impossible
to call member functions of such data members except as the last line in
the constructor body, which means that there are still similar
limitations as to which functions one may safely call because the
constructor hasn't finished yet... Post-constructors might come in handy
here.

There are two main solutions within the scope of C++98.

(1)
The idea Dynamic Binding During Initialization is discussed in the FAQ at <url:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.6>. Quite
simply, you pass up, either via constructor argument or via templating, the
functionality needed in the Base class constructor, e.g. a factory for API level
widgets. It is just a kind of separation of concerns.

Like most other regulars here I've contributed a lot of times in small doses to
the FAQ, but the above is my main contribution. It's Marshall Cline's writing,
though. And the DBDI acronym is his invention.

This is the intrusive solution, the class has to be designed to support DBDI.


(2)
The second solution, which is non-intrusive, is to derive from the class and
forward constructor arguments.

General constructor argument forwarding is directly supported in C++0x (by a
combo of rvalue references, variadic template arguments and variadic function
args) but how to do that in C++98, e.g. for a templated bottom level class?

Well, consider the following (actual, working test-) code:


<code origin="my cppx lib, which is Under Construction">
// Copyright (c) Alf P. Steinbach, 2010.

#include <progrock/cppx/argument_forwarding.h>

#include <assert.h>
#include <iostream>
#include <iomanip>

using namespace progrock;
using namespace cppx;

using namespace std;

namespace {
static bool test( char const expr[], bool const value )
{
cout << setw( 75) << left << expr << " " << value << endl;
return value;
}

#define TEST( expected, e ) assert( !!expected == !!test( #e, e ) )


struct Base
{
Base( int x, char const s[] )
{
cout << x << ", " << s << endl;
}
};

struct Wrapped
: ConstructorArgForwarder< Base >
{
template< class ArgPack >
Wrapped( char const s[], ArgPack const& args )
: ConstructorArgForwarder< Base >( args )
{
cout << "Wrapped: " << s << endl;
}
};

} // namespace anon

void testArgumentForwarding()
{
Wrapped( "at bottom", args( 42, "blah blah" ) );
}
</code>


The trick here is to have suitable ArgPack and ConstructorArgForwarder
(templated) classes! I'm guessing that you can probably use Boost's Parameters
Library for the ArgPack. However, you'll have to then roll your own
ConstructorArgForwarder, or use the cppx one if/when I post the code for that
library.

Hm, I'll have to blog about this!


Cheers, & hth.,

- Alf
(who has a BLOG at <url: http://alfps.wordpress.com/> )

 

[Squeamizh]

* Robert Hairgrove:

In Germany, there is a saying: "The farmer won't eat something
unfamiliar to him" (i.e., "Was der Bauer nicht kennt, det frisst er
net...")

Or even old ideas!

ditto...

[snip]

* Post-constructors and pre-destructors.
Advanced by Andrei over in clc++m. He thought it would help especially
with X-windows programming. I then thought it was ridiculous, fearing
an escalation to N-phase initialization -- instead of looking for
solutions to the bad-usage problems I envisioned.

Do you have a link to that thread?

I see Keith Duggar has provided one, if it is that thread. I would be reluctant
to provide such link because as I recall that thread reflected so extremely
poorly on me, resorting to really bad & inexcusable ad hominem argumentation. On
the other hand, perhaps that behavior proves that I'm human, not a furry ALF
from Tralfamadore or wherever (of course I'm just pretending to not remember...).

Eh, no worries, dude. Everyone has said things they regret. Some of
us are unfortunate enough to have our mistakes recorded in history via
the Internet. Anyway, I didn't think you really said anything all
that bad in that thread.

 

[DaveB]

I wonder why we, or at least I, react with so much fear to new ideas.

I wonder why we, or at least I, react with so much fear to new ideas.

[snip, read the important to context snipped stuff in clc]

Sounds like "the change of the guard" is trying to ... um, what are
(ARE?) you trying to do Alf? Is it just your job?

 

[Robert Hairgrove]

> [snip lots of good stuff...]

I did have a look at that thread. Didn't get past the first 50 messages
or so, but this kind of problem would easily be handled by an abstract
factory class or function. The factory could take care of the logging,
and access to the constructor could be limited to the factory class.

At least that's how I would do it.