Since std::list and std::vector exist, is there a reason to use traditional C arrays in C++, or should they be avoided, just like malloc?
In C++11 where std::array is available, the answer is "yes, arrays should be avoided". Prior to C++11, you may need to use C arrays to allocate arrays in the automatic storage (i.e. on the stack).
Definitely, although with std::array in C++11, practically only for
static data. C style arrays have three important advantages over
std::vector:
They don't require dynamic allocation. For this reason, C style
arrays are to be preferred where you're likely to have a lot of very
small arrays. Say something like an n-dimension point:
template <typename T, int dims>
class Point
{
T myData[dims];
// ...
};
Typically, one might imagine a that dims will be very small (2 or 3),
T a built-in type (double), and that you might end up with
std::vector<Point> with millions of elements. You definitely don't
want millions of dynamic allocations of 3 double.
The support static initialization. This is only an issue for static
data, where something like:
struct Data { int i; char const* s; };
Data const ourData[] =
{
{ 1, "one" },
{ 2, "two" },
// ...
};
This is often preferable to using a vector (and std::string), since it
avoids all order of initialization issues; the data is pre-loaded,
before any actual code can be executed.
Finally, related to the above, the compiler can calculate the actual
size of the array from the initializers. You don't have to count them.
If you have access to C++11, std::array solves the first two issues,
and should definitely be used in preference to C style arrays in the
first case. It doesn't address the third, however, and having the
compiler dimension the array according to the number of initializers is
still a valid reason to prefer C style arrays.
Never say "never", but I'd agree that their role is greatly diminished by true data structures from STL.
I'd also say that encapsulation inside objects should minimize the impact of choices like this. If the array is a private data member, you can swap it in or out without affecting clients of your class.
I have worked on safety critical systems where you are unable to use dynamic memory allocation. The memory has to always be on the stack. Therefore in this case you would use arrays as the size is fixed at compile time.
array in c++ gives you fixed size fast alternative of dynamic sized std::vector and std::list. std::array is one of the additions in c++11. It provides the benefit of std containers while still providing the aggregate type semantics of C-style arrays.
So in c++11 i'd certainly use std::array, where it is required, over vector. But i'd avoid C style array in C++03.
Most usually, no, I can't think of a reason to use raw arrays over, say, vectors. If the code is new.
You might have to resort to using arrays if your libraries need to be compatible with code that expects arrays and raw pointers.
I know a lot of people are pointing out std::array for allocating arrays on the stack, and std::vector for the heap. But neither seem to support non-native alignment. If you're doing any kind of numeric code that you want use SSE or VPX instructions on (thus requiring 128 or 256 byte alignment respectively), C arrays would still seem to be your best bet.
I would say arrays are still useful, if you are storing a small static amount of data why not.
The only advantage of an array (of course wrapped in something that will manage automatically its deallocation when need) over std::vector I can think about is that vector cannot pass ownership of its data, unless your compiler supports C++11 and move constructors.
C style arrays are a fundamental data structure, so there will be cases when it is better to use it. For the general case, however, use the more advanced data structures that round off the corners of the underlying data. C++ allows you to do some very interesting and useful things with memory, many of which work with simple arrays.
You should use STL containers internally, but you should not pass pointers to such containers between different modules, or you will end up in dependency hell. Example:
std::string foo;
// fill foo with stuff
myExternalOutputProc(foo.c_str());
is a very good solution but not
std::string foo;
// fill foo with stuff
myExternalOutputProc(&foo);
The reason is that std::string can be implemented in many different ways but a c-style string is always a c-style string.
Related
I am trying to connect two existing codebases — one in C, the other in C++. The C++ code uses std::vector whereas the other one is based on arrays of double. I would like to pass arrays of double from the C code, perform operations on std::vectors in the C++ code, and eventually have these operations reflected in the arrays of double.
Is it possible to create a std::vector that matches the memory occupied by the array of double?
I have tried several options, but they all involve the creation of a new vector and a copy of the array of double into that vector. For instance:
void fcn(double* a, int sizeofa)
{
std::vector<double> vect_a;
vect_a.assign(a, a + sizeofa);
// operations on vect_a
for (int i=0;i<sizeofa;i++) { a[i] = vect_a[i]; }
}
As noted in the comments, std::vector manages its own memory, you can't make it use some other memory as the backing store (it would have no idea what to do if the size changed, among other issues).
But you may not need a vector at all; if you're just using vector for non-dynamic size related features, it's highly likely you could just use the functions from <algorithm> to perform the same work directly on the array that you wanted to use vector's methods to accomplish.
In C++, functions requiring a container often denote the container by Iterator pairs, which are templated. This is very convenient, especially when interfacing with external libraries, because an iterator isn't a type. It is a concept, which is just an interface that defines what a type should look like. Turns out, C style pointers are valid iterators. This means that you can use any C++ function that accepts an iterator with any C array.
So, now to answering your question. In other answers, it was made clear that you cannot make a std::vector control the memory allocated by a C array because a std::vector requires full ownership over the data because it wouldn't know how to deallocate it. You can copy the C array into a vector, but there is no point in using a std::vector unless you want it's resizing capabilities.
In summary: try not to pass std::vectors into functions because iterators are more generic. If you must avoid templates (virtual function, etc) than use a C style array because those are very flexible too, you can turn a std::vector into a C array, but the other way requires a copy.
I know this is hard if you have already made your code interface with std::vectors, in which case a copy is the only possible way. Prefer C style arrays when you don't need to resize the array, and maybe in the future std::array_view
I was told that in C++, one should always use std::array over c-style array.
After viewing around questions I come across people saying that std::array is better.
In that sense, I used a lot of std::array and sometimes when I use other libraries, I have to use methods that takes in c-style arrays.
For example, I am working with this function
void Draw(float* arg);
Is it possible to pass in std::array<float,4> as a parameter?
Will there be any undefined behavior if I were to pass in &vec4[0] as the parameter?
In that sense, will it be the same for multi-dimensional arrays?
With this array declared as
std::array<std::array<float,4>,4>;
Will there also be any undefined behavior if I were to pass in &mtx4[0][0] as the parameter?
Edit: Thanks for pointing out my error in the code for the multidimensional array. I edited it.
Is it possible to pass in std::array as a parameter?
Yes. The correct syntax is:
Draw(my_array.data());
Will there be any undefined behavior if I were to pass in &vec4[0] as the parameter?
No. Syntactically it is less good at making your intentions clear, but semantically it is the same.
In that sense, will it be the same for multi-dimensional arrays?
Yes, if you mean classic C multi-dimensional arrays, which are really just flat arrays associated with indexing information. No, if you mean C array-of-array.
float array2d[5][5]; // ok
float *array2d[5]; // not ok
std::array<std::array<float,5>,5> array2d; // not ok
The first has contiguous storage. The other two are arrays of pointer-to-array and have to be handled differently. There is not enough here to recommend how.
I found a reference here to another/new syntax for multi-dimensional arrays. It should provide contiguous storage.
std::array<float,5,5>; // should be ok
I really have no idea what the status of this syntax is. Perhaps others can assist.
After some further investigation of this declaration:
std::array<std::array<float,5>,5> array2d;
The storage for array2d here is all in-line, with no pointers involved. In all the cases I was able to investigate the storage appears to be contiguous, so that the memory layout is the same as for
float array2d[5][5];
This is not a requirement of the standard. A conforming implementation could insert additional information or padding such that sizeof(array<T>) is larger than sizeof(T[]) for some T. If it did then the storage layout for these two would not be the same.
Is there a way to use RAII when creating an array in C++, or do I have to resort to manual memory management via the "new" keyword?
EDIT: By request, some additional details:
First my disclaimer: I'm fairly novice at C++.
Now the details: I simply wanted to iterate through an existing array, SomeClass source[], and parse each element into a storage array, string results[].
So to create that storage string results[], do I need to say string results[] = new string[source.size()] or is there a way to avoid the "new" keyword here via RAII techniques?
It sounds like I'm hearing vector is the way to go. Still, wondered if it's possible with a plain old array.
In C++, especially since we're talking about RAII, we really shouldn't be using C-style arrays at all. The Standard Library provides many containers with different properties that obviate most needs for C-style arrays. By default, you should be using std::vector<> unless you have an understanding of the other containers and a compelling reason not to 1.
Judging from your comments, it looks like what you're trying to do is build an array of string data. This is simple in modern C++ -- just use a std::vector <std::string>.
int main()
{
std::vector <std::string> myStrings;
myStrings.push_back ("hello");
myStrings.push_back ("goodbye");
}
This achieves all your mentioned goals of being RAII and no need to new or delete anything. It also integrates very nicely with other Standard Library facilities, such as find.
I did say "obviate most needs," emphasis mine. There is still occasional need to go old-school. I won't discuss them here since if you actually need it you already know. Which is to say, if you don't know you probably don't need it.
All that being said, std::unique_ptr does support managing C-style arrays with special syntax:
std::unique_ptr <unsigned []> myArray (new unsigned [256]);
the array managed by myArray above will be properly deleted with delete [] at destruction time.
Since there is no unique_ptr analogue to shared_ptr's make_shared, you will either have to use new to actually construct the array, or provide your own (or someone else's) implementation of make_unique
Sidebar: make_unique will be added to C++14.
1 " you should be using std::vector<> unless you have an understanding of the other containers and a compelling reason not to"
This isn't just my opinion. It's also the general (unofficial) opinion of StackOverflow as a whole, C++'s creator Bjarne Stroustup, and the C++ Standard itself (23.1.1).
std::vector<T> is an RAII array type. From the additional information you've given std::vector<string> is appropriate for your use.
string results[] = new string[source.size()]
Just as an aside about arrays, this syntax isn't correct for C++. People teaching C and C++ often teach that arrays and pointers are the same thing, but this is not true and the syntax above shows one of the ways they differ.
The actual relationship between arrays and pointers is
Arrays and pointers are distinct types
In many contexts an implicit conversion from an array to pointer is applied. The conversion results in the address of the array's first element.
pointer arithmetic is defined such that if a pointer points to an element in an array then you can get pointers to other elements of the array by adding and subtracting to the pointer value.
In a some contexts writing an array type will result in a pointer type. In particular, function parameters declared to be of array types are adjusted to be of pointer type. E.g. void foo(int[10]); is effectively identical to void foo(int*);.
So the code you show is declaring an array and initializing it with a pointer. This will result in an error because there's no conversion from pointers to arrays.
Generally you should avoid raw arrays in C++; Arrays just have too many weird rules, such as the weird function parameter rule described above, the rules about when exactly the implicit conversion is performed, prohibitions on assignment and returning arrays from functions, etc. When starting out it's probably best to just stick with the std::array template for arrays with a size known at compile time and the std::vector template for arrays with a size not known at compile time.
You can use std::vector<string> and push_back() each result string in to the vector. You don't have to use new unless you want to avoid vectors and manage memory by yourself
I think a simple template would do the trick in the general case:
template<class T>
class HeapArray {
T* ptr = nullptr;
public:
HeapArray(int size) { ptr = new T[size]; }
~HeapArray() { delete [] ptr; }
operator T*() { return ptr; }
};
You use it as:
HeapArray<std::string> results(source.size());
results[i] = "how cool is this";
basically the HeapArray object is automatically cast'd to its member pointer.
I'm pretty new to C++, so I apologize if the answer to this is obvious.
I've been writing an STL-style custom data structure as a way to improve my skills. (I actually do have a practical need for this structure as well, but I'm going a little overboard for study purposes.)
This structure needs to dynamically resize (like a vector), and in my first draft, I made the underlying "container" a C-style array and did all the allocations and de-allocations manually. I'm refactoring, and I'd like to use a C++11-style std::array as my underlying structure, just to make the code a little cleaner. My problem is that I don't know how to declare the array class member in a way that allows for resizing. Since different template parameters entail a different type, I can't just declare a member as array and then assign the same variable to an array upon resize.
I thought about declaring a member for each potential size, like
private:
array<T, 8>
array<T, 16>
array<T, 32>
...
but I don't want each of those arrays default constructing T members.
Is there a clean solution here? Or do I just have to stick with C-style arrays?
Thanks for the help.
EDIT:
After re-reading my question, I don't think it makes sense, actually. I understood that std::array's size had to be known at compile time, but for some reason my brain to infer that my goal was impossible. It seems obvious to me now that I'm stuck with C-style arrays and the heap. I think I just needed to write it out to get perfectly clear.
Thanks for your answers.
std::array represents an array whose size is known statically (i.e. at compile time), so it cannot be used in cases such as this where the size will be only known at runtime.
Simply use std::vector instead, it has a constructor that takes the size as its argument.
std::array is specifically designed not to be resizable. It's mainly a workaround for the fact that fixed-size arrays aren't first-class value types.
The only use case that I can think of is some sort of externalized or serialized object (stored on disk or delivered over socket, or something along those lines), where there is a dynamically sized component. If you already have a format defined for that, then you should probably stick with what you have. Trying to reuse std::array<> for this will not work if the sizes are not known at compile time.
If you want to refactor, what might be useful would be a template class that can take a C array as a constructor argument, but provide an STL container interface to it.
I've got a lightweight templated class that contains a couple of member objects that are very rarely used, and so I'd like to avoid calling their constructors and destructors except in the rare cases when I actually use them.
To do that, I "declare" them in my class like this:
template <class K, class V> class MyClass
{
public:
MyClass() : wereConstructorsCalled(false) {/* empty */}
~MyClass() {if (wereConstructorsCalled) MyCallPlacementDestructorsFunc();}
[...]
private:
bool wereConstructorsCalled;
mutable char keyBuf[sizeof(K)];
mutable char valBuf[sizeof(V)];
};
... and then I use placement new and placement delete to set up and tear down the objects only when I actually need to do so.
Reading the C++ FAQ it said that when using placement new, I need to be careful that the placement is properly aligned, or I would run into trouble.
My question is, will the keyBuf and valBuf arrays be properly aligned in all cases, or is there some extra step I need to take to make sure they will be aligned properly? (if so, a non-platform-dependent step would be preferable)
There's no guarantee that you'll get the appropriate alignment. Arrays are in general only guaranteed to be aligned for the member type. A char array is aligned for storage of char.
The one exception is that char and unsigned char arrays allocated with new are given maximum alignment, so that you can store arbitrary types into them. But this guarantee doesn't apply in your case as you're avoiding heap allocation.
TR1 and C++0x add some very helpful types though:
std::alignment_of and std::aligned_storage together give you a portable (and functioning) answer.
std::alignment_of<T>::value gives you the alignment required for a type T. std::aligned_storage<A, S>::type gives you a POD type with alignment A and size S. That means that you can safely write your object into a variable of type std::aligned_storage<A, S>::type.
(In TR1, the namespace is std::tr1, rather than just std)
May I ask why you want to place them into a char buffer? Why not just create pointer objects of K and V then instantiate it when you need it.
Maybe I didn't understand your question, but can't you just do char *keyBuf[..size..];, set it initially to NULL (not allocated) and allocate it the first time you need it?
What you're trying to do with placement new seems risky business and bad coding style.
Anyway, code alignment is implementation dependent.
If you want to change code alignment use pragma pack
#pragma pack(push,x)
// class code here
#pragma pack(pop) // to restore original pack value
if x is 1, there will be no padding between your elements.
Heres a link to read
http://www.cplusplus.com/forum/general/14659/
I found this answer posted by SiCrane at http://www.gamedev.net/community/forums/topic.asp?topic_id=455233 :
However, for static allocations, it's less wasteful to declare the memory block in a union with other types. Then the memory block will be guaranteed to be aligned to the alignment of the most restrictive type in the union. It's still pretty ugly either way.
Sounds like a union might do the trick!
I recommend that you look at the boost::optional template. It does what you need, even if you can't use it you should probably look at its implementation.
It uses alignment_of and type_with_alignment for its alignment calculations and guarantees.
To make a very very long story very very short this isn't going to help your performance any and will cause lots of headaches and it won't be long before you get sucked into writing your own memory managemer.
Placement new is fine for a POD (but won't save you anything) but if you have a constructor at all then it's not going to work at all.
You also can't depend on the value of your boolean variable if you use placement new.
Placement new has uses but not really for this.