a question regarding QByteArray

[franco.amato]

Hi to all,
(wysota sorry in advance if my question is trivial ).
I would know why these 2 piece of code give different result:

QByteArray ba = m_axobj->dynamicCall("GetUserData(QString)", id ).toByteArray();
quint16 templatesize = 0;
memcpy( &templatesize, &ba[87], sizeof(quint16) );
templatesize = qFromBigEndian(templatesize);
qDebug() << templatesize;

QByteArray ba = m_axobj->dynamicCall("GetUserData(QString)", id ).toByteArray();
quint16 templatesize = 0;
memcpy( &templatesize, &ba[87], sizeof(quint16) );
templatesize = qFromBigEndian(templatesize);
qDebug() << templatesize;

To copy to clipboard, switch view to plain text mode 

And

QByteArray ba = m_axobj->dynamicCall("GetUserData(QString)", id ).toByteArray();
const char *dat = ba.constData();
quint16 templatesize = 0;
memcpy( &templatesize, dat+87, sizeof(quint16) );
templatesize = qFromBigEndian(templatesize);
qDebug() << templatesize;

QByteArray ba = m_axobj->dynamicCall("GetUserData(QString)", id ).toByteArray();
const char *dat = ba.constData();
quint16 templatesize = 0;
memcpy( &templatesize, dat+87, sizeof(quint16) );
templatesize = qFromBigEndian(templatesize);
qDebug() << templatesize;

To copy to clipboard, switch view to plain text mode 

Reading QByteArray documentation the [i] operator should return the byte at position i so with the & operator I get its address.
This should be the same of adding the offset i at the first value address.
I'm sure I'm wrong but where?

[squidge]

Isn't the [] an overloaded operator in the QByteArray class? If you want to get a pointer to a sequential array of the bytes, you should use the constData or equivalent member functions.

[franco.amato]

Isn't the [] an overloaded operator in the QByteArray class?

Yes is it.

If you want to get a pointer to a sequential array of the bytes, you should use the constData or equivalent member functions.

But teorically the 2 code should give the same address as

int vet[10] = {1,2,3,4,5,6,7,8,9,0};
 
&vet[5] and
vet+5

int vet[10] = {1,2,3,4,5,6,7,8,9,0};

&vet[5] and
vet+5

To copy to clipboard, switch view to plain text mode 

should give the same address or I'm wrong somewhere?

[wysota]

(wysota sorry in advance if my question is trivial ).

If it's trivial then post it in the newbie forum.

BTW. Check if sizeof(quint16)==sizeof(char) and then think what it means.

[faldzip]

Yes is it.

If so then check the signature, declaration and description in docs. I can help you:

QByteRef operator[] ( int i )
char operator[] ( int i ) const
QByteRef operator[] ( uint i )
char operator[] ( uint i ) const

As you can see operator[] is not returning reference, but copy. So if it is a copy then it is somewhere else in memory then the actual value in the internal array (and yes, it is rather basic knowledge - if you are not sure how returning a copy, reference and pointer differs make some class with some message printing in copy constructor and return it from any function in different ways so you can see how many times an instance of a class was copied - useful excercise - I'm making such similar excericises quite often as sometimes I'm not sure how something works and I helps me to understand).

But teorically the 2 code should give the same address as

int vet[10] = {1,2,3,4,5,6,7,8,9,0};
 
&vet[5] and
vet+5

int vet[10] = {1,2,3,4,5,6,7,8,9,0};

&vet[5] and
vet+5

To copy to clipboard, switch view to plain text mode 

should give the same address or I'm wrong somewhere?

For C style array it is true. But you are using QByteArray class and not C array, so operator[] can do anything (it can even always return letter 'a' independently of given index - why not? )

[franco.amato]

Thank you very much.

[SixDegrees]

Reading QByteArray documentation the [i] operator should return the byte at position i so with the & operator I get its address.
This should be the same of adding the offset i at the first value address.

No, the documentation makes no such guarantee. Just because they've overloaded the indexing operator to make it look like a C-style array doesn't mean it is a C-style array. In fact, there is no way of telling how the data in such an object is actually stored simply by looking at the class interface. In fact, given the mention of the use of shared memory in the class documentation, it's nearly certain that taking brute-force addresses as you are doing will fail to behave anything like such tactics would with a simple C array.

[wysota]

so operator[] can do anything (it can even always return letter 'a' independently of given index - why not? )

It can even return 42