This is the mail archive of the
mailing list for the libstdc++ project.
Re: [PATCH v3 headers] variable uglification
- From: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Sun, 19 Sep 2010 11:59:01 +0200
- Subject: Re: [PATCH v3 headers] variable uglification
- References: <20100919082136.GE5435@gmx.de> <4C95D372.email@example.com>
* Paolo Carlini wrote on Sun, Sep 19, 2010 at 11:10:10AM CEST:
> > I noticed that C++ header uglification seems to be a slow manual
> > process. That looks suboptimal, and shouldn't be the case, it
> > should be mostly automatic and quick (in terms of developer time).
> Well, I agree, but it seems to me that the issue normally is rather
> academic because people working on the C++ runtime full time *know from
> the outset* that uglification is required, *never* write first
> un-uglified names and then fix each name in a second pass.
This statement seems to be at odds with several files below include/ext.
For example, include/ext/pb_ds/assoc_container.hpp seems not uglified at
all. Does it maybe not need uglification for some reason, and if so, is
there some rule I'm overlooking for which files don't need it?
> Thus I see
> efforts in this area more as a diagnostic, pre-commit tool for patches
> contributed by accidental contributors, this kind of situation.
> > Who designed C++ classes inside <random> with multiple one-character
> > member names in the API by the way?
> Physicists? ;) I'm rather serious actually, the specifications have been
> largely worked out by physicists at Fermi Lab + Jens Maurer and somehow
> nobody noticed so far. Bad, I agree that can be a problem. I'm afraid
> it's a bit too late to change it but if you really think it can be a
> *serious* problem, you can send a DR to the current LWG Chair, Alisdair
> Meredith (firstname.lastname@example.org). I'll personally take care of following
> its iter at the next Meetings.
Well, not serious, it's rather that it looks at odds with the rest of
the STL which for the most part uses descriptive names.
> > Anyway, I found a couple of instances with the above approach, patch
> > below survived bootstrap and regtest on x86_64-unknown-linux-gnu. OK?
Thanks for the super-fast feedback, committed,