Re: array -v- array_traits

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-10-26 17:42:57

on 10/26/01 12:48 PM, David Abrahams at david.abrahams_at_[hidden] wrote:

> ----- Original Message -----
> From: "Darin Adler" <darin_at_[hidden]>
> 
> 
>> on 10/26/01 7:55 AM, David Abrahams at david.abrahams_at_[hidden] wrote:
>> 
>>> This demonstrates why using a little bit of name mangling in #include guards
>>> is a good idea. I use my initials and the date, which surely would have
>>> prevented this problem if either author had done it.
>> 
>> While I agree that your discipline would have prevented this, the cause of
>> the problem is that when someone renamed the file from array.hpp to
>> array_traits.hpp they didn't change the contents of the file. So the comment
>> at the top still said array.hpp, and so did these define statements.
> 
> I disagree with your analysis of the cause. With my discipline, there's no
> need to change the contents of the file when it is renamed. Also, since we
> have multiple subdirectories, it's entirely conceivable that this could have
> happened in separate directories where two files may have the same name.

The same name isn't a problem when the full path is used.

For instance, in dlw_gcd.zip, the <boost/math_fwd.hpp> header has:

    BOOST_MATH_FWD_HPP

while <boost/math/common_factor.hpp> has:

    BOOST_MATH_COMMON_FACTOR_HPP

There is a chance of collision between a multi-word header and a nephew
header (like if we had <boost/math_fwd.hpp> and <boost/math/fwd.hpp>).
Hopefully, we won't get pathological cases like that.

Also, the file should have been changed.  A lot of headers include their
name as part of their contents, so the internal name should have changed
when the external one did (as did the docs, right?).

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com