fastest way of passing data to a class

hey

I'm currently building a new data structures that will be used in monte carlo generators (and so will be constructed several milion times) and I'm wondering what's the best way (computer-speed-wise) to pass the data to the constructor.

I am currently doing it using references and passing arrays as pointers like this:

Code:

---

class particle{
public:
    particle(double *ar,int &id):IDup(id){
        for (int i=0;i<5;++i)
            Pup[i]=ar[i];
    }
        int IDup;
        double Pup[5];
};

---

I'm assuming that since using referencies has no need to create a temporary memory slot it's more efficient (if there is a better way, I'm all ears).

As for the arrays: is there a way for me to pass them as reference as well? (not using c++11), I'm using arrays instead of vectors as much as I can because I assume that vectors, being more advanced data structures, would take more time to create.

Pointers and references typically incur an extra indirection (possible cache miss too). Therefore, for small data, you should pass it by value. For big data, you should pass it by reference. That's the general suggestion. To do further optimizations, you have to profile your code to see where the bottlenecks are.

vectors have an overhead when created, but not necessarily when accessing elements (via the index operator).
std::array (C++11) is a pure array which have none to little overhead when created, but is still much safer than C arrays.

See this article for more information:
SourceForge.net: Safer arrays in Cpp - cpwiki

Copying vectors would be expensive, so avoid it where you can. The same goes for any STL type. When it comes to C arrays, copying them is not possible: the language will automatically use pointer semantics.

Is there the option of reusing existing data structures by resetting and/or updating them instead of deleting and recreating them?

Object lifetimes are usually dictated by scope in C++, so once an object falls out of scope it is gone. There are at least a couple of ways to extend object lifetimes so that you can recycle objects. One, using static storage, isn't thread safe. The other method, using dynamic storage, is just hard to use (especially if you eschew smart pointers because you want to be able to recycle objects and all pointer types respect scope to some degree). Having to keep a pointer alive so that you have access to the memory is probably going to wreck havoc on your more important aspects of the program.

Quote:

---

Pointers and references typically incur an extra indirection (possible cache miss too). Therefore, for small data, you should pass it by value.

---

thats exacly the oposite of what thought. thanks, I would pointlessly go the wrong way about this.

Quote:

---

Is there the option of reusing existing data structures by resetting and/or updating them instead of deleting and recreating them?

---

I thought of that, the class will be used in more than one calculation, and in at least one of them I only need a couple of objects and will just reset them when I'm done, but for what is probably the larger part of the work i need a variable number of objects created in sequence (that need data from the previous ones in order to be created).

so for that part I was considering making a vector of the class and push_back. (having 1 object "outside" the vector that gets reused for calculations).
I supose I could have an arbitrarily large array of particles and keep reseting but that kind of defeats the purpose of using C++ (I'm re-coding a Fortran 77 aplication, horrible language, whoever invented "GOTO" should be shot)

Quote:

---

vectors have an overhead when created, but not necessarily when accessing elements (via the index operator).

---

what about extended?

You can use vector. Using the reserve() function, you can reserve a chunk of memory so you won't get reallocations all the time, saving you time. You can use use clear() to get rid of all the data, if you need to start over fresh. It probably won't get rid of the reserved memory, so further push_back's will not cost you so much.

If you store complex objects in the vector, you may consider using emplace_back() (C++11), to further save time.

Quote:

---

Originally Posted by Elysia

You can use vector. Using the reserve() function, you can reserve a chunk of memory so you won't get reallocations all the time, saving you time. You can use use clear() to get rid of all the data, if you need to start over fresh. It probably won't get rid of the reserved memory, so further push_back's will not cost you so much.

If you store complex objects in the vector, you may consider using emplace_back() (C++11), to further save time.

---

one of my project requeriments is to stay out of C++11 for portability considerations (not really my choice). So reserve(), I'll look it up. thank you all

this sounds silly but my only consideration should be class data right?

I mean, my class will have roughly 10 simple variables and a couple of arrays inside. the amount of member functions I put in it is irrelevant right?

Functions do not add to size. An object with 1 million functions but no data is just as cheap to construct as an object with no functions and no data.
If that's what you're asking.

Member functions only need to be placed in memory once and then all the objects will use the same ones.

If this program is going to run on PC, and if 64 bit mode is an option, you may want to consider it. Pointers double in size from 4 bytes to 8 bytes, but you get 8 additional registers that help with compiler optimization.

Quote:

---

Originally Posted by rcgldr

If this program is going to run on PC, and if 64 bit mode is an option, you may want to consider it. Pointers double in size from 4 bytes to 8 bytes, but you get 8 additional registers that help with compiler optimization.

---

program is intended for linux, it requires a library (LHAPDF) that currently has no way of being installed on PC (well, at least not an easy one) and the idea is for the source code to be released so various research groups can alter it for specific projects.

The operating system is typically irrelevant. But different architectures can make a difference.
Regardless, 32-bit or 64-bit is usually the domain of the compiler. All you have to do is typically make no size assumptions in order to make it possible to compile it as 32-bit and 64-bit.

Quote:

---

Originally Posted by rcgldr

If this program is going to run on PC, and if 64 bit mode is an option, you may want to consider it. Pointers double in size from 4 bytes to 8 bytes, but you get 8 additional registers that help with compiler optimization.

---

There are tons of plusses and minuses.
E.g. x64 has a better exception handling mechanism. IIRC, It's faster to throw exceptions, but slower to enter a try block.
The performance of an x64 app vs an x86 app might be sometimes better, sometimes worse, and sometimes the same.

In any case, I would stick to a discussion of the language in this instance, and not go into architecture specifics as it is a completely tangential topic.