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 1 of 2  [1] 2  Next page →

#3677 — Simple structure and copying data to pointer of the same structure

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

[toc] | [next] | [standalone]

#3679

On Thu, 14 Apr 2011 17:25:27 +0200, "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.
>
>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? 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.
>

If I am understanding you correctly and you want to copy objects to a
preallocated region, then you should have a look at memcpy or the standard copy
from <algorithm>.

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)

hth

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

#3680

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

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)?

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

#3681

OK I tried:

memcpy(pWhatever, &MyVect[0], sizeof(TWhatever));

and that seems to work and is simple enough for what I need.
Thanks for your suggestion.

If anyone has anything to add go ahead ;) 

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

#3684

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

>OK I tried:
>
>memcpy(pWhatever, &MyVect[0], sizeof(TWhatever));
yes this is what first came to mind
>
>and that seems to work and is simple enough for what I need.
>Thanks for your suggestion.
np
>
>If anyone has anything to add go ahead ;) 
>

Charles

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

#3685

> memcpy(pWhatever, &MyVect[0], sizeof(TWhatever));

one added question: if the original structure contains dynamically allocated 
stuff like for example std::string

struct TWhatever
    {
    int a;
    bool b;
    std::string c;
    }

will the above memcpy still work without any memory leaks because size of 
the structure is constant.... or the std::string handles that automatically? 

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

#3688

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

>> memcpy(pWhatever, &MyVect[0], sizeof(TWhatever));
>
>one added question: if the original structure contains dynamically allocated 
>stuff like for example std::string
>
>struct TWhatever
>    {
>    int a;
>    bool b;
>    std::string c;
>    }
>
>will the above memcpy still work without any memory leaks because size of 
>the structure is constant.... or the std::string handles that automatically? 
>
As soon as you start adding non-POD types in your object then you should
generally stop using memcpy and start using standard copy from <algorithm>.

STL gives you everything you need in this regard.

Also, as far as the above type goes, you still are not in "needing a cctor"
territory yet.

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

#3689

Am 14.04.2011 17:59, schrieb A:
>> memcpy(pWhatever,&MyVect[0], sizeof(TWhatever));
>
> one added question: if the original structure contains dynamically allocated
> stuff like for example std::string
>
> struct TWhatever
>      {
>      int a;
>      bool b;
>      std::string c;
>      }
>
> will the above memcpy still work without any memory leaks because size of
> the structure is constant.... or the std::string handles that automatically?

No, don't use memcpy with that struct. memcpy only works on POD types, 
that is (basicly, but not fully correct) structs that could be used in a 
C program. Since a std::string is not a POD, the struct that contains a 
std::string also is not a POD.

You can use a simple assignment instead, since the compiler 
automatically generates an assignment operator for you. Example:

TWhatever a,b;
... // initialize b here
a = b;

-- 
Thomas

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

#3692

* A, on 14.04.2011 17:59:
>> memcpy(pWhatever,&MyVect[0], sizeof(TWhatever));
>
> one added question: if the original structure contains dynamically allocated
> stuff like for example std::string
>
> struct TWhatever
>      {
>      int a;
>      bool b;
>      std::string c;
>      }
>
> will the above memcpy still work without any memory leaks because size of
> the structure is constant.... or the std::string handles that automatically?

The memcpy yields Undefined Behavior.

Most likely that some internal buffer will be deallocated twice or more. That 
is, that the code will attempt to do so.

Remember: each occurrence of "memcpy" indicates a novice. So to progress out of 
that category, you have to (temporarily) forget about existence of "memcpy". 
Simply, don't use it  --  and that way you also avoid a lot of bugs.


Cheers & hth.,

- Alf

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

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

#3697

* Alf P. Steinbach /Usenet:
> Remember: each occurrence of "memcpy" indicates a novice.

A statement like that doesn't help. In fact, it shows more about you than
anything else.

Just because *you* are safely hiding in an ivory tower where you don't need
memcpy doesn't mean that people who *do* have a clue are idiots.

-- 
Martijn van Buul - pino@dohd.org 

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

#3699

* Martijn van Buul, on 14.04.2011 18:30:
> * Alf P. Steinbach /Usenet:
>> Remember: each occurrence of "memcpy" indicates a novice.
>
> A statement like that doesn't help.

If the statement does not help you, then just ignore it. No need to tell the 
world that it doesn't help you. It's akin to yelling "i'm a super programmer who 
is not helped by simple advice like that" -- nobody believes it...


> In fact, it shows more about you than anything else.

What do you think it shows?


> Just because *you* are safely hiding in an ivory tower where you don't need
> memcpy

I'm not hiding, I'm not in an ivory tower, and it's not the case that I never 
need memcpy.

Why this hostility & lying?


> doesn't mean that people who *do* have a clue are idiots.

Why do you think that "people who do have a clue are idiots"?


Puzzled,

- Alf

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

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

#3704

* Alf P. Steinbach /Usenet:
> * Martijn van Buul, on 14.04.2011 18:30:
>> * Alf P. Steinbach /Usenet:
>>> Remember: each occurrence of "memcpy" indicates a novice.
> I'm not hiding, I'm not in an ivory tower, and it's not the case that I never 
> need memcpy.

Ah, so it's "Each occurrence of memcpy indicates a novice unless it's me" ?

-- 
Martijn van Buul - pino@dohd.org 

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

#3706

* Martijn van Buul, on 14.04.2011 19:01:
> * Alf P. Steinbach /Usenet:
>> * Martijn van Buul, on 14.04.2011 18:30:
>>> * Alf P. Steinbach /Usenet:
>>>> Remember: each occurrence of "memcpy" indicates a novice.
>> I'm not hiding, I'm not in an ivory tower, and it's not the case that I never
>> need memcpy.
>
> Ah, so it's "Each occurrence of memcpy indicates a novice unless it's me" ?

No, it's just as I wrote.

If you find that sentence inordinately difficult to understand, then just ask 
about it.

For my part, I admit that I failed to guess that your out of the blue ad hominem 
attack, could be really just a conversation opener, preparing you for asking 
your so-extremely-hard-to-ask question (whatever it is)?


- Alf

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

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

#3722

On Apr 14, 6:12 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> > Ah, so it's "Each occurrence of memcpy indicates a novice unless it's me" ?
>
> No, it's just as I wrote.
>
> If you find that sentence inordinately difficult to understand, then just ask
> about it.

To be honest Alf, I find most of your posts an enlightening breath of
sanity, but I'm not altogether sure what you mean about memcpy being
the sign of a novice. Using memcpy *wrongly*, or a using it a lot is
the sign of a novice, sure but ... anyway, I miss your point.

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

#3723

* gwowen, on 14.04.2011 23:32:
> On Apr 14, 6:12 pm, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...@gmail.com>  wrote:
>>> Ah, so it's "Each occurrence of memcpy indicates a novice unless it's me" ?
>>
>> No, it's just as I wrote.
>>
>> If you find that sentence inordinately difficult to understand, then just ask
>> about it.
>
> To be honest Alf, I find most of your posts an enlightening breath of
> sanity, but I'm not altogether sure what you mean about memcpy being
> the sign of a novice. Using memcpy *wrongly*, or a using it a lot is
> the sign of a novice, sure but ... anyway, I miss your point.

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


Cheers & hth.,

- Alf

Notes:
[1] Hey, that's just trolling. ;-)

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

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

#3740

On Apr 14, 10:48 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:

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

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

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

#3752

On Fri, 15 Apr 2011 04:23:30 -0700 (PDT), gwowen <gwowen@gmail.com> wrote:

>On Apr 14, 10:48 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
>+use...@gmail.com> wrote:
>
>> 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.
>
>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

You're response to the original as well as follow-up broad and unfounded opinons
raises some very noteworthy points.

Starting with UB which should always be a concern for a novice programmers and
gurus alike.

Using memcpy effectively and safely does require some intimate familiarity with
your compiler since the function is purely implementation-defined rather than
defined by the Standard.

While the Standard (apparently to some, a work of "novices") does willfully
acknowledge the memcpy function with quite a few examples in the context of POD
types (3.9/1),  It does not define the behavior of memcpy itself.  To do so is
not possible for several reasons such as aligment issues. (3.9/5).  By
definition or lack thereof, using memcpy is undefined by the Standard. 

A more reasonable statement that excludes the potential for mis-labelling a
programmer is "The use of memcpy by lack of C++ Standard definition is always
going to yield  "undefined behavior" in C++ programs." This indeed is the
greater point. 

That being said, what the Standard does do is define POD very well.  In addition
there are other definitions with regards to POD and in the context of POD. Since
presumably most programmers know what POD is (more likely than not, anway), then
it can reasonably be said that one of the primary preconditions for using memcpy
have been met if they are applying its use to POD.

Now to your response.  Does using memcpy() really imply "novice" or "guru"? 
I still think statements like these are broad and unfounded opinions.  

If you use memcpy with a POD type instead of a C++ or more well-defined function
with awareness of your platform and compiler's description of how memcpy works,
then it might be true that you are seeking some performance gain.  Not to say
that memcpy is always faster as it may be slower on some platforms and not to
say that there are no other cases where memcpy might be useful, because there
are.

To the novices and all non-gurus alike.  If you cannot assess the assembly
functions that your implementation of memcpy may be using with regards to the
processor in the target machine and your compiler's capability for code
optimization, then just run a few simple benchmarks.  You do not need to be a
guru to do this. If memcpy or similar function from your platform's C library
does what you need it to (such as for the case of a desirable performance gain),
then you certainly are not a novice simply for choosing memcpy.

hth.

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

#3757

On Fri, 15 Apr 2011 09:32:52 -0400, cg_chas <cg_chas@hotmail.com> wrote:

>On Fri, 15 Apr 2011 04:23:30 -0700 (PDT), gwowen <gwowen@gmail.com> wrote:
>
>>On Apr 14, 10:48 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
>>+use...@gmail.com> wrote:
>>
>>> 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.
>>
>>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
>
>You're response to the original as well as follow-up broad and unfounded opinons
>raises some very noteworthy points.
>
>Starting with UB which should always be a concern for a novice programmers and
>gurus alike.
>
>Using memcpy effectively and safely does require some intimate familiarity with
>your compiler since the function is purely implementation-defined rather than
>defined by the Standard.
>
>While the Standard (apparently to some, a work of "novices") does willfully
>acknowledge the memcpy function with quite a few examples in the context of POD
>types (3.9/1),  It does not define the behavior of memcpy itself.  To do so is
>not possible for several reasons such as aligment issues. (3.9/5).  By
>definition or lack thereof, using memcpy is undefined by the Standard. 
>
>A more reasonable statement that excludes the potential for mis-labelling a
>programmer is "The use of memcpy by lack of C++ Standard definition is always
>going to yield  "undefined behavior" in C++ programs." This indeed is the
>greater point. 
>
>That being said, what the Standard does do is define POD very well.  In addition
>there are other definitions with regards to POD and in the context of POD. Since
>presumably most programmers know what POD is (more likely than not, anway), then
>it can reasonably be said that one of the primary preconditions for using memcpy
>have been met if they are applying its use to POD.
>
>Now to your response.  Does using memcpy() really imply "novice" or "guru"? 
>I still think statements like these are broad and unfounded opinions.  
>
>If you use memcpy with a POD type instead of a C++ or more well-defined function
>with awareness of your platform and compiler's description of how memcpy works,
>then it might be true that you are seeking some performance gain.  Not to say
>that memcpy is always faster as it may be slower on some platforms and not to
>say that there are no other cases where memcpy might be useful, because there
>are.
>
>To the novices and all non-gurus alike.  If you cannot assess the assembly
>functions that your implementation of memcpy may be using with regards to the
>processor in the target machine and your compiler's capability for code
>optimization, then just run a few simple benchmarks.  You do not need to be a
>guru to do this. If memcpy or similar function from your platform's C library
>does what you need it to (such as for the case of a desirable performance gain),
>then you certainly are not a novice simply for choosing memcpy.
Conversely, using memcpy successfully does not make you a guru either.
>
>hth.

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

#3766

* cg_chas, on 15.04.2011 15:38:
>>
>> While the Standard (apparently to some, a work of "novices")

Whoever it is that you're trying to stab in the back, remarks like that place 
you squarely in the troll category.


>> does willfully
>> acknowledge the memcpy function with quite a few examples in the context of POD
>> types (3.9/1),  It does not define the behavior of memcpy itself.

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


>  To do so is
>> not possible for several reasons such as aligment issues. (3.9/5).  By
>> definition or lack thereof, using memcpy is undefined by the Standard.

That's rubbish.


- Alf

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

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

#3768

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web