On Mon, Jun 11, 2012 at 6:31 PM, Aaron Wishnick <[email protected]>wrote:
> On Jun 11, 2012, at 9:15 PM, Richard Smith wrote: > > Do we need __LPREFIX() support for anything else? If not, it would seem a > lot simpler to add support for a L__FUNCTION__, which behaves just like > __FUNCTION__ but produces a wide string. > > > MSVC also supports some other predefined expressions, like __FUNCDNAME__, > __FUNCSIG__, etc, so it would be necessary to provide the wide versions of > any of those. > OK, but we don't yet support any of those, and adding the L version at the same time would probably not be a massive undertaking. > Also, though it's undocumented, there are people who know about it and use > it, e.g. see [1] and [2]. Also, my hope for this patch is to increase > compatibility with the MSVC headers, as well as other projects that only > target Microsoft's compiler, and there's the potential for those other > projects to make use of the __LPREFIX extension. > If that's a problem in practice, we could provide a predefined __LPREFIX macro: #define __LPREFIX_impl(x) L ## x #define __LPREFIX(x) __LPREFIX_impl(x) > I agree though, it would be much simpler to add L__FUNCTION__, so I guess > it's up to you where you want to set the bar. > It certainly seems reasonable for us to provide compatibility with constructs which are used in MSVC headers, such as L ## __FUNCTION__. The argument for providing perfect compatibility (to handle situations we've not seen) is weaker.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
