[
https://issues.apache.org/jira/browse/THRIFT-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14137541#comment-14137541
]
Ben Craig commented on THRIFT-2688:
-----------------------------------
I've had thoughts about this issue, and similar issues. The C++ generator has
tons of flags, and I'd rather not add more.
Instead what I'd like to do is generate each family of classes into a different
file. Ideally, the name of this file could be determine by the name of the
input file, so that GNU Make substitutions would be easy. For compatibility,
we would still generate files with the old name, but those would #include the
related C++ files.
For the Null implementations, the output file for calculator.thrift could be
something like calculatorNulls.h and calculatorNulls.cpp.
When the next batch of features comes along, instead of adding more classes to
existing files, they would instead generate new files. This way, existing
clients don't pay in compile time and binary size for features they don't use.
> Generating *Null implementations should be optional
> ---------------------------------------------------
>
> Key: THRIFT-2688
> URL: https://issues.apache.org/jira/browse/THRIFT-2688
> Project: Thrift
> Issue Type: New Feature
> Components: C++ - Compiler
> Reporter: Konrad Grochowski
> Attachments: THRIFT-2688.patch
>
>
> *Null implmentations introduce another level of ugly diamond shaped
> inheritance (with extended ifaces), which - among other things - leads to a
> lot of warnings on MSVC ("inheritance via dominance" C4250).
> Additionallly it just clobbers generated header as when stubs are needed
> GoogleMock/Turtle could/should be used.
> But I do understand requirement for backward compatibility, so in attached
> patch I've added option to ommit nulls generation, so still by default
> they'll be generated
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
