STL and Unicode, recommended settings

[RomanH]

I'm using OTL on Windows with Visual Studio for ODBC, with and without STLPort. I'd like to use STL string and Unicode, therefore my definitions look like this:

#define OTL_ODBC
#define OTL_ANSI_CPP
#define OTL_VALUE_TEMPLATE_ON
#if defined(_STLPORT_VERSION)
#define OTL_STLPORT
#else
#define OTL_STL
#endif
#define OTL_BIGINT __int64
#define OTL_STR_TO_BIGINT(str,n)                \
{                                               \
  n=_atoi64(str);                               \
}
#define OTL_BIGINT_TO_STR(n,str)                \
{                                               \
  _i64toa(n,str,10);                            \
}
#define OTL_UNICODE
#define OTL_UNICODE_CHAR_TYPE wchar_t
#define OTL_UNICODE_STRING_TYPE std::wstring

Unfortunately, in otlv4.h there are the following lines:

#if defined(OTL_STL) && defined(OTL_UNICODE_STRING_TYPE)
#error Invalid combination: OTL_STL and OTL_UNICODE_STRING_TYPE
#endif

Therefore the build with the Microsoft STL fails.
Why is this an "invalid combination"? If I comment out the #error line, everything compiles and runs fine.
What is the recommended setting for using STL string classes with Unicode?
For example, removing the definition of OTL_UNICODE_STRING_TYPE will remove the definition of the << operator for otl_stream with std::wstring, which I'd like to use. Removing the definition of OTL_STL leads to a lot of other compilation errors.

Thanks in advance!

Regards
Roman

[Sergei Kuchin]

Not everything works / not everything is consistent when both OTL_STL and Unicode are used, so that's why. If a subset of functionality works for you (OTL_STL + Unicode) with VC++, use it.

Sergei

[RomanH]

Thank you for your answer. We really only use a small subset of the functionality of OTL.

Thanks anyway for this great library!

Roman

[bogdan]

Although this thread is very old, I think it's still relevant. I need to use OTL_STL and Unicode together as well.

Sergei, could you please elaborate a bit on the things that aren't working properly when these two options are used together?

I'll be using OTL_ODBC_MSSQL_2008 with OTL_STREAM_POOLING_ON on Visual C++ 2013 32-bit. I'll use the standard wchar_t and std::wstring.

Basically, what pieces of functionality should I worry about? Should I expect compilation issues? Runtime problems?

Thanks a lot.

Bogdan

[Sergei Kuchin]

Hi Bogdan,

I think you found a documentation bug. I extended OTL stream pooling to work with Unicode back in 2013. Here's an excerpt from What's New Page:

27-May-2013, (New in OTL 4.0.296):

A problem was reported with OTL_UNICODE_ID (an internal #define in the OTL header file) being defined more than once when OTL_STREAM_POOLING_ON and OTL_UNICODE_STRING_TYPE are used together under some circumstances. The C++ compiler issues a warning, and when warnings are set to be treated like errors, it makes the compilation fail. The problem was introduced in OTL 4.0.295. The problem is fixed in this release. Also, the following new code examples have been added to demonstrate how to use OTL_STREAM_POOLING_ON and OTL_UNICODE_STRING_TYPE together: examples 751 (Oracle), 752 (MS SQL), 753 (DB2). These new code examples should be easy enough to modify to work with the rest of the database types that OTL supports.

You may want to take a closer look at example 752: http://otl.sourceforge.net/otl4_ex752.htm

Cheers,
Sergei

[bogdan]

Thanks a lot for your quick reply, Sergei.

Silly me, I actually looked at that example but, concentrating on the use of the stream pool, I didn't even notice OTL_STREAM_POOLING_ON being used without OTL_STL.

All right, so this means the only remaining reason for defining OTL_STL is to use the OTL iterators, correct? The description of OTL_STL says something about 'turning on std::strings', but I'm not sure what that means or if it's still relevant. If it's only the iterators, I can live without those.

Thanks again,
Bogdan

[Sergei Kuchin]

define OTL_STL is needed when using std::string, otl_input_iterator, and otl_output_iterator. OTL input/output iterators are old and slightly inefficient as it turns out. I implemented otl_read_from_stream / otl_write_to_stream template functions (http://otl.sourceforge.net/otl4_read_from_stream.htm) that don't require #define OTL_STL. You can try them if you want. Also, there are otl_read_row / otl_write_row template functions (http://otl.sourceforge.net/otl4_read_row.htm) that make extra checks.

[bogdan]

OK, so a quick summary would be:
- you need OTL_STL to read / write std::strings from / to a stream;
- you need OTL_UNICODE to read / write std::wstrings from / to a stream;
- you can't use these two together.

Did I get the above right?

[Sergei Kuchin]

Correct.

[bogdan]

Regarding the above, I've just hit another roadblock: as far as I can tell, when OTL_UNICODE is defined, not only can't you use std::strings, but you can't use char*s either, because

otl_stream::operator>>(char*)

is guarded by a

#if !defined(OTL_UNICODE)

Sergei, is the above correct?

[bogdan]

Good stuff.

Now for a suggestion / feature request: I think it would be great to be able to use the two together. In my case, I have a SQL Server database where most of the application string data is Unicode, but there are also quite a few tables that are used internally, where plain ASCII is just fine. I'd love to have the convenience of using both standard string classes when working with this stuff.

Frankly, the level of backwards compatibility that you've managed to maintain in this library, while also adding some of the latest language features and keeping the whole thing stable is nothing short of unbelievable. However, I believe that at some stage things have to move forward and leave the past behind.

My guess is that projects using very old compilers and libraries, including old versions of ODBC, OCI and so on, will stay with those versions, possibly forever, but they would also be very reluctant to switch to newer versions of OTL, for the same reasons as for the other libraries. What I mean is that they would be fine with the existing versions that are backwards compatible and stable, but the library itself could start dropping support for very old code in new versions and get rid of a bunch of related configuration options, simplifying the code and enabling features like the one above in the process.

Sorry for the ramblings, didn't mean to hijack the thread, I'll shut up now.

Thanks again for clarifying the use of those options.

Cheers,
Bogdan

[Sergei Kuchin]

Let's take this discussion offline. Send me an email to my gmail account (can be found at the bottom of any OTL Web page).