Wide space input support

[WilcoBT]

Due to internationalisation, everything here has to go in wide characters. I discovered an uncommited change floating around here to run tests with wide character parameter input support that might be useful here as well.

[basvodde]

Also thanks for your pull requests. Also, as started, the tests are missing. Perhaps you want to add them to the pull request? Also, the try/catch isn't going to get accepted like that. We avoid using exception handling, except in specific places (and then only when providing an alternative)

[WilcoBT]

Hmm, adding that tests isn't exactly trivial. The moment I add a test that actually uses the "RunAllTests" public interface I get access violations in the memory leak reporting. I get the impression it is interfering with itself as it seems it runs itself for these commandlinetestrunner tests. I suspect this explains why the following test is thus missing:

TEST( CommandLineTestRunner, VerifyRunAllTests ) {
    const char* argv[] = { "dummy.exe", "-fdskjnfkds" };

    CommandLineTestRunner::RunAllTests( 2, argv );

    LONGS_EQUAL( 0, registry.countPlugins() );
}

So I guess this means I can't test the complete function but have to do with extracting the conversion from wide and adding a test for that.

[arstrube]

Maybe make your test more like the existing ones, e.g.

const char* argv[] = { "dummy.exe", "-fdskjnfkds" };
CommandLineTestRunner commandLineTestRunner(2, argv, &output, &registry);
commandLineTestRunner.runAllTestsMain();

Also, maybe look at CommandLineArgumentsTest.

[WilcoBT]

No, because that is already at a level that everything is normal characters. I only added a top level that transforms from wide to normal such that that level can stay the same.

[WilcoBT]

oeps, wrong button

[arstrube]

I was actually wondering that in your test you declare the args as const char*?

[WilcoBT]

I mirrored the const/not constness of the normal char RunAllTests functions where the actual code is also in the const arguments version. From that, and that the argumenets are only read, follows that the input of the conversion function is also a const.

[WilcoBT]

Well, it looks at Travis like I still have some crossplatform compatibility work to do...

[arstrube]

I meant char as opposed to wchar_t, sorry.

[arstrube]

I also meant passing in the address of output and registry to the constructor, as opposed to not to.

[WilcoBT]

The test I placed here was more about signalling a problem trying to test the top level function before any of my changes so still with the normal chars.

And that passing is only possible one level lower that I am not touching and also using from the wide top level functions.
I'm used to equalising these things at the front door.

[WilcoBT]

Ok, I have an error on Travis CI that I don't get and my colleague's have no idea either. But we normally program for Windows (CE5/7)
Any clue how to fix this? Seems an internal issue:

/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu/bits/os_defines.h:40:10: fatal error:
'features.h' file not found
#include <features.h>
^
1 error generated.

[basvodde]

Hmm, the wchar_t does raises some questions on support on embedded platforms. @arstrube do you know the cl2000 support of wchart_t? I assume wchar_t is one of the first things to go?

[basvodde]

Direct dependencies with Lib C aren't allowed in CppUTest. You'd need to wrap the methods in PlatformSpecific to deal with portability to "less supported" platforms.

[WilcoBT]

Ah, that makes sense.

[arstrube]

@basvodde I don't know offhand about wchar_t. What I do know is that, due to limited memory, we had to use the non-std-C++ lib option. I suppose that means at least the conversion functions won't be available for the cl2000.

[arstrube]

seems to be a c lib though.

[basvodde]

Yeah, though we are going to have problems with wchar_t not being a type without #include...

[WilcoBT]

Well as I was adding this one as a sidenote while fixing the verbose junit combinetion I can't invest to much time in this. I am getting the feeling I'd better move the conversion to our mains and be done with it.

An interesting experience though, discovering the details to keep in mind. But something I rather not work on with only a continuous integration server to verify with.

[basvodde]

@WilcoBT Though, I like to have wchar_t support... I'm wondering whether we should. Would you mind explaining a bit how you ended up implementing it, so that we can understand why it was needed.

The reason for this is:

• It will mean several PlatformSpecific methods to wrap C-lib, which would mean additional effort for porting them
• I'm not sure if the wchar_t can be used without an #include (which caused problems with size_t)

If the reason for adding these is worth the effort, I'm definitively for it. Just want to reflect on that before continuing...

[WilcoBT]

I didn't implement it. I found it in our local git clone. But the reason it was added it because we have test suites for multiple repositories(a shared and a few products). Practically each such suite is build in visual studio with unicode support which automagically gives the arguments in wchars.
To avoid code duplication of the conversion in the main of all these test suites, I'd rather have cppUtest be able to handle it.

[arstrube]

@WilcoBT putting it into your own main() is an excellent idea in your case.

We have set up all our tests suites to share the same main() ;-)

There need not be any code duplication that way. We have put our CppUTestMain.cpp into a the folder above the CppUTest lib and headers, but anywhere is fine.

[WilcoBT]

no, multiple mains :) one per repository
I have to see if I can do something with the shared though.

[arstrube]

P.S. Just that VS likes putting a main() in when you create a new project doesn't mean it has to be there. You can safely delete all those and then add the one and only main that contains your wide character support.

[basvodde]

So, what do we do with the wchar_t support? need it? Decline as we don't want the additional dependencies? We could just leave it open for now and see if other people would want it?