copy content of vector<BYTE> to BYTE*

[Vince]

Hi,

I have replaced my BYTE* by a vector<BYTE> and before I used to do :

void CCardRecord::GetRecData(int nOffset, int nDataSize, CString& csValue)
{
BYTE *pTmp = NULL;
pTmp = new BYTE[nDataSize + 1];
memset(pTmp, 0, nDataSize + 1);
//memcpy(pTmp, &m_pData[ nOffset ], nDataSize);
csValue = pTmp;
}

But now m_pData is a vector.

[Victor Bazarov]

Vince wrote:

I have replaced my BYTE* by a vector<BYTE> and before I used to do :

void CCardRecord::GetRecData(int nOffset, int nDataSize, CString& csValue)
{
BYTE *pTmp = NULL;
pTmp = new BYTE[nDataSize + 1];
memset(pTmp, 0, nDataSize + 1);
//memcpy(pTmp, &m_pData[ nOffset ], nDataSize);
Nothing changes, really. You should still be able to do

memcpy(pTmp, &m_pData[nOffset], nDataSize);

The reason is that vector's storage is a contiguous chunk of elements,
essentially an array. 'm_pData[nOffset]' does call the operator[] for the
vector, but it returns a reference to the nOffset-th element, and you may
take its address. All elements of the vector after the nOffset-th sit in
the same array, so you may pass it to 'memcpy'.
csValue = pTmp;
}

But now m_pData is a vector.

V

[Vince]

d:\RATP\Borne_FROM_SCRATCH_200105\CardObj.cpp(159) : error C2440: '=' :
cannot convert from 'std::vector<_Ty>' to 'BYTE *'
with
[
_Ty=BYTE
]
"Victor Bazarov" <v.********@comAcast.net> a écrit dans le message de news:
5u******************@newsread1.mlpsca01.us.to.veri o.net...

Vince wrote:

I have replaced my BYTE* by a vector<BYTE> and before I used to do :

void CCardRecord::GetRecData(int nOffset, int nDataSize, CString&
csValue)
{
BYTE *pTmp = NULL;
pTmp = new BYTE[nDataSize + 1];
memset(pTmp, 0, nDataSize + 1);
//memcpy(pTmp, &m_pData[ nOffset ], nDataSize);

Nothing changes, really. You should still be able to do

memcpy(pTmp, &m_pData[nOffset], nDataSize);

The reason is that vector's storage is a contiguous chunk of elements,
essentially an array. 'm_pData[nOffset]' does call the operator[] for the
vector, but it returns a reference to the nOffset-th element, and you may
take its address. All elements of the vector after the nOffset-th sit in
the same array, so you may pass it to 'memcpy'.

csValue = pTmp;
}

But now m_pData is a vector.

V

[Victor Bazarov]

Vince wrote:

d:\RATP\Borne_FROM_SCRATCH_200105\CardObj.cpp(159) : error C2440: '=' :
cannot convert from 'std::vector<_Ty>' to 'BYTE *'
with
[
_Ty=BYTE
]
WHERE? There is no assignment in your code fragment except to 'csValue'
and 'pTmp', none of which is a vector.

You said 'm_pData' was a vector. Is it? Or is it a pointer to a vector?
Did you leave the rest of the function intact? Did you change it? If you
did change it, how?

And don't top-post, please. Thank you.


"Victor Bazarov" <v.********@comAcast.net> a écrit dans le message de news:
5u******************@newsread1.mlpsca01.us.to.veri o.net...

Vince wrote:

I have replaced my BYTE* by a vector<BYTE> and before I used to do :

void CCardRecord::GetRecData(int nOffset, int nDataSize, CString&
csValue)
{
BYTE *pTmp = NULL;
pTmp = new BYTE[nDataSize + 1];
memset(pTmp, 0, nDataSize + 1);
//memcpy(pTmp, &m_pData[ nOffset ], nDataSize);

Nothing changes, really. You should still be able to do

memcpy(pTmp, &m_pData[nOffset], nDataSize);

The reason is that vector's storage is a contiguous chunk of elements,
essentially an array. 'm_pData[nOffset]' does call the operator[] for the
vector, but it returns a reference to the nOffset-th element, and you may
take its address. All elements of the vector after the nOffset-th sit in
the same array, so you may pass it to 'memcpy'.

csValue = pTmp;
}

But now m_pData is a vector.

V

--
Please remove capital As from my address when replying by mail

[Vince]

"Victor Bazarov" <v.********@comAcast.net> a écrit dans le message de news:
GD*******************@newsread1.mlpsca01.us.to.ver io.net...

Vince wrote:

d:\RATP\Borne_FROM_SCRATCH_200105\CardObj.cpp(159) : error C2440: '=' :
cannot convert from 'std::vector<_Ty>' to 'BYTE *'
with
[
_Ty=BYTE
]

WHERE? There is no assignment in your code fragment except to 'csValue'
and 'pTmp', none of which is a vector.

You said 'm_pData' was a vector. Is it? Or is it a pointer to a vector?
Did you leave the rest of the function intact? Did you change it? If you
did change it, how?

And don't top-post, please. Thank you.

"Victor Bazarov" <v.********@comAcast.net> a écrit dans le message de
news: 5u******************@newsread1.mlpsca01.us.to.veri o.net...

Vince wrote:

I have replaced my BYTE* by a vector<BYTE> and before I used to do :

void CCardRecord::GetRecData(int nOffset, int nDataSize, CString&
csValue)
{
BYTE *pTmp = NULL;
pTmp = new BYTE[nDataSize + 1];
memset(pTmp, 0, nDataSize + 1);
//memcpy(pTmp, &m_pData[ nOffset ], nDataSize);

Nothing changes, really. You should still be able to do

memcpy(pTmp, &m_pData[nOffset], nDataSize);

The reason is that vector's storage is a contiguous chunk of elements,
essentially an array. 'm_pData[nOffset]' does call the operator[] for
the
vector, but it returns a reference to the nOffset-th element, and you may
take its address. All elements of the vector after the nOffset-th sit in
the same array, so you may pass it to 'memcpy'.
csValue = pTmp;
}

But now m_pData is a vector.

V

--
Please remove capital As from my address when replying by mail

It is located somewhere else :

BYTE* pData = NULL;
map<int, CCardFile>::iterator itFile = NULL;
map<int, CCardRecord>::iterator itRec = NULL;
for ( itFile = m_FileIndex.begin(); itFile != m_FileIndex.end(); ++itFile )
{
for (itRec = itFile->second.m_RecIndex.begin(); itRec !=
itFile->second.m_RecIndex.end(); ++itRec)
{
nSFID = itFile->first;
nRecNo = itRec->second.m_nRecNo;
nRecLen = itRec->second.m_nRecLen;
pData = itRec->second.m_ByteArray;
bRet = m_pCardReader->ReadRecord((BYTE)nSFID, (BYTE)nRecNo, pData, nRecLen);
if ( ! bRet )
return bRet;
}
}

[Victor Bazarov]

Vince wrote:

"Victor Bazarov" <v.********@comAcast.net> a écrit dans le message de news:
GD*******************@newsread1.mlpsca01.us.to.ver io.net...

Vince wrote:

d:\RATP\Borne_FROM_SCRATCH_200105\CardObj.cpp(1 59): error C2440: '=' :
cannot convert from 'std::vector<_Ty>' to 'BYTE *'
with
[
_Ty=BYTE
]
WHERE? There is no assignment in your code fragment except to 'csValue'
and 'pTmp', none of which is a vector.

You said 'm_pData' was a vector. Is it? Or is it a pointer to a vector?
Did you leave the rest of the function intact? Did you change it? If you
did change it, how?

And don't top-post, please. Thank you.

[...]

It is located somewhere else :

BYTE* pData = NULL;
map<int, CCardFile>::iterator itFile = NULL;
map<int, CCardRecord>::iterator itRec = NULL;
for ( itFile = m_FileIndex.begin(); itFile != m_FileIndex.end(); ++itFile )
{
for (itRec = itFile->second.m_RecIndex.begin(); itRec !=
itFile->second.m_RecIndex.end(); ++itRec)
{
nSFID = itFile->first;
nRecNo = itRec->second.m_nRecNo;
nRecLen = itRec->second.m_nRecLen;
pData = itRec->second.m_ByteArray;
I suppose I have to guess again, don't I? What's wrong? Couldn't you
somehow mark the line to which the error message relates?

Anyway, you made m_ByteArray a vector<BYTE>, right? Well, you need to
fix the rest of your code to reflect that. In particular, here you can
probably do

pData = & (itRec->second.m_ByteArray[0]);
bRet = m_pCardReader->ReadRecord((BYTE)nSFID, (BYTE)nRecNo, pData, nRecLen);
if ( ! bRet )
return bRet;
}
}

But in any case, I strongly recommend you to rethink the implementation of
all your functions. For example, you probably don't need 'm_nRecLen' any
more because the vector keeps its own size. And so on...

Victor

[gMorphus]

Indeed it would work, although, the right way to do it, if you are
working with STL is to use the "copy" function.
For example:
vector < BYTE > Vect;
copy(Vect.begin()+nOffset, Vect.begin()+nOffset+nDataSize, pTmp);

Now let's complicate it.
Assuming you to replace the "vector" with a "list".
The copy fucntion receives 3 iterators so it is only logical we can use
list.
But, the with a list iterator we cannot use the '+' operator, so we
will operator overloading:

typedef list<BYTE> tSequent;
tSequent::iterator operator+(tSequent::iterator it, int n)
{
for (int i=0; i<n; ++i) {
it++;
}
return it;
}

Now we don't even have to change our function. We can still use this
sentence:
copy(Vect.begin()+nOffset, Vect.begin()+nOffset+nDataSize, pTmp);

only Vect is a "list"...

P.S.
Effiency: using a vector is a lot more efficient. Using the copy
function with a vector instead the memcpy is a lot _less_ efficient.
The reason is that the copy function have to copy BYTE BYTE, as opposed
to coping the whole segment at once with the memcpy.

[Victor Bazarov]

gMorphus wrote:

[..] Effiency: using a vector is a lot more efficient. Using the copy
function with a vector instead the memcpy is a lot _less_ efficient.
The reason is that the copy function have to copy BYTE BYTE, as opposed
to coping the whole segment at once with the memcpy.

Actually, this all is not necessarily so. For all we know, 'std::copy'
can be specialised for vectors to perform memcpy under the covers...

[White Wolf]

gMorphus wrote:
[<<<snip]

Effiency: using a vector is a lot more efficient. Using the copy
function with a vector instead the memcpy is a lot _less_ efficient.
The reason is that the copy function have to copy BYTE BYTE, as opposed
to coping the whole segment at once with the memcpy.

Nothing whatsoever requires a standard vector of POD types to do so.

Also, counting the fact that the full implementation of std::copy is most
probably visible to the compiler, it is not too far fetched to assume that
in certain cases (if inlining happens) std::copy will beat the hell out of
memcpy in speed. Of course this is true as long as memcpy is not a compiler
intrinsic, in which case it may be so unpolitely fast that no code can be
faster. And of course, as Victor has pointed out, std::copy and memcpy can
just be the very same functions.

So in a short time we have given acceptable (or at least a tiny bit
convincing) arguments for std::copy being way slower than memcpy, way faster
than memcpy and the same as memcpy. Now I guess all we need is to remember
that Michael Jackson, who is not in jail and not on bail. Or Knuth. They
have placed the root of evil to a very different place than the current US
government. They were pointing out, that premature optimization is the root
of all evil. Which it may not be, but it surely is a damn dumb waste of
time guesswork to optimize code, wich has not been written yet, unknown if
it is slow or not, unknown what causes it to be slow if it is... It is as
reasonable spending of ones' time as me thinking about what should I wear on
my date with Claudia Schiffer.

Sorry for the (kinda) outburts, nothing personal. I just wanted to point
out that guesswork is evil. Especially if people believe it.

--
WW aka Attila
:::
Constant change is here to stay

[gMorphus]

Ok, after a little investigation I have realized that my solution is
not good.
That operator overlaoding wouldn't work for vector because the type
will be a "const unsigned char *" - which you cannot overload.

Moreover, I think the copy function _cannot_ be overloaded. The reason
for is the same - the vector iterator is simply a pointer, which you
cannot be overloaded or specialised.

Am I right?

[Howard]

"White Wolf" <wo***@freemail.hu> wrote in message
news:cs**********@phys-news1.kolumbus.fi...

gMorphus wrote:
[<<<snip] Now I guess all we need is to remember that Michael Jackson, who is not
in jail and not on bail.
Umm... what? Can you diagram that sentence? Or at least complete it? :-)
Or Knuth.
Ditto.
They have placed the root of evil to a very different place than the
current US government.
Tread lightly there, friend. We may not all like Bush/Cheney, but it's
still OUR government.

Sorry for the (kinda) outburts, nothing personal. I just wanted to point
out that guesswork is evil. Especially if people believe it.

Apology accepted, I guess. ;-)

-Howard
"Life is like a donut. With sprinkles. Mmmm...sprinkles!"

[White Wolf]

gMorphus wrote:

Ok, after a little investigation I have realized that my solution is
not good.
That operator overlaoding wouldn't work for vector because the type
will be a "const unsigned char *" - which you cannot overload.

Moreover, I think the copy function _cannot_ be overloaded. The reason
for is the same - the vector iterator is simply a pointer, which you
cannot be overloaded or specialised.

Am I right?

No, you aren't.

1.) Copy can be overloaded, since it is *noty* an operator function. Now it
may be a very bad idea to overload it, but it can be done. Although it
cannot (eh, must not) be overloaded as std::copy.

2.) The vector iterator *may* be a pointer. In more and more Standard
Library implementations it is more and more frequently not apointer. And
of course any function can be overloaded and any template can be specialized
for pointers. Operators cannot be. It may be a very bad idea to do so with
"well known functions", but it can be done:

void foo(int);
void foo(char const *);
void foo(std::vector<char>::const_iterator);

Of course, if your iterator implementation happens to use typedefs to create
a type alias const_iterator for char const *, the above code will not
compile.

You do have good point, but your wording uses too strict statements:

"That operator overlaoding wouldn't work for vector because the type
/may/ be a "const unsigned char *" - /and/ you cannot overload /an operator
for that type/."

--
WW aka Attila
:::
SUSHIDO: The way of the Tuna.

[Victor Bazarov]

White Wolf wrote:

[...]
1.) Copy can be overloaded, since it is *noty* [...]

I think it's spelled *naughty*

:-) Sorry, couldn't resist...

[White Wolf]

Howard wrote:

"White Wolf" <wo***@freemail.hu> wrote in message
news:cs**********@phys-news1.kolumbus.fi...

gMorphus wrote:
[<<<snip]

Now I guess all we need is to remember that Michael Jackson, who is not
in jail and not on bail.

Umm... what? Can you diagram that sentence? Or at least complete it?
:-)

Read Herb Sutter more often. ;-) Did you at least make an attempt to ask
Google about Michel Jackson and optimization? Hints:

"Principles of Program Design" by M.A. Jackson, Associated Press 1975
ISBN 0 12 379050 6

Michael Jackson, rules of optimization:

Rule 1. Don't do it.
Rule 2. (for experts only) Don't do it yet.

Or Knuth.

Ditto.

Not knowing Knuth as a programmer is excuseable. But telling it in public
is not wise. First hit on Google:

http://www-cs-faculty.stanford.edu/~knuth/

I feel like the father, whose 25 years old sun calls out from the toilet: I
have finished, you can come!

They have placed the root of evil to a very different place than the
current US government.

Tread lightly there, friend. We may not all like Bush/Cheney, but it's
still OUR government.

Yours my friend. Not mine. Mine is worse than your, but at least has no
nucular weapons, or any other weapons of mass destruction, with
pronounciation errors or without.

Sorry for the (kinda) outburts, nothing personal. I just wanted to
point out that guesswork is evil. Especially if people believe it.

Apology accepted, I guess. ;-)

Understanding what was said may have been more benefitial.

--
WW aka Attila
:::
Nothing makes your clothes go out of fashion faster than getting a raise.

[White Wolf]

Victor Bazarov wrote:

White Wolf wrote:

[...]
1.) Copy can be overloaded, since it is *noty* [...]

I think it's spelled *naughty*

:-) Sorry, couldn't resist...

Ohm I couldn't resist. (Bad joke, but that's all I can do today.)

--
WW aka Attila
:::
Birthdays are good for you. Statistics show that the people who have the
most live the longest.

[Howard]

"White Wolf" <wo***@freemail.hu> wrote in message
news:cs**********@phys-news1.kolumbus.fi...

Howard wrote:

"White Wolf" <wo***@freemail.hu> wrote in message
news:cs**********@phys-news1.kolumbus.fi...

gMorphus wrote:
[<<<snip]

Now I guess all we need is to remember that Michael Jackson, who is not
in jail and not on bail.

Umm... what? Can you diagram that sentence? Or at least complete it?
:-)

Read Herb Sutter more often. ;-) Did you at least make an attempt to ask
Google about Michel Jackson and optimization? Hints:

Sorry. I thought "remember that..." meant something like "remember that you
need to lift the toilet seat...". I suppose you meant it like "remember
that Michael Jackson guy?" As I read it, it wasn't a complete sentence.
"Principles of Program Design" by M.A. Jackson, Associated Press 1975
ISBN 0 12 379050 6

Michael Jackson, rules of optimization:

Rule 1. Don't do it.
Rule 2. (for experts only) Don't do it yet.

Or Knuth.
Ditto.

Not knowing Knuth as a programmer is excuseable. But telling it in public
is not wise. First hit on Google:

Again, I was commenting (joking) about your lack of complete sentences. "Or
Knuth" lacks something as sentences go.
http://www-cs-faculty.stanford.edu/~knuth/

I feel like the father, whose 25 years old sun calls out from the toilet:
I have finished, you can come!

They have placed the root of evil to a very different place than the
current US government.
Tread lightly there, friend. We may not all like Bush/Cheney, but it's
still OUR government.

Yours my friend. Not mine. Mine is worse than your, but at least has no
nucular weapons, or any other weapons of mass destruction, with
pronounciation errors or without.

Sorry for the (kinda) outburts, nothing personal. I just wanted to
point out that guesswork is evil. Especially if people believe it.

Apology accepted, I guess. ;-)

Understanding what was said may have been more benefitial.

(I thought the smiley faces were a clue I was just joking?)

--
WW aka Attila
:::
Nothing makes your clothes go out of fashion faster than getting a raise.

[White Wolf]

Howard wrote:
[SNIP]

Read Herb Sutter more often. ;-) Did you at least make an attempt to
ask Google about Michel Jackson and optimization? Hints:
Sorry. I thought "remember that..." meant something like "remember that
you need to lift the toilet seat...". I suppose you meant it like
"remember that Michael Jackson guy?" As I read it, it wasn't a complete
sentence.

Yeah. It also happens to me. It can be quite fun when you stare at your
own slides on a course. That is when I take a note to simplify the
language. :-)

[SNIP] Again, I was commenting (joking) about your lack of complete sentences.
"Or Knuth" lacks something as sentences go.

And deliberately so. ;-)

[SNIP]

Apology accepted, I guess. ;-)

Understanding what was said may have been more benefitial.

(I thought the smiley faces were a clue I was just joking?)

You were joking and I was serious about the part that please please don't do
guesswork.

--
WW aka Attila
:::
Sorry - yesterday was the deadline for all complaints.