[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] still MSVC compilation problems
From: |
Greg Chicares |
Subject: |
Re: [lmi] still MSVC compilation problems |
Date: |
Sun, 22 Jun 2008 02:39:16 +0000 |
User-agent: |
Thunderbird 2.0.0.14 (Windows/20080421) |
On 2008-06-22 01:22Z, Vadim Zeitlin wrote:
>
> I'm about ready to just accept the defeat in my struggle to make LMI code
> compilable with MSVC. I spent quite a lot of time on this already but
> unfortunately it seems that there is just something fundamentally wrong in
> (all versions, including 2008 one, of) the compiler which prevents it from
> compiling the code in any_member.hpp. More precisely, it's the
> any_member<ClassType>::exact_cast() function which can't be compiled
> because it insists on fully instantiating holder<ClassType,pmd_type> (even
> though normally MSVC 7+ does understand the concept of SFINAE).
>
> Would you have any ideas about how could this code possibly be changed to
> accommodate this compiler? I'm afraid I ran out of ideas...
At first I was going to ask whether we could use this function instead
of exact_cast(), conditionally, for msvc:
template<typename MemberType, typename ClassType>
MemberType* member_cast(any_member<ClassType>& member)
{
MemberType* z = (member.type() == typeid(MemberType ClassType::*))
? member.template exact_cast<MemberType>()
: reconstitutor<MemberType,ClassType>::reconstitute(member)
;
[...throw if z is NULL]
but the first '?:' branch calls exact_cast(), and the alternative...
calls exact_cast().
I guess that if we can get this example to work, then we've solved
the problem, because other uses of member_cast() are so similar:
datum_base const* Input::DoBaseDatumPointer
(std::string const& name
) const
{
#if !defined APPROPRIATE_MSVC_MACRO
return member_cast<datum_base>(operator[](name));
#else // defined APPROPRIATE_MSVC_MACRO
return ?????????
#endif // defined APPROPRIATE_MSVC_MACRO
}
But IIRC that function returns a datum_base* that must point to an
object of a (deduced) derived class, so
(datum_base*)(&something)
won't work: what we need is like this:
(datum_base*)(deduced_class*)(&something)
But that's just what exact_cast() does, so we're back to the original
problem; let's look for another approach....
> it insists on fully instantiating holder<ClassType,pmd_type>
Is there some way to instantiate it? Is this one of the problems shown
in this
http://lists.nongnu.org/archive/html/lmi/2008-01/msg00010.html
message? For instance, if it's this:
error C2259: 'datum_base' : cannot instantiate abstract class
1> due to following members:
1> 'std::istream &datum_base::read(std::istream &)' : is
abstract
then could we just do the following?
class LMI_SO datum_base
{
...
#if !defined APPROPRIATE_MSVC_MACRO
virtual std::istream& read (std::istream&) = 0;
#else // defined APPROPRIATE_MSVC_MACRO
virtual std::istream& read (std::istream&);
#endif // defined APPROPRIATE_MSVC_MACRO
- [lmi] still MSVC compilation problems, Vadim Zeitlin, 2008/06/21
- Re: [lmi] still MSVC compilation problems, Vadim Zeitlin, 2008/06/21
- Re: [lmi] still MSVC compilation problems, Greg Chicares, 2008/06/21
- Re[2]: [lmi] still MSVC compilation problems, Vadim Zeitlin, 2008/06/22
- Re: [lmi] still MSVC compilation problems, Greg Chicares, 2008/06/24
- Re[2]: [lmi] still MSVC compilation problems, Vadim Zeitlin, 2008/06/24
- Re: [lmi] still MSVC compilation problems, Greg Chicares, 2008/06/24
- [lmi] Re: patch to avoid hard coding RTTI types names in the tests (was: still MSVC compilation problems), Vadim Zeitlin, 2008/06/30
Re: [lmi] still MSVC compilation problems,
Greg Chicares <=