From: Mathias Gaunard on
On 4 sep, 15:38, James Kuyper <jameskuy...(a)verizon.net> wrote:

> I'm only questioning the claim that "it is hard (NP-hard even)" to
> perform such a check; I'm not arguing that it's a good thing to do.

I said it is hard to do alias analysis, which is a static analysis
done at compile-time.

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

From: James Kuyper on
Jens Schmidt wrote:
> James Kuyper schrieb:
>
>> I'm only questioning the claim that "it is hard (NP-hard even)" to
>> perform such a check; I'm not arguing that it's a good thing to do.
>
> I came to the understanding that you are talking about different things.
>
> The NP-hard claim was done for a compile-time check, where the check
> is not even computable in all cases (halting problem equivalent).

The original claim that this could not be done was by Mathias Gaunard in
the message with a Date: header of Sun, 30 Aug 2009 08:44:59 CST. While
he mentioned the lack of static knowledge of the alignment and size, to
me this came across as a non-sequitur, because his claim was not
specifically restricted to a compile-time decision; he simply said
flatly that it couldn't be done at all. To me, it seemed he was ruling
out making the decision at runtime, as well as at compile time.

> For a run-time check this is trivial.

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

From: James Kuyper on
Mathias Gaunard wrote:
> On 4 sep, 15:38, James Kuyper <jameskuy...(a)verizon.net> wrote:
>
>> I'm only questioning the claim that "it is hard (NP-hard even)" to
>> perform such a check; I'm not arguing that it's a good thing to do.
>
> I said it is hard to do alias analysis, which is a static analysis
> done at compile-time.

Yes, but my real point was that it's not obvious why you thought that
alias-checking at compile time was necessary, when pointer comparisons
at runtime were clearly sufficient for the job.

You made a flat claim that it was not possible for std::copy<> to decide
whether to use memcpy() or memmove() - you did not restrict that
assertion to decisions made at compile time.

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

From: Brian Neal on
On Sep 3, 7:10 pm, Brian Neal <bgn...(a)gmail.com> wrote:
> On Aug 30, 9:44 am, Mathias Gaunard <loufo...(a)gmail.com> wrote:
>
> > On 30 ao�t, 01:24, Thomas Maeder <mae...(a)glue.ch> wrote:
>
> > > Just use std::copy and let the library implementation sort out which
> > > optimizations apply.
>
> > std::copy can't even call memcpy since the arguments are not
> > guaranteed not to overlap, at best it can call memmove.
> > It doesn't statically know the alignment and size of memory either, so
> > even if it the arguments were guaranteed not to overlap, it couldn't
> > do better than memcpy anyway.
>
> I've seen a std::copy() turn into a memcpy() call on gcc. And this was
> way back on gcc 2.95. It used template magic to determine it was being
> passed pointers to built in types. I don't recall if it did any
> overlap checking, but it might have.
>

I just checked out the implementation in gcc 4.2.4. There are memmove
() calls all over the place. That's a very nice optimization.

There is a comment in there now (bits/stl_algobase.h) about how they
can't use memcpy because of overlap issues.


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

From: Andrew on
On 28 Aug, 18:52, Sada <steggi...(a)gmail.com> wrote:
> hi how can I improve the performance of a C++ program?
>
> In my program I am using strcmp() strcpy() functions heavily , are
> they costly? if so how can i avoid them??
> Is memcpy() is better than strcpy()?
>
> Please suggest me the factors that affect the performance of a C++
> program.

It really depends on what the program is doing. I worked on some C++
price feeds once where my initial implementation copied the fields
into string variables before doing various things, such as atoi
conversions etc. This was very expensive. A quick gprof analysis
showed the time was being spent in string copying. This is because we
had a dozen or fields per message and thousands of ticks a second. A
bright chap on the team wrote a library with a class he called a
string descriptor. This basically held the char* pointer and the
length. It also provided string compare routines that did a compare in
place. Numeric conversion routines were also provided. This was very
efficient. Perhaps you need something like this.

Regards,

Andrew Marlow

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