Can't make sense of this arrays and pointers assignment

[jewel87]

Hello guys,

I have a problem again with my lecturer's task she has given, I feel it is wrong at all.
Here is what she gave us:

in the Account.h attributes

 Transaction **Transactions; // she called this 'declaring an array Transactions'

but so far this is just a pointer to pointer, isn't it?

then in Account.cpp :

Account :: Account()
{
        Transactions = new Transaction *[SizeOfArray];
        for (int i=0; i<SizeOfArray; i++)
                Transactions[i] = new Transaction();   ///is this right access of array elements?
}

Account :: ~Account()
{
        for (int i=0; i<SizeOfArray; i++)
                delete Transactions[i];

        delete Transactions;
}

Can anyone explain what's going on here? I understand that she is declaring an array or pointers through a pointer Transactions, and then allocates an object for each pointer, but is it right to access the array like that?

[Ganon11]

Everything I see here is correct. You are correct in seeing that Transactions is a pointer to a pointer to a Transaction. So, when you initialize the 'first' pointer, you make it point to an array of its type - pointers:

[CODE=cpp]Transactions = new Transaction*[size];[/CODE]

There is nothing special about this - Transactions is just a regular array like you've always seen. What changes is the type of data held in the array - pointers, each of which can point to a whole new Transaction object or array of Transaction objects.

When initializing the Transaction pointers, you have to access each pointer held in Transactions, and set each of these to a new Transaction.

When deleting, it is not enough to delete [] Transactions. All of the pointers also allocated memory, which must be de-allocated. The only way to get the memory locations is by using the still-intact Transactions array. Once this is done, you can de-allocate the pointers held in Transactions.

The only note I would make is I'm not sure you should put the parentheses after new Transaction - it may give you some funny errors. If you do get errors around this part of the function, try removing them.

[weaknessforcats]

Transaction **Transactions; // she called this 'declaring an array Transactions'

Your instructor is incorrect. A Transaction** is a pointer to a Tranaction* and a Trancaction* is a pointer to a single Transcation. There is nothing about an array here.

This is a common scew-up where arrays are concerned.

Read this:

First, there are only one-dimensional arrays in C or C++. The number of elements in put between brackets:
[code=c]
int array[5];
[/code]

That is an array of 5 elements each of which is an int.

[code=c]
int array[];
[/code]

won't compile. You need to declare the number of elements.

Second, this array:
[code=c]
int array[5][10];
[/code]

is still an array of 5 elements. Each element is an array of 10 int.

[code=c]
int array[5][10][15];
[/code]

is still an array of 5 elements. Each element is an array of 10 elements where each element is an array of 15 int.


[code=c]
int array[][10];
[/code]

won't compile. You need to declare the number of elements.

Third, the name of an array is the address of element 0
[code=c]
int array[5];
[/code]

Here array is the address of array[0]. Since array[0] is an int, array is the address of an int. You can assign the name array to an int*.

[code=c]
int array[5][10];
[/code]

Here array is the address of array[0]. Since array[0] is an array of 10 int, array is the address of an array of 10 int. You can assign the name array to a pointer to an array of 10 int:
[code=c]
int array[5][10];

int (*ptr)[10] = array;
[/code]

Fourth, when the number of elements is not known at compile time, you create the array dynamically:

[code=c]
int* array = new int[value];
int (*ptr)[10] = new int[value][10];
int (*ptr)[10][15] = new int[value][10][15];
[/code]

In each case value is the number of elements. Any other brackets only describe the elements.

Using an int** for an array of arrays is incorrect and produces wrong answers using pointer arithmetic. The compiler knows this so it won't compile this code:

[code=c]
int** ptr = new int[value][10]; //ERROR
[/code]

new returns the address of an array of 10 int and that isn't the same as an int**.

Likewise:
[code=c]
int*** ptr = new int[value][10][15]; //ERROR
[/code]

new returns the address of an array of 10 elements where each element is an array of 15 int and that isn't the same as an int***.

With the above in mind this array:
[code=cpp]
int array[10] = {0,1,2,3,4,5,6, 7,8,9};
[/code]
has a memory layout of

0 1 2 3 4 5 6 7 8 9

Wheras this array:
[code=cpp]
int array[5][2] = {0,1,2,3,4,5,6, 7,8,9};
[/code]
has a memory layout of

0 1 2 3 4 5 6 7 8 9

Kinda the same, right?

So if your disc file contains

0 1 2 3 4 5 6 7 8 9

Does it make a difference wheher you read into a one-dimensional array or a two-dimensional array? No.

Therefore, when you do your read use the address of array[0][0] and read as though you have a
one-dimensional array and the values will be in the correct locations.

You might show this to your instructor.

[MarshMallow]

Your instructor is incorrect. A Transaction** is a pointer to a Tranaction* and a Trancaction* is a pointer to a single Transcation. There is nothing about an array here.
This is a common scew-up where arrays are concerned.
You might show this to your instructor.

Listen Weakness....ple ase be sure you clearly understood what you are talking about before claiming yourself to be right.
you should know that new operator return an address,and a Transaction object contructed trhrough a new operation is itself a pointer (i.e. the variable stores an address).
Remember that an array is nothing but a variable,a variable wich represents the first address of a set of contiguous memory blocks;so an array variable is itself a pointer.
Therefore declaration: Transaction** transactions declares transactions as the first address of a set of memory regions storing addresses.Do you still believe the instructor is wrong?

[oler1s]

And MarshMallow, before you accuse someone of being wrong, it's probably a good idea to check that you aren't making a mistake yourself. See the C-FAQ. Or grab a draft of the standards and check for yourself.

It does not follow that if you can manipulate arrays through pointer notation, that pointers and arrays are equivalent. An array is not a pointer. Referring to an array is syntactically equivalent to referring to the address of the first element.

I don't know how you get the implication that a pointer unconditionally becomes a reference to an array. Like the instructor, you too have confused the word "equivalenc e".

[MarshMallow]

And MarshMallow, before you accuse someone of being wrong, it's probably a good idea to check that you aren't making a mistake yourself. See the C-FAQ.

The code posted by the instructor is right.let's stop it.
Taking a C-whatsoeverFAQ as the reference is not a good way to study Oler.

[oler1s]

Taking a C-whatsoeverFAQ as the reference is not a good way to study Oler.

Apparently, you aren't aware of where this C-FAQ is coming from. The C-FAQ and C++-FAQ sites are in a way connected to the Usenet groups comp.lang.c and .c++. If you don't understand the implications of what I'm saying, well, let's just say you should use Google to find out about them.

EDIT: I realize my post might have come off as an attack. It's not. You really should know about the C-FAQ and C++-FAQ. If you post a Usenet question in the comp.lang groups for those languages, and it's answered by something in one of the FAQs, you will be pointed there. That's why you would do well to read the material in the FAQ. They genuinely address a lot of the mistakes that people make in C and C++.

Using the C FAQ, C++ FAQ, and the Usenet groups is an excellent way to study.

[weaknessforcats]

The code posted by the instructor is right.let's stop it.
Taking a C-whatsoeverFAQ as the reference is not a good way to study Oler.

The instructor's code is not correct. Do a Google on decay of array to pointer and you will see what I mean.

[jewel87]

ok, guys, thank you all anyways, don't fight, it's ok.