why it is necessary to write column during function prototype or function definition?
example:  int fun(int ary[][col]);   <-- function prototype

I am a bit busy at the moment so I do not have time to go into a huge amount of detail at the moment but built in arrays in C++ are

a) always single dimensional
b) always have elements of fixed size.

BUT, BUT, BUT you say surely we can have 2D arrays as in my question.

Nope. Not really. What you have is an array whose elements are themselves arrays.

You have to specify the size of the inner (col) array elements as their size is needed to compute the start of each of them within the outer (row) array. The size of the outer array need not be known because all a function needs to know is the starting address of an array. This of course leads to problems knowing how many items an array argument actually has, which is why many C style functions provide a size value specifying how many elements are in array arguments.

BUT the compiler does, as I said, needs to know how much to add onto the starting location to reach the start of each element. For non-array elements the size of the element type is all that is required. This, in fact, is the same for elements that are themselves arrays, except to compute the size of the elements that are arrays both the size of the types of the (inner) array elements is required _and_ the number of elements in the (inner) array. Hence, the size of each row's columns-array is number-of-columns * size-of-element-type.

So if you had an array int a[3][5], and size of int is 4, then size of an inner columns array is 4*5 or 20 and the memory layout would look like so (starting as 1000 as before...):

   1000-1003 row 0, column 0 integer <- start of row 0 int[5] element
   1004-1007 row 0, column 1 integer
   1008-1011 row 0, column 2 integer
   1012-1015 row 0, column 3 integer
   1016-1019 row 0, column 4 integer
   1020-1023 row 1, column 0 integer <- start of row 1 int[5] element
   1024-1027 row 1, column 1 integer
   1028-1031 row 1, column 2 integer
   1032-1035 row 1, column 3 integer
   1036-1039 row 1, column 4 integer
   1040-1043 row 2, column 0 integer <- start of row 2 int[5] element
   1044-1047 row 2, column 1 integer
   1048-1051 row 2, column 2 integer
   1052-1055 row 2, column 3 integer
   1056-1059 row 2, column 4 integer

It follows that the formula for locating an element is (row * NUMBER_OF_COLUMS) + column (leaving aside array the start location and element size as the compiler takes care of that for us).

Consider that if the compiler did not know the size of the 'inner' columns array how would it know where the rows start? In the above example it could just as easily assume that each row consisted of 3 columns (allowing 5 rows to fit in the same space), or only 1 (i.e. a 1 dimensional array). Or, as effectively only a pointer to the start is passed, any number you like, and you risk accessing memory beyond the end of the array - a Bad Thing (tm). In fact as there are so many options to choose, if you do not provide the value the compiler with give up and give you an error, hopefully indicating you are missing a dimension value.

Note: of course the row columns-arrays can of course themselves be comprised of arrays (3D array)..and so on, and likewise the number of elements in this third dimension needs to be known. In fact all array dimensions except the first (outer) need to be specified to specify the 'shape' of the array.

Note2: You might have started to gather that C and C++ built in arrays are just ways of cheaply managing chunks of memory containing many things of the same type (and size), and are in fact are really simple and quite dumb and one thing you loose when passing arrays to functions is the size of the array (or outer array if the array is an array of arrays (of arrays, ...)).

Hope this helps, although I suspect you might need to engage your brain and do a bit of thinking on this.


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at http://www.open-std.org/jtc1/sc22/wg21/.


©2016 About.com. All rights reserved.