[cfe-commits] [libcxx] r119611 - /libcxx/trunk/include/algorithm

[Howard Hinnant]

On Nov 20, 2010, at 1:01 PM, Chris Lattner wrote:

> 
> On Nov 18, 2010, at 11:53 PM, Chandler Carruth wrote:
> 
>> On Thu, Nov 18, 2010 at 8:18 AM, Howard Hinnant <hhinnant at apple.com> wrote:
>> Ok, if that is the consensus of the community I can easily remove them.  On a previous product this was a customer-requested feature and subsequent feedback on it was positive.
>> 
>> I encourage people to view this question through actual use of the header, as opposed to a svn diff.
>> 
>> I'm actually pretty positive on them, but I wonder if using the (somewhat more annoying to maintain) '//' prefix comments would help avoid confusion? That would provide an ever-present reminder, even in diffs, that this is merely a comment. On the other side, it makes formatting etc more annoying so I understand that it may not be the right tradeoff.
> 
> I agree that it would make it easier to read/know.  On the other hand, /* */ comments have a nice vectorized comment skipper and // don't (and can't reasonably).  It probably isn't measurable, but this means that // comments are slower to lex than /* comments :-)

Some of the headers do have a very long synopsis.  And compile-time performance has always been a high priority.  Though I haven't measured the impact of the synopsis nor the type of comment either.  My best guess is that template instantiation time would dominate.

My assumption is that the client is viewing the header using a code editor that syntax highlights C/C++ comments.  I'll agree that this crowd most often sees the headers as svn diff's in an email (which isn't syntax highlighted and thus far more vulnerable to confusion).  But imho that isn't the intended audience.

Unfortunately "file types" are usually recognized by their suffix (e.g. *.h) and the standard headers don't have a suffix (yet another amazing feature brought to you by design-by-committee ;-)).  I've put the following line as the top line of each header in an attempt to help the editor discover the file type:

// -*- C++ -*-

If anyone knows of a better technique, I'd be happy to apply it.

-Howard