Moving data from array to deque

[goodTwe...@hotmail.com]

Hi,

The ReadFile function places read info into a char array (cReadBuf)
and I would like for put it in a deque. What is the most efficient way
to copy, using pushes or some other type of iteration?

Thanks,

quakerP

=====================================

char cReadBuf[512];
deque<char> cDdeq1(512);
;
Result = ReadFile(m_usbHandle, cReadBuf, m_reportLength, &bytesRead,
(LPOVERLAPPED) &HIDOverlapped);

[Victor Bazarov]

You should probably profile it to be sure which one is most efficient,
but if you 'assign', it's going to be [a tiny bit] faster than if you
'push_back' in a loop. Of course, the most efficient is probably
constructing the deque (BTW, why do you need deque?) from the array:

Result = ReadFile( ...
deque<char> cDdeq1(cReadBuf, cReadBuf + 512);

IOW, don't construct it before you actually need it. If this is not
an option, assign:

cDdeq1.assign(cReadBuf, cReadBuf + 512);

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Ulrich Eckhardt]

goodTwe...@hotmail.com wrote:
> The ReadFile function places read info into a char array (cReadBuf)
> and I would like for put it in a deque. What is the most efficient way
> to copy, using pushes or some other type of iteration?

I can't stress Victor's point too much that you need to profile before you
can make any optimisations. Until then, stay with the most simple solution:

byte buffer[size];
received = read( buffer, size);
std::copy( buffer, buffer+received, back_inserter(queue));

Especially for USB that will probably be fast enough.

BTW: the up to now fastest solution I had for a similar problem that lateron
required decoding the queue as a stream was to allocate fixed-size buffers
and queue those, using an allocator with a small pool as buffer. The whole
stream-interface was then constructed around this. That means that after
the read operation put the data into a buffer, it was never again copied...

Uli

[goodTwe...@hotmail.com]

Thanks for the answer. Should have seen assign but I have just started
investigating containers.

> constructing the deque (BTW, why do you need deque?)

Good question.

I am reading data from a USB HID that is apparently glued onto an
RS232 device. It sends packets of 32 bytes. The strings to be
extracted are from 16 to 128 bits in length. So I must look for a
start sentinel and retrieve characters until the end sentinel. In
amongst these characters are NULLs, EOTs, and other unprintables.
With the deque or actually a queue I check the front and pop
characters until the the end sentinel is found or the queue is empty.
When empty I read the device and stuff it into the end of the queue.
When the end of a sentence if found (an end sentinel) this getSentence
function returns. Next call I start checking the head of the queue for
another start sentinel.

I am not a power programmer and there may be better ways but using
deques allowed me to throw away a big piece of state machine code
where I kept up with array pointers, etc.

You also raised an excellent point about not creating the deque till
needed. I suppose when it is empty I could create a new one but don't
know about the overhead of creating a new one vs just assigning since
the size is only 32. I could use larger buffers and maybe the trade
off would tilt towards generating new deques. But the size of 32 is
determined by querying the device and my supervisor wants me to make
the classes as reusable as possible. Other HIDs I read behave much
more nicely.

That's probably more info than you wanted but writing it has made me
do some helpful thinking.

Looking fwd to your reply,

quakerP

[goodTwe...@hotmail.com]

PS - I suppose creating a new deque each time would require a function
call to make a temporal scope.

[Victor Bazarov]

goodTwe...@hotmail.com wrote:
> Thanks for the answer. Should have seen assign but I have just started
> investigating containers.
>
>> constructing the deque (BTW, why do you need deque?)
>
> Good question.
>
> I am reading data from a USB HID that is apparently glued onto an
> RS232 device. It sends packets of 32 bytes. The strings to be
> extracted are from 16 to 128 bits in length. So I must look for a
> start sentinel and retrieve characters until the end sentinel. In
> amongst these characters are NULLs, EOTs, and other unprintables.
> With the deque or actually a queue I check the front and pop
> characters until the the end sentinel is found or the queue is empty.
> When empty I read the device and stuff it into the end of the queue.

Popping from the top and re-stuffing is good enough a reason to have
a container that can do it fast. std::deque is one of them. OK.

> When the end of a sentence if found (an end sentinel) this getSentence
> function returns. Next call I start checking the head of the queue for
> another start sentinel.

So, I suppose the deque object has to survive beyond this function
and you probably pass it in. OK.

> I am not a power programmer and there may be better ways but using
> deques allowed me to throw away a big piece of state machine code
> where I kept up with array pointers, etc.

Sounds good.

> You also raised an excellent point about not creating the deque till
> needed. I suppose when it is empty I could create a new one but don't
> know about the overhead of creating a new one vs just assigning since
> the size is only 32.

Ah, forget I suggested it. You can safely reuse the deque you got.

> I could use larger buffers and maybe the trade
> off would tilt towards generating new deques. But the size of 32 is
> determined by querying the device and my supervisor wants me to make
> the classes as reusable as possible. Other HIDs I read behave much
> more nicely.
>
> That's probably more info than you wanted but writing it has made me
> do some helpful thinking.

I am glad I've helped. You're on the right track.