• Jon Papaioannou (30/30) Nov 26 2007 Hi! Please forgive the rather utilitarian format of this post, but I tri...
• Matthew Wilson (16/46) Nov 27 2007 Jon
• Jon Papaioannou (5/5) Nov 29 2007 Thanks for the heads up, Matt.
• Matthew Wilson (4/9) Nov 29 2007 LOL!
• Matthew Wilson (16/38) Dec 05 2007 the
• Matthew Wilson (6/36) Jun 08 2008 This has finally been addressed, in v1.8.13. Download from http://recls....

Jon Papaioannou <pj moodle.org> writes:

Hi! Please forgive the rather utilitarian format of this post, but I tried
first to send this as an email (it bounced), so... :)

PROBLEM:
I recently downloaded and built the excellent recls library to include its
functionality on a small Win32 utility I needed to make. However, when I
switched from multibyte to widechar builds for my utility, I noticed that
recls didn't work correctly (actually threw some exception, don't remember the
particulars).

CAUSE:
Debugging showed that this was because the (supposedly widechar) recls
binaries used plain "char" as the character type. Hashing the multibyte and
widechar library binaries confirmed that they were identical.

SOLUTION:
Therefore I delved into the makefile and saw that it simply... copied the
multibyte binaries to produce the widechar ones. I expanded and modified the
makefile to produce correct widechar builds and everything worked out fine.

QUESTION:
Are you aware of this behavior? Surely it can't be intended? I didn't check
the makefiles for other compilers, but quite possibly this "bug" exists in
these as well.

I can happily provide a patch for the makefile to save others some grief, if
you are willing to update the source packages.

In a related issue, the STLSoft 1.9.9 distribution has an error in the
source code which bit me during the widechar build:

stlsoft/filesystem/searchspec_sequence.hpp, line 168 reads:
   typedef string_tokeniser<string_type, char> tokeniser_type;

while it should read:
   typedef string_tokeniser<string_type, char_type> tokeniser_type;


Cheers,
Jon

"Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:

Jon

Just wanted to give you a quick answer, to let you know I'm aware of your
post.

Will follow up shortly. (And, yes, the behaviour is not intended! ;-/)

One immediate question: what compiler(s) were you using? (If it's VC++ 8, I
think I may have an idea ...)

Cheers

Matt

"Jon Papaioannou" <pj moodle.org> wrote in message
news:fifhfm$2807$1 digitalmars.com...
 Hi! Please forgive the rather utilitarian format of this post, but I tried
 first to send this as an email (it bounced), so... :)

 PROBLEM:
 I recently downloaded and built the excellent recls library to include its
 functionality on a small Win32 utility I needed to make. However, when I
 switched from multibyte to widechar builds for my utility, I noticed that
 recls didn't work correctly (actually threw some exception, don't remember

the
 particulars).

 CAUSE:
 Debugging showed that this was because the (supposedly widechar) recls
 binaries used plain "char" as the character type. Hashing the multibyte

and
 widechar library binaries confirmed that they were identical.

 SOLUTION:
 Therefore I delved into the makefile and saw that it simply... copied the
 multibyte binaries to produce the widechar ones. I expanded and modified

the
 makefile to produce correct widechar builds and everything worked out

fine.
 QUESTION:
 Are you aware of this behavior? Surely it can't be intended? I didn't

check
 the makefiles for other compilers, but quite possibly this "bug" exists in
 these as well.

 I can happily provide a patch for the makefile to save others some grief,

if
 you are willing to update the source packages.

 In a related issue, the STLSoft 1.9.9 distribution has an error in the
 source code which bit me during the widechar build:

 stlsoft/filesystem/searchspec_sequence.hpp, line 168 reads:
    typedef string_tokeniser<string_type, char> tokeniser_type;

 while it should read:
    typedef string_tokeniser<string_type, char_type> tokeniser_type;


 Cheers,
 Jon

Jon Papaioannou <pj moodle.org> writes:

Thanks for the heads up, Matt.

Looks like I managed to hide some data real good in the post title. ;-) Compiler
was VC++ 7.1 (verbatim: "Version 13.10.3077 for 80x86").

Cheers
Jon

"Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:

LOL!


"Jon Papaioannou" <pj moodle.org> wrote in message
news:fimqe9$q92$1 digitalmars.com...
 Thanks for the heads up, Matt.

 Looks like I managed to hide some data real good in the post title. ;-)

Compiler
 was VC++ 7.1 (verbatim: "Version 13.10.3077 for 80x86").

 Cheers
 Jon

"Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:

"Jon Papaioannou" <pj moodle.org> wrote in message
news:fifhfm$2807$1 digitalmars.com...
 Hi! Please forgive the rather utilitarian format of this post, but I tried
 first to send this as an email (it bounced), so... :)

 PROBLEM:
 I recently downloaded and built the excellent recls library to include its
 functionality on a small Win32 utility I needed to make. However, when I
 switched from multibyte to widechar builds for my utility, I noticed that
 recls didn't work correctly (actually threw some exception, don't remember

the
 particulars).

 CAUSE:
 Debugging showed that this was because the (supposedly widechar) recls
 binaries used plain "char" as the character type. Hashing the multibyte

and
 widechar library binaries confirmed that they were identical.

 SOLUTION:
 Therefore I delved into the makefile and saw that it simply... copied the
 multibyte binaries to produce the widechar ones. I expanded and modified

the
 makefile to produce correct widechar builds and everything worked out

fine.
 QUESTION:
 Are you aware of this behavior? Surely it can't be intended? I didn't

check
 the makefiles for other compilers, but quite possibly this "bug" exists in
 these as well.

 I can happily provide a patch for the makefile to save others some grief,

if
 you are willing to update the source packages.

John

I'm having a hard time replicating this issue. Can you tell me your exact
sequence of steps and/or send me through an example project (incl .vcproj)
that illustrates?

I'm really keen to fix this, in part because I want to move recls onto the
1.9 stream, but am unwilling to move until the 1.8 version is without issue.

Cheers

Matt

"Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:

This has finally been addressed, in v1.8.13. Download from http://recls.org/

FYI: recls development is now on the 1.9 stream, which will include some new
features, and a lot more order in the packaging, docs
and automated testing. Should start hitting the streets in August.

Cheers

Matt

"Jon Papaioannou" <pj moodle.org> wrote in message
news:fifhfm$2807$1 digitalmars.com...
 Hi! Please forgive the rather utilitarian format of this post, but I tried
 first to send this as an email (it bounced), so... :)

 PROBLEM:
 I recently downloaded and built the excellent recls library to include its
 functionality on a small Win32 utility I needed to make. However, when I
 switched from multibyte to widechar builds for my utility, I noticed that
 recls didn't work correctly (actually threw some exception, don't remember the
 particulars).

 CAUSE:
 Debugging showed that this was because the (supposedly widechar) recls
 binaries used plain "char" as the character type. Hashing the multibyte and
 widechar library binaries confirmed that they were identical.

 SOLUTION:
 Therefore I delved into the makefile and saw that it simply... copied the
 multibyte binaries to produce the widechar ones. I expanded and modified the
 makefile to produce correct widechar builds and everything worked out fine.

 QUESTION:
 Are you aware of this behavior? Surely it can't be intended? I didn't check
 the makefiles for other compilers, but quite possibly this "bug" exists in
 these as well.

 I can happily provide a patch for the makefile to save others some grief, if
 you are willing to update the source packages.

 In a related issue, the STLSoft 1.9.9 distribution has an error in the
 source code which bit me during the widechar build:

 stlsoft/filesystem/searchspec_sequence.hpp, line 168 reads:
    typedef string_tokeniser<string_type, char> tokeniser_type;

 while it should read:
    typedef string_tokeniser<string_type, char_type> tokeniser_type;


 Cheers,
 Jon