Answers:
Boost字符串算法：
#include <boost/algorithm/string.hpp>
#include <string>
std::string str = "Hello World";
boost::to_upper(str);
std::string newstr = boost::to_upper_copy<std::string>("Hello World");std::string newstr(boost::to_upper_copy<std::string>("Hello World"));
#include <algorithm>
#include <string>
std::string str = "Hello World";
std::transform(str.begin(), str.end(),str.begin(), ::toupper);toupper()可以实现为宏。这可能会引起问题。
toupper。有任何想法吗？
使用C ++ 11和toupper（）的简短解决方案。
for (auto & c: str) c = toupper(c);c是const char类型（来自auto）吗？如果是这样，则不能（由于const部分原因）将其分配给所返回的值toupper(c)。
c需要unsigned char对此进行校正。
struct convert {
void operator()(char& c) { c = toupper((unsigned char)c); }
};
// ...
string uc_str;
for_each(uc_str.begin(), uc_str.end(), convert());注意：最佳解决方案有两个问题：
21.5空终止的序列实用程序
这些标头的内容应与标准C库标头<ctype.h>，<wctype.h>，<string.h>，<wchar.h>和<stdlib.h>相同。[...]
这意味着cctype成员很可能是不适合在标准算法中直接使用的宏。
同一示例的另一个问题是，它不会强制转换参数或验证其是否为非负数。这对于使用普通char签名的系统尤其危险。（原因是：如果将其实现为宏，则可能会使用查找表并将您的参数索引到该表中。负索引将给您UB。）
对于ASCII字符集，SIMD可以解决此问题。
-O3 -march=native在Core2Duo（Merom）上使用x86-64 gcc 5.2 进行的初步测试。相同的120个字符的字符串（混合的小写字母和非小写ASCII）在循环中转换了40M次（没有跨文件内联，因此编译器无法优化或提升其中的任何一个）。源缓冲区和目标缓冲区相同，因此没有malloc开销或内存/缓存影响：数据一直在L1缓存中处于高温状态，而我们纯粹是受CPU限制的。
boost::to_upper_copy<char*, std::string>()： 198.0秒。是的，Ubuntu 15.10上的Boost 1.58确实很慢。我在调试器中对asm进行了概要分析并单步执行，这确实非常糟糕：每个字符都有一个dynamic_cast的语言环境变量！！！（dynamic_cast需要多次调用strcmp）。LANG=C和一起发生这种情况LANG=en_CA.UTF-8。
我没有使用除std :: string之外的RangeT进行测试。 也许的其他形式to_upper_copy提供更优更好，但我认为它会永远new/ malloc在复制空间，所以它很难测试。也许我所做的事情与正常的用例有所不同，也许正常停止的g ++可以将语言环境设置的内容从每个字符循环中提升出来。我的循环从a读取std::string并写入到a char dstbuf[4096]对于测试很有意义。
循环调用glibc toupper：6.67秒 （不过，不检查int潜在的多字节UTF-8 的结果。这对于土耳其语很重要。）
cmov，无论如何该表在L1中都很热。另请参阅有关toupper()在设置区域设置时在Windows上运行缓慢的问题。
我感到震惊的是，Boost比其他选项慢一个数量级。我仔细检查了我是否-O3启用了该功能，甚至单步检查了组件的运行状况。与clang ++ 3.8几乎完全相同的速度。每个字符循环内部都有巨大的开销。的perf record/ report结果（对于cyclesPERF事件）为：
32.87% flipcase-clang- libstdc++.so.6.0.21 [.] _ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastElNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16
21.90% flipcase-clang- libstdc++.so.6.0.21 [.] __dynamic_cast
16.06% flipcase-clang- libc-2.21.so [.] __GI___strcmp_ssse3
8.16% flipcase-clang- libstdc++.so.6.0.21 [.] _ZSt9use_facetISt5ctypeIcEERKT_RKSt6locale
7.84% flipcase-clang- flipcase-clang-boost [.] _Z16strtoupper_boostPcRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
2.20% flipcase-clang- libstdc++.so.6.0.21 [.] strcmp@plt
2.15% flipcase-clang- libstdc++.so.6.0.21 [.] __dynamic_cast@plt
2.14% flipcase-clang- libstdc++.so.6.0.21 [.] _ZNKSt6locale2id5_M_idEv
2.11% flipcase-clang- libstdc++.so.6.0.21 [.] _ZNKSt6locale2id5_M_idEv@plt
2.08% flipcase-clang- libstdc++.so.6.0.21 [.] _ZNKSt5ctypeIcE10do_toupperEc
2.03% flipcase-clang- flipcase-clang-boost [.] _ZSt9use_facetISt5ctypeIcEERKT_RKSt6locale@plt
0.08% ...只有在循环之前知道迭代计数时，Gcc和clang才会自动对循环进行矢量化。（即，像普通C实现那样的搜索循环strlen不会自动矢量化。）
因此，对于足够小的字符串以适合高速缓存的字符串，从strlen第一次执行开始，我们将获得大约128个字符的字符串的显着加速。对于显式长度的字符串（例如C ++ std::string），这将不是必需的。
// char, not int, is essential: otherwise gcc unpacks to vectors of int! Huge slowdown.
char ascii_toupper_char(char c) {
return ('a' <= c && c <= 'z') ? c^0x20 : c; // ^ autovectorizes to PXOR: runs on more ports than paddb
}
// gcc can only auto-vectorize loops when the number of iterations is known before the first iteration. strlen gives us that
size_t strtoupper_autovec(char *dst, const char *src) {
size_t len = strlen(src);
for (size_t i=0 ; i<len ; ++i) {
dst[i] = ascii_toupper_char(src[i]); // gcc does the vector range check with psubusb / pcmpeqb instead of pcmpgtb
}
return len;
}任何体面的libc都将具有strlen比一次循环一个字节快得多的效率，因此单独的矢量化strlen和toupper循环会更快。
基线：一个循环，用于动态检查终止0。
在Core2（Merom）2.4GHz上进行40M迭代的时间。gcc 5.2 -O3 -march=native。（Ubuntu 15.10）。 dst != src（因此我们制作了副本），但它们没有重叠（并且不在附近）。两者都对齐。
对于clang，某些结果有些不同。
调用该函数的微基准循环位于一个单独的文件中。否则，它会内联并strlen()从循环中吊起，并且运行速度会大大加快，尤其是。为16个字符字符串（0.187s）。
gcc的主要优点是可以对任何体系结构将其自动矢量化，但是主要缺点是，在通常的小字符串情况下，它要慢一些。
因此，可以大大提高速度，但是编译器自动向量化并不能产生出色的代码，尤其是。用于清理最后15个字符。
基于我的case-flip函数，该函数可以反转每个字母字符的大小写。它利用了“无符号比较技巧”，在这里您可以low < a && a <= high通过范围移动来进行单个无符号比较，这样，小于的任何值都会low换成大于的值high。（如果相隔不远low，high则此方法有效。）
SSE只有一个带符号的比较器更大，但是我们仍然可以通过将范围移动到带符号的范围的底部来使用“无符号比较”技巧：减去“ a” +128，因此字母字符的范围从-128到-128 +25（-128 +'z'-'a'）
请注意，对于8位整数，加128和减128是相同的。进位无处可去，所以它只是异或（无进位加法），翻转高位。
#include <immintrin.h>
__m128i upcase_si128(__m128i src) {
// The above 2 paragraphs were comments here
__m128i rangeshift = _mm_sub_epi8(src, _mm_set1_epi8('a'+128));
__m128i nomodify = _mm_cmpgt_epi8(rangeshift, _mm_set1_epi8(-128 + 25)); // 0:lower case -1:anything else (upper case or non-alphabetic). 25 = 'z' - 'a'
__m128i flip = _mm_andnot_si128(nomodify, _mm_set1_epi8(0x20)); // 0x20:lcase 0:non-lcase
// just mask the XOR-mask so elements are XORed with 0 instead of 0x20
return _mm_xor_si128(src, flip);
// it's easier to xor with 0x20 or 0 than to AND with ~0x20 or 0xFF
}给定此函数可用于一个向量，我们可以在循环中调用它以处理整个字符串。由于我们已经针对SSE2，因此我们可以同时进行向量化的字符串结尾检查。
在执行16B向量后，我们还可以对剩余的最后15个字节的“清理”做得更好：上框是幂等的，因此重新处理一些输入字节就可以了。我们对源的最后16B进行未对齐的加载，并将其存储到与循环中最后16B的存储重叠的dest缓冲区中。
唯一不起作用的时间是整个字符串都在16B以下：即使当时dst=src，非原子读取-修改-写入也不是完全不涉及某些字节的事情，并且可能破坏多线程代码。
为此，我们有一个标量循环，也可以使其src对齐。由于我们不知道终止0的位置，因此来自的未对齐负载src可能会进入下一页并出现段错误。如果我们在对齐的16B块中需要任何字节，则加载整个对齐的16B块始终是安全的。
全文：在github gist中。
// FIXME: doesn't always copy the terminating 0.
// microbenchmarks are for this version of the code (with _mm_store in the loop, instead of storeu, for Merom).
size_t strtoupper_sse2(char *dst, const char *src_begin) {
const char *src = src_begin;
// scalar until the src pointer is aligned
while ( (0xf & (uintptr_t)src) && *src ) {
*(dst++) = ascii_toupper(*(src++));
}
if (!*src)
return src - src_begin;
// current position (p) is now 16B-aligned, and we're not at the end
int zero_positions;
do {
__m128i sv = _mm_load_si128( (const __m128i*)src );
// TODO: SSE4.2 PCMPISTRI or PCMPISTRM version to combine the lower-case and '\0' detection?
__m128i nullcheck = _mm_cmpeq_epi8(_mm_setzero_si128(), sv);
zero_positions = _mm_movemask_epi8(nullcheck);
// TODO: unroll so the null-byte check takes less overhead
if (zero_positions)
break;
__m128i upcased = upcase_si128(sv); // doing this before the loop break lets gcc realize that the constants are still in registers for the unaligned cleanup version. But it leads to more wasted insns in the early-out case
_mm_storeu_si128((__m128i*)dst, upcased);
//_mm_store_si128((__m128i*)dst, upcased); // for testing on CPUs where storeu is slow
src += 16;
dst += 16;
} while(1);
// handle the last few bytes. Options: scalar loop, masked store, or unaligned 16B.
// rewriting some bytes beyond the end of the string would be easy,
// but doing a non-atomic read-modify-write outside of the string is not safe.
// Upcasing is idempotent, so unaligned potentially-overlapping is a good option.
unsigned int cleanup_bytes = ffs(zero_positions) - 1; // excluding the trailing null
const char* last_byte = src + cleanup_bytes; // points at the terminating '\0'
// FIXME: copy the terminating 0 when we end at an aligned vector boundary
// optionally special-case cleanup_bytes == 15: final aligned vector can be used.
if (cleanup_bytes > 0) {
if (last_byte - src_begin >= 16) {
// if src==dest, this load overlaps with the last store: store-forwarding stall. Hopefully OOO execution hides it
__m128i sv = _mm_loadu_si128( (const __m128i*)(last_byte-15) ); // includes the \0
_mm_storeu_si128((__m128i*)(dst + cleanup_bytes - 15), upcase_si128(sv));
} else {
// whole string less than 16B
// if this is common, try 64b or even 32b cleanup with movq / movd and upcase_si128
#if 1
for (unsigned int i = 0 ; i <= cleanup_bytes ; ++i) {
dst[i] = ascii_toupper(src[i]);
}
#else
// gcc stupidly auto-vectorizes this, resulting in huge code bloat, but no measurable slowdown because it never runs
for (int i = cleanup_bytes - 1 ; i >= 0 ; --i) {
dst[i] = ascii_toupper(src[i]);
}
#endif
}
}
return last_byte - src_begin;
}在Core2（Merom）2.4GHz上进行40M迭代的时间。gcc 5.2 -O3 -march=native。（Ubuntu 15.10）。 dst != src（因此我们制作了副本），但它们没有重叠（并且不在附近）。两者都对齐。
（实际上_mm_store是在循环中定时，不是_mm_storeu，因为即使地址对齐，在Merom上storeu也会变慢。在Nehalem和更高版本上都很好。我现在还是按原样保留代码，而不是解决无法复制的问题在某些情况下以0结尾，因为我不想重新计时所有时间。）
因此，对于长度超过16B的短字符串，这比自动矢量化要快得多。长度小于向量宽度不存在问题。在原地操作时，它们可能会成为问题，因为存储转发停滞。（但是请注意，处理我们自己的输出而不是原始输入还是可以的，因为toupper是幂等的）。
根据周围代码的需求以及目标微体系结构，有很多范围可以针对不同的用例进行调整。让编译器为清理部分发出漂亮的代码是棘手的。使用ffs(3)（在x86上编译为bsf或tzcnt）使用似乎不错，但显然，该位需要重新考虑，因为我在编写了大部分答案后发现一个错误（请参阅FIXME注释）。
可以通过movq或movd加载/存储来获得甚至更小的字符串的矢量加速。根据您的用例进行定制。
我们可以检测到向量何时具有设置了高位的任何字节，在这种情况下，可以回退到该向量的标量utf-8感知循环。该dst点的前进量可以与src指针的前进量不同，但是一旦返回对齐的src指针，我们仍然只是将未对齐的向量存储到dst。
对于UTF-8，但主要由UTF-8的ASCII子集组成的文本，这可能很好：通常情况下具有高性能，并且在所有情况下均具有正确的行为。但是，当存在大量非ASCII字符时，它可能比一直保持在标量UTF-8感知循环中更糟糕。
如果不利之处很严重，那么以牺牲其他语言为代价来提高英语速度并不是一个面向未来的决定。
在土耳其语区域设置（tr_TR）中，来自的正确结果toupper('i')是'İ'（U0130），而不是'I'（纯ASCII）。请参阅Martin Bonnertolower()关于Windows速度慢的问题的评论。
我们还可以检查一个例外列表并在那里回退到标量，例如多字节UTF8输入字符。
由于存在如此多的复杂性，SSE4.2 PCMPISTRM或某些功能也许可以一次完成很多检查。
字符串中是否包含ASCII或国际字符？
如果是后一种情况，“大写”并不是那么简单，它取决于所使用的字母。有两院制和一院制的字母表。只有双头字母具有大小写不同的字符。另外，还有一些复合字符，如拉丁大写字母“DZ”（\ u01F1“DZ”），它采用所谓的首字母大写。这意味着仅第一个字符（D）被更改。
我建议您研究ICU以及简单案例映射和完整案例映射之间的区别。这可能会有所帮助：
string StringToUpper(string strToConvert)
{
for (std::string::iterator p = strToConvert.begin(); strToConvert.end() != p; ++p)
*p = toupper(*p);
return p;
}要么，
string StringToUpper(string strToConvert)
{
std::transform(strToConvert.begin(), strToConvert.end(), strToConvert.begin(), ::toupper);
return strToConvert;
}**第一个解的参数后的星星会做什么？
**是尝试在代码语法中使用粗体字留下的错字。
toupper用负数调用时，此代码将调用未定义的行为。
以下对我有用。
#include <algorithm>
void toUpperCase(std::string& str)
{
std::transform(str.begin(), str.end(), str.begin(), ::toupper);
}
int main()
{
std::string str = "hello";
toUpperCase(&str);
}toupper用负数调用时，此代码将调用未定义的行为。
使用lambda。
std::string s("change my case");
auto to_upper = [] (char_t ch) { return std::use_facet<std::ctype<char_t>>(std::locale()).toupper(ch); };
std::transform(s.begin(), s.end(), s.begin(), to_upper);如果仅使用ASCII字符，则速度更快：
for(i=0;str[i]!=0;i++)
if(str[i]<='z' && str[i]>='a')
str[i]-=32;请注意，此代码运行速度更快，但仅适用于ASCII，而不是“抽象”解决方案。
如果您需要UNICODE解决方案或更常规的抽象解决方案，请寻求其他答案并使用C ++字符串方法。
C++，但是您C在此处写了一个答案。（我不是
'？
//works for ASCII -- no clear advantage over what is already posted...
std::string toupper(const std::string & s)
{
std::string ret(s.size(), char());
for(unsigned int i = 0; i < s.size(); ++i)
ret[i] = (s[i] <= 'z' && s[i] >= 'a') ? s[i]-('a'-'A') : s[i];
return ret;
}for (size_t i = 0 ...。也没有充分的理由使它难以阅读。这还将首先复制字符串，然后在其上循环。@Luke的答案在某些方面更好，除了不利用'a'字符常量。
#include <string>
#include <locale>
std::string str = "Hello World!";
auto & f = std::use_facet<std::ctype<char>>(std::locale());
f.toupper(str.data(), str.data() + str.size());这将比使用全局toupper函数的所有答案更好，并且大概是boost :: to_upper在下面做的事情。
这是因为::: toupper必须为每次调用查找语言环境-因为它可能已由其他线程更改，而在这里，只有对locale（）的调用才会受到这种惩罚。查找语言环境通常涉及锁定。
在替换自动，使用新的非常量str.data（）并添加空格以中断模板关闭（“ >>”到“>>”）后，这也适用于C ++ 98，如下所示：
std::use_facet<std::ctype<char> > & f =
std::use_facet<std::ctype<char> >(std::locale());
f.toupper(const_cast<char *>(str.data()), str.data() + str.size());typedef std::string::value_type char_t;
char_t up_char( char_t ch )
{
return std::use_facet< std::ctype< char_t > >( std::locale() ).toupper( ch );
}
std::string toupper( const std::string &src )
{
std::string result;
std::transform( src.begin(), src.end(), std::back_inserter( result ), up_char );
return result;
}
const std::string src = "test test TEST";
std::cout << toupper( src );reserve和back_inserter（使字符串仅被复制一次）。inline std::string to_lower(const std::string &s) { std::string result; result.reserve(s.size()); std::transform(s.begin(), s.end(), std::back_inserter( result ), static_cast<int(*)(int)>(std::tolower)); return result; }
std::string value;
for (std::string::iterator p = value.begin(); value.end() != p; ++p)
*p = toupper(*p);toupper用负数调用时，此代码将调用未定义的行为。
该答案的@dirkgently是非常鼓舞人心的，但我想强调的是，由于这种担心是如下图所示，
像from中的所有其他函数一样，如果参数的值既不能表示为无符号字符也不等于EOF，则std :: toupper的行为是不确定的。要在纯字符（或带符号的字符）中安全使用这些函数，应首先将参数转换为无符号字符。
参考：std :: toupper
的正确用法std::toupper应为：
#include <algorithm>
#include <cctype>
#include <iostream>
#include <iterator>
#include <string>
void ToUpper(std::string& input)
{
std::for_each(std::begin(input), std::end(input), [](char& c) {
c = static_cast<char>(std::toupper(static_cast<unsigned char>(c)));
});
}
int main()
{
std::string s{ "Hello world!" };
std::cout << s << std::endl;
::ToUpper(s);
std::cout << s << std::endl;
return 0;
}输出：
Hello world!
HELLO WORLD!不确定是否有内置功能。试试这个：
包括ctype.h或cctype库，以及stdlib.h作为预处理器指令的一部分。
string StringToUpper(string strToConvert)
{//change each element of the string to upper case
for(unsigned int i=0;i<strToConvert.length();i++)
{
strToConvert[i] = toupper(strToConvert[i]);
}
return strToConvert;//return the converted string
}
string StringToLower(string strToConvert)
{//change each element of the string to lower case
for(unsigned int i=0;i<strToConvert.length();i++)
{
strToConvert[i] = tolower(strToConvert[i]);
}
return strToConvert;//return the converted string
}toupper用负数调用时，此代码将调用未定义的行为。
我的解决方案（将第6位清除为alpha）：
#include <ctype.h>
inline void toupper(char* str)
{
while (str[i]) {
if (islower(str[i]))
str[i] &= ~32; // Clear bit 6 as it is what differs (32) between Upper and Lowercases
i++;
}
}toupper用负数调用时，此代码将调用未定义的行为。
此页面上的所有这些解决方案都比他们需要的难。
做这个
RegName = "SomE StRing That you wAnt ConvErTed";
NameLength = RegName.Size();
for (int forLoop = 0; forLoop < NameLength; ++forLoop)
{
RegName[forLoop] = tolower(RegName[forLoop]);
}RegName是你的string。获取您的字符串大小不要string.size()用作您的实际测试仪，这很乱，并可能导致问题。然后。最基本的for循环。
请记住，字符串大小也会返回分隔符，因此请在循环测试中使用<而不是<=。
输出将是：您要转换的一些字符串
tolower循环，并且大多数使用标准循环变量名称，例如i，而不是怪异的forLoop。
不使用任何库：
std::string YourClass::Uppercase(const std::string & Text)
{
std::string UppperCaseString;
UppperCaseString.reserve(Text.size());
for (std::string::const_iterator it=Text.begin(); it<Text.end(); ++it)
{
UppperCaseString.push_back(((0x60 < *it) && (*it < 0x7B)) ? (*it - static_cast<char>(0x20)) : *it);
}
return UppperCaseString;
}如果只关心8位字符（除了米兰·巴布斯科夫，所有其他答案都假定为8位字符），则可以通过在编译时使用元编程生成查找表来获得最快的速度。在ideone.com上，它的运行速度比库函数快7倍，比手写版本（http://ideone.com/sb1Rup）快3倍。它也可以通过特征进行定制，而不会降低速度。
template<int ...Is>
struct IntVector{
using Type = IntVector<Is...>;
};
template<typename T_Vector, int I_New>
struct PushFront;
template<int ...Is, int I_New>
struct PushFront<IntVector<Is...>,I_New> : IntVector<I_New,Is...>{};
template<int I_Size, typename T_Vector = IntVector<>>
struct Iota : Iota< I_Size-1, typename PushFront<T_Vector,I_Size-1>::Type> {};
template<typename T_Vector>
struct Iota<0,T_Vector> : T_Vector{};
template<char C_In>
struct ToUpperTraits {
enum { value = (C_In >= 'a' && C_In <='z') ? C_In - ('a'-'A'):C_In };
};
template<typename T>
struct TableToUpper;
template<int ...Is>
struct TableToUpper<IntVector<Is...>>{
static char at(const char in){
static const char table[] = {ToUpperTraits<Is>::value...};
return table[in];
}
};
int tableToUpper(const char c){
using Table = TableToUpper<typename Iota<256>::Type>;
return Table::at(c);
}与用例：
std::transform(in.begin(),in.end(),out.begin(),tableToUpper);要深入了解（很多页面）其工作原理，请允许我无耻地插入我的博客：http : //metaporky.blogspot.de/2014/07/part-4-generating-look-up-tables-at.html
template<size_t size>
char* toupper(char (&dst)[size], const char* src) {
// generate mapping table once
static char maptable[256];
static bool mapped;
if (!mapped) {
for (char c = 0; c < 256; c++) {
if (c >= 'a' && c <= 'z')
maptable[c] = c & 0xdf;
else
maptable[c] = c;
}
mapped = true;
}
// use mapping table to quickly transform text
for (int i = 0; *src && i < size; i++) {
dst[i] = maptable[*(src++)];
}
return dst;
}此c ++函数始终返回大写字符串...
#include <locale>
#include <string>
using namespace std;
string toUpper (string str){
locale loc;
string n;
for (string::size_type i=0; i<str.length(); ++i)
n += toupper(str[i], loc);
return n;
}我使用这个解决方案。我知道您不应该修改该数据区...。但是我认为这主要是为了解决缓冲区溢出错误和空字符...。
void to_upper(const std::string str) {
std::string::iterator it;
int i;
for ( i=0;i<str.size();++i ) {
((char *)(void *)str.data())[i]=toupper(((char *)str.data())[i]);
}
}I know you're not supposed to modify that data area-您不应该修改哪个数据区？
str[i] = toupper(str[i]);完全正确的方法代替那条疯狂的路线（嗯，不是完全正确的方法，但是它可以修复大多数错误）。
::toupper最有可能采用ASCII。