[
https://issues.apache.org/jira/browse/PROTON-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15825597#comment-15825597
]
Andrew Stitcher edited comment on PROTON-1383 at 1/17/17 7:54 AM:
------------------------------------------------------------------
[[email protected]] Unless the compiler is in error it does not complain
for every use of error_condition, just ones where it needs to know the struct
definition. It should not need the definition for a mere declaration of a
member function (as far as I have researched the matter)
So in your example: {{PN_CPP_EXTERN void close(const error_condition&);}} no
definition of {{error_condition}} is needed because nothing happens to an error
condition - the type is only referred to. When you use close in some code you
might need to create an {{error_condition}} and in that code you will need to
include the header file so that your code can do things with an
{{error_condition}}. Obviously link.cpp will also need to know about
{{error_condition}} to implement {{close()}}, but the header does not need to
know it to declare {{close()}}.
*Perhaps you could paste the precise error message you are seeing with some
lines of context either side to help me understand better what the compiler is
complaining about.*
In general a cpp that uses any type (as opposed to just referring to the type)
will need to include the header file for that type (if they didn't how would
they be able to use the type at all). But header files that only make
declarations that use the type should not need definitions.
There is a possible exception here for return types as the user may not know
what returns type are in use by a header file if he uses "auto" to define his
variables. However for the moment I have been strict on that case everywhere
and make the user include header files for all used types even if they are
because of types returned.
So I've been pretty careful to only include the necessary header files in other
header files because it can make a huge difference to compile time after more
development work adds even more transitive dependencies.
was (Author: astitcher):
[[email protected]] Unless the compiler is in error it does not complain
for every use of error_condition, just ones where it needs to know the struct
definition. It should not need the definition for a mere declaration of a
member function (as far as I have researched the matter)
*Perhaps you could paste the precise error message you are seeing with some
lines of context either side to help me understand better what the compiler is
complaining about.*
In general a cpp that uses any type (as opposed to just referring to the type)
will need to include the header file for that type (if they didn't how would
they be able to use the type at all). But header files that only make
declarations that use the type should not need definitions.
There is a possible exception here for return types as the user may not know
what returns type are in use by a header file if he uses "auto" to define his
variables. However for the moment I have been strict on that case everywhere
and make the user include header files for all used types even if they are
because of types returned.
So I've been pretty careful to only include the necessary header files in other
header files because it can make a huge difference to compile time after more
development work adds even more transitive dependencies.
> Add missing includes to fix Solaris compilation
> -----------------------------------------------
>
> Key: PROTON-1383
> URL: https://issues.apache.org/jira/browse/PROTON-1383
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.16.0
> Reporter: Adel Boutros
> Assignee: Andrew Stitcher
> Labels: patch
> Fix For: 0.17.0
>
> Attachments: 0002-add-missing-includes.patch
>
>
> All details available here:
> http://qpid.2158936.n2.nabble.com/Proton-0-16-0-Solaris-Unit-tests-hanging-when-destroying-connection-driver-td7657231.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
