[bash]714:wxStringBase& wxStringBase::replace(size_t nStart, size_t nLen,Compiling in debug mode works fine. Is this a known issue and is there some work around?
715: const wxChar *sz)
717: wxASSERT_MSG( nStart <= length(),
718 _T("index out of bounds in wxStringBase::replace") );
I tried with both Debug & Release build and used 2008 IDE.
Did you change anything in Project Properties etc etc.
Please try using latest 11.1 compiler.
Since the application is very huge, you can just go to
And you would be able to test compilation in a few seconds.
I think I did a mistake. I used 32-bit , and I think what you asked was for 64-bit.
Anyhow, in case you know about the build result for 32-bit, or used 11.1 compiler, please let me know.
I even could not reproduce your issue in Intel64 with 11.0.066 or 11.1 compilers.
(please tell architecture also, eg., are you testing in Itanium-64, AMD64 etc?? )
I also tested using Release & Debug builds.
Are you using batch builds, or DLL configuration or something?
What are the steps & configuration you are using to buildthewholeproject.
I am also using wxwidgets 2.8.8 release.
Please let me know , your environment, machine, and steps in more detail, for me to reproduce at my end.
Ok. It reproduces with the default options that came with the download, with the Release build.
I forgot to change Win32 to X64 configuration platform, and hence missed that error. Now it reproduces, quite easily.
internal error: 0_1599 with string.cpp .
Will look at how it could be escalated as a minimal test-code, and would keep you in the loop.
Thanks for the issue, and sorry for the confusion.
And its not easy to classify this error as it comes from within the compiler itself , eg. due to stack it cannot allocate, or exceptions/crash inside its own code, or other ways the compiler code itself is at fault.
For general brief on this typical error, you can see this link:--
As the reason is unknown, to fix it will be needed a minimal test-code, and that was the reason I tried with latest compiler 11.1 to check whether this works, and let you know so you could use it straightway.
Also, I did some search through our defect records and did not see bug filed with 0_1599 code for the internal error.