Russell> As I understand things, if I create an array of class
Russell> objects, the default constructor for each object will run. I
Russell> would like to avoid this.

Why?  That is, why would you want to create objects but not
initialize them?

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrew Koenig <ark@research.att.com> wrote in message news:<yu99heinactb.fsf@europa.research.att.com>...
> Russell> As I understand things, if I create an array of class
> Russell> objects, the default constructor for each object will run. I
> Russell> would like to avoid this.
>
> Why?  That is, why would you want to create objects but not
> initialize them?

Good question.  I believe that what he really wants is to grab storage
in which objects will later be created, which is exactly what
vector::reserve does.

IMHO, the functionality desired is provided by std::vector and there
is no need for any other change or contortion.

Randy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Russell Reagan" <rreagan@attbi.com> wrote in message
news:mqO%8.161070$uw.94041@rwcrnsc51.ops.asp.att.net...
> As I understand things, if I create an array of class objects, the default
> constructor for each object will run. I would like to avoid this. In C
this
> would be "free" since there would be no initialization, just an addition
to
> the stack pointer. I'd like to see something similar happen in C++.
>
> Is it safe to assume that the compiler will optimize away an empty
> contructor? Or should I do something like change my class to a struct and
> have no default constructor?
>
> For example, if I have a Thing class:
>
> class Thing {
> public:
> Thing() { } // empty constructor
> // other methods
> private:
> // private data
> };
>
> And if I didn't want Thing's constructor to run everytime I created a
large
> array of it, could I solve this problem by making Thing a struct instead
and
> removing it's default constructor? Or should I not worry about the problem
> and assume that the compiler will optimize it away? If that assumption is
> wrong, it could mean big performance hits if I am creating a few billion
of
> these things.

If what you want is to delay construction until you actually need the
object, you could:

1.  Allocate the space with malloc:

    void *buffer = malloc(n * sizeof(Thing));

2. Before using each object, explicitly construct it in place using
placement new

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrew Koenig <ark@research.att.com> wrote:
> Russell> As I understand things, if I create an array of class
> Russell> objects, the default constructor for each object will run. I
> Russell> would like to avoid this.
>
> Why?  That is, why would you want to create objects but not
> initialize them?

There are sometimes circumstances that make this desirable. If memory does
not get touched during initialization, "sparse arrays" can be "faked"
simply be relying on the OS's paging mechanism (at least on some OSs).
For big ranges of "unused" indices, no real memory will ever be used.

I'd guess there are other scenarios like this, but I've seen this one
actually being used.

Andre'

--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrew Koenig wrote:
> Why?  That is, why would you want to create objects but not
> initialize them?

Because there are data structures which can work with
uninitialized parts, and those parts can be arrays which
would be expensive to initialize. Here's an example:

template<size_t N> struct set
{
   size_t n;
   unsigned dense[N];
   unsigned sparse[N];

   set() : n(0) { }
   bool in(unsigned v)
   { return v < N && sparse[v] < n && dense[sparse[v]] == v; }
   void insert(unsigned v)
   { if (!in(v) && v < N) dense[sparse[v] = n++] = v; }
   void delete(unsigned v)
   { if (in(v) && sparse[v] < --n) sparse[dense[sparse[v]] = dense[n]] = sparse[v]; }
   void clear()
   { n = 0; }
};

This code has undefinded behavior in C++; for it to work,
the implementation must guarantee that accessing an
uninitialized array element produces some specific value,
and that this value will be the same each time the
element is accessed. That is, the arrays in set will be
initialized with arbitrary garbage, but then the compiler
should act as if those are the values with which the arrays
have been initialized. The in test makes use of this.

The code above allows for constant-time set creation,
set deletion, membership test, member insertion, and
member deletion. It's particularly good for when sets
are usually small, but can occasionally grow large.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>[<SNIP>]
>class Thing {
>public:
>Thing() { } // empty constructor
>// other methods
>private:
>// private data
>};
>
>And if I didn't want Thing's constructor to run everytime I created a large
>array of it, could I solve this problem by making Thing a struct instead and
>removing it's default constructor?

Yeah, this is an ugly problem.  Generally I'd expect that you need
proper construction and destruction for your classes, you just don't
want to pay for initialization until you need it.  To do this you
would need to implement your own version of the std::vector class with
a custom [] operator.  This uses a bitfield to determine if the
indexed field is constructed, if it isn't it uses a placement new to
default construct the new instance in the "proper place", sets the
constructed bit and then returns the instance.  On destruction of the
vector, the bitfield is walked, destructing the instances that are
constructed.

There are a bunch of gotchas here.  The primary array into which you
are instantiating your classes must be allocated in some way.  This is
a memory management issue, and there are several methods, some simple
and somewhat wasteful(block allocation of memory chunks), some complex
and most efficient(OS organized demand paging).

Another problem is class alignment.  There's no (standard) way to know
the required alignment of a class.  Typically the compiler does this
for you (for example in the new[] operator), but doing it on your own
will be more complex (and less portable).

The whole point here is to avoid touching the memory for those
instances that you never use (demand paging is your friend).  You may
choose to implement an is_present method of some kind to provide a way
to check for instantiated instances.  Another thing to consider is the
possibility of having two types of iterators.  One walks the indexes
(n, n+1, n+2, etc), and the other walks the instantiated instances.

I hope you follow this.  I've tried to cover it in the broadest
possible strokes.  It's not a trivial thing to implement, but it's not
*too* bad.

-SpeedBump

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

As I understand things, if I create an array of class objects, the default
constructor for each object will run. I would like to avoid this. In C this
would be "free" since there would be no initialization, just an addition to
the stack pointer. I'd like to see something similar happen in C++.

Is it safe to assume that the compiler will optimize away an empty
contructor? Or should I do something like change my class to a struct and
have no default constructor?

For example, if I have a Thing class:

class Thing {
public:
Thing() { } // empty constructor
// other methods
private:
// private data
};

And if I didn't want Thing's constructor to run everytime I created a large
array of it, could I solve this problem by making Thing a struct instead and
removing it's default constructor? Or should I not worry about the problem
and assume that the compiler will optimize it away? If that assumption is
wrong, it could mean big performance hits if I am creating a few billion of
these things.

Thanks,
Russell

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Russell Reagan" <rreagan@attbi.com> wrote in message
news:mqO%8.161070$uw.94041@rwcrnsc51.ops.asp.att.net...
> As I understand things, if I create an array of class objects, the default
> constructor for each object will run. I would like to avoid this. In C
this
> would be "free" since there would be no initialization, just an addition
to
> the stack pointer. I'd like to see something similar happen in C++.

You're not alone.

>
> Is it safe to assume that the compiler will optimize away an empty
> contructor? Or should I do something like change my class to a struct and
> have no default constructor?

Changing your class to a struct will have no effect.

>
> And if I didn't want Thing's constructor to run everytime I created a
large
> array of it, could I solve this problem by making Thing a struct instead
and
> removing it's default constructor? Or should I not worry about the problem
> and assume that the compiler will optimize it away? If that assumption is
> wrong, it could mean big performance hits if I am creating a few billion
of
> these things.

If I understand the situation correctly, to ensure that no initialization
occurs:

1. Your class/struct must have no members of class type (only simple types)
and no constructor.
2. You allocate memory using new char[] (or malloc), deal with alignment
issues yourself, and cast the resulting pointer to the right type.

In other words: write it the way you would have in C, and it'll still behave
like C, with all the risks & benefits that come with it.

-cd



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Carl Daniel" <cpdaniel@pacbell.net> wrote in message
news:Y2T%8.28528$fv.90612848@newssvr14.news.prodigy.com...
> "Russell Reagan" <rreagan@attbi.com> wrote in message
> news:mqO%8.161070$uw.94041@rwcrnsc51.ops.asp.att.net...
> > As I understand things, if I create an array of class objects, the
default
> > constructor for each object will run. I would like to avoid this. In C
> this
> > would be "free" since there would be no initialization, just an addition
> to
> > the stack pointer. I'd like to see something similar happen in C++.
>
> You're not alone.
>
> >
> > Is it safe to assume that the compiler will optimize away an empty
> > contructor? Or should I do something like change my class to a struct
and
> > have no default constructor?
>
> Changing your class to a struct will have no effect.
>
> >
> > And if I didn't want Thing's constructor to run everytime I created a
> large
> > array of it, could I solve this problem by making Thing a struct instead
> and
> > removing it's default constructor? Or should I not worry about the
problem
> > and assume that the compiler will optimize it away? If that assumption
is
> > wrong, it could mean big performance hits if I am creating a few billion
> of
> > these things.
>
> If I understand the situation correctly, to ensure that no initialization
> occurs:
>
> 1. Your class/struct must have no members of class type (only simple
types)
> and no constructor.
> 2. You allocate memory using new char[] (or malloc), deal with alignment
> issues yourself, and cast the resulting pointer to the right type.
>
> In other words: write it the way you would have in C, and it'll still
behave
> like C, with all the risks & benefits that come with it.
>
> -cd

You could also use std::vector for this.

std:vector<foo> vecfoo;
vecfoo.reserve(1000000);
//fill the array in order using push_back and only the copy ctor ever gets
called.

Ken Shaw



>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Is it safe to assume that the compiler will optimize away an empty
> contructor? Or should I do something like change my class to a struct and
> have no default constructor?

Yup... the compiler/optimizer should inline that constructor and thus
eliminate
it completely... but then again don't think anything in the C++ standard
mandates this behaviour... it's QoI issue so you should test it with every
particular
compiler you have in mind.

Mind you... a compiler that doesn't do this kind of a thing would... hehehe
... soon
find itself out of a job :-)))

Btw... if you don't define any constructor in a C++ class/struct the
compiler will
still generate an inlined empty default one for you :-)

HTH,
    Jurko


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]