This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ ambiguous template specialization (cygwin only)


Marco Atzeri wrote:
> Dear all,
> unfortunately I am not too much familiar with C++,
> so I have no clue where to look for difference
> between Cygwin and all the other platforms where this
> problem does not happen.

  I'm not that hot on C++ templates either, but it's probably something to do
with different native types affecting name resolution at a guess.

> Only on cygwin, both with gcc-3 and gcc-4,
> the building from last development
> sources of octave-3.1.51+  stop here:

> Any suggestion ?

#1:  Use STLfilt!

BD Software STL Message Decryptor v3.10 for gcc 2/3/4
../../octave_local/liboctave/oct-inttypes.cc:516: error: ambiguous template
    specialization `mop<octave_int_cmp_op::ne>' for
   `bool octave         _int_cmp_op::mop(uint64_t, double)'
../../octave_local/liboctave/oct-inttypes.h: In function
   `bool operator<(const double &, const octave_int<uint64_t> &)':
../../octave_local/liboctave/oct-inttypes.h:1054:error: call of overloaded
   `mop(const double &, uint64_t)' is ambiguous
../../octave_local/liboctave/oct-inttypes.h:193: candidates are: static bool
    octave_int_cmp_op::mop(
        T,
double)
../../octave_local/liboctave/oct-inttypes.h:198:  static bool octave_int_cmp_op
    ::mop(double, long long unsigned int)
../../octave_local/liboctave/oct-inttypes.cc:60:  static bool octave_int_cmp_op
    ::mop(uint64_t, double)
../../octave_local/liboctave/oct-inttypes.cc:80:  static bool octave_int_cmp_op
    ::mop(int64_t, double)
../../octave_local/liboctave/oct-inttypes.cc:127:  static bool
    octave_int_cmp_op::mop(double, uint64_t)
../../octave_local/liboctave/oct-inttypes.cc:135:  static bool
    octave_int_cmp_op::mop(double, int64_t)

  Hmm.  The generic template with the <T> is less specific and shouldn't
matter if there's a more-specific one, which there is.  So, why doesn't the
(uint64_t, double) version match?  Well, looking at the other possible
matches, it seems to think that int64_t is as near a match.  I wonder if when
it doesn't have an exact match, it sees sign-extension and size-promotion as
equally different and therefore equally similar and therefore ambiguous.  You
could find a C++ expert to explain the resolution rules for you, but I think
that's the sort of basis on which it works.

  I wonder what would happen if, on Cygwin, uint64_t was a typedef for
unsigned long long int.  Does it help if you comment out the <double, long
long unsigned int> template on line 198, leaving just the <double, uint64_t>
on line 127 to be a precise match?

    cheers,
      DaveK

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]