I would like to do something like this in c++ (but I cant since there is no "baseobject" like in for example JAVA)
double integrate(double(*integrand)(InputData, int), vector<BaseObject>& inputdata){
...
for(...)
value+= integrand(inputdata, someIntVariable);
...
return value;
}
where I have put different types of objects in inputData that shuold be input for my integrand-function. I then can just cast these values inside my integrand-functions
double integrand1(vector<BaseObject> &inputdata, int s){
double d = (double) inputdata.at(1);
char s = (char ) inputdata.at(2);
... do stuff with d ans s
}
How can I accomplish this in some other way?
Edit I understand why it is not a good idee to pass a vector by value, I just wanted to show that I need a collection of different data for different integrands.
I can explain what my goal with the function is: I want to do a general integration-function, so I can can pass a general "integrand" that my function then integrates numerically. However, different integrands needs completely different input data (say maybe some need 4x4 matrices etc).
In java anything more complex than an int is a reference. In C++ objects are not references by default. This makes it impossible to store different objects in a vector since each object type will require a different ammount of space to store it (vectors store objects contiguously).
To achive what you want you will have to use pointers (a more generalized version of a reference since you can perform pointer maths on a pointer). There is nothing wrong with using a vector of void* but you are probably better off using a common base class for all the objects you want to store in the vector since you will need some way to find out the type before you can process your objects (C++ has very limited RTTI).
Use boost::any.
vector<boost::any> inputdata
The C++ way to do this is with templates:
template<typename integrand_type, typename inputdata_type>
double integrate(integrand_type &&integrand, const inputdata_type &inputdata){
...
for(...)
value+= integrand(inputdata, someIntVariable);
...
return value;
}
... assuming inputdata should be a constant container of some sorts. Also, you do understand that passing a vector by value, as a function parameter, makes a complete copy of the vector, right? That's why you need a reference.
Java objects are completely different from C++ objects. In Java, when you reference an object you are really referencing a pointer to an object. All objects in Java are references. In C++ you have to be explicit as to what you want, otherwise you will end up producing terribly inefficient code.
Related
I am reading a lot of different things on C++ optimization and I am getting quite mixed up. I would appreciate some help. Basically, I want to clear up what needs to be a pointer or not when I am passing vectors and structures as parameters or returning vectors and structures.
Say I have a Structure that contains 2 elements: an int and then a vector of integers. I will be creating this structure locally in a function, and then returning it. This function will be called multiple times and generate a new structure every time. I would like to keep the last structure created in a class member (lastStruct_ for example). So before returning the struct I could update lastStruct_ in some way.
Now, what would be the best way to do this, knowing that the vector in the structure can be quite large (would need to avoid copies). Does the vector in the struct need to be a pointer ? If I want to share lastStruct_ to other classes by creating a get_lastStruct() method, should I return a reference to lastStruct_, a pointer, or not care about that ? Should lastStruct_ be a shared pointer ?
This is quite confusing to me because apparently C++ knows how to avoid copying, but I also see a lot of people recommending the use of pointers while others say a pointer to a vector makes no sense at all.
struct MyStruct {
std::vector<int> pixels;
int foo;
}
class MyClass {
MyStruct lastStruct_;
public:
MyStruct create_struct();
MyStruct getLastStruct();
}
MyClass::create_struct()
{
MyStruct s = {std::vector<int>(100, 1), 1234};
lastStruct_ = s;
return s;
}
MyClass::getLastStruct()
{
return lastStruct_;
}
If the only copy you're trying to remove is the one that happen when you return it from your factory function, I'd say containing the vector directly will be faster all the time.
Why? Two things. Return Value Optimisation (RVO/NRVO) will remove any need for temporaries when returning. This is enough for almost all cases.
When return value optimisation don't apply, move semantics will. returning a named variable (eg: return my_struct;) will do implicit move in the case NRVO won't apply.
So why is it always faster than a shared pointer? Because when copying the shared pointer, you must dereference the control block to increase the owner count. And since it's an atomic operation, the incrementation is not free.
Also, using a shared pointer brings shared ownership and non-locality. If you were to use a shared pointer, use a pointer to const data to bring back value semantics.
Now that you added the code, it's much clearer what you're trying to do.
There's no way around the copy here. If you measure performance degradation, then containing a std::shared_ptr<const std::vector<int>> might be the solution, since you'll keep value semantic but avoid vector copy.
I'm making custom vector and matrix class for numerical calculations.
I want to treat each row and column of the matrix as a vector. Also, I do not want to use extra memory, therefore, I made VectorView class which uses data in matrix directly(Like GSL library). Here is the outline of my matrix class.
class Matrix{
priavte:
T data[];
....
public:
VectorView row(int n);
VectorView colum(int n);
};
And I define a function which uses VectorView.
myFunc(VectorView& v);
My VectorView class has some extra data, therefore I want to use VectorView as a reference to save memory.
However, I got a problem when I calling a function like this.
Matrix m;
...
...
myFunc(m.row(i));
The problem is that m.row(i) returns temporary object therefore I cannot use reference type to treat it. But
auto v = m.row(i);
myFunc(v);
this does not makes a error even though it is exactly same but not clear reason to use v. I want to use the above one. Is there an brilliant solution for this type of problem?
row returns an rvalue reference (VectorView&&), which cannot be passed as a non-const lvalue reference (VectorView&). You can either redefine myFunc as myFunc(const VectorView& v) or myFunc(VectorView&& v), depending on your requirements and the behaviour of VectorView.
If myFunc needs access to non-const members of VectorView, you'll need to define the latter, which will pass the returned value from row into myFunc using move semantics. However, since VectorView is just a "view" onto the original data, it possibly doesn't have (or need) any non-const members, in which case, you should use the former.
use valarray and gslice
http://www.cplusplus.com/reference/valarray/gslice/
N-D (including 2D) matrices are why Bjarne added gslices (AFAIK)
Don't reinvent the wheel and use Eigen
eigen.tuxfamily.org
is a header-only c++ matrix library with very good support and performance
Guess your vector view contains only a pointer to original data and a integer for step (1 for row, n for column). In that case treat it as a value object is fine (as long as you make sure the life cycle of matrix is good). So if you want the syntax, you can just use value in myFunc. Like: myFunc(VectorView) ...
Write two VectorViews: VectorView and ConstVectorView. The first holds a view of a slice of data, and a method is const iff it does not change which slice you are looking at. Changing members is ok in a const method of VectorView.
ConstVectorView is a view of a vector where changing the value of elements is illegal. You can change what you are viewing with non-const methods, and you can access elements to read with const methods.
You should be able to construct a ConstVectorView from a VectorView.
Then, when you return a VectorViewand pass it to a function, the function should either take it by value, or take it by const&. If the function doesn't modify its contents, it takes a ConstVectorView.
Make your life simple, and stick to C-style semantics (this allows you to use the wealth of C linear algebra code available out there, and easy to use the fortran ones as well).
You state that you are concerned about using extra memory, but if you are simply concerned and do not have tight bounds, ensure you store the matrix in both row and column format. This will be crucial for getting any kind of performance out of common matrix operations (as you will be using whole cache lines at a time).
class Matrix{
private:
T rowData[];
T colData[];
...
public:
T const * row(int n) const;
T const * colum(int n) const;
...
};
I'm adding a C++ front-end to a C library. One function in this library calls back to a handler with an array and an integer with the size of the array. Therefore you must provide a C function,
int handler(int argc, sometype **argv);
Now, I'd like to allow the C++ calling code to provide a more C++ish handler function, something like,
int handler(std::vector<sometype*> args);
Changing the handler type isn't hard, I just have to provide my own handler which then calls the user-provided handler. So I need to create an std::vector and copy the contents of argv into it.
However, I don't really want to copy the entire list of pointers if possible. Unfortunately I think it's not possible to tell std::vector to use an already-allocated block of memory for its internal array, and moreover the array is static, and should be considered const.
Is there some STL type similar to std::vector that can be used to wrap pre-allocated C-style arrays with a more friendly interface? It should support size query and iteration, similar to std::vector.
Thanks.
Have you thought about making your function take a pair of iterators instead of a container? You would have to make it a template function, so I can understand why that may not work as well as you would like, but it would let you pass in the array.
template<typename I>
int handler(I begin, I end);
handler(argv, &argv[argc]);
It's still not a perfect solution, but it would be a touch more generic and allow for you to use the preexisting array.
I'm not certain what you're asking, but If I was given this function prototype
int handler(int argc, const sometype *const *argv);
Here's make a C++ wrapper:
int handler(const std::vector<sometype*>& arg)
{return handler(arg.size(), &arg[0]);} //no copies
template<class const_iterator>
int handler(const_iterator begin, const_iterator end) //can pass any structure
{return handler(std::distance(begin, end), &*begin);} //no copies
Here's how I would implement this API in C++:
int handler(int argc, const sometype *const*argv) {
const std::vector<const sometype*> arg(argv, argv+argc); //this will copy the pointers
//stuff
}
Unfortunately, there's no way to get an existing array into a vector, but is copying a few pointers really slow enough to care about?
Proof of compilation: http://ideone.com/BkSVd
Well, I'm sure if you know about ::vector, you've looked into ::array?
http://www.cplusplus.com/reference/stl/array/
However, the main problem - overlaying objects onto existing memory - reminds me of simple packet sniffers: create the object structure, then overlay it by moving its reference over the known data. I'm not sure if you can do this in your problem, but that'd be the first avenue I'd consider.
Note: I don't know exactly how a std::array is laid out so obviously that would be difficult to implement :/
What type of data is going to be referenced by those pointer elements ?
Who is the owner of those pointer elements, I mean, are those elements just referenced by the collection / data structure, or is that collection in charge of allocating, deallocating those items ?
Are those items equal type or equal size ?
For example, array of characters of different size, or objects that may be different base class, but descend from a common ancestor.
All these topics maybe considered to decide which library, object oriented or not, and which data structure or collection to use.
Seems std and Boost should be first option to lookup first. But, sometimes, you may have to built your own collection.
Your library seems to require more like an indexable List concept than an Array, altought, sometimes are interchangable.
Cheers.
In our application we have an object that receives attributes at runtime. For example, to add a float to the object:
my_object->f("volume") = 1.0f;
Retrieving the volume works the same way:
cout << my_object->f("volume") << endl;
Internally, this is represented by a map of strings to their respective type. Each type has its own access methods and map. It looks like this:
map<string, float> my_floats;
map<string, int> my_ints;
map<string, void *> my_void_pointers;
Oh, the dreaded void *. Sometimes we need to add classes or functions to the object. Rather than have a separate map for every conceivable type, we settled on a void * map. The problem we're having is with cleanup. Currently, we keep around a list of each type of these "dangling" objects that the void * point to, and call a cleanup function on these separate lists when necessary.
I don't like having to use void * and all the extra attention it requires for proper cleanup. Is there some better way to store arbitrary types in an object at runtime, accessible via a string map, and still benefit from automatic cleanup via destructor?
You are spoiled for choice here - boost::any or simply storing everything as std::string both come immediately to mind.
This post seems to be a good answer to your question.
Storing a list of arbitrary objects in C++
Rather than storing a map to so many values, it would be better to use a boost::variant. After all, judging by your interface, it would not be legal for me to assign both an int and a float to the same string.
std::map<std::string, boost::variant<float, int, std::string, ...>>;
When does using pointers in any language require someone to use more than one, let's say a triple pointer. When does it make sense to use a triple pointer instead of just using a regular pointer?
For example:
char * * *ptr;
instead of
char *ptr;
each star should be read as "which pointed to by a pointer" so
char *foo;
is "char which pointed to by a pointer foo". However
char *** foo;
is "char which pointed to by a pointer which is pointed to a pointer which is pointed to a pointer foo". Thus foo is a pointer. At that address is a second pointer. At the address pointed to by that is a third pointer. Dereferencing the third pointer results in a char. If that's all there is to it, its hard to make much of a case for that.
Its still possible to get some useful work done, though. Imagine we're writing a substitute for bash, or some other process control program. We want to manage our processes' invocations in an object oriented way...
struct invocation {
char* command; // command to invoke the subprocess
char* path; // path to executable
char** env; // environment variables passed to the subprocess
...
}
But we want to do something fancy. We want to have a way to browse all of the different sets of environment variables as seen by each subprocess. to do that, we gather each set of env members from the invocation instances into an array env_list and pass it to the function that deals with that:
void browse_env(size_t envc, char*** env_list);
If you work with "objects" in C, you probably have this:
struct customer {
char *name;
char *address;
int id;
} typedef Customer;
If you want to create an object, you would do something like this:
Customer *customer = malloc(sizeof Customer);
// Initialise state.
We're using a pointer to a struct here because struct arguments are passed by value and we need to work with one object. (Also: Objective-C, an object-oriented wrapper language for C, uses internally but visibly pointers to structs.)
If I need to store multiple objects, I use an array:
Customer **customers = malloc(sizeof(Customer *) * 10);
int customerCount = 0;
Since an array variable in C points to the first item, I use a pointer… again. Now I have double pointers.
But now imagine I have a function which filters the array and returns a new one. But imagine it can't via the return mechanism because it must return an error code—my function accesses a database. I need to do it through a by-reference argument. This is my function's signature:
int filterRegisteredCustomers(Customer **unfilteredCustomers, Customer ***filteredCustomers, int unfilteredCount, int *filteredCount);
The function takes an array of customers and returns a reference to an array of customers (which are pointers to a struct). It also takes the number of customers and returns the number of filtered customers (again, by-reference argument).
I can call it this way:
Customer **result, int n = 0;
int errorCode = filterRegisteredCustomers(customers, &result, customerCount, &n);
I could go on imagining more situations… This one is without the typedef:
int fetchCustomerMatrix(struct customer ****outMatrix, int *rows, int *columns);
Obviously, I would be a horrible and/or sadistic developer to leave it that way. So, using:
typedef Customer *CustomerArray;
typedef CustomerArray *CustomerMatrix;
I can just do this:
int fetchCustomerMatrix(CustomerMatrix *outMatrix, int *rows, int *columns);
If your app is used in a hotel where you use a matrix per level, you'll probably need an array to a matrix:
int fetchHotel(struct customer *****hotel, int *rows, int *columns, int *levels);
Or just this:
typedef CustomerMatrix *Hotel;
int fetchHotel(Hotel *hotel, int *rows, int *columns, int *levels);
Don't get me even started on an array of hotels:
int fetchHotels(struct customer ******hotels, int *rows, int *columns, int *levels, int *hotels);
…arranged in a matrix (some kind of large hotel corporation?):
int fetchHotelMatrix(struct customer *******hotelMatrix, int *rows, int *columns, int *levels, int *hotelRows, int *hotelColumns);
What I'm trying to say is that you can imagine crazy applications for multiple indirections. Just make sure you use typedef if multi-pointers are a good idea and you decide to use them.
(Does this post count as an application for a SevenStarDeveloper?)
A pointer is simply a variable that holds a memory address.
So you use a pointer to a pointer, when you want to hold the address of a pointer variable.
If you want to return a pointer, and you are already using the return variable for something, you will pass in the address of a pointer. The function then dereferences this pointer so it can set the pointer value. I.e. the parameter of that function would be a pointer to a pointer.
Multiple levels of indirection are also used for multi dimensional arrays. If you want to return a 2 dimensional array, you would use a triple pointer. When using them for multi dimensional arrays though be careful to cast properly as you go through each level of indirection.
Here is an example of returning a pointer value via a parameter:
//Not a very useful example, but shows what I mean...
bool getOffsetBy3Pointer(const char *pInput, char **pOutput)
{
*pOutput = pInput + 3;
return true;
}
And you call this function like so:
const char *p = "hi you";
char *pYou;
bool bSuccess = getOffsetBy3Pointer(p, &pYou);
assert(!stricmp(pYou, "you"));
ImageMagicks's Wand has a function that is declared as
WandExport char* * * * * * DrawGetVectorGraphics ( const DrawingWand *)
I am not making this up.
N-dimensional dynamically-allocated arrays, where N > 3, require three or more levels of indirection in C.
A standard use of double pointers, eg: myStruct** ptrptr, is as a pointer to a pointer. Eg as a function parameter, this allows you to change the actual structure the caller is pointing to, instead of only being able to change the values within that structure.
Char *** foo can be interpreted as a pointer to a two-dimensional array of strings.
You use an extra level of indirection - or pointing - when necessary, not because it would be fun. You seldom see triple pointers; I don't think I've ever seen a quadruple pointer (and my mind would boggle if I did).
State tables can be represented by a 2D array of an appropriate data type (pointers to a structure, for example). When I wrote some almost generic code to do state tables, I remember having one function that took a triple pointer - which represented a 2D array of pointers to structures. Ouch!
int main( int argc, char** argv );
Functions that encapsulate creation of resources often use double pointers. That is, you pass in the address of a pointer to a resource. The function can then create the resource in question, and set the pointer to point to it. This is only possible if it has the address of the pointer in question, so it must be a double pointer.
If you have to modify a pointer inside a function you must pass a reference to it.
It makes sense to use a pointer to a pointer whenever the pointer actually points towards a pointer (this chain is unlimited, hence "triple pointers" etc are possible).
The reason for creating such code is because you want the compiler/interpreter to be able to properly check the types you are using (prevent mystery bugs).
You dont have to use such types - you can always simply use a simple "void *" and typecast whenever you need to actually dereference the pointer and access the data that the pointer is directing towards. But that is usually bad practice and prone to errors - certainly there are cases where using void * is actually good and making code much more elegant. Think of it more like your last resort.
=> Its mostly for helping the compiler to make sure things are used the way they are supposed to be used.
To be honest, I've rarely seen a triple-pointer.
I glanced on google code search, and there are some examples, but not very illuminating. (see links at end - SO doesn't like 'em)
As others have mentioned, double pointers you'll see from time to time. Plain single pointers are useful because they point to some allocated resource. Double pointers are useful because you can pass them to a function and have the function fill in the "plain" pointer for you.
It sounds like maybe you need some explanation about what pointers are and how they work?
You need to understand that first, if you don't already.
But that's a separate question (:
http://www.google.com/codesearch/p?hl=en#e_ObwTAVPyo/security/nss/lib/ckfw/capi/ckcapi.h&q=***%20lang:c&l=301
http://www.google.com/codesearch/p?hl=en#eVvq2YWVpsY/openssl-0.9.8e/crypto/ec/ec_mult.c&q=***%20lang:c&l=344
Pointers to pointers are rarely used in C++. They primarily have two uses.
The first use is to pass an array. char**, for instance, is a pointer to pointer to char, which is often used to pass an array of strings. Pointers to arrays don't work for good reasons, but that's a different topic (see the comp.lang.c FAQ if you want to know more). In some rare cases, you may see a third * used for an array of arrays, but it's commonly more effective to store everything in one contiguous array and index it manually (e.g. array[x+y*width] rather than array[x][y]). In C++, however, this is far less common because of container classes.
The second use is to pass by reference. An int* parameter allows the function to modify the integer pointed to by the calling function, and is commonly used to provide multiple return values. This pattern of passing parameters by reference to allow multiple returns is still present in C++, but, like other uses of pass-by-reference, is generally superseded by the introduction of actual references. The other reason for pass-by-reference - avoiding copying of complex constructs - is also possible with the C++ reference.
C++ has a third factor which reduces the use of multiple pointers: it has string. A reference to string might take the type char** in C, so that the function can change the address of the string variable it's passed, but in C++, we usually see string& instead.
When you use nested dynamically allocated (or pointer linked) data structures. These things are all linked by pointers.
Particularly in single-threaded dialects of C which don't aggressively use type-based aliasing analysis, it can sometimes be useful to write memory managers which can accommodate relocatable objects. Instead of giving applications direct pointers to chunks of memory, the application receives pointers into a table of handle descriptors, each of which contains a pointer to an actual chunk of memory along with a word indicating its size. If one needs to allocate space for a struct woozle, one could say:
struct woozle **my_woozle = newHandle(sizeof struct woozle);
and then access (somewhat awkwardly in C syntax--the syntax is cleaner in
Pascal): (*my_woozle)->someField=23; it's important that applications not
keep direct pointers to any handle's target across calls to functions which
allocate memory, but if there only exists a single pointer to every block
identified by a handle the memory manager will be able to move things around
in case fragmentation would become a problem.
The approach doesn't work nearly as well in dialects of C which aggressively
pursue type-based aliasing, since the pointer returned by NewHandle doesn't
identify a pointer of type struct woozle* but instead identifies a pointer
of type void*, and even on platforms where those pointer types would have
the same representation the Standard doesn't require that implementations
interpret a pointer cast as an indication that it should expect that aliasing
might occur.
Double indirection simplifies many tree-balancing algorithms, where usually one wants to be able to efficiently "unlink" a subtree from its parent. For instance, an AVL tree implementation might use:
void rotateLeft(struct tree **tree) {
struct tree *t = *tree,
*r = t->right,
*rl = r->left;
*tree = r;
r->left = t;
t->right = rl;
}
Without the "double pointer", we would have to do something more complicated, like explicitly keeping track of a node's parent and whether it's a left or right branch.