Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #3677 > unrolled thread

Simple structure and copying data to pointer of the same structure

Back to article view | Back to comp.lang.c++

Contents

  Simple structure and copying data to pointer of the same structure "A" <a@a.a> - 2011-04-14 17:25 +0200
    Re: Simple structure and copying data to pointer of the same structure cg_chas <cg_chas@hotmail.com> - 2011-04-14 11:38 -0400
      Re: Simple structure and copying data to pointer of the same structure "A" <a@a.a> - 2011-04-14 17:44 +0200
        Re: Simple structure and copying data to pointer of the same structure "A" <a@a.a> - 2011-04-14 17:55 +0200
          Re: Simple structure and copying data to pointer of the same structure cg_chas <cg_chas@hotmail.com> - 2011-04-14 11:57 -0400
          Re: Simple structure and copying data to pointer of the same structure "A" <a@a.a> - 2011-04-14 17:59 +0200
            Re: Simple structure and copying data to pointer of the same structure cg_chas <cg_chas@hotmail.com> - 2011-04-14 12:06 -0400
            Re: Simple structure and copying data to pointer of the same structure "Thomas J. Gritzan" <phygon_antispam@gmx.de> - 2011-04-14 18:09 +0200
            Re: Simple structure and copying data to pointer of the same structure "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-14 18:15 +0200
              Re: Simple structure and copying data to pointer of the same structure Martijn van Buul <pino@dohd.org> - 2011-04-14 16:30 +0000
                Re: Simple structure and copying data to pointer of the same structure "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-14 18:39 +0200
                  Re: Simple structure and copying data to pointer of the same structure Martijn van Buul <pino@dohd.org> - 2011-04-14 17:01 +0000
                    Re: Simple structure and copying data to pointer of the same structure "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-14 19:12 +0200
                      Re: Simple structure and copying data to pointer of the same structure gwowen <gwowen@gmail.com> - 2011-04-14 14:32 -0700
                        Re: Simple structure and copying data to pointer of the same structure "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-14 23:48 +0200
                          Re: Simple structure and copying data to pointer of the same structure gwowen <gwowen@gmail.com> - 2011-04-15 04:23 -0700
                            Re: Simple structure and copying data to pointer of the same structure cg_chas <cg_chas@hotmail.com> - 2011-04-15 09:32 -0400
                              Re: Simple structure and copying data to pointer of the same structure cg_chas <cg_chas@hotmail.com> - 2011-04-15 09:38 -0400
                                Re: Simple structure and copying data to pointer of the same structure "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-15 18:48 +0200
                                  Re: Simple structure and copying data to pointer of the same structure cg_chas <cg_chas@hotmail.com> - 2011-04-15 13:21 -0400
                                    Re: Simple structure and copying data to pointer of the same structure "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-15 19:31 +0200
                              Re: Simple structure and copying data to pointer of the same structure gwowen <gwowen@gmail.com> - 2011-04-15 11:45 -0700
                                Re: Simple structure and copying data to pointer of the same structure Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-04-16 23:07 +0000
                          Re: Simple structure and copying data to pointer of the same structure Martijn van Buul <pino@dohd.org> - 2011-04-15 20:08 +0000
                            Re: Simple structure and copying data to pointer of the same structure "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-15 22:34 +0200
        Re: Simple structure and copying data to pointer of the same structure cg_chas <cg_chas@hotmail.com> - 2011-04-14 11:56 -0400
          Re: Simple structure and copying data to pointer of the same structure "A" <a@a.a> - 2011-04-14 18:02 +0200
            Re: Simple structure and copying data to pointer of the same structure cg_chas <cg_chas@hotmail.com> - 2011-04-14 12:15 -0400
        Re: Simple structure and copying data to pointer of the same structure "Thomas J. Gritzan" <phygon_antispam@gmx.de> - 2011-04-14 18:04 +0200
          Re: Simple structure and copying data to pointer of the same structure "A" <a@a.a> - 2011-04-14 18:15 +0200
            Re: Simple structure and copying data to pointer of the same structure "Thomas J. Gritzan" <phygon_antispam@gmx.de> - 2011-04-14 18:21 +0200
        Re: Simple structure and copying data to pointer of the same structure "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 17:21 +0100
    Re: Simple structure and copying data to pointer of the same structure "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-14 18:10 +0200
    Re: Simple structure and copying data to pointer of the same structure Noah Roberts <dont@email.me> - 2011-04-14 09:31 -0700
      Re: Simple structure and copying data to pointer of the same structure "A" <a@a.a> - 2011-04-14 21:06 +0200
    Re: Simple structure and copying data to pointer of the same structure Goran <goran.pusic@gmail.com> - 2011-04-15 00:05 -0700

Page 2 of 2 — ← Prev page 1 [2]

#3770

* cg_chas, on 15.04.2011 19:21:
> On Fri, 15 Apr 2011 18:48:08 +0200, "Alf P. Steinbach /Usenet"
> <alf.p.steinbach+usenet@gmail.com>  wrote:
>
>> Whoever it is that you're trying to stab in the back, remarks like that place
>> you squarely in the troll category.
> 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.
>
>> The C++ standard refers down to the C standard for such definitions.
> and?
>
>> That's rubbish.
> 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.


-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#3784

On Apr 15, 2:32 pm, cg_chas <cg_c...@hotmail.com> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#3838

On Fri, 2011-04-15, gwowen wrote:
...
> 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

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#3790

* 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.

-- 
Martijn van Buul - pino@dohd.org 

[toc] | [prev] | [next] | [standalone]

#3795

* 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

-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#3682

On Thu, 14 Apr 2011 17:44:32 +0200, "A" <a@a.a> wrote:

>> If your objects are types that perform their own initializationsor have 
>> internal
>> pointers  (which they do not seem to be given the above TWhatever) , then 
>> your
>> struct should also define a copy constructor. (cctor)
>
>I want to avoid having additional constructors within structure itself 
>because structure is allocated thousands of times so additional constructors 
>means additional memory for each of them.
If you do not need constructors, then by all means dont use them. 
>
>So effectively you're saying there is no other way except memcpy or the 
>stuff I just did above right (if we rule out putting a copy constructor to 
>save memory)?
>
Your question appears to be about how to copy POD structs, cctor likely will not
be needed, but the question of whether or not to use the copy constructor is one
of whether or not a simple binary copy is sufficient for your objects.  From
what you've posted, it looks like a binary copy is fine- assuming your posted
example is not from a program that has a more complex object that does other
things.

As far as other ways to copy memory there are plenty. You can construct a vector
from a vector for example:

std::vector <yourType> v1;
yourType yt.
yt.member = 1;
v1.push_back(yt);

std::vector<yourType> v2(v1); // v2 is constructed using v1

hth

[toc] | [prev] | [next] | [standalone]

#3686

> Your question appears to be about how to copy POD structs, cctor likely 
> will not
> be needed, but the question of whether or not to use the copy constructor 
> is one

Yes, but it's not just POD's... in fact, in C++ Builder which I use this 
struct also contains UnicodeString's
But I got no memory leaks so I'm guessing it works with memcpy.... 

[toc] | [prev] | [next] | [standalone]

#3691

On Thu, 14 Apr 2011 18:02:03 +0200, "A" <a@a.a> wrote:

>> Your question appears to be about how to copy POD structs, cctor likely 
>> will not
>> be needed, but the question of whether or not to use the copy constructor 
>> is one
>
>Yes, but it's not just POD's... in fact, in C++ Builder which I use this 
>struct also contains UnicodeString's
>But I got no memory leaks so I'm guessing it works with memcpy.... 
>
I had a feeling that the initial post was a simplification of something more
meaningful.

If you are using any kind of pointers in your object definition, then i would
urge you to use a copy constructor and not use memcpy, but rather some form of
proper iterator-based copy mechanism of STL.

now, within your copy constructor block if you are copying raw bytes to a newly
allocated region, then memcpy might be useful for its "generally
well-implemented" low level efficiency. 

binary POD copies = use memcpy
everything else copies  = use STL
objects with pointers inside or generally anything dynamically allocated  =
needs a cctor

hth

[toc] | [prev] | [next] | [standalone]

#3687

Am 14.04.2011 17:44, schrieb A:
>> If your objects are types that perform their own initializationsor have
>> internal
>> pointers  (which they do not seem to be given the above TWhatever) , then
>> your
>> struct should also define a copy constructor. (cctor)
>
> I want to avoid having additional constructors within structure itself
> because structure is allocated thousands of times so additional constructors
> means additional memory for each of them.

That's wrong. Constructors don't consume any memory in the objects.

> So effectively you're saying there is no other way except memcpy or the
> stuff I just did above right (if we rule out putting a copy constructor to
> save memory)?

You can just assign the object. Don't assign the pointers.

Instead of
    memcpy(pWhatever, &MyVect[0], sizeof(TWhatever));
you can do:
    *pWhatever = MyVect[0];

-- 
Thomas

[toc] | [prev] | [next] | [standalone]

#3693

> Instead of
>    memcpy(pWhatever, &MyVect[0], sizeof(TWhatever));
> you can do:
>    *pWhatever = MyVect[0];

ok, that worked too :)

but it copies data right? it doesn't just change memory pointer points to? 

[toc] | [prev] | [next] | [standalone]

#3694

Am 14.04.2011 18:15, schrieb A:
>> Instead of
>>     memcpy(pWhatever,&MyVect[0], sizeof(TWhatever));
>> you can do:
>>     *pWhatever = MyVect[0];
>
> ok, that worked too :)
>
> but it copies data right? it doesn't just change memory pointer points to?

Yes.

pWhatever = &MyVect[0]; // this assigns the *pointer*
*pWhatever = MyVect[0]; // this assigns the object; i.e. all of its data

-- 
Thomas

[toc] | [prev] | [next] | [standalone]

#3695

"A" <a@a.a> wrote in message news:io74pd$9ru$1@gregory.bnet.hr...
>> If your objects are types that perform their own initializationsor have 
>> internal
>> pointers  (which they do not seem to be given the above TWhatever) , then 
>> your
>> struct should also define a copy constructor. (cctor)
>
> I want to avoid having additional constructors within structure itself 
> because structure is allocated thousands of times so additional 
> constructors means additional memory for each of them.

This is not the case, there will be only 1 constructor even if you have 500 
objects allocated.

struct TWhatever{
 TWhatever():MyInt(0), MyBool(0){}
 TWhatever(const TWhatever& rhs){
  MyInt= rhs.MyInt;
  MyBool= rhs.MyBool;}
 TWhatever& operator=(const TWhatever& rhs){
  MyInt= rhs.MyInt;
  MyBool = rhs.MyBool;
  return *this;}
 ~TWhatever (){}
    int MyInt;
    bool MyBool;
};

struct TWhatever2{
 int MyInt;
 bool MyBool;
};


int main(){
 std::cout<<sizeof(TWhatever) << "\t" << sizeof(TWhatever2);
} 

[toc] | [prev] | [next] | [standalone]

#3690

* A, on 14.04.2011 17:25:
> 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.
>
> So I tried:
> pWhatever =&MyVect[0]; // doesn't seem to work
>
> But this worked:
> pWhatever->MyInt = MyVect[0].MyInt; // works
> pWhatever->MyBool = MyVect[0].MyBool; // also works
>
> The question - can I do it somehow simpler than the last example?

Yes.

   *pWhatever = myVect[0];


> The
> problem is not in last 2 lines but there are 30 or so lines for each
> initialization so something simpler would be much more readable in code.

Define constructors to do initialization.


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#3698

On 4/14/2011 8:25 AM, A wrote:
> 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.
>
> So I tried:
> pWhatever =&MyVect[0]; // doesn't seem to work
>
> But this worked:
> pWhatever->MyInt = MyVect[0].MyInt; // works
> pWhatever->MyBool = MyVect[0].MyBool; // also works

*pWhatever = MpVect[0];

-- 
http://crazycpp.wordpress.com

[toc] | [prev] | [next] | [standalone]

#3717

thank you all for your comments. now i know more about pointers ;) 

[toc] | [prev] | [next] | [standalone]

#3735

On Apr 14, 5:25 pm, "A" <a...@a.a> wrote:
> 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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web