C++ standard library use increased

[Neil Hodgson]

To avoid overhead and to support potential targets with subset C++ compilers, Scintilla was originally written with exception handling turned off. This disallowed using standard containers like vector and string so Scintilla had several hand-coded vector-like classes and raw char* allocations were often passed around.

Most of these have now been replaced with standard library classes vector, string, and map. There are still some remnants such as UndoHistory which would be less efficient as vector although C++11 should allow this to be changed. The 4 platform layers distributed with Scintilla have been updated.

Other platform layers may need to be updated due to 2 modified/removed methods. Document::TransformLineEnds has been modified to return a std::string instead of a char* with length returned in a parameter. SelectionText::Set which took over ownership of a char * has disappeared: SelectionText::Copy which copies text into an internally allocated buffer should be used instead.

All previously supported versions of GCC (4.1+) still work. Visual C++ 2005 and earlier no longer work. If there is sufficient need, Visual C++ 2005 compatibility could be restored but its too late for Visual C++ 6.0 (1998).

Change sets 4509, 4514 .. 4518, 4525 .. 4543 implemented these changes and removed code that was no longer needed.

Neil

[Mike Lischke]

Hey Neil,

> To avoid overhead and to support potential targets with subset C++ compilers, Scintilla was originally written with exception handling turned off. This disallowed using standard containers like vector and string so Scintilla had several hand-coded vector-like classes and raw char* allocations were often passed around.
>
> Most of these have now been replaced with standard library classes vector, string, and map. There are still some remnants such as UndoHistory which would be less efficient as vector although C++11 should allow this to be changed. The 4 platform layers distributed with Scintilla have been updated.

One thing to consider here is memory consumption. As you might remember I had trouble with large scripts loaded into Scintilla (at that time using the .NET wrapper) which caused several copies of the text kept in memory during certain operations (e.g. for callbacks/events as well as when setting text). I have seen 1GB+ mem usage for a 130MB file at that time.

Later when I removed that and added a low level wrapper (for C++ backend code) I carefully selected where to use std::string and where const char*. For text setting and retrieval (including selected text) I recommend to use const char* still as this avoids unwanted copies. I'm not sure how much of that applies to your recent changes. I just wanted to raise a warning voice as I have been bitten by that.

Mike
--
www.soft-gems.net

[Neil Hodgson]

Mike Lischke:

> Later when I removed that and added a low level wrapper (for C++ backend code) I carefully selected where to use std::string and where const char*. For text setting and retrieval (including selected text) I recommend to use const char* still as this avoids unwanted copies.

The changes to ScintillaView's selectedString and string are in:
http://sourceforge.net/p/scintilla/code/ci/a160448217bc06684677502680c125f6f2b03e9b/
In these cases there was already a heap allocation of the string contents so std::string just precedes this with a 3 integer control block. The std::string constructor also fills the buffer with 0 which is an extra cost but zeroing blocks is very fast. Using an object to hold the allocation ensures that all execution paths free the memory.

Some things that look like copies, such as returning a std:string are elided by the compiler - the "Return value optimization".

Most of the changes were cases where there is already a heap allocation and wrapping it in a std::string doesn't make much difference. There are a few places where extra copies are performed but they are for more complex cases like ScintillaGTK::CaseMapString where the text is first transcoded to UTF-8 if needed, case is changed, then transcoded back to the original document encoding. The previous implementation was made overly complex by the need to track the only-for-non-UTF-8 allocations. If case conversion is a bottleneck then the std::string version could be made to avoid any extra copies but that would make the control flow more complex.

Neil

[Florian Balmer]

I'm using Visual Studio 2002 (Version 7.0.9466) with the DirectX SDK headers to work on Notepad2, as I would like to maintain Windows 2000 compatibility. With the latest C++ STL use changes from Hg, the build breaks with the following errors and warnings:

error C2039: 'data' : is not a member of 'std::vector<_Ty,_Ax>'

PlatWin.cxx: line 2098

ScintillaWin.cxx: lines 1773, 1782, 1785, 1806, 1808, 1811, 1811, 1813, 2565, 2577, 2595, 2611, 2751

warning C4312: 'reinterpret_cast/typecast' : conversion from 'X' to 'Y' of greater size

PlatWin.cxx: lines 50, 2211, 2769, 2783, 2791, 2794

ScintillaWin.cxx: lines 116, 1831

The release builds are created by the WDK 7600.16385.1 tools with the DirectX SDK headers, and the build breaks with the same errors, but does not produce the warnings.

I'd be deeply grateful if the use of std::vector::data() could be omitted.

--Florian

[Neil Hodgson]

Florian Balmer:

> I'd be deeply grateful if the use of std::vector::data() could be omitted.

OK, changed to &X[0].

It is possible to target Windows 2000 (and NT 4) with gcc 4.7 or 4.8 which are much more current than Visual C++ 2002. These compilers can even be hosted on the older versions of Windows. Both Scintilla and SciTE build and run on Windows 2000 and NT 4 using gcc 4.7. The TDM downloads are easier to install as the installer for the main MinGW distribution doesn't work before Windows XP.
http://tdm-gcc.tdragon.net/download

Compatibility with older compilers is likely to be short-lived. I've been using C++11 and Modern Objective C in SciTE for OS X since that code isn't published and now prefer these language versions.

Neil

[Florian Balmer]

Thanks a lot, building works again!

Yes, I fear that my build environment will definitely expire, one day.

Windows 2000 compatibility could probably be achieved with newer build tools, too. Yet with mine, I can produce very compact executable files dynamically linking to msvcrt.dll, the present-on-all-versions-of-Windows-out-of-the-box, already-memory-resident, always-most-recently-updated, no-WinSxS-messing-with-msvcrXX.dll-or-msvcrXXX.dll-or-whatever, used-by-the-Windows-OS-itself C runtime library. Quite a nice point, in my opinion :-)

--Florian

[Andreas Tscharner]

On 06.05.2013 21:02, Florian Balmer wrote:
> I'm using Visual Studio 2002 (Version 7.0.9466) with the DirectX SDK
> headers to work on Notepad2, as I would like to maintain Windows 2000
> compatibility. With the latest C++ STL use changes from Hg, the build

May I ask why do you care about Win2000 compatibility?

Best regards
Andreas
--
Andreas Tscharner <sterne...@gmail.com>
----------------------------------------------------------------------
"Intruder on level one. All Aliens please proceed to level one."
-- Call in "Alien: Resurrection"

[Florian Balmer]

> May I ask why do you care about Win2000 compatibility?

For various personal / subjective reasons:

* I'm fascinated by the Microsoft philosophy that everything should be source- and binary-compatible forever.

* Historical interest / nostalgic reasons.

* Technical interest / learning / challenge, i.e. I've written some helper functions to make 32-bit (alpha-channel) toolbar images look smooth on Windows 2000.

* I consider it a sign of quality for software being backwards compatible and relying on time-tested principles and user interface design (in contrast to software trying to attract attention by always using the latest fancy features and user interfaces).

* Feedback by Notepad2 users shows me Windows 2000 is still in use.

--Florian