I see what you're saying. I'll get together a patch that implements L__FUNCTION__ and a predefined __LPREFIX macro.
On Jun 12, 2012, at 1:04 AM, Richard Smith wrote: > 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
