Is it possible to allocate an unsigned char[] within an else statement????

phamtv

My code is as follow:
@
else
{
QByteArray tmp_Buffer = _port->readAll();

            if (tmp_Buffer.length())
            {
                unsigned char temp[tmp_Buffer.length()];
                qMemCopy(&temp[0], &tmp_Buffer.data()[0], tmp_Buffer.length());

                emit LogMsgChanged(temp, sizeof(temp));

                ParseReceiveMsg(temp, rx_data);
            }
       }

@
But the variable temp does not seem to be allocated properly...

goetz

I'm not sure if all compilers support variable length arrays on the stack. With gcc on a Mac it works for me in a simple test program.

BUT: If your slot is not called synchronously it might be that the execution flow in the sending object left the scope of the inner if-statement when your slot gets called. At this point in time the temp array is already destroyed and you have a dangling pointer in your slot!

Why don't you pass the QByteArray as argument to the signal? That would save you the qMemCopy and Qt handles all the reference counting for you.

Franzk

Fully agree with Volker here. There are too much things to take into account when not using a reference counted or copied object here.

Felix

as far as i know array lengthes need to be const at compile time, i had a similar error long time ago.

but you could try this:
@
char* temp = (char*)malloc(tmp_buffer.length);
memcpy(temp, tmp_buffer.data(), tmp_buffer.length);
@

goetz

From a C++ perspective better use:

@
char *temp = new char[tmp_buffer.length()];
memcpy(temp, tmp_buffer.data(), tmp_buffer.length);
// do some work
delete[] temp;
@

It's important to use delete[] rather than delete without brackets!

Advantages:

no need for a cast
the same syntax as with objects on the heap
no sizeof necessary

BTW: to be on the safe side one should use

@
malloc(sizeof(char) * length);
@

and of course not forget to call free(temp) after the malloc'ed memory isn't required anymore :-)

Regarding compiler support:
At least gcc does support variable length arrays on the stack as an extension to the C standard (and therefore in C++ too). With other compilers your mileage may vary. I would not depend on it, anyways. As I would avoid raw arrays of pointers wherever I can, too :-) (or put them at least into a nice object which cleans up in the destructor)

goetz

Uhm, forgot something very important:

On the same pointer

use T *x = new T() and delete x
or T *x = new T[ 42] and delete[] x
or T *x = (T *)malloc(sizeof(T) * 42) and free(x)

never, never, never mix any of these on the same pointer!

Of course one can use x = new and y = malloc in the same program, just use delete on x and free on y.

Felix

i work with vs compiler i think this compiler has problems with variable length arrays but not sure anymore.

@Volker thanks for the annotations and explanations

Is there a reason why i should use free for a pointer that was allocated with malloc instead of deleting it?

goetz

Yes. You definitely want to avoid earth destruction :-)

To be serious: There are several reaseon, among them:

The memory allocation from new might not be the same as with malloc, so the pools are messed up if you mix them
new/delete call the constructors/destructors of objects whereas malloc/free only give you a bunch of bytes without any meaning.

You can find some more background infos in the "Freestore management":http://www.parashift.com/c++-faq-lite/freestore-mgmt.html Chapter of the C++ FAQ.