On Sun, Dec 2, 2012 at 1:20 AM, Daniel Jasper <[email protected]> wrote:
> On Fri, Nov 30, 2012 at 11:50 AM, Douglas Gregor <[email protected]> > wrote:>> +/// \brief A character range of source code. > >> +struct CodeRange { > >> + CodeRange(unsigned Offset, unsigned Length) > >> + : Offset(Offset), Length(Length) {} > >> + > >> + unsigned Offset; > >> + unsigned Length; > >> +}; > >> > >> Why isn't this a SourceRange or CharSourceRange? > > > > > > This would put the burden on the client to do the "Offset+Length -> > > SourceRange" translation. But you're right, in this case that might be > the > > right trade-off… > > > > > > This seems like a *very* small burden to eliminate two > > similar-but-not-the-same concepts with disturbingly similar names. It's > > CharSourceRange you want, though. > > Ok, I will remove CodeRange here. The reasoning behind it was that > both SourceRange and CharSourceRange effectively work with > SourceLocations and SourceLocations provide locations based on a > SourceManager. We thought that the library might have users that do > not actually have a SourceManager... By the way - I still expect that we'll need a SourceManager independent representation of code ranges, but the current interface is obviously not SourceManager independent - it even takes a SourceManager and works exactly on one file, so it doesn't make sense to artificially decouple this one piece. Cheers, /Manuel
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
