[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] still MSVC compilation problems
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] still MSVC compilation problems |
Date: |
Sun, 22 Jun 2008 04:11:53 +0200 |
On Sun, 22 Jun 2008 03:22:40 +0200 Vadim Zeitlin <address@hidden> wrote:
VZ> Would you have any ideas about how could this code possibly be changed to
VZ> accommodate this compiler? I'm afraid I ran out of ideas...
Of course, as so often, it was enough to post a plea for help to find
[what seems to be] a simple answer. Here is the diff which works around
this MSVC problem:
--- any_member.hpp 2008-04-11 14:33:29 +0000
+++ any_member.hpp 2008-06-22 01:58:43 +0000
@@ -101,6 +101,7 @@
virtual bool equals(placeholder const&) const = 0;
virtual std::string str() const = 0;
virtual std::type_info const& type() const = 0;
+ virtual void* get() const = 0;
};
// Implementation of class placeholder.
@@ -130,6 +131,7 @@
virtual bool equals(placeholder const&) const;
virtual std::string str() const;
virtual std::type_info const& type() const;
+ virtual void* get() const;
private:
ClassType* object_;
@@ -204,6 +206,13 @@
return typeid(ValueType);
}
+template<typename ClassType, typename ValueType>
+void* holder<ClassType,ValueType>::get() const
+{
+ LMI_ASSERT(object_);
+ return &(object_->*held_);
+}
+
// Definition of class any_member.
// This class is necessarily Assignable, so that a std::map can hold it.
@@ -369,9 +378,7 @@
}
typedef holder<ClassType,pmd_type> holder_type;
LMI_ASSERT(content_);
- pmd_type pmd = static_cast<holder_type*>(content_)->held_;
- LMI_ASSERT(object_);
- return &(object_->*pmd);
+ return static_cast<ExactMemberType *>(content_->get());
}
template<typename ClassType>
What do you think about this? It does, of course, use an ugly untyped get()
function and correspondingly uses static_cast to the right type when we
need to access it later but it doesn't look to be much worse to me than the
existing static_cast to holder_type (which makes MSVC instantiate
holder_type and thus can't be used with this compiler). Would this be
acceptable or, if not, could we at least use this version for MSVC while
keeping the old one for the other compilers? I'd prefer to apply the patch
as is (well, with some comments explaining what's going on) because the
advantage of the current version don't seem to outweigh the burden of
having to maintain 2 versions.
Finally, I still have unit test failures after this change:
**** test failed: Caught exception
'Symbol table for class class S ascribes no member named 'nonexistent'.'
when
'Symbol table for class S ascribes no member named 'nonexistent'.'
was expected.
[file any_member_test.cpp, line 367]
**** test failed: Caught exception
'Symbol table for class class S ascribes no member named 'nonexistent'.'
when
'Symbol table for class S ascribes no member named 'nonexistent'.'
was expected.
[file any_member_test.cpp, line 368]
**** test failed: Caught exception
'Cannot cast from 'int S::*' to 'struct base_datum'.'
when
'Cannot cast from 'int S::*' to 'base_datum'.'
was expected.
[file any_member_test.cpp, line 476]
but they seem to be due to the difference between the expected and real
value of std::type::info::name() so I think I should just add tests for
MSVC into any_member_test.cpp along the existing tests for g++ version. Do
you see anything wrong with this?
Thanks,
VZ
- [lmi] still MSVC compilation problems, Vadim Zeitlin, 2008/06/21
- Re: [lmi] still MSVC compilation problems,
Vadim Zeitlin <=
- 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, 2008/06/21