Hi all,
Thanx, I was not aware of the type conversion operator... It seems that in this
case the compiler doesn't realize that it should do the implicit conversion...
Anyway, I used Andrew's suggestion and added a function that returns the
IOHandle&, fixed the call in 2 places I think, and it worked.
Now I have another issue, which I fear is not going to be an easy one to
resolve.
[ 5%] Building CXX object
src/CMakeFiles/qpidcommon.dir/qpid/framing/SequenceSet.o
cd /achinst/atk/qpid_build/build/src && /usr/vacpp/bin/xlC -+
-Dqpidcommon_EXPORTS -DHAVE_CONFIG_H -qthreaded -qhalt=e -qrtti=all
-qtemplateregistry=/achinst/atk/qpid_build/build/template_registry
-qstaticinline -qalias=noansi -qtls -g -I/usr/local/include/boost-1_34
-I/achinst/atk/qpid_build/qpidc-0.20/src
-I/achinst/atk/qpid_build/qpidc-0.20/src/../include
-I/achinst/atk/qpid_build/build/src
-I/achinst/atk/qpid_build/build/src/../include -I/usr/local/include -o
CMakeFiles/qpidcommon.dir/qpid/framing/SequenceSet.o -c
/achinst/atk/qpid_build/qpidc-0.20/src/qpid/framing/SequenceSet.cpp
"/usr/local/include/boost-1_34/boost/bind.hpp", line 66.22: 1540-0065 (S) The
qualifier "F" is neither a class nor a namespace.
"/usr/local/include/boost-1_34/boost/bind/bind_template.hpp", line 15.13:
1540-0700 (I) The previous message was produced while processing "struct
boost::_bi::result_traits<boost::_bi::unspecified,qpid::RangeSet<qpid::framing::SequenceNumber>
&(qpid::RangeSet<qpid::framing::SequenceNumber>::*)(const
qpid::Range<qpid::framing::SequenceNumber> &)>".
bind.hpp:
64 template<class F> struct result_traits<unspecified, F>
65 {
66 typedef typename F::result_type type;
67 };
The problem lies in line 243 in RangeSet.h:
240 template <class T> void RangeSet<T>::addSet(const RangeSet<T>& s) {
241 typedef RangeSet<T>& (RangeSet<T>::*RangeSetRangeOp)(const Range<T>&);
242 std::for_each(s.ranges.begin(), s.ranges.end(),
243 boost::bind((RangeSetRangeOp)&RangeSet<T>::operator+=,
this, _1));
244 }
So xlC is having problems calling bind function in bind.hpp.
Then I read FAQ on http://www.boost.org/doc/libs/1_53_0/libs/bind/bind.html and
tried with alternative call:
boost::bind<RangeSetRangeOp>((RangeSetRangeOp)&RangeSet<T>::operator+=, this,
_1));
which gives me:
"/usr/local/include/boost-1_34/boost/mem_fn.hpp", line 318.5: 1540-0142 (S)
cv-qualifiers must not be added to a typedef of function type.
"/usr/local/include/boost-1_34/boost/bind.hpp", line 278.36: 1540-0700 (I) The
previous message was produced while processing "class
boost::_mfi::dm<qpid::RangeSet<qpid::framing::SequenceNumber> &(const
qpid::Range<qpid::framing::SequenceNumber>
&),qpid::RangeSet<qpid::framing::SequenceNumber> >".
mem_fn.hpp:
314 template<class R, class T> class dm
315 {
316 public:
317
318 typedef R const & result_type;
319 typedef T const * argument_type;
As a side note, if I remove const, it goes further, but the compiler has
problems with all such lines, e.g.:
template<class U> R const & call(U & u, T const *) const
...
reports the same error, while changed to:
template<class U> R& call(U & u, T const *) const
...
it works. Of course, if I change all such occurences, the compiler starts to
complain about not maching params (const vs. not const)...
I have no idea why it doesn't work... it has to have some relevance to how the
compiler is handling partial template specialization. Any ideas?
Regards,
Ales
-----Original Message-----
From: Andrew Stitcher [mailto:[email protected]]
Sent: Tuesday, May 28, 2013 5:08 PM
To: [email protected]
Subject: Re: Building qpid C++ broker on AIX
On Tue, 2013-05-28 at 14:39 +0000, Steve Huston wrote:
> Hi Ales,
>
> The IOHandle conversion comes from this method on Socket:
>
> virtual operator const IOHandle&() const = 0;
>
> I've been having problems with this type of thing trying to get Qpid
> building XL C++ 11 too, so I'm not sure you'd be in much better shape
> with an updated compiler :-(
>
> Try putting a cast to const IOHandle& - let us know how that goes.
That conversion operator was put in because in a previous design Socket did in
fact extend IOHandle. But upon some refactoring that seemed like a bad idea -
it isn't obvious that 'Socket "is a" IOHandle' makes a lot more sense than
'Socket "has a" IOHandle'. Given that aggregation generally causes less
coupling than inheritance I think it is a better design, so I changed it and
added the conversion operator to deal with any code that still needed to do the
conversion.
All of which is long winded explanation to say it would be better to make the
conversion explicit and to add:
virtual const IOHandle& getIOHandle() const = 0; Obviously this may
cause some knock-on changes throughout the code base, but I suspect not too
many.
Try this and see if it helps your situation. if so changing Socket in this way
seems like a good idea to me.
Andrew
>
> -Steve
>
> > -----Original Message-----
> > From: Aleš Trček [mailto:[email protected]]
> > Sent: Monday, May 27, 2013 8:09 PM
> > To: [email protected]
> > Subject: Building qpid C++ broker on AIX
> >
> > Hi all,
> >
> > Since I obviously won't succeed with this so easily, I'm opening a
> > thread on the subject. Many thanks to all who can help me.
> >
> > System with AIX 5.3 / xlC 9.0 (yeah old as sh*t, but I can't do
> > anything about that soon) and Boost 1.34, building qpidc-0.20.
> > Anyway, I managed to go over some obstacles so far, but currently
> > I'm stuck with the following error(s):
> > [ 20%] Building CXX object
> > src/CMakeFiles/qpidcommon.dir/qpid/sys/posix/AsynchIO.o
> > "/achinst/atk/qpid_build/qpidc-0.20/src/qpid/sys/posix/AsynchIO.cpp"
> > , line
> > 96.5: 1540-0218 (S) The call does not match any parameter list for
> > "DispatchHandle::DispatchHandle".
> > "/achinst/atk/qpid_build/qpidc-0.20/src/qpid/sys/DispatchHandle.h",
> > line
> > 88.24: 1540-1283 (I)
> > "qpid::sys::DispatchHandle::DispatchHandle(const
> > qpid::sys::IOHandle &, Callback, Callback, Callback)" is not a viable
> > candidate.
> > "/achinst/atk/qpid_build/qpidc-0.20/src/qpid/sys/posix/AsynchIO.cpp"
> > , line
> > 96.12: 1540-0256 (I) A parameter of type "const qpid::sys::IOHandle &"
> > cannot be initialized with an expression of type "const qpid::sys::Socket".
> > "/achinst/atk/qpid_build/qpidc-0.20/src/qpid/sys/posix/AsynchIO.cpp"
> > , line
> > 168.5: 1540-0218 (S) The call does not match any parameter list for
> > "DispatchHandle::DispatchHandle".
> > "/achinst/atk/qpid_build/qpidc-0.20/src/qpid/sys/DispatchHandle.h",
> > line
> > 88.24: 1540-1283 (I)
> > "qpid::sys::DispatchHandle::DispatchHandle(const
> > qpid::sys::IOHandle &, Callback, Callback, Callback)" is not a viable
> > candidate.
> > "/achinst/atk/qpid_build/qpidc-0.20/src/qpid/sys/posix/AsynchIO.cpp"
> > , line
> > 168.20: 1540-0256 (I) A parameter of type "const qpid::sys::IOHandle &"
> > cannot be initialized with an expression of type "const qpid::sys::Socket".
> > "/achinst/atk/qpid_build/qpidc-0.20/src/qpid/sys/posix/AsynchIO.cpp"
> > , line
> > 306.5: 1540-0218 (S) The call does not match any parameter list for
> > "DispatchHandle::DispatchHandle".
> > "/achinst/atk/qpid_build/qpidc-0.20/src/qpid/sys/DispatchHandle.h",
> > line
> > 88.24: 1540-1283 (I)
> > "qpid::sys::DispatchHandle::DispatchHandle(const
> > qpid::sys::IOHandle &, Callback, Callback, Callback)" is not a viable
> > candidate.
> > "/achinst/atk/qpid_build/qpidc-0.20/src/qpid/sys/posix/AsynchIO.cpp"
> > , line
> > 306.20: 1540-0256 (I) A parameter of type "const qpid::sys::IOHandle &"
> > cannot be initialized with an expression of type "const qpid::sys::Socket".
> >
> > So, DispatchHandle has a constructor:
> > QPID_COMMON_EXTERN DispatchHandle(const IOHandle& h, Callback rCb,
> > Callback wCb, Callback dCb);
> >
> > which takes IOHandle& as the first parameter, however in AsynchIO,
> > the constructor is called with the qpid::sys::Socket e.g:
> > AsynchAcceptor::AsynchAcceptor(const Socket& s,
> > AsynchAcceptor::Callback
> > callback) :
> > acceptedCallback(callback),
> > handle(s, boost::bind(&AsynchAcceptor::readable, this, _1), 0, 0),
> > socket(s)
> >
> > (Member "handle" is of type DispatchHandle.)
> >
> > The thing is, IOHandle and Socket are totally unrelated. For this to
> > ever work, Socket would need to extend IOHandle (or one of its
> > derived classes). So the question is, how does this compile
> > anywhere? :)
> >
> > Regards,
> > Ales
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] For
> additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional
commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
