further updates to support DLL import/export on Windows =)
add missing ROSCONSOLE_BACKEND_DECL (from previous visibility change) for console_backend.h
move console_impl functions shared by log4cxx, glog, print into one single header console_impl.h (and remove the function declarations from rosconsole.cpp)
as mentioned in the comments, the ROSCONSOLE_CONSOLE_IMPL_DECL macro is added to manage visibility for functions in the impl components in one centralized position. For the implementations (src/rosconsole/impl/rosconsole_xxx.cpp), ROSCONSOLE_CONSOLE_IMPL_EXPORTS needs to be defined in the .cpp file before including console_impl.h since these files are compiled to generate their own runtime binaries (dlls). Another way of achieving the same result would be to use independent visibility control macros for each implementation; however, that means more duplicated code and makes it harder to manage.
Another reason to use a centralized header is so that it'd be easier to notice when the declaration and definition have a mismatch (at compile time); otherwise, such mismatch would cause error at runtime, making it harder to spot.
dirk-thomas
commented
5 years ago
further updates to support DLL import/export on Windows =)
ROSCONSOLE_BACKEND_DECL(from previous visibility change) forconsole_backend.hconsole_implfunctions shared bylog4cxx,glog,printinto one single headerconsole_impl.h(and remove the function declarations fromrosconsole.cpp)as mentioned in the comments, the
ROSCONSOLE_CONSOLE_IMPL_DECLmacro is added to manage visibility for functions in the impl components in one centralized position. For the implementations (src/rosconsole/impl/rosconsole_xxx.cpp),ROSCONSOLE_CONSOLE_IMPL_EXPORTSneeds to be defined in the .cpp file before includingconsole_impl.hsince these files are compiled to generate their own runtime binaries (dlls). Another way of achieving the same result would be to use independent visibility control macros for each implementation; however, that means more duplicated code and makes it harder to manage.Another reason to use a centralized header is so that it'd be easier to notice when the declaration and definition have a mismatch (at compile time); otherwise, such mismatch would cause error at runtime, making it harder to spot.