Return-Path: 
 <stdcxx-dev-return-3077-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org
Received: (qmail 78706 invoked from network); 29 Mar 2007 18:38:38 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 29 Mar 2007 18:38:38 -0000
Received: (qmail 49788 invoked by uid 500); 29 Mar 2007 18:38:46 -0000
Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org
Received: (qmail 49780 invoked by uid 500); 29 Mar 2007 18:38:46 -0000
Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:stdcxx-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:stdcxx-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:stdcxx-dev@incubator.apache.org>
List-Id: <stdcxx-dev.incubator.apache.org>
Reply-To: stdcxx-dev@incubator.apache.org
Delivered-To: mailing list stdcxx-dev@incubator.apache.org
Received: (qmail 49769 invoked by uid 99); 29 Mar 2007 18:38:45 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Mar 2007 11:38:45 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: local policy)
Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Mar 2007 11:38:36 -0700
Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59])
	by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l2TIbG0d004241
	for <stdcxx-dev@incubator.apache.org>; Thu, 29 Mar 2007 18:37:17 GMT
Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with
 Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 29 Mar 2007 12:38:07 -0600
Message-ID: <460C079F.7010803@roguewave.com>
Date: Thu, 29 Mar 2007 12:38:23 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: [PATCH] dynatype.cpp example and MSVC
References: <7BDB2168BEAEF14C98F1901FD2DE6438656E17@epmsa009.minsk.epam.com>
In-Reply-To: <7BDB2168BEAEF14C98F1901FD2DE6438656E17@epmsa009.minsk.epam.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Mar 2007 18:38:07.0163 (UTC)
 FILETIME=[64B0F0B0:01C77231]
X-Virus-Checked: Checked by ClamAV on apache.org

Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Wednesday, March 28, 2007 10:35 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PATCH] dynatype.cpp example and MSVC
>>
>> This looks familiar. Didn't I already review this patch?
>>
>> [...searching archives...]
>>
>> I see you original patch in our archive 
>> (http://tinyurl.com/ywxq9w) but I can't find my reply there. 
>> I was able to find it here though:
>> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/ms
>> g02760.html
>>
>> but I haven't found any further follow-ups on the issues I 
>> raised, either from you or anyone else.
>>
> 
>   I have not received the reply from you. 
> 

Yeah, the lists (or at least the archives) seem to have some
problems. I've opened another issue for these missing emails
with the infrastructure team:
   https://issues.apache.org/jira/browse/INFRA-1209

>>>     @@ -105,27 +105,19 @@
>>>
>>>     // 14.7.3, p6 - explicit specializations must be defined before
> first
>>>     use
>>>      template <>
>>>     -inline void dynatype::remove<dynatype::map<void> >()
>>>     +inline void dynatype::remove<void>()
>>>
>> The replacement doesn't look equivalent to the original. Is it correct
>> for compilers other than MSVC?
> 
>   Why not?

Only because void isn't the same thing as dynatype::map<void>.

> 
>   The dynatype::remove<dynatype::map<void> > used only in default
> constructor,
> because the dynatype::map<void> type is private type, so here that type
> can be
> replaced to the type void.

I think I understand what you did now. I also tested the patch
with both the latest EDG eccp as well as gcc so the change must
be good. Thanks for your patience :)

> 
>   This change deals with MSVC error:
> dynatype.cpp(109) : error C2248: 'dynatype::map<T>' : cannot access
> private struct declared in class 'dynatype'
>         with
>         [
>             T=void
>         ]
>         dynatype.cpp(31) : see declaration of 'dynatype'
> 
> 
>   The dynatype::operator= (const dynatype::map<void>&) removed because
> it's never used.

Could it ever be used? Imagine dynatype being a general class
provided by a library. Does there exist a valid use case for
this operator? If not, I have no problem with removing it.
Otherwise, if it doesn't break anything, let's keep it.

> 
>   The CREF macro used to resolve ambiguity between dynatype::operator T&
> () and dynatype::operator T () const:

This was and still is my objection to this patch. As I said
in my initial comments on it:

   The examples should be portable C++, i.e., free of #ifdef's
   and other platform-specific workarounds. Unless there's a
   way to get it to work with the compiler I'm not sure we
   should pollute the code with hacks for broken compilers.

Can you think of a way to work around this bug that doesn't
involve MSVC-specific #ifdefs or macros?

> 
> dynatype.cpp(188) : error C2440: 'type cast' : cannot convert from
> 'dynatype' to 'int'
>         Ambiguous user-defined-conversion
> 
> 
>> Btw., do you have a test case for the MSVC bug that prevents the code
> from compiling?
> 
> The first test:

Excellent! Can I ask you to do the usual two things:

1. Report this issue to Microsoft (http://tinyurl.com/yq66vu).
2. Copy the text of the issue to Jira.

If you don't have a Microsoft Connect account you should
create one (it's free). If you run into any trouble let me
know, I can either help you get it set up, try to get you
help from someone at Microsoft, or file the bug myself.

Martin

> -----------------------------------
> class test
> {
>     struct private_t;
> 
>     template <class T>
>     int foo () {
>         return 1;
>     }
> };
> 
> template <>
> int test::foo<test::private_t> ()
> {
>     return 2;
> }
> 
> int main ()
> {
>     return 0;
> }
> -----------------------------------
> 
> test.cpp(13) : error C2248: 'test::private_t' : cannot access private
> struct declared in class 'test'
>         test.cpp(3) : see declaration of 'test::private_t'
>         test.cpp(2) : see declaration of 'test'
> 
> 
>   The second test:
> 
> -----------------------------------
> class test
> {
> public:
>     template <class T>
>     operator T& () {
>         static T x_;
>         return x_;
>     }
> 
>     template <class T>
>     operator T () const {
>         return T (1);
>     }
> };
> 
> int main ()
> {
>     test t;
>     int x = int (t);
>     return 0;
> }
> -----------------------------------
> 
> test.cpp(19) : error C2440: 'type cast' : cannot convert from 'test' to
> 'int'
>         Ambiguous user-defined-conversion
> 
> 
> Farid.