Prev: ON_BLOCK_EXIT and e.g. C4189
Next: operator== for aggregate types / member wise comparison
From: Yongwei Wu on 10 Sep 2009 05:55
On Sep 7, 3:03 pm, Florian Weimer <f...(a)deneb.enyo.de> wrote:
> * Mathias Gaunard:
>
> > std::copy can't even call memcpy since the arguments are not
> > guaranteed not to overlap, at best it can call memmove.
>
> std::copy is undefined in this case (at least in C++98), so it's
> perfectly fine to call memcpy.

No. The copying order in std::copy is strictly defined (from first to
last), while that of memcpy is UNdefined. std::copy requires that
"the ranges [first,last) and [result,result + (last - first)) shall
not overlap". memcpy only specifies: "If copying takes place between
objects that overlap, the behavior is undefined." So an
implementation is allowed to copy from the last byte to the first byte
in the case of memcpy.

Best regards,

Yongwei


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: peter koch on 10 Sep 2009 17:26
On 10 Sep., 22:55, Yongwei Wu <wuyong...(a)gmail.com> wrote:
> On Sep 7, 3:03 pm, Florian Weimer <f...(a)deneb.enyo.de> wrote:
>
> > * Mathias Gaunard:
>
> > > std::copy can't even call memcpy since the arguments are not
> > > guaranteed not to overlap, at best it can call memmove.
>
> > std::copy is undefined in this case (at least in C++98), so it's
> > perfectly fine to call memcpy.
>
> No. The copying order in std::copy is strictly defined (from first to
> last), while that of memcpy is UNdefined. std::copy requires that
> "the ranges [first,last) and [result,result + (last - first)) shall
> not overlap". memcpy only specifies: "If copying takes place between
> objects that overlap, the behavior is undefined." So an
> implementation is allowed to copy from the last byte to the first byte
> in the case of memcpy.

You are overlooking the fact that the ones who wrote the C++ compiler
most likely are the ones that implemented memcpy.
Compiler writers are allowed to exploit the knowledge of their
environment and usually do so.

/Peter


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Lasse Reichstein Nielsen on 12 Sep 2009 01:13
James Kuyper <jameskuyper(a)verizon.net> writes:

> Mathias Gaunard wrote:

>> The compiler could do it, by doing alias analysis, which is a hard (NP-
>> hard even) problem -- which is why you can't rely on the compiler
>> doing it -- but a function certainly cannot.
>
> NP is an abbreviation used in complexity theory for "nondeterministic
> polynomial time", where the polynomial in question is a polynomial in
> 'n', where 'n' is some measure of the size of the problem, which gives
> the amount of time it takes to verify that the solution to the problem
> is correct. NP problems are not necessarily hard to solve; the category
> includes some of the very easiest problems to solve. I think what you
> actually mean is NP-complete, which is the sub-set of NP problems for
> which no polynomial-time solution is known. Those are very hard
> problems, at least when 'n' is large.

He actually said "NP hard", which is the class of problems that are
"at least NP complete", i.e., problems that NP complete problems
reduce to. These problems may not even be in NP, but they can be no
easier than NP complete problems.

/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: James Kuyper on 13 Sep 2009 05:16
Lasse Reichstein Nielsen wrote:
....
> He actually said "NP hard", which is the class of problems that are
> "at least NP complete",


You're running a little late; we resolved my confusion on that issue
nearly a week ago.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Seungbeom Kim on 17 Sep 2009 01:04
Yongwei Wu wrote:
>
> std::copy requires that
> "the ranges [first,last) and [result,result + (last - first)) shall
> not overlap".

It doesn't say so; all it says is that "result shall not be in the
range [first, last)", which prohibits only one of the two ways how
overlapping can occur. In particular, it allows a call such as
std::copy(first + 1, last, first).

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: ON_BLOCK_EXIT and e.g. C4189
Next: operator== for aggregate types / member wise comparison