我正在尝试将第三方库移植到Visual C ++ 2013.该库有一些非常长的字符串,似乎是Base64编码的数据。我将它们分成多个字符串文字,每个文字字符都低于Visual C ++对字符串文字强加的2,600多字符限制,但即便如此,也有一些字符串在连接后超过65,535字符限制。
用法归结为:
boost::any value = +"abcd...";
有人可以建议使用超过65,000的文字数据来初始化boost::any
吗?
编辑:执行此操作的代码是从XML文件自动生成的。有成千上万的这样的价值观。只有两个对于65,535限制来说太长了。
这使得任何使用动态内存分配的解决方案(例如std::string
)都没有吸引力,因为只有两个需要时,代码生成实用程序会将其应用于所有成千上万的数据库中。动态内存分配将是昂贵的。我更喜欢编译时的解决方案。
答案 0 :(得分:3)
从nonius修订日志中引用
commit ec0e32ea96e8c0b1c7068f80207c586e6c4ba7aa
Author: Martinho Fernandes <email-in-commit>
Date: Wed Feb 19 02:44:43 2014 +0100
Shutting up MSVC warning.
Dear Microsoft C/C++ Optimizing Compiler,
I hate you. After I chopped up my HTML template into tiny, tiny string pieces to appease you tiny fixed-size buffers,
I thought we could maybe be friends after all. But no. You had to go and give me more bullshit. You had to start your
ridiculous warning bullshit. The warning bullshit that there is no way to turn off without leaking crap to user code.
You're a joke.
Sincerely,
rmf
commit 8f10050a3217d94af1d3fb12e1e3752ab33c8159
Author: Martinho Fernandes <email-in-commit>
Date: Tue Feb 18 19:35:26 2014 +0100
Now with no string pieces larger than 11k
Dear Microsoft C/C++ Optimizing Compiler,
It was a bit hilarious when you complained about that ~200kiB string
literal. The standard even has only a recommendation of 64kiB. This
16380 bytes per string piece bullshit, though? This is just ridiculous.
I hope this is the last hoop I have to jump through.
Sincerely,
rmf
commit 6b6a098e4e43c7f8d5e5fd580f6e6be463132f81
Author: Martinho Fernandes <email-in-commit>
Date: Tue Feb 18 19:02:05 2014 +0100
HTML template string broken into pieces that are assembled on first use.
Dear Microsoft C/C++ Optimizing Compiler,
The 1990s called. They want their 64kiB fixed-size buffers back.
I didn't pay for 32GiB of RAM so that you could whine about a string
literal that is a few hundred kiB big.
Fuck You.
Sincerely,
rmf
我可以向您保证,此处已报告此问题
您会注意到惯用的 WONTFIX 响应。当然,这只是形式。显然,最新版本的内容发生了变化:
是@ R.MartinhoFernandes吗? James告诉我他们已经修复了VC2015中字符串文字长度的限制:) - jalf on Apr 25 10:33 PM
从上下文来看,我们可以推导出这可能是James McNellis。
之前有关于此限制的详细信息的对话on march 5th。