Visual C++'s __identifier keyword

[Myriachan]

I think Visual Studio's __identifier keyword is really nice: it allows using keywords as identifiers.  This is useful in interoperability.  For example, if you had this in a .c file:

int class;

You could then do this from a .cpp file to access it:

extern "C" int __identifier(class);

__identifier also may take a literal string as a parameter, allowing weird characters in identifiers.  I would say that the effect of using a literal string that is neither a legal C++ identifier nor a C++ keyword (i.e. something that'd work without being a string) has unspecified behavior, leaving it to the implementation to decide whether such a thing is meaningful or an error.  This literal string feature can be used to access mangled symbol names if used in conjunction with extern "C", or could be used to put dollar signs in identifiers.  And yes, __identifier(__identifier) is legal.


There is actually an interesting secondary use for __identifier: detecting whether a type is native.  For example, this will return true whenever Microsoft gets around to implementing char16_t for real:

class _is_wchar_t_native_helper
{
    struct dummy;
    typedef dummy *__identifier(wchar_t);
    struct inner
    {
        typedef wchar_t direct;
    };
    friend struct is_wchar_t_native;
};

struct is_wchar_t_native
    : std::integral_constant<bool, !std::is_same<
        _is_wchar_t_native_helper::inner::direct,
        _is_wchar_t_native_helper::__identifier(wchar_t)>::value>
{
};

Of course, I wouldn't call it "__identifier".  Maybe _Identifier, if we could get C on board.  Assuming that this proposal isn't hated =)

Melissa

[Thiago Macieira]

On Thursday 30 October 2014 12:52:10 Myriachan wrote:
> extern "C" int __identifier(class);
>
> __identifier also may take a literal string as a parameter, allowing weird
> characters in identifiers. I would say that the effect of using a literal
> string that is neither a legal C++ identifier nor a C++ keyword (i.e.
> something that'd work without being a string) has unspecified behavior,
> leaving it to the implementation to decide whether such a thing is
> meaningful or an error. This literal string feature can be used to access
> mangled symbol names if used in conjunction with extern "C", or could be
> used to put dollar signs in identifiers. And yes,
> __identifier(__identifier) is legal.

How about an identifier containing the closing parenthesis? You probably want
to have this as a string literal.

With GCC:

extern "C" int class_() asm("class");
extern "C" int closingparen() asm("(");

Or, maybe just use the backtick like SQL does:

SELECT `SELECT` FROM `FROM`;

But aside from external names, what use would this have? I'm not sure I
understood your example for wchar_t/char16_t and, to be honest, it's not
relevant because the standard can assume that the implementation fully
implements the standard.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Myriachan]

On Thursday, October 30, 2014 8:14:46 PM UTC-7, Thiago Macieira wrote:

How about an identifier containing the closing parenthesis? You probably want
to have this as a string literal.

With GCC:

extern "C" int class_() asm("class");
extern "C" int closingparen() asm("(");

Visual C++ equivalent, in theory:

extern "C" int __identifier(class)();
extern "C" int __identifier("(")();
 

Or, maybe just use the backtick like SQL does:

SELECT `SELECT` FROM `FROM`;

I actually prefer the MySQL `` style to __identifier =)  (It's implementation-specific, by the way.  Oracle uses double quotes, and Microsoft SQL Server I believe uses square brackets...?)
 

But aside from external names, what use would this have? I'm not sure I
understood your example for wchar_t/char16_t and, to be honest, it's not
relevant because the standard can assume that the implementation fully
implements the standard.

Certainly; it was just a little trick you can do in the Visual C++ style, and isn't something needed in the Standard.  It doesn't work with GCC or Clang's __asm__ because those don't modify the name of the variable, only its object symbol.  It's like creating a legal-identifier alias, whereas MSVC's __identifier actually makes the identifier name be "class" and will show it in error messages that way and such.

Melissa

[Ville Voutilainen]

On 30 October 2014 21:52, Myriachan <myri...@gmail.com> wrote:
> I think Visual Studio's __identifier keyword is really nice: it allows using
> keywords as identifiers. This is useful in interoperability. For example,
> if you had this in a .c file:
>
> int class;
>
> You could then do this from a .cpp file to access it:
>
> extern "C" int __identifier(class);

I don't think the benefit of such a facility outweighs its cost. The use cases
for such obnoxious C code are, I believe, rare.

> There is actually an interesting secondary use for __identifier: detecting
> whether a type is native. For example, this will return true whenever

I think we already have sufficient type traits for that.

> Of course, I wouldn't call it "__identifier". Maybe _Identifier, if we
> could get C on board. Assuming that this proposal isn't hated =)

-1 Hates It.

[Douglas Boffey]

On Friday, 31 October 2014 11:48:16 UTC, Ville Voutilainen wrote:

> could get C on board.  Assuming that this proposal isn't hated =)

-1 Hates It.

Ditto.

[Sean Middleditch]

I don't think it's needed today, but I believe it could be very handy for forward compatibility.

[Daniel Gutson]

There's a use case I hit too often, but goes well beyond this: interoperability with C.
Many times I had to use a C API (specially if it is a low level API) which is not C++ valid. Referring to a hardware device by its "class" is very common (struct class {...}), forcing me to #define class _class before #including the C API headers but still requiring a huge amount of PITAness.
I think that addressing these problems would be very useful, I don't think __identifier would be a nice solution, but in any case it addresses a very small part of it.
Maybe something like #include_c or alike (I'm not even sure it is solvable within the cpp scope only).
Anyway, it's worth to consider.

Daniel.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.