Some single-letter symbols are already defined on GCC-ARM about units

[nholthaus]

I'm assuming those are macros?

I'll have to think about that. I can sort of replicate the problem with the windows API which defines a _T macro, which originally conflicted with the Tesla definition. There was a reddit comment which had a suggestion for de-conflicting user-defined literals and macros which I can try out.

If that doesn't work I'm personally not opposed to the #undefs. It can be documented, and I tend to think the people who macro-ize their code are not the same people looking for type-safe c++14 libraries.

[nholthaus]

Also, would you mind copy/pasting the original ctype.h definitions into the issue? I can try to define them manually and come up with some unit testing.

[pvaibhav]

To be fair symbols starting with underscore and uppercase letter are reserved by the C++ standard. I expect more clashes on other platforms. We need to find a solution that scales. Personally I would remove the underscore, don't mind writing literals as 12.0V or 13.32mA myself :)

[nholthaus]

Yikes, that was a big oversight on my part. I should have googled it. I think we probably have to do that, but I'll have to rev the version to 3.x since it will break every single piece of code currently using the library.

And then I think if I'm going to change the interface so destructively, I might also move the _t suffix from the unit container types to the unit tag types (and probably change it to _tag as well). It's both annoying, and apparently reserved by POSIX.

[pvaibhav]

I agree, perhaps a quick documentation update is enough for v2.2.x, directing users to #undef any clashing symbols.

[nholthaus]

Yup, I think I'll put out 2.2 as the last release with that interface, and I should be able to roll out a 3.0 relatively quickly.

@martinmoene as a fellow unit conversion aficionado, I'm curious if you have any thoughts on this proposed interface change? It may also be an issue in PhysUnits-CT-Cpp11.

[martinmoene]

PhysUnits-CT-Cpp11 does have the same issue.

Note that UDLs are in namespace units::literals and --apart from macros-- only might clash when using (necessary to use them) and using something else that contains the same name(s).

I'd much like to see this units library evolve into a proposal for C++ standardization. As such it might be written as std::experimental::units, nullifying the issue ;)

[EvanBalster]

So it looks like the developer is already on top of this, but there's a C++14 feature that solves this issue. If there's no space after the quotes in the definition (ex.) operator ""_T, then the macro _T is not expanded. This allows the use of reserved words as literal suffixes.

See here for details: http://en.cppreference.com/w/cpp/language/user_literal (search for "defined-string")

[nholthaus]

@EvanBalster so a few people have made that comment to me, but that's how the library is currently implemented and I've had existential problems when including <Windows.h> with VS2015 and having the macro still clash. Maybe it's just a bug on their end, and maybe gcc-arm isn't fully c++14 compliant?

@pvaibhav so I think in the end I'm actually not going to change the UDLs because there's a requirement that suffixes must begin with an underscore, which kind of ruins our whole idea. Additionally, per @EvanBalster 's comment, UDLs are intended to be able to override underscore + capital letter (at least with a fully conformant c++14 compiler).

I still plan make the documentation update (eventually), and I'll probably change _Te to _T and just warn the user to undef it.

[nholthaus]

This is now going to go into v2.2.0 as a documentation change, which warns about some known #undef statements that will have to be made when compiling with c++11.