Sizing Array Value in variable

[hpy_awad]

I need to make the size of an array as variable read from screen . How can I do it ?

 

[Attila Feher]

I need to make the size of an array as variable read from screen .
How can I do it ?

First read in the size of the array from screen, into a variable with the
proper type (ptrdiff_t of stdlib.h), then create the array (with dynamic
allocation) using that number. Didn't your course instructor give you a
book to read or hints?

 

[John Harrison]

I need to make the size of an array as variable read from screen . How can

I do it ?

Use dynamic allocation. But don't use it before you've read a book on C++.
Something like this

int main()
{
int array_size;
cin >> array_size;

int* array = new int[array_size];

...

delete[] array;
}

 

[Tim Love]

I need to make the size of an array as variable read from screen . How can I do it ?

#include <vector>
#include <iostream>
using namespace std;
int main()
{
int i;
cin >> i;
vector<int> v(i);
cout << v.size() << endl;
}

 

[Ivan Vecerina]

I need to make the size of an array as variable read from screen . How
can

I do it ?

Use dynamic allocation. But don't use it before you've read a book on C++.
Something like this

int main()
{
int array_size;
cin >> array_size;

int* array = new int[array_size];

...

delete[] array;
}

I think that a much better idea would be to use std::vector:

#include <vector>
#include <iostream>

int main()
{
int array_size;
std::cin >> array_size;
std::vector array( array_size );

// sample usage:
for( int i = 0 ; i<array_size ; ++i )
std::cin >> array; // read elements 1 by 1

}

No explicit memory deallocation (ie. delete) is needed then.

Most authors advise against the use of heap-allocated arrays,
which in almost all cases can be replaced with std::vector.


Regards,
Ivan

 

[Karthik Kumar]

First read in the size of the array from screen, into a variable with the
proper type (ptrdiff_t of stdlib.h), then create the array (with dynamic

Would it be more appropriate to use size_t here ?



--
Karthik.
http://akktech.blogspot.com .
------------ And now a word from our sponsor ----------------------
For a quality mail server, try SurgeMail, easy to install,
fast, efficient and reliable. Run a million users on a standard
PC running NT or Unix without running out of power, use the best!
---- See http://netwinsite.com/sponsor/sponsor_surgemail.htm ----

 

[David Hilsee]

Would it be more appropriate to use size_t here ?

IMHO, yes, because an array is not supposed to have a size that is larger
than the maximum value of size_t. ptrdiff_t is supposed to be used for
expressing the difference between two pointers which point to elements in
the same array. However, the relationship between size_t and ptrdiff_t is a
little odd. When you think about it, it makes sense that ptrdiff_t should
be used instead of size_t, because (according to my understanding) any
value, including zero, subtracted from the maximum value of size_t must be
representable as a ptrdiff_t, or else the array size is unsupported from a
portability perspective. That would lead me to believe that ptrdiff_t
should be able to portably represent the maximum size of an array for most
applications. For more informed comments about this, I recommend reading
Francis Glassborow's comments about ptrdiff_t on comp.lang.c++.moderated and
other newsgroups. For the most part, I'm regurgitating his words, to the
best of my understanding, so I may have misstated something.

 

[Attila Feher]

Would it be more appropriate to use size_t here ?

In theory yes. In practice no. Reasons being:

- size_t is unsigned, prone to nasty, undetectable overflows

- there are platforms (many IIRC) where is it not possible to allocate more
memory than the maximum value of ptrdiff_t.

The reason being for the second is that most platforms use a signed type for
offsets, so it would be impossible to address anything beyond that.

Anyway, if you allocate maximum-of-ptrdiff_t bytes memory, you have
allocated nearly half of you CPUs addressable memory. That is like 2
Gigabytes minus 1 byte in one chunk for 32bit addressing. I do not think
that a usual array should worry about this. Anyway, the
OS/C-library/heap-handler will refuse the request for allocating more (than
max of ptrdiff_t) - on most systems I know.