Friday, November 21, 2008

STLSoft 1.10 new additions: string_to_integer

Having not posted for over a month, there's a lot to catch up on.

I'm going to start with a series of short missives on the latest additions to STLSoft 1.10. (See this for how to install/use 1.10 alpha (delta) releases.) While I'm catching up with the releases, it's probably not going to go in order, so you'll have to be bear with me.

I'll start today with the new stlsoft::string_to_integer() functions, defined in the new include file stlsoft/conversion/string_to_integer.hpp. These are low-level string->number parsing functions. Their raison d'etre is performance - they'll be used in the forthcoming FastFormat 0.3 version, for high-speed parsing of replacement parameters - and for this they sacrifice some functionality, as discussed below.

They look like the following:

namespace stlsoft
int string_to_integer(char const* s, char const** endptr);

int string_to_integer(wchar_t const* s, wchar_t const** endptr);
int string_to_integer(char const* s, size_t len, char const** endptr);
int string_to_integer(wchar_t const* s, size_t len, wchar_t const** endptr);
} // namespace stlsoft

The functions in the first pair take a (non-NULL) pointer to a (nul-terminated) C-style string, along with an optional (may be NULL) pointer to pointer to C-style string, which will receive the pointer to the character terminating the parsing. In this aspect, these functions ape the functionality of the standard strtol() function. However, where they differ is that they do not accept a radix parameter: currently all conversion is decimal.

The second pair do not require nul-terminated strings, and instead use a length parameter. This is useful when parsing numbers out of string types that may not be null-terminated. (Again, this is found in FastFormat, which is the main driver for the release of these functions.)

These functions are very new, and will evolve further before STLSoft 1.10 beta. Three changes that are candidates to be introduced are:
  • Supporting different radixes (although for radixes not in [8, 10, 16] it may be that they'd defer to strtol()).
  • Support for different integer types. In fact, the four concrete functions are implemented in terms of two function templates whose integral type is a template parameter, so the groundwork is all there
  • Support for truncation testing.
I'd like to hear from anyone on these, or other, features.

I'll do some specific performance tests on the functions at a later time. They've had some exposure as part of a larger performance test of the forthcoming FastFormat 0.3's new functionality, and have shown to confer a benefit over strtol() and its siblings.


Сергей said...


Could you please provide future plans regarding stlsoft features?
For example - network, xml, database support?

thank you!

Matt Wilson said...

The medium-term (2009) plans are:
1. Move over 1.9 into 1.10, enhancing/fixing/removing in the process.
2. Build a proper website for STLSoft, including places to publish articles and blogs for members and power-users.
3. Construct a decent set of (automated) documentation
4. Put 1.10 in a subversion repo that's available online (and which can be read/write to project members)
5. Prepare RPMs, etc., so people on UNIX can have easy install access to the libraries

After that, then several (long-planned) new features might come along. These would include:
A. Decent file-system entity facades; this is something I'm currently working on in the preparation of Monolith
B. Get XMLSTL - a good idea that was never finished - in a releasable state, and see if anyone has interest in it.

beyond that, there are no firm plans for Database and/or Network, although as soon as I am called upon by a client to work with either again it is likely that some STLSoft components along those lines would fall out of that work.

I don't know if that answers your question (and I apologise for leaving it 6 weeks before answering; I tend to do that a lot :$). Were there any specific features you want to see? Requests/discussions are always useful.