C++11 Feature Proposal: __func__

[Peter Kasting]

What: __func__ is a C99ism added to C++11 that is a local string variable whose contents are the name of the current function.

Why: We use __FUNCTION__ in various logging macros for this purpose, which is technically an extension that multiple compilers support.  __func__ provides a standard-compliant way to do this.

Detail: I propose we simply replace __FUNCTION__ with __func__ everywhere.

PK

[Reid Kleckner]

A quick test with MSVC shows that this is not supported:

# func.cpp

const char *f() { return __func__; }

# compile with cl.exe from depot_tools

func.cpp(1) : error C2065: '__func__' : undeclared identifier

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Scott Graham]

d:\src\x>type a.cc

#include <stdio.h>

void Wee() {

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

}

d:\src\x>cl a.cc

Microsoft (R) C/C++ Optimizing Compiler Version 18.00.30723 for x86

Copyright (C) Microsoft Corporation.  All rights reserved.

a.cc

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

So, -1 for now.

On Wed, Sep 24, 2014 at 4:37 PM, 'Peter Kasting' via Chromium-dev <chromi...@chromium.org> wrote:

--

[Victor Khimenko]

What's the benefit? If __FUNCTION__ is supported then it's more efficient that __func__ (since __func__ is not a macro but variable one could not use to form longer text strings) and if it's supported on all compilers we care about... I just don't see the point.

[Peter Kasting]

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.  To Victor's question, using standards-compliant mechanisms is more portable in case we begin bringing up a new compiler (as we did with Clang, and are now doing with Clang-on-Windows), and I think using real, typed variables in place of macros where possible is just good practice in general -- you can see them in the debugger, the compiler can catch more type errors, etc.  For __func__ these aren't huge deals, but I still would like to consider them later.

PK

[Peter Kasting]

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

[Rob Percival]

Should this now be moved off of the banned list?

[Scott Graham]

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

[Rob Percival]

+cxx

[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