Hi,
I am copying data from one buffer(this data is a binary data not
string) to another buffer. Earlier when I used C, I used the memcpy
function call to copy the values. Is there any equivalent replacement
in C++ for this call.
8  5233 
On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[127.0.0.1]said:
>
Why not simply use std::copy? (don't forget pointers are iterators too ;-)
It's a good deal safer, and likely to be just as efficient, because
it's probably specialised to call memmove or its moral equivalent
whenever it's safe to do so.
Given two pointers and a length, copy is not safer than memcpy.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
In message <20080207101524 16807-pete@versatilec odingcom>, Pete Becker
<pe**@versatile coding.comwrite s
>On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[127.0.0.1]said:
> Why not simply use std::copy? (don't forget pointers are iterators
too ;-)
It's a good deal safer, and likely to be just as efficient, because
it's probably specialised to call memmove or its moral equivalent
whenever it's safe to do so.
Given two pointers and a length, copy is not safer than memcpy.
What, even if they point to non-POD objects?
--
Richard Herring
On 2008-02-07 11:09:04 -0500, Richard Herring <ju**@[127.0.0.1]said:
In message <20080207101524 16807-pete@versatilec odingcom>, Pete Becker
<pe**@versatile coding.comwrite s
>On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[127.0.0.1]said:
>> Why not simply use std::copy? (don't forget pointers are iterators too ;-)
It's a good deal safer, and likely to be just as efficient, because
it's probably specialised to call memmove or its moral equivalent
whenever it's safe to do so.
Given two pointers and a length, copy is not safer than memcpy.
What, even if they point to non-POD objects?
Sighg. Okay: given that memcpy is acceptable for the two pointers and
the length, copy is not safer than memcpy.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
In message <20080207113538 16807-pete@versatilec odingcom>, Pete Becker
<pe**@versatile coding.comwrite s
>On 2008-02-07 11:09:04 -0500, Richard Herring <ju**@[127.0.0.1]said:
>In message <20080207101524 16807-pete@versatilec odingcom>, Pete Becker
<pe**@versati lecoding.comwri tes
>>On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[127.0.0.1]said:
Why not simply use std::copy? (don't forget pointers are iterators
too ;-)
It's a good deal safer, and likely to be just as efficient,
because it's probably specialised to call memmove or its moral
equivalen t whenever it's safe to do so.
Given two pointers and a length, copy is not safer than memcpy.
What, even if they point to non-POD objects?
Sighg. Okay: given that memcpy is acceptable for the two pointers and
the length, copy is not safer than memcpy.
Agreed, but it's no less safe and probably no slower.
(And if the ranges overlap, you may have to stop and think whether you
really meant memcpy and not memmove.)
I just don't like to see solutions implying that copying objects is
merely a matter of shuffling bits around. Sooner or later one gets
bitten.
--
Richard Herring
On Feb 7, 4:15 pm, Pete Becker <p...@versatile coding.comwrote :
On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[127.0.0.1]said:
Why not simply use std::copy? (don't forget pointers are
iterators too ;-)
It's a good deal safer, and likely to be just as efficient, because
it's probably specialised to call memmove or its moral equivalent
whenever it's safe to do so.
Given two pointers and a length, copy is not safer than memcpy.
There are two potential errors with memcpy: the length is wrong,
and that memcpy doesn't have appropriate semantics for the type
being copied. Copy only suffers from the first of these.
--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Feb 7, 7:16 pm, Richard Herring <ju**@[127.0.0.1]wrote:
In message <20080207113538 16807-pete@versatilec odingcom>, Pete Becker
<p...@versatile coding.comwrite s
On 2008-02-07 11:09:04 -0500, Richard Herring <ju**@[127.0.0.1]said:
In message <20080207101524 16807-pete@versatilec odingcom>, Pete Becker
<p...@versatil ecoding.comwrit es
On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[127.0.0.1]said:
>> Why not simply use std::copy? (don't forget pointers are iterators
too ;-)
It's a good deal safer, and likely to be just as efficient,
because it's probably specialised to call memmove or its moral
equivalent whenever it's safe to do so.
Given two pointers and a length, copy is not safer than memcpy.
What, even if they point to non-POD objects?
Sighg. Okay: given that memcpy is acceptable for the two pointers and
the length, copy is not safer than memcpy.
Agreed, but it's no less safe and probably no slower.
(And if the ranges overlap, you may have to stop and think whether you
really meant memcpy and not memmove.)
If the ranges overlap, you may have to think whether you need to
use reverse iterators or not with std::copy. If you don't know
whether they overlap or not, memmove always works, but you can't
use std::copy. (Note that there is no standard conformant way
of determining whether two ranges overlap, given only the
pointers and their length. memmove cannot be implemented in
standard conformant, portable C.)
--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On 2008-02-08 04:46:10 -0500, James Kanze <ja*********@gm ail.comsaid:
On Feb 7, 4:15 pm, Pete Becker <p...@versatile coding.comwrote :
>On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[127.0.0.1]said:
>>Why not simply use std::copy? (don't forget pointers are
iterators too ;-)
>>It's a good deal safer, and likely to be just as efficient, because
it's probably specialised to call memmove or its moral equivalent
whenever it's safe to do so.
>Given two pointers and a length, copy is not safer than memcpy.
There are two potential errors with memcpy: the length is wrong,
and that memcpy doesn't have appropriate semantics for the type
being copied. Copy only suffers from the first of these.
Right. But given that memcpy works, which is the premise for replacing
it, copy is not inherently "a good deal safer."
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
In message <20080208090656 16807-pete@versatilec odingcom>, Pete Becker
<pe**@versatile coding.comwrite s
>On 2008-02-08 04:46:10 -0500, James Kanze <ja*********@gm ail.comsaid:
>On Feb 7, 4:15 pm, Pete Becker <p...@versatile coding.comwrote :
>>On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[127.0.0.1]said:
>>>Why not simply use std::copy? (don't forget pointers are
iterators too ;-)
>>>It's a good deal safer, and likely to be just as efficient, because
it's probably specialised to call memmove or its moral equivalent
whenever it's safe to do so.
>>Given two pointers and a length, copy is not safer than memcpy.
There are two potential errors with memcpy: the length is wrong,
and that memcpy doesn't have appropriate semantics for the type
being copied. Copy only suffers from the first of these.
Right. But given that memcpy works, which is the premise for replacing
it, copy is not inherently "a good deal safer."
"Given that memcpy works" is *not* a premise. It's a proviso that
practically begs the question. The original premise was this:
>>>>If the source is a raw stream of bytes, (say from a communications
line), or the source and destination are disparate data types and
can not be made the same type (for whatever reason), then just memcpy.
and in the second case ("disparate data types") naively applying memcpy
is unlikely to have a happy outcome.
--
Richard Herring This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Christopher Benson-Manica |
last post by:
(if this is a FAQ or in K&R2, I didn't find it)
What parameters (if any) may be 0 or NULL? IOW, which of the following
statements are guaranteed to produce well-defined behavior?
char src;
char dst;
memcpy( dst, src, 1 );
memcpy( NULL, src, 1 );
|
by: Case |
last post by:
#define SIZE 100
#define USE_MEMCPY
int main(void)
{
char a;
char b;
int n;
/* code 'filling' a */
|
by: myhotline |
last post by:
hi all
im very confused about using memcpy and i have three
questions....memcpy takes a pointer to src and a pointer to dest and
copies src to destination...but im very confuzed about when to use '&'
operator while using memcpy....i have code that use '&' and the code
that call memcpy without '&'
like is the following same
Quest1
---
|
by: remove the CAPS |
last post by:
Hi, all.
This question came up in a code review: are null pointers legal as
arguments to memcpy? That is, is the program at the end of this article
strictly conforming? (Of course, I check the FAQ first and could not
find an answer on point.)
I don't have C89 or C99 handy, so I checked draft N869 from here:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/n869.txt.gz
|
by: ebrahimbandookwala |
last post by:
HI everyone
I am supposed to pass back a pointer to a struct from a function whos
definition cannot be changed
flight_t * get_item(field_t field , void * data)
the problem I encounter is whe I pass back the address of a local var
it gives me garbled output at the calling end ( obv !! )
| | |
by: Martin Jørgensen |
last post by:
Hi,
I'm relatively new with C-programming and even though I've read about
pointers and arrays many times, it's a topic that is a little confusing
to me - at least at this moment:
----
1) What's the difference between these 3 statements:
(i) memcpy(&b, &KoefD, n); // this works somewhere in my code
|
by: Eric |
last post by:
Tell me why the following doesn't work...
void MyClass::StoreCommand( struct command cmdToStore )
{
memcpy( (char*)&theCommand,
(char*)&cmdToStore,
sizeof( struct command ) );
}
theCommand is also a struct command type.
|
by: Mark |
last post by:
Hi List,
I want to write a function to copy some data out of a hardware buffer.
The hardware can change the contents of this buffer without it being
written to by my function. I want to use memcpy to unload the data.
Do I need to specify the source data as volatile in this case?
What is the correct syntax for specifying that the data pointed to by
the source pointer is volatile and not the pointer itself?
|
by: sam |
last post by:
(newbie)Technically what's the difference between memset() and
memcpy() functions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
