Manuel Teira Paz wrote:
Hello.
Trying to get the solaris port in sync with trunk changes, I've found
errors in a new overloading of qpid::client::Connection::open introduced
in revision 693918 by aconway. It doesn't compile on solaris, and the
guilty seems to be:
const TcpAddress* tcp = i->get<TcpAddress>();
The SunCC compiler doesn't like get as a method of Url, and as far as I
see, it isn't. What I've made, after a fast read about boost:variant,
was to change it to looks like this:
const qpid::TcpAddress tcp = boost::get<qpid::TcpAddress>(*i);
and using tcp later as an object, not a pointer.
I'm not sure about the qpid:: qualifier in TcpAddress being needed,
since there's not a 'using namespace qpid' , are names from parent
namespaces directly available in nested ones?
So, did it compile in gcc-linux in the previous form? And, do you agree
with the changes made?
Alan, you're probably the best person to answer that question.
And a new question regarding this. Now that I should have commit rights,
what's the way to proceed? For example, do you think a change like this
one, should be discussed before commit? Should I open JIRA issues for
these changes? Is there any document about commit policies in the
project or something similar?
We don't have any official policies on the c++ side of things at
present, relying on common sense judgements by committers really.
My view is that changes for platform issues should probably at least be
commented (in the code or at least in the svn log) so that people on
other platforms start to learn what causes problems (and don't
re-introduce the problem by later changes).
For some issues JIRAs may be extremely valuable. For others where the
JIRA is created and closed as the fix is committed (and contains the
same text as the svn log!), it seems unnecessary to me.
Its never a problem to discuss before a commit, its just a judgement
call by individuals really. Everyone should also feel comfortable
pointing out issues after they see a commit they have concerns over either.
And of course if people feel that a different way of working would be
beneficial, they can bring that up for discussion also. Whatever works best.
