After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 506410 - Call of overloaded Stringify is ambiguous
Call of overloaded Stringify is ambiguous
Status: RESOLVED FIXED
Product: glibmm
Classification: Bindings
Component: strings
2.15.x
Other All
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2007-12-30 13:10 UTC by Szilárd Pfeiffer
Modified: 2008-10-20 14:37 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
Proposed patch (2.86 KB, patch)
2008-10-08 14:04 UTC, Armin Burgmeier
none Details | Review

Description Szilárd Pfeiffer 2007-12-30 13:10:27 UTC
Please describe the problem:
In case of string literals or character pointers cause compilation problem.

Steps to reproduce:
Test case:

#include <glibmm.h>

#include <iostream>

int main(int, char**)
{
  Glib::init();

  using Glib::ustring;

  const char *constant_string = "constant string";

  std::cout
    << ustring::compose("Compose strings: %1, %2.", constant_string, "literal string")
    << std::endl;

  return 0;
}


Actual results:
Compiler error message:

/usr/local/include/glibmm-2.4/glibmm/ustring.h: In static member function ‘static Glib::ustring Glib::ustring::compose(const Glib::ustring&, const T1&, const T2&) [with T1 = const char*, T2 = char [15]]’:
test.cc:14:   instantiated from here
/usr/local/include/glibmm-2.4/glibmm/ustring.h:1276: error: call of overloaded ‘Stringify(const char* const&)’ is ambiguous
/usr/local/include/glibmm-2.4/glibmm/ustring.h:1243: note: candidates are: Glib::ustring::Stringify<T>::Stringify(const char*) [with T = const char*]
/usr/local/include/glibmm-2.4/glibmm/ustring.h:1242: note:                 Glib::ustring::Stringify<T>::Stringify(const T&) [with T = const char*]
test.cc:14:   instantiated from here
/usr/local/include/glibmm-2.4/glibmm/ustring.h:1277: error: call of overloaded ‘Stringify(const char [15])’ is ambiguous
/usr/local/include/glibmm-2.4/glibmm/ustring.h:1243: note: candidates are: Glib::ustring::Stringify<T>::Stringify(const char*) [with T = char [15]]
/usr/local/include/glibmm-2.4/glibmm/ustring.h:1242: note:                 Glib::ustring::Stringify<T>::Stringify(const T&) [with T = char [15]]


Expected results:


Does this happen every time?


Other information:
The following patch or the patch in bug 506394 comment 0 may solve the problem.

Index: glib/glibmm/ustring.h
===================================================================
--- glib/glibmm/ustring.h       (revision 490)
+++ glib/glibmm/ustring.h       (working copy)
@@ -1240,7 +1240,6 @@
 
 public:
   explicit inline Stringify(const T& arg) : string_ (ustring::format(arg)) {}
-  explicit inline Stringify(const char* arg) : string_ (arg) {}
   inline const ustring* ptr() const { return &string_; }
 };
Comment 1 Murray Cumming 2008-01-20 18:20:03 UTC
CCing Daniel, who wrote that code. Let's make sure that we correct this before releasing this in glibmm 2.16.0.

And why is Stringify() not stringify()?
Comment 2 Murray Cumming 2008-08-06 08:34:11 UTC
I have fixed this for const char*, by adding a Stringify<> template specialization.

But I can't seem to find the correct syntax to provide a Stringify<> template specialization for string literals. An attempt at that is commented-out in ustring.h in svn trunk, and a test for it is commented out in tests/glibmm_ustring_compose/main.cc.

I would appreciate it if you could take a look.
Comment 3 Armin Burgmeier 2008-10-08 12:32:14 UTC
Could it be that the string_ member of that specialization should be a value rather than a reference? MSVC 2008 says:

1>c:\msys\home\Armin\gnome\glibmm-2.18.0\glib\glibmm/ustring.h(1282) : warning C4413: '' : reference member is initialized to a temporary that doesn't persist after the constructor exits

I believe it is right.
Comment 4 Armin Burgmeier 2008-10-08 14:04:21 UTC
Created attachment 120186 [details] [review]
Proposed patch

This patch fixes this issue, and it also enables the specialization for string literals.
Comment 5 Murray Cumming 2008-10-20 14:37:00 UTC
Excellent. Committed. Thanks.