[cmake-developers] dependency scanning speed

Brad King brad.king at kitware.com
Tue Sep 12 14:17:30 EDT 2006


Alexander Neundorf wrote:
> On Monday 11 September 2006 19:24, Tanner Lovelace wrote:
>> On 9/11/06, Alexander Neundorf <neundorf at kde.org> wrote:
>>> Can you please compile and run the attached file with gcc 4.0 and if
>>> possible gcc 4.1 and post the output here ?
>>> Maybe the capacity-behaviour is already "fixed" in current gcc.
>> Actually, I believe it's expected behavior.  Assigning a string to another
>> string doesn't just copy the character contents to it, but also
>> copies all of the internals too.  
> 
> That's what I thought too, and I also had a quick look at the standard, but 
> didn't see anything mentioned.

The standard just specifies the interface and leaves details like this
implementation defined.  When you do

  lhs = rhs; // #1

the implementation is probably using a copy-on-write optimization which
throws out the lhs memory and actually references the rhs data directly.
 When either lhs or rhs is later modified the copy occurs at that point.

When you do

  lhs = rhs.c_str(); // #2

the lhs has to use its own data anyway so the implementation doesn't
bother reallocating.

If you do

  lhs.assign(rhs) // #3

I bet you will get behavior at least as fast as #2 because

  - The specification talks about replacing parts of lhs in this case
  - The length of rhs is already known so no search for '\0' is needed

...but I have not tested it.

-Brad



More information about the cmake-developers mailing list