Simple structure and copying data to pointer of the same structure

[Goran]

let's say I have:

struct TWhatever
    {
    int MyInt;
    bool MyBool;
    }

Now I have already preallocated memory to where pWhatever points so:

TWhatever* pWhatever;

// Memory is already preallocated so the below lines work properly
pWhatever->MyInt = 1;
pWhatever->MyBool = false;

And now I also have vector:

std::vector<TWhatever> MyVect;
MyVect.pushBack(TWhatever());
MyVect[0].MyInt = 1;
MyVect[0].MyBool = false;

And now the question finally - all I want is to copy data from vector to
memory that pWhatever points to.

All vector data? Then:

std::copy(MyVect.begin(), MyVect.end(), pWhatever);
// pWhatever __must__ point to MyVect.size() TWhatever objects

Avoid using memcpy. That works only with POD types. TWhatever
currently is one, but that might change. So why take the memcpy risk?
(Answer: only if your code needs a perf. improvement, and you can see
it, through measurement, (on your own code, not a synthetic test), AND
you consider too expensive changing the code to avoid copying).

Goran.

 

[gwowen]

In modern C++ "memcpy", on its own, just says: this programmer don't evenknow
about curly braces initializations, or was not able to express the logical types
as C++ types, or... So, that would most likely be a novice.

If you'd have said "Every usage of memcpy() indicates the code was
written by a novice or guru, and there are a hell of lot more novices
than gurus", I think you'd have had fewer complaints.

As a datapoint, its worth noting that the linux version of Flash
recently had a bug in it that was only triggered by some glibc
versions, precisely because the programmer used memcpy() without
respecting the preconditions (a novice mistake - and a good example
that UB really can be "works perfectly for ages then dies in a ball of
flaming death").[0]

[0] https://bugzilla.redhat.com/show_bug.cgi?id=638477

 

[Alf P. Steinbach /Usenet]

* cg_chas, on 15.04.2011 15:38:
Whoever it is that you're trying to stab in the back, remarks like that place
you squarely in the troll category.


The C++ standard refers down to the C standard for such definitions.

To do so is

That's rubbish.


- Alf

 

[Alf P. Steinbach /Usenet]

* cg_chas, on 15.04.2011 19:21:

Don't worry Alf, your ivory tower has you well shielded from being stabbed in
the back. Besides the comment was directed towards the troll that thinks, "each
occurrence of "memcpy" indicates a novice".

If that person cannot own the blanket statement and all of its connotation, then
perhaps he or she should simply step down from their tower and take it back.

What is? the part about being in an ivory tower or the part about making broad,
unsubstantiated blanket statements like, "each occurrence of "memcpy" indicates
a novice."

As far as my citation goes, perhaps the wording does not stand up to the
immutable elitist perspective, so I'll simply rephrase and say that "the use of
memcpy _yields_ UB". The reason is clear enough and the part of the Standard
that I cited very much dicusses one of reasons that has to do with why.

In either case, people that tend to make broad unsubstantiated statements such
as the one referenced in this dicussion are at best not taken seriously, and at
worst labelled "troll".

Just be glad your tower is ivory because we all know what they say about those
that throw stones from glass houses.

Have a super day!

Charles

Plink.

 

[gwowen]

Now to your response.  Does using memcpy() really imply "novice" or "guru"?

No. Nor did I ever say such a thing. What I said was

If you'd have said "Every usage of memcpy() indicates the code was
written by a novice or guru, and there are a hell of lot more
novices
than gurus", I think you'd have had fewer complaints.

Even ignoring the smiley, that does *not* have the same meaning as:

If you'd have said "Every usage of memcpy() indicates the code was
written by a novice or guru, and there are a hell of lot more
novices
than gurus", I think you'd have been right.

Not the same meaning.

memcpy() has still has many uses in C++. But most of its mundane C-
style uses should probably be discouraged in C++ because they are
subsumed by assignment operators. Not banned outright, merely
discouraged. We have operator= and it is (a) typesafe and (b) more
generic. If I memcpy a non-copyable object, bad things happen. If I
assign one, the compiler tells me I've made a mistake. Those places
where memcpy may beat operator= (speed-critical path optimization,
library implementors) are not places where novice programmers should
be working.

At the risk of over-simplfication, there are, in my experience two
thought process that lead to memcpy usage:

(i) I know that my code will never be used on non-POD types so know
that I can memcpy() these objects and I know that assignment won't cut
it here, for reasons of efficiency, or because I'm *defining*
assignment at a very low level, and I know the compiler will not do as
good a job of optimizing this as I can, and this is a code path where
that really matters. This often applies to embedded programmers where
code efficiency (size or speed) may be of major importance. This is
guru-like thinking.

(ii) I remember from a text book that C has a memcpy() function for
copying stuff. C++ is like C, and I want to copy stuff, so I'll use
memcpy(). This is novice-like thinking.

The rest of us know that one of the virtues of C++ is that all that
low level C-style byte twiddling is left to the gurus who implement
the libraries, and we can concentrate on writing clear, expressive,
readable, *type-safe* code and very rarely lose much efficiency. Type
safety is the our friend - it enables the compiler to stop us making
many novice mistakes.

 

[Martijn van Buul]

* Alf P. Steinbach /Usenet:

In modern C++ "memcpy", on its own, just says: this programmer don't even
know about curly braces initializations, or was not able to express the
logical types as C++ types, or...

.... knows his stuff, but happens to be dealing with hardware interfaces,
requiring copying of unstructured data, or has very good reasons why data needs
to be treated as such.

So, that would most likely be a novice.

Sure, *patpat*

Much less likely, I think, but still possible, it could perhaps be an
incompetent or someone forced by a silly coding guideline, or perhaps an MS
engineer[1].

And you're accusing *ME* of ad hominem attacks, after you feel you can get
away by a broad insult. Hmm.

 

[Alf P. Steinbach /Usenet]

* Martijn van Buul, on 15.04.2011 22:08:

* Alf P. Steinbach /Usenet:

In modern C++ "memcpy", on its own, just says: this programmer don't even
know about curly braces initializations, or was not able to express the
logical types as C++ types, or...

... knows his stuff, but happens to be dealing with hardware interfaces,
requiring copying of unstructured data, or has very good reasons why data needs
to be treated as such.

So, that would most likely be a novice.

Sure, *patpat*

Much less likely, I think, but still possible, it could perhaps be an
incompetent or someone forced by a silly coding guideline, or perhaps an MS
engineer[1].

And you're accusing *ME* of ad hominem attacks, after you feel you can get
away by a broad insult. Hmm.

Calling the above, even taken out of original context and placed in a misleading
new context, an ad hominem (personal) attack, is meaningless.

It's like calling a house a banana or apple, or calling a house or a bridge evil
or something.

It doesn't even make sense metaphorically, it's utterly and completely
meaningless, like insane.


Anyway, what I wrote and you misprepresented by snipping context and adding a
new implied one, was,

<<
It's about the same as, in the 1970's, one could say that every "goto" was the
sign of a novice.

Sure, there are situations where it's the right thing to do. And yes, when there
is a "goto" which is at least arguably acceptable, then it was most likely
placed there by a very competent person (since chances of anyone else managing
that feat would be infinitesimal). Then you can weight up other evidence to
counter the evidence that the "goto" gives by itself.

In modern C++ "memcpy", on its own, just says: this programmer don't even know
about curly braces initializations, or was not able to express the logical types
as C++ types, or... So, that would most likely be a novice. Much less likely, I
think, but still possible, it could perhaps be an incompetent or someone forced
by a silly coding guideline, or perhaps an MS engineer[1].

Goodbye.

- Alf

 

[Jorgen Grahn]

.

At the risk of over-simplfication, there are, in my experience two
thought process that lead to memcpy usage:
....
(ii) I remember from a text book that C has a memcpy() function for
copying stuff. C++ is like C, and I want to copy stuff, so I'll use
memcpy(). This is novice-like thinking.

It's a problem in C code too. I have lost count of the times I've
replaced really weird-looking memcpy() calls with plain C struct
assignment.

/Jorgen