cppumaker resolves typedefs in generated header files when defining typedefs in .idl files: typedef long XLongTypedef typedef sequence<XLongTypedef> XLongSequenceTypedef typedef XKeyValue XStructTypedef typedef sequence<XStructTypedef> XStructSequenceTypedef generated .hdl files contain: typedef ::css::uno::Sequence< ::sal_Int32 > XLongSequenceTypedef; typedef ::css::uno::Sequence< XKeyValue > XStructSequenceTypedef; It would be better to generate the following, ie. avoid unrolling the typedef: typedef ::css::uno::Sequence< XongTypedef > XLongSequenceTypedef; typedef ::css::uno::Sequence< XStructTypedef > XStructSequenceTypedef; Method declarations could also benefit: idl: XLongTypedef aMethod([in] XLongSequenceTypedef arg) currently results in the following .hdl declaration: ::sal_Int32 aMethod(const Sequence<::sal_Int32>& arg) but this one would be nicer: XLongTypdef aMethod(const XLongSequenceTypedef& arg)
Why would it be better? (My assumption would be that the generated .hdl/.hpp files are not looked at much by humans anyway. But, ultimately, I don't care much either way about this topic.)
(In reply to Stephan Bergmann from comment #1) > Why would it be better? (My assumption would be that the generated > .hdl/.hpp files are not looked at much by humans anyway. But, ultimately, I > don't care much either way about this topic.) Waiting for the reply
Dear straub, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Not unrolling the typedef would be better since it will improve readability of the calling code. When using a method using a typedef, an engineer will most likely use the typedef in code that calls such a method, resulting in better self-explaining code: XLongTypedef result = methodReturningXTypedef() instead of sal_Int32 result = methodReturningXTypedef() It all depends on the engineer of course...
(In reply to Marc-Oliver Straub from comment #4) > Not unrolling the typedef would be better since it will improve readability > of the calling code. > When using a method using a typedef, an engineer will most likely use the > typedef in code that calls such a method, resulting in better > self-explaining code: > > XLongTypedef result = methodReturningXTypedef() > instead of > sal_Int32 result = methodReturningXTypedef() But that's all independent of whether or not the typedef is unrolled in the cppumaker-generated files.
I don't think so. When I'm working on C++ code, I rely on the stuff in the headerfiles, not switching to IDL files. If I don't see the typedef in the header file, I'll not use it in my code.
(In reply to Marc-Oliver Straub from comment #6) > I don't think so. When I'm working on C++ code, I rely on the stuff in the > headerfiles, not switching to IDL files. If I don't see the typedef in the > header file, I'll not use it in my code. As I already wrote in comment 1, "My assumption would be that the generated .hdl/.hpp files are not looked at much by humans anyway. But, ultimately, I don't care much either way about this topic." So if anybody wants to change that...