private default constructor is good or bad?

[swengtoo]

In his book "More Effective C++", Scott Meyer suggests in "Item 4" to
"Avoid gratuitous default constructors".

To summarize his claims against default constructors for "the right
classes" he states that:

=============== === START QUOTE =============
"A default constructor is the C++ way of saying you can get something
for nothing. Constructors initialize objects, so default constructors
initialize objects without any information from the place where the
object is being created. Sometimes this makes perfect sense. Objects
that act like numbers, for example, may reasonably be initialized to
zero or to undefined values. Objects that act like pointers may
reasonably be initialized to null or to undefined values. Data
structures like linked lists, hash tables, maps, and the like may
reasonably be initialized to empty containers.

Not all objects fall into this category. For many objects, there is no
reasonable way to perform a complete initialization in the absence of
outside information. For example, an object representing an entry in an
address book makes no sense unless the name of the thing being entered
is provided. In some companies, all equipment must be tagged with a
corporate ID number, and creating an object to model a piece of
equipment in such companies is nonsensical unless the appropriate ID
number is provided.

Inclusion of meaningless default constructors affects the efficiency of
classes, too. If member functions have to test to see if fields have
truly been initialized, clients of those functions have to pay for the
time those tests take. Furthermore, they have to pay for the code that
goes into those tests, because that makes executables and libraries
bigger. They also have to pay for the code that handles the cases where
the tests fail. All those costs are avoided if a class's constructors
ensure that all fields of an object are correctly initialized. Often
default constructors can't offer that kind of assurance, so it's best
to avoid them in classes where they make no sense. That places some
limits on how such classes can be used, yes, but it also guarantees
that when you do use such classes, you can expect that the objects they
generate are fully initialized and are efficiently implemented."
=============== === END QUOTE =============

Now... I tried to follow this guideline (among others), by declaring a
private default constructor for a class that seems to be useless
without being properly initialized with some values.

However, this created a problem of inability to optimize my application
for speed. The reason is that in my particular case I am re-creating a
database record (represented by the aforementioned class with private
ctor) on the heap in a pretty huge loop. The call to 'new' is very
costly in terms of CPU cycles... I realized I can improve performance
greatly if I instantiate this record only once *outside* the loop.
However, outside the loop I don't have any meaningful values to
initialize that record with, so a default constructor seems to be
required here...

So, my question is: how do I solve the dilemma? On one hand, from the
*logical correctness* point of view, it doesn't make sense for my class
to have a default constructor. On the other hand, from *performance*
point of view a default constructor is required (or using some dummy
values for the non-default ctor, which is basically the same).

Can performance considerations justify violation of "elegant
implementation" ?

[swengtoo]

Oops... Sorry for posting here. After waiting in vain the entire day
for my post to appear on comp.lang.c++.m oderated, I thought my message
was rejected and thus decided to try my luck here. Interestingly
enough, a few minutes after posting here, my message appeared in
comp.lang.c++.m oderated as well... I guess I should have waited longer.
Sorry again for the double-post. You can safely ignore this thread.

[roberts.noah]

swengtoo wrote:

In his book "More Effective C++", Scott Meyer suggests in "Item 4" to
"Avoid gratuitous default constructors". So, my question is: how do I solve the dilemma?

First by realizing that even what seems like a logically good idea
doesn't always apply.

Second, you could implement some sort of static class that does the
optimization you want by "initializi ng" the same pointer with different
data. Doing this without getting ugly could get ugly. Some sort of
factory method of sorts.

Good luck.

[Art Stamness]

Maybe I am missing the point here. but I will give this a try. . .

If you want to construct and not pay for the memory allocation penalty
, why not just create your object local to this function. You create a
local object and then using placement new, you can re-construct the
object over and over again, with whatever constructor. You will not
allocate any memory, and the only penalty you pay is the actual
constructor call.

I think there is some magic involved if you need to call the
onstructor. something like

Is this what you are looking for ?

-Art

#include <new>

class Foo {
public:
Foo ( int a ) : A(a) { }
private :
Foo() ;
int A ;
};

void do_some_foo ( void )
{
Foo local_foo ( -1 ) ; // Local variable
int count_a = 0 ;
while ( 1 ) {
local_foo.Foo:: ~Foo() ; // If you need to call this
new ( &local_foo ) Foo ( count_a++ ) ; // will not allocate
}
}