Re: [chromium-dev] C++11 Feature Proposal: __func__

[Rob Percival]

+cxx

On Monday, June 27, 2016 at 9:37:06 PM UTC+1, Scott Graham wrote:

Extensive testing* suggests this is probably fine for Windows now that we're on 2015.

* Not-actually-extensive:

d:\src\x>type a.cc && cl /W4 /wd 4577 /wd4530 /Bv /nologo a.cc && a

#include <stdio.h>

int main() {

  const char* x = __func__;

  printf("__func__: %s\n", x);

}

Compiler Passes:

 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86\cl.exe:        Version 19.00.23918.0

 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86\c1.dll:        Version 19.00.23918.0

 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86\c1xx.dll:      Version 19.00.23918.0

 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86\c2.dll:        Version 19.00.23918.0

 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86\link.exe:      Version 14.00.23918.0

 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\mspdb140.dll:      Version 14.00.23918.0

 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86\1033\clui.dll: Version 19.00.23918.0

a.cc

__func__: main

On Mon, Jun 27, 2016 at 1:27 PM, Rob Percival <robpe...@google.com> wrote:

Should this now be moved off of the banned list?

On Thursday, 25 September 2014 01:44:55 UTC+1, Peter Kasting wrote:

On Wed, Sep 24, 2014 at 4:52 PM, Peter Kasting <pkas...@google.com> wrote:

On Wed, Sep 24, 2014 at 4:43 PM, Scott Graham <sco...@chromium.org> wrote:

a.cc(3) : error C2065: '__func__' : undeclared identifier

So, -1 for now.

Yeah, I agree.  Let's put this on the banned list with a note about MSVC not supporting it.

I'd like to reconsider if/when support becomes available.

Note: According to http://blogs.msdn.com/b/vcblog/archive/2013/12/02/c-11-14-core-language-features-in-vs-2013-and-the-nov-2013-ctp.aspx , the Nov 2013 CTP supports __func__, which means I suspect support will be present in the next major MSVC version.

PK

[Jeremy Roman]

I don't see any reason to leave this banned at the styleguide level (and I'm fine LGTM-ing a CL that used it and changed the styleguide rule), though it's worth noting that we seem to use __PRETTY_FUNCTION__ (which has the class name and parameters, unlike __func__/__FUNCTION__) in many places, and __func__ is only a drop-in replacement for __FUNCTION__.

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/cb8f4e30-b5ee-4fd1-a396-b634ad13bc29%40chromium.org.

[Peter Kasting]

To keep this thread in the loop: I have a CL to make this change at https://codereview.chromium.org/2161193003/ .  This is currently stalled because we've confirmed that the linux_android_rel_ng build environment is non-standards-compliant; it treats __func__ like __PRETTY_FUNCTION__ instead of __FUNCTION__ and causes test failures if we switch.  I'm working with some toolchain folks to see what the right thing to do here is.

PK

[Peter Kasting]

Thanks to Primiano Tucci and various others, the Android toolchain has been fixed and the CL here has landed.

PK