CODEWITHSUNDEEP
c++stringvisual-c++booststring-literals
Tom
Tom

Reputation: 7951

Visual C++ and extremely long strings

I'm trying to port a third-party library to Visual C++ 2013. The library has some extremely long strings which appear to be Base64-encoded data. I've split them into multiple string literals, each of which is below the 2,600-odd character limit Visual C++ imposes on string literals, but even then there are some that exceed the 65,535-character limit after concatenation.

The use boils down to this:

boost::any value = +"abcd...";

Can someone suggest a way to initialize boost::any with over 65k of literal data?

EDIT: The code which does this is auto-generated from an XML file. There are some tens of thousands of such values. Only two are too long for the 65,535 limit.

This makes any solution that uses dynamic memory allocation (such as std::string) unattractive, as it will be applied by the code generation utility to all of the tens of thousands of them, when only two require it; the dynamic memory allocation will be expensive. I'd much prefer a compile-time solution.

Upvotes: 1

Views: 2325

Answers (1)

sehe
sehe

Reputation: 392931

Quoting from the nonius revision log

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

I can assure you that issue have been reported here

You'll note the customary WONTFIX response. This is just formality, of course. Apparently something has changed in the newest version:

Is @R.MartinhoFernandes around? James told me that they've fixed the limitations on string literal lengths in VC2015 :) — jalf on Apr 25 10:33 PM

From context, we can derive this was probably James McNellis.

There was an earlier conversation about the details of this limitation on march 5th.

Upvotes: 4

Related Questions