Created attachment 286337 [details] [review]
Make giomm tests runnable under Windows

Hi,

First up is the updates to the giomm_ioerror and giomm_simple tests, as they use /etc/fstab, which is *nix/Cygwin only, which will cause the tests to throw an exception as /etc/fstab could not be found.  The proposed patch looks for the Wordpad executable (c:/Windows/write.exe) on Windows as it is a standard part of it, and /etc/fstab otherwise.  The tests will therefore pass on Windows builds...

Created attachment 286338 [details] [review]
Fix build of glibmm_ustring_compose on Visual Studio

Hi,

Later Visual Studio versions are quite picky regarding type casting, so we need to do some casting to the string so that the test will build and run.

These are what I have for now.

With blessings, thank you!

Review of attachment 286337 [details] [review]:

Looks good. Please push.

Review of attachment 286338 [details] [review]:

Isn't there some way to make this work without the need for the strange cast?

Created attachment 286359 [details] [review]
Fix build of glibmm_ustring_compose on Visual Studio (take ii)

Hello Murray,

Thanks for the review, attachment 286337 [details] [review] was pushed as d95bc556.

This is the revised patch for glibmm_ustring_compose.

With blessings, thank you!

With the patch in comment 5 Glib::ustring::compose() is not called with
a string literal. The test does not test what it intends to test.
If it's not possible to call compose() with a string literal, I suppose either
compose() should be fixed, or if that's not possible, a note need to be added
to its description.

Why doesn't Visual Studio accept the call with a string literal? Does it
print an understandable error message?

Hello Kjell,

This is what I get, oddly:

c:\gnome.build.unstable\vs10\Win32\include\glibmm-2.4\glibmm/ustring.h(1340) : e
rror C2668: 'Glib::ustring::Stringify<T>::Stringify' : ambiguous call to overloa
ded function
        with
        [
            T=const char [15]
        ]
        c:\gnome.build.unstable\vs10\Win32\include\glibmm-2.4\glibmm/ustring.h(1
272): could be 'Glib::ustring::Stringify<T>::Stringify(const char *)'
        with
        [
            T=const char [15]
        ]
        c:\gnome.build.unstable\vs10\Win32\include\glibmm-2.4\glibmm/ustring.h(1
269): or       'Glib::ustring::Stringify<T>::Stringify(T (&))'
        with
        [
            T=const char [15]
        ]
        while trying to match the argument list '(const char [15])'
        main.cc(18) : see reference to function template instantiation 'Glib::us
tring Glib::ustring::compose<const char[15]>(const Glib::ustring &,T1 (&))' bein
g compiled
        with
        [
            T1=const char [15]
        ]
c:\gnome.build.unstable\vs10\Win32\include\glibmm-2.4\glibmm/ustring.h(1351) : e
rror C2668: 'Glib::ustring::Stringify<T>::Stringify' : ambiguous call to overloa
ded function
        with
        [
            T=const char [15]
        ]
        c:\gnome.build.unstable\vs10\Win32\include\glibmm-2.4\glibmm/ustring.h(1
272): could be 'Glib::ustring::Stringify<T>::Stringify(const char *)'
        with
        [
            T=const char [15]
        ]
        c:\gnome.build.unstable\vs10\Win32\include\glibmm-2.4\glibmm/ustring.h(1
269): or       'Glib::ustring::Stringify<T>::Stringify(T (&))'
        with
        [
            T=const char [15]
        ]
        while trying to match the argument list '(const char [15])'
        main.cc(19) : see reference to function template instantiation 'Glib::us
tring Glib::ustring::compose<const char*,const char[15]>(const Glib::ustring &,c
onst T1 &,T2 (&))' being compiled
        with
        [
            T1=const char *,
            T2=const char [15]
        ]

Created attachment 286568 [details] [review]
ustring.h: Add specialization for string literals in the form of const char[N]

Hi,

This patch attempts to fix the part using string literals where they are taken as const char[N] by compilers, such as under Visual Studio.

With blessings, thank you!

Glib::ustring::Stringify has a rather strange set of specializations.
There are specializations for Glib::ustring, const char* and char[],
but there are no specializations for const Glib::ustring, char*,
const char[], std::string or const std::string.

I added calls to Glib::ustring::compose() with all of these:
  char arr[] = "array";
  const char carr[] = "const array";
  char* parr = arr;
  const char* pcarr = carr;
  Glib::ustring ustr = "ustring";
  const Glib::ustring custr = "const ustring";
  std::string str = "std::string";
  const std::string cstr = "const std::string";

g++ accepted all the calls. It did not report any ambiguous calls.
Strange, actually!

I also tested your patch. It does not cause any problems when compiling with
g++. 'make' and 'make check' still work. If the patch solves a problem for
Visual Studio, I recommend that you push it.

Hello Kjell,

I agree that it's odd in this sense, but anyways, thanks for the reviews and patience though.

I have pushed attachment 286568 [details] [review] as 169cce1e.

Will close this bug now, as this bug is a Visual Studio-related build issue.

With blessings, thank you!

Review of attachment 286568 [details] [review]:

::: glib/glibmm/ustring.h
@@ +1328,3 @@
 
+/** A template specialization for Stringify<const char[N]> (for string literals),
+ * because the regular template has ambiguous constructor overloads for char*.

Please mention that it's ambiguous only on MSVC++.

Hello Murray,

(In reply to comment #11)
>...
> Please mention that it's ambiguous only on MSVC++.

Just did that in commit b2599d49, thanks for the reminder.

With blessings, thank you!