incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [PATCH] dynatype.cpp example and MSVC
Date Thu, 29 Mar 2007 19:12:35 GMT
Btw., I should mention that I have no objection to immediately
committing the first part of this patch, i.e., everything but
the #ifdefs and the CREF() macro. That we can deal with later.

Martin

Martin Sebor wrote:
> 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.
> 


Mime
View raw message