X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS,WEIRD_PORT
X-Spam-Check-By:	sourceware.org
MIME-Version:	1.0
In-Reply-To:	<356127.29325.qm@web25006.mail.ukl.yahoo.com>
References:	<356127 DOT 29325 DOT qm AT web25006 DOT mail DOT ukl DOT yahoo DOT com>
Date:	Fri, 30 Jan 2009 11:30:37 +0000
Message-ID:	<2ca21dcc0901300330h2d95351fyeeaa36a5d86887ad@mail.gmail.com>
Subject:	Re: C++ ambiguous template specialization (cygwin only)
From:	Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
To:	cygwin AT cygwin DOT com
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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/

- Raw text -