qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PROTON-1831) [C++ binding] Nested complex types fail compilation with "incomplete type" error
Date Fri, 27 Apr 2018 16:59:00 GMT

    [ https://issues.apache.org/jira/browse/PROTON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16456744#comment-16456744

ASF GitHub Bot commented on PROTON-1831:

Github user gemmellr commented on the issue:

    > Thanks - I didn't know about stolen. I think we could implement what the spec says
on the server side - close the old link/handle with "stolen" and create a new link under the
new handle.
    In the same place its doing it now, or for the whole connection? (Still leaving other
connections as something for the using server, e.g dispatch, to handle on its own).
    Its worth saying that it doesnt currently check the handle is appropriate as it chokes
on the name first. It'd need to check the handles more fully too, e.g two attaches with the
same name and the same remote handle would still be an session:handle-in-use error.
    > That would fix the crash, which was because of multiple handles to the same link
object - we'd have a seprate link object for each handle, all but one of which are closed
with "stolen". 
    One further annoyance is how to inform the stuff already using the link that this all
    As I mentioned elsewhere before, this also starts getting into issues with limits checking
e.g maxHandles (as it may still be 'in use' until the engine is processed later).
    >I think on the client side its always an error to try to attach if you already have
a link with same name an a handle. After disconnect all handles are cleared, so it is OK an
error to re-attach during reconnect. I want to fix the client to refuse to create a link at
all in this case. That would prevent this happening on the wire and give more immediate feedback
to code that is mistakenly trying to double-attach. 
    I think thats fair personally, always have.
    > The fix is not trivial due to proton's batch-processing madness or I'd have done
it first.
    I feel your pain from previously looking at similar stuff :)

> [C++ binding] Nested complex types fail compilation with "incomplete type" error
> --------------------------------------------------------------------------------
>                 Key: PROTON-1831
>                 URL: https://issues.apache.org/jira/browse/PROTON-1831
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: cpp-binding
>            Reporter: Kim van der Riet
>            Assignee: Alan Conway
>            Priority: Major
> When using nested complex types (for example, a list of maps or an array of lists), the
compiler fails to compile. For example, the following code snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include <map>
> #include <vector>
> #include <proton/types.hpp>
> int main(int, char**) {
>     std::map<proton::value, proton::value> m1 = {{uint8_t(0), "zero"}, {uint8_t(1),
>     std::map<proton::value, proton::value> m2 = {{true, "true"}, {false, "false"}};
>     std::vector<std::map<proton::value, proton::value> > am = {m1, m2};
>     proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of ‘proton::codec::encoder&
proton::codec::operator<<(proton::codec::encoder&, const std::vector<_Tp, _Alloc>&)
[with T = std::map<proton::value, proton::value>; A = std::allocator<std::map<proton::value,
proton::value> >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename proton::value::assignable<T,
proton::value&>::type proton::value::operator=(const T&) [with T = std::vector<std::map<proton::value,
proton::value> >; typename proton::value::assignable<T, proton::value&>::type
= proton::value&]’
> install/include/proton/./value.hpp:79:85: required from ‘proton::value::value(const
T&, typename proton::value::assignable<T>::type*) [with T = std::vector<std::map<proton::value,
proton::value> >; typename proton::value::assignable<T>::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type ‘proton::internal::type_id_of<std::map<proton::value,
proton::value> >’ used in nested name specifier
>     return e << encoder::array(x, internal::type_id_of<T>::value);
>                 ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> {noformat}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message