Announce: standard stream output support in cppx lib at GitHub

[Alf P. Steinbach]

I've done a bit more coding on (this re-creation of) the cppx
header-only library, at


https://github.com/alf-p-steinbach/cppx/commit/bf1081a6e5465d1dd0265f9dca9ba6d20cd288f1

so that the following works nicely in Windows:


<code>
#include <p/cppx/basics.hpp>
using namespace std;
namespace cppx = progrock::cppx;

void cpp_main()
{
using cppx::sys;
using cppx::String;
sys.out << "Using cppx version " << cppx::version_cstring << "." <<
endl;
sys.out << endl;

sys.out << "Direct output of narrow literal : "
<< "• “blåbærsyltetøy”." << endl;

sys.out << "Widened at compile time (in Windows): "
<< CPPX_RAW_SYSTEXT( "• “blåbærsyltetøy”." ) << endl;

sys.out << "Widened at runtime (in Windows) : "
<< String( "• “blåbærsyltetøy”." ) << endl;
}
</code>


The extra indirection via sys.out means that it should work nicely also
in Unix-land, when I get to that. In Windows sys.out is a reference to
wcout, while in Unix-land & elsewhere it's a reference to cout. And in
Windows those streams are configured to use Unicode, so that the output
from the above is not the usual gobbledegook, but like this:


<output>
Using cppx version 2015-12-30.

Direct output of narrow literal : • “blåbærsyltetøy”.
Widened at compile time (in Windows): • “blåbærsyltetøy”.
Widened at runtime (in Windows) : • “blåbærsyltetøy”.
</output>


The strange result with the direct output of narrow literal is
consistent with replacing every non-Latin-1 character with something.
That could happen if the internal translation (from Windows ANSI Western
to UTF-16) in Microsoft's stream implementation just copies the
character codes blindly. But I'm not sure what really goes on inside the
stream, it's just an hypothesis that matches the data so far.

Input is a more complicated. I remember that g++ used to produce
double-spaced input, with every second line blank, and I have a fix for
that somewhere. Unless they've fixed the g++ library implementation now.


Anyway, cheers!, enjoy, and Happy New Year coming up!,

- Alf

[Alf P. Steinbach]

On 12/30/2015 11:51 AM, Alf P. Steinbach wrote:
> I've done a bit more coding on (this re-creation of) the cppx
> header-only library, at
>
>
> https://github.com/alf-p-steinbach/cppx/commit/bf1081a6e5465d1dd0265f9dca9ba6d20cd288f1
>

Checked in a fix for the cppx::is_empty function template (which
automatically uses a class' member function empty() if available),
because somehow most of the unit test for that header had been commented
out and when it now was invoked it didn't even compile...

Fixed code:

https://github.com/alf-p-steinbach/cppx/commit/6bcf5be4b53e882dbf76b5414bfcf8820cddc240

This probably also says something about how I (can) work as a hobby
programmer, just changing the names of functions at a whim, as to my
liking, because nobody else is using this stuff yet. I think.

Cheers, & again, Happy Upcoming New Year!,

- Alf

PS: You (clc++) are the first to read about this and maybe look at it
and try it out. I haven't even blogged about it yet. Wordpress says I
had roughly 10 000 unique views of my main blog this year, even though I
just posted 1 short article (and that was mainly about Python), so I'm
considering starting blogging again – I have less physical pains.

[Alf P. Steinbach]

On 12/31/2015 6:31 AM, Alf P. Steinbach wrote:
> On 12/30/2015 11:51 AM, Alf P. Steinbach wrote:
>> I've done a bit more coding on (this re-creation of) the cppx
>> header-only library, at
>>
>> https://github.com/alf-p-steinbach/cppx/commit/bf1081a6e5465d1dd0265f9dca9ba6d20cd288f1
>>
> Checked in a fix for the cppx::is_empty function template
>

> https://github.com/alf-p-steinbach/cppx/commit/6bcf5be4b53e882dbf76b5414bfcf8820cddc240

Now, on Github:
https://github.com/alf-p-steinbach/cppx/commit/c7daa7c6decd4a48c1278217557eb4404f4c469a

Finally Unicode interactive line input so that this kind of beginner's
program now works as expected with non-ASCII characters in Windows:

<code>
#include <p/cppx/basics_and_main.hpp> // This header brings in a
default "main".
using namespace progrock::cppx;

void cpp_main()
{
// Basics: output of text parts, input of Unicode line.
sys.out << "Hi, what’s your name? ";
const String username = line_from( sys.in );
sys.out << "Pleased to meet you, " << username << "!" << endl;

// Just to input at least 2 lines, so as to test the g++ workaround:
sys.out << endl;
sys.out << "What’s your favorite activity, then, " << username << "? ";
const String activity = line_from( sys.in );
sys.out
<< "What a coincidence!" << endl
<< "Earlier I favored making Norwegian blåbærsyltetøy," << endl
<< "but now my favorite activity is also " << activity << "!"
<< endl;

sys.out << endl;
sys.out << "Well, have a nice day, " << username << "! Bye!" << endl;
}
</code>

Here

• The "’" apostrophe is displayed correctly (it's not in Latin-1).

• In Windows any character in Unicode's Basic Multilingual Plane should
work as input. Testing with “日本国 кошка” (a “Japanese cat”, with
“Japanese” expressed in Chinese and “cat” in Russian, or I believe it's
so :) ) worked nicely, except the console window, with my choice of
font, was unable to display the Chinese glyphs.

• The narrow string literals are translated at run time using the code
page that the compiler encoded them with. In Windows this relies on a
simple text file that specifies that code page, e.g. "1252".
Unfortunately, as far as I know it can't be more automatically
determined, but I supply a little batch file that can generate the text
file; it just looks up the ACP codepage in the Windows registry.

Of course one doesn't need to use the library's “main”, but it avoids
coding up a minimal exception-handling “main”, and I believe that the
ability to just use a “cpp_main” and throw exceptions for failures, will
be useful to a beginner.

Probably next is making this work with g++, and then testing in
Unix-land. And then, not doing the constant-time-operations string
optimizations, which is much work for not much manifestly apparent gain,
but rather file operations, I think. Opening and creating files with
Unicode paths – in an amazing coincidence someone just now directed me
to my old code for that in an SO answer, by upvoting.

Constructive thoughts?


Cheers, & new year survival to all! :),

- Alf

[Alf P. Steinbach]

On 1/4/2016 12:39 AM, Alf P. Steinbach wrote:
> ...

It's been several days (half a week? more?) since I did anything with
the cppx code, but now I sat down and fixed two COMPILER-SPECIFIC issues:

https://github.com/alf-p-steinbach/cppx/commit/40c9fb367a0c00479cdd374b0c7bba01fc5caef2

• g++, at least as of 4.8.2, has a compiler bug where it requires a
template value parameter to be type size_t, no other type will do.

• MSVC, at least as of 2015 update 1, has a library bug where after
narrow string output to a wide stream, it fails to flush that output
(e.g. when using std::flush or when input is performed).

An additional issue with MSVC, that I've not yet coded up a fix for,
concerns the translation of narrow characters to wide characters in wide
stream output. g++, with the standard library implementation used for
MinGW, gets this right, but MSVC acts as if directly copying the
character code should work, and it doesn't. Well, later.

I think that as of 2015 one really should not have to deal with such
compiler-specific issues, /non-conformance in the basics/.

Cheers,

- Alf