I know that when I do this
int x;
cin >> x;
char arr [x];
it is ill fomed according to c++ standard since c++ does not allow static arrays of variable size.
My question is, if I declare static array in function scope with variable size from function parameter is it still ill formed? Or is it well defined in the standard?
void foo(int size)
{
char arr [size];
// do something
}
void main()
{
foo(10);
foo(20);
}
For starters you have no "static arrays". The arrays used in your examples have automatic storage duration. And C where variable length arrays are allowed requires that such arrays had automatic storage duration.
Variable length arrays are not a standard feature of C++.
Instead use the standard container std::vector. Or if you are using strings then use the standard class std::string.
For example
#include <iostream>
#include <string>
void foo(int size)
{
std::string s;
s.resize( size );
}
int main()
{
foo(10);
foo(20);
}
This is not a valid C++ code:
char arr [size];
It may work on some compilers which has support of variable size array of C as an extension.
The array also is not static it is automatic in your case if size was constant known at compile time.
It is not valid anywhere neither function scope nor anywhere else.
You can use std containers such as vector which has support for variable size or even std::string.
When foo is called, a new stack frame is pushed on the stack which reserves just enough space for all the local variables in the scope of foo to fit. If another function bar were to be called from within foo, its stack frame would be pushed on top of foo's. For this to work (efficiently), the size of the stack frame (by extension all local variables in foo, including the array arr) must be known to the compiler.
When the functions return (first bar, then foo) their stack frames are popped in reverse order of their creation, and thus the stack memory remains defragmented at all times and the location of each and every local variable is determined at compile time, hence the relative efficiency. Heap memory can have a dynamic size but this comes at the cost of having to allocate a suitably sized spot on the heap.
You can also see this dichotomy in the standard library containers std::vector and std::array. std::array is effectively just a wrapper around C-style arrays and thus its size needs to be known at compile time and is therefore specified as a template parameter, e.g. std::array<char, 42> wraps char[42]. Unlike in your case, the compiler will (rightly) complain if you use a runtime variable as the second template parameter. You can however safely use any constant expression (e.g. result of a constexpr function).
Related
Why can't we initialize array size using non-const size in global area....outside main() ....
//outside main - global
int val=5;
int arr[val];
int main()
{
}
this gives error
7:12: error: array bound is not an integer constant before ']' token
In function 'int main()':
But if i move this same code inside main/body of function error disappears....
there is no error and it compiles fine...
int main()
{
int val=5;
int arr[val];
}
Also this works fine inside body of a function
void fn(int val)
{
int arr[val];
}
int main()
{
fn(5);
}
Confused and how does moving array size can't be intialized only outside main?
The first sample, at file scope
int val=5;
int arr[val];
int main()
is illegal on both C and C++. Variables at file scope must be defined (created) before their first use, and continue to exist until the program ends - which also means that, once created, an array cannot be resized. In the case of arrays, this means (among other things) that their dimension must be known at compile time. Using a variable as an array dimension runs afoul of the need for the size of a static to be known at compile time - for example, the value of val could be changed at run time (e.g. in main()) which will be AFTER arr is created.
The second example
void fn(int val)
{
int arr[val];
}
is legal in C (from 1999), because arr is of automatic (not static) storage duration. It will be created when the function body is entered, and cease to exist when the function returns. This is called a "variable length array" or VLA, because the number of elements is determined by a value of a variable (val) at run time.
VLAs were also not supported before the 1999 C standard.
In C++, VLAs are illegal. Period. However, some C++ compilers do support such a feature as a non-standard extension. In C++, rather than using arrays, a standard container (e.g. std::vector<int>) is preferred for various reasons, including ability to resize it at run time.
For the array inside function:
you are relying on GCC extension, if you add -pedantic you will get this warning:
warning: ISO C++ forbids variable length array 'arr' [-Wvla]
So C++ does not support variable length arrays, suggested alternative is std::vector.
For the array outside function:
you need to add const before int. Yes I know compiler could in theory figure out that val is never changed, but for some reason(nobody thought to add that to standard, or there are good reasons not to do it) you are required to add const.
I'm reading Stroustrup's A Tour of C++. On page 9, he states:
"The size of an array must be a constant expression."
Yet later, on pg. 16, he uses the following code sample:
void vector vector_init(Vector& v, int s)
{
v.elem = new double[s]; // Allocate an array of s doubles
v.sz = s;
}
Here s is not a constant expression, so how is initializing v.elem to new double[s] legal?
There is a differentiation between allocated arrays (i.e. those created with a new[] expression, like new double[s]), whose lifetimes must be managed by the code (via delete[]) and declared arrays, whose lifetimes are managed by their scope alone:
int* p = new int[s]; // allocated array, p has type int*
int q[10]; // declared array, q has type int[10]
std::vector<int> u; // has member allocated array
std::array<int, 5> v; // has member declared array
The differentiation is not based on stack/heap. A declared array can be heap allocated (e.g. new array<int,5>) or not on the stack (e.g. static double x[100];)
With an allocated array, the size does not have to be a constant expression. The size will simply be encoded into the block of memory yielded by the allocator somehow (for instance the four leading bytes before the actual data starts) so that the corresponding delete[] knows how many elements to delete.
With a declared array (or non-allocated array, no new/malloc/etc.), the size must† be coded into the type, so that the destructor knows what to do. The only allowed, standard array declaration is:
T D[constant-expression_opt];
(where D is a declarator that could be a name or another array declaration, etc.) Declared arrays are not limited to the stack. Note that, for added confusion, the constant-expression is optional.
Arrays offer many sources of confusion in C++. Allocated and declared arrays have different size rules, different management practices, but you can assign a T* to either and they're equivalently indexed. An allocated array is a pointer (that's all you get), but a declared array decays to a pointer (but is an array!).
†Note that there is a concept of a Variable Length Array (VLA). gcc, for instance, supports them as an extension, but they are non-standard C++. It gets periodically proposed though, and you can see this question for more information about them.
When creating an array whose memory is managed by compiler, its size must be (compile time) constant. For ex:
int a[5];
const int sz = 7;
int b[sz] = {0};
(Some languages for ex: C (C99 onwards) support dynamic array size)
If you want a dynamically sized array (Example snippet given by you), you need to allocate memory for it by yourself you'll also need to free it with delete when you're done. Size of such arrays can be non-const also. Moreover you need to manage the memory by yourself, allocation may fail and operators (for example sizeof) would operate on the pointer rather than array.
In modern C++ (C++11 onwards), even stl container std::array must have a constant size.
The quote
The size of an array must be a constant expression.
is talking about an array declaration, such as
double a[EXPR];
where EXPR must indeed be a constant or constexpr (C has variable-length arrays, but they're not part of standard C++).
The expression you mention as a counter-example,
new double[s]
is not an array, despite the []. It is a new-expression, and yields a pointer, not an array. You didn't show the definition of v.elem, but I can tell it's a pointer-to-double.
Note from the linked discussion on new expressions that
If type is an array type, all dimensions other than the first must be specified as positive {something like an integral constant - detail elided}.
So the type referred to above is double[s], which is explicitly allowed.
Admittedly the difference between an array, and the array type passed to a new expression is a little subtle, but you can't conflate them just because of the [], any more than you can claim that
map["key"]
violates something by declaring an array with length "key".
This is what I found during my learning period:
#include<iostream>
using namespace std;
int dis(char a[1])
{
int length = strlen(a);
char c = a[2];
return length;
}
int main()
{
char b[4] = "abc";
int c = dis(b);
cout << c;
return 0;
}
So in the variable int dis(char a[1]) , the [1] seems to do nothing and doesn't work at
all, because I can use a[2]. Just like int a[] or char *a. I know the array name is a pointer and how to convey an array, so my puzzle is not about this part.
What I want to know is why compilers allow this behavior (int a[1]). Or does it have other meanings that I don't know about?
It is a quirk of the syntax for passing arrays to functions.
Actually it is not possible to pass an array in C. If you write syntax that looks like it should pass the array, what actually happens is that a pointer to the first element of the array is passed instead.
Since the pointer does not include any length information, the contents of your [] in the function formal parameter list are actually ignored.
The decision to allow this syntax was made in the 1970s and has caused much confusion ever since...
The length of the first dimension is ignored, but the length of additional dimensions are necessary to allow the compiler to compute offsets correctly. In the following example, the foo function is passed a pointer to a two-dimensional array.
#include <stdio.h>
void foo(int args[10][20])
{
printf("%zd\n", sizeof(args[0]));
}
int main(int argc, char **argv)
{
int a[2][20];
foo(a);
return 0;
}
The size of the first dimension [10] is ignored; the compiler will not prevent you from indexing off the end (notice that the formal wants 10 elements, but the actual provides only 2). However, the size of the second dimension [20] is used to determine the stride of each row, and here, the formal must match the actual. Again, the compiler will not prevent you from indexing off the end of the second dimension either.
The byte offset from the base of the array to an element args[row][col] is determined by:
sizeof(int)*(col + 20*row)
Note that if col >= 20, then you will actually index into a subsequent row (or off the end of the entire array).
sizeof(args[0]), returns 80 on my machine where sizeof(int) == 4. However, if I attempt to take sizeof(args), I get the following compiler warning:
foo.c:5:27: warning: sizeof on array function parameter will return size of 'int (*)[20]' instead of 'int [10][20]' [-Wsizeof-array-argument]
printf("%zd\n", sizeof(args));
^
foo.c:3:14: note: declared here
void foo(int args[10][20])
^
1 warning generated.
Here, the compiler is warning that it is only going to give the size of the pointer into which the array has decayed instead of the size of the array itself.
The problem and how to overcome it in C++
The problem has been explained extensively by pat and Matt. The compiler is basically ignoring the first dimension of the array's size effectively ignoring the size of the passed argument.
In C++, on the other hand, you can easily overcome this limitation in two ways:
using references
using std::array (since C++11)
References
If your function is only trying to read or modify an existing array (not copying it) you can easily use references.
For example, let's assume you want to have a function that resets an array of ten ints setting every element to 0. You can easily do that by using the following function signature:
void reset(int (&array)[10]) { ... }
Not only this will work just fine, but it will also enforce the dimension of the array.
You can also make use of templates to make the above code generic:
template<class Type, std::size_t N>
void reset(Type (&array)[N]) { ... }
And finally you can take advantage of const correctness. Let's consider a function that prints an array of 10 elements:
void show(const int (&array)[10]) { ... }
By applying the const qualifier we are preventing possible modifications.
The standard library class for arrays
If you consider the above syntax both ugly and unnecessary, as I do, we can throw it in the can and use std::array instead (since C++11).
Here's the refactored code:
void reset(std::array<int, 10>& array) { ... }
void show(std::array<int, 10> const& array) { ... }
Isn't it wonderful? Not to mention that the generic code trick I've taught you earlier, still works:
template<class Type, std::size_t N>
void reset(std::array<Type, N>& array) { ... }
template<class Type, std::size_t N>
void show(const std::array<Type, N>& array) { ... }
Not only that, but you get copy and move semantic for free. :)
void copy(std::array<Type, N> array) {
// a copy of the original passed array
// is made and can be dealt with indipendently
// from the original
}
So, what are you waiting for? Go use std::array.
It's a fun feature of C that allows you to effectively shoot yourself in the foot if you're so inclined. I think the reason is that C is just a step above assembly language. Size checking and similar safety features have been removed to allow for peak performance, which isn't a bad thing if the programmer is being very diligent. Also, assigning a size to the function argument has the advantage that when the function is used by another programmer, there's a chance they'll notice a size restriction. Just using a pointer doesn't convey that information to the next programmer.
First, C never checks array bounds. Doesn't matter if they are local, global, static, parameters, whatever. Checking array bounds means more processing, and C is supposed to be very efficient, so array bounds checking is done by the programmer when needed.
Second, there is a trick that makes it possible to pass-by-value an array to a function. It is also possible to return-by-value an array from a function. You just need to create a new data type using struct. For example:
typedef struct {
int a[10];
} myarray_t;
myarray_t my_function(myarray_t foo) {
myarray_t bar;
...
return bar;
}
You have to access the elements like this: foo.a[1]. The extra ".a" might look weird, but this trick adds great functionality to the C language.
To tell the compiler that myArray points to an array of at least 10 ints:
void bar(int myArray[static 10])
A good compiler should give you a warning if you access myArray [10]. Without the "static" keyword, the 10 would mean nothing at all.
This is a well-known "feature" of C, passed over to C++ because C++ is supposed to correctly compile C code.
Problem arises from several aspects:
An array name is supposed to be completely equivalent to a pointer.
C is supposed to be fast, originally developerd to be a kind of "high-level Assembler" (especially designed to write the first "portable Operating System": Unix), so it is not supposed to insert "hidden" code; runtime range checking is thus "forbidden".
Machine code generrated to access a static array or a dynamic one (either in the stack or allocated) is actually different.
Since the called function cannot know the "kind" of array passed as argument everything is supposed to be a pointer and treated as such.
You could say arrays are not really supported in C (this is not really true, as I was saying before, but it is a good approximation); an array is really treated as a pointer to a block of data and accessed using pointer arithmetic.
Since C does NOT have any form of RTTI You have to declare the size of the array element in the function prototype (to support pointer arithmetic). This is even "more true" for multidimensional arrays.
Anyway all above is not really true anymore :p
Most modern C/C++ compilers do support bounds checking, but standards require it to be off by default (for backward compatibility). Reasonably recent versions of gcc, for example, do compile-time range checking with "-O3 -Wall -Wextra" and full run-time bounds checking with "-fbounds-checking".
C will not only transform a parameter of type int[5] into *int; given the declaration typedef int intArray5[5];, it will transform a parameter of type intArray5 to *int as well. There are some situations where this behavior, although odd, is useful (especially with things like the va_list defined in stdargs.h, which some implementations define as an array). It would be illogical to allow as a parameter a type defined as int[5] (ignoring the dimension) but not allow int[5] to be specified directly.
I find C's handling of parameters of array type to be absurd, but it's a consequence of efforts to take an ad-hoc language, large parts of which weren't particularly well-defined or thought-out, and try to come up with behavioral specifications that are consistent with what existing implementations did for existing programs. Many of the quirks of C make sense when viewed in that light, particularly if one considers that when many of them were invented, large parts of the language we know today didn't exist yet. From what I understand, in the predecessor to C, called BCPL, compilers didn't really keep track of variable types very well. A declaration int arr[5]; was equivalent to int anonymousAllocation[5],*arr = anonymousAllocation;; once the allocation was set aside. the compiler neither knew nor cared whether arr was a pointer or an array. When accessed as either arr[x] or *arr, it would be regarded as a pointer regardless of how it was declared.
One thing that hasn't been answered yet is the actual question.
The answers already given explain that arrays cannot be passed by value to a function in either C or C++. They also explain that a parameter declared as int[] is treated as if it had type int *, and that a variable of type int[] can be passed to such a function.
But they don't explain why it has never been made an error to explicitly provide an array length.
void f(int *); // makes perfect sense
void f(int []); // sort of makes sense
void f(int [10]); // makes no sense
Why isn't the last of these an error?
A reason for that is that it causes problems with typedefs.
typedef int myarray[10];
void f(myarray array);
If it were an error to specify the array length in function parameters, you would not be able to use the myarray name in the function parameter. And since some implementations use array types for standard library types such as va_list, and all implementations are required to make jmp_buf an array type, it would be very problematic if there were no standard way of declaring function parameters using those names: without that ability, there could not be a portable implementation of functions such as vprintf.
It's allowed for compilers to be able to check whether the size of array passed is the same as what expected. Compilers may warn an issue if it's not the case.
I have a few array-related questions. I've studied that array-size must be constant on declaration/compiler must know its value. But using the GNU GCC compiler (C++11 standard filter) and I am able to perfectly compile and run a program using a variable as array size, when declaring said array dynamically (using new)
int num;
cout << "How big an array? ";
cin >> num;
int *arr = new int [num];
Ques1) Is this considered standard? My profs are contradictory.
Ques2) If it is standard, in that case, is it possible to extend the size of the array (or any array) after creation?
Ques3) Again, if this expression is standard, then is it possible to use it within a function - eg. using a function to create such an array? (if so, how?)
(PS: Hi, I'm new here and also still a novice in C++)
Ques1) Is this considered standard? My profs are contradictory.
Yes, this is completely valid. Note that you need to explicitly delete the memory pointed by arr using operator delete[]. It is much better to use a std::vector<int> which will perform the memory management for you.
You might be mistaken with variable length arrays(VLAs), which are not allowed in C++:
// same num as the one in your example
int arr[num]; // ERROR
This is valid in C but invalid in C++(C++14 will include VLAs, although they will have some differences with C VLAs).
Ques2) If it is standard, in that case, is it possible to extend the
size of the array (or any array) after creation?
No, you can't extend it. You can allocate a bigger array, copy the elements and delete the previous one. Again, this is done automatically if you're using std::vector<int>.
Ques3) Again, if this expression is standard, then is it possible to
use it within a function - eg. using a function to create such an
array? (if so, how?)
Yes, of course:
int *allocate(size_t size) {
return new int[size];
}
But again use std::vector:
int num;
cout << "How big an array? ";
cin >> num;
std::vector<int> arr(num); // num elements, all of them initialized to 0
// insert 42 at the end. reallocations(if any) are done automatically
arr.push_back(42);
I've studied that array-size must be constant on declaration/compiler must know its value.
Well, that's true, but only for static or automatic arrays. You are allocating a dynamic array on the heap, which is different.
Static array
An array declared at global scope must have a constant size.
int arr[5];
Automatic array
An array allocated automatically within a function must have constant size (with exception, see below).
void f() {
int arr[5];
}
Dynamic array
A dynamic array allocated on the heap with new can have any size, constant or variable.
new int[5];
new int[n * 4];
GCC extension
The exception is that GCC allows one to use a variable to declare the size of an automatic array:
void f(int n) {
int arr[n];
}
However, this usage is not standard.
Question 1 - operator 'new' is used to make dynamic allocation, I mean, when you don't know previously what is the size of the array, so, there is no problem, you can do it! I think your profs are confusing with C sintax, where new neither exists and is not allowed to make things like: int p[n]; for instance.
Question 2 - No, it is not possible increase the size of an array created using operator new. You have to alocate another array and copy the data. You can consider use vector in order to do it easily.
Question 3 - I don't see why to do it, but it is possible..
int* createarray(int size)
{
return new int[size];
}
int main()
{
int *p = createarray(10);
}
Q1:Is this considered standard?
Given the definition int n = 42, new float[n][5]
is well-formed (because n is the expression of a
noptr-new-declarator), but new float[5][n] is ill-formed (because n is
not a constant expression).
--5.3.4.6,N3242
If the allocated type is an array type, the allocation function’s
name is operator new[] and the deallocation function’s name is
operator delete[].
--5.3.4.8,N3242
new T[5] results in a call of operator new[](sizeof(T)*5+x)
Here, x and y are non-negative unspecified values representing array allocation overhead;
--5.3.4.12,N3242
Q2:If it is standard, in that case, is it possible to extend the size of the array (or any array) after creation?
Partially no, or not recommended.
when the allocation function returns a value other than null, it must be a pointer to a block of storage
in which space for the object has been reserved. Mostly allocation happened in heap, and there may not have more contiguous memory left which is important for array.
If you have to do this and have a memory poll, use placement new operator you can do this partially, but what you do now is what the designer of allocator do, and have risk ruin the inner memory storage.
Q3: using a function to create such an array? (if so, how?)
Entities created by a new-expression have dynamic storage duration
(3.7.4). [Note: the lifetime of such an entity is not necessarily
restricted to the scope in which it is created. — end note ]
--5.3.4.1,N3242
The rest of things are how to design such function to meet your need, even use template.
1 template<typename T>T* foo(std::size_t size){
2 return new T[size] ;
3 }
As a complement to other answers :
Vectors
(Agreed with vector for dynamic resize) :
std::vector<int> v;
v.push_back(1);
v.push_back(1);
v.resize(v.size()+10, 5); // Greater resized
v.resize(v.size()-1); // Lower resized
If the new size is greater than the old one, additional elements will be initialized to 5 (or 0 in case of int, if the second parameter is not used) and ancient elements remain unchanged.
If the new size is lower than the old one, it is truncated.
Arrays
Side note : (about stack and heap allocation)
The way an array is handled can lead to significantly different results (See this very interesting discussion):
// Create 500 bytes on the heap
char *pBuffer = new char[500]; // or malloc in C
// Create 500 bytes on the stack
char buffer[500];
I know that int* array = new int [n]; allocates memory space in heap.
But if I declare something like that: int array[n]; in codeblocks it compile successfully, but if I move it to visual studio, it comes out of error.
What I want to ask is:
What does int[n] really do and how does it compare to heap allocation? What is the difference between them?
What the error may come out if I use int array[n] instead of int* array = new int [n];?
int array[n] declares an array on the stack, not the heap. In standard C++ n must be a compile time constant, however some compilers have an extension that allows for variable length arrays declared in this form without a compile time constant n. It's not standard and probably shouldn't be used.
int array[n] can cause a couple problems over int* array = new int [n];:
If n is big enough you can cause a stack overflow. Or if the array is a class member and you create a large array of the class.
If array is a class member moving could be as expensive as copying
If array is a class member and you have given out pointers to the array and move the class, the pointers now refer to a post-moved object, or if random memory if the object was also destroyed. Either way, bad.
GCC has an extension in C++ that allows int array[n] where n is not a compile time constant value. The standard language doesn't allow you to use non-constant value for n in such a case (it is allowed in C99).
If I understand your questions correctly, then I can answer both.
int array[10] is allocated on the stack, whereas int *array = new int[10] is allocated on the heap. Usually, stack arrays only work with a constant number of elements, so int array[n] is not allowed in C90 (as long as n is not constant).
MinGW (which is the version of the GCC compiler that codeblocks uses on windows) has an extension which does allow you to write int array[n] in C90 mode, where n is not constant. Visual C++ does not allow this.
when you write int array[n], that means you are performing a static allocation. i.e. memory will be allocated at the compile time. So using a variable length here will result in a compile time error.