[
https://issues.apache.org/jira/browse/THRIFT-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723362#comment-14723362
]
Randy Abernethy commented on THRIFT-1712:
-----------------------------------------
Hey Martin,
One thing I think might work well with this idea, in your next approach, is IDL
annotations. For example Apache Thrift IDL allows for annotations like:
{code:title=anno.thrift|borderStyle=solid}
struct anno {
1: i32 (cpp.type = "long") counter
} (final="true")
{code}
The first is C++ specific (cpp.*) the second applies to all languages which can
make sense of it (final).
The Thrift compiler acquired annotation support for several reasons but some
that are important as I see it are:
- Command line switches apply to the entire IDL indiscriminately
- Command line switches are not a documented part of the specification one
gets for free with IDL
- Command line switches are easy to forget
Annotations avoid all three of these issues. With IDL annotations, I can commit
the above IDL to version control and track the change (and bugs it generates),
I no longer need a command line switch to make counter a long (you can't forget
it and it is documented) and you have the ability to treat an i32 in another
struct differently if that makes sense. Annotations can be used at file scope
as well. If you are familiar with the IDL instructions:
- cpp_include Adds a #include line for the given literal in C++ output
- cpp_type Allows the container implementation type to be selected in C++
Both predate annotation support and should be converted to annotations in the
future (pre v1.0 I would hope). Thus the new annotation style (cpp.include =
"myheader.h") could handle your header hint and something like this could allow
base class specification:
struct example {
} (cpp.base = "mybase")
Annotations separate abstract IDL (non annotation IDL) from implementation
details but still allow high level implementation details to be a documented
part of the interface specification. They are also controllable service by
service and type by type.
I don't personally like a lot of implementation noise in my IDL but I think it
is an improvement over IDL compiler command line switches which do the same
thing.
My 2 cents.
Best,
Randy
> Add TBase class for c++
> -----------------------
>
> Key: THRIFT-1712
> URL: https://issues.apache.org/jira/browse/THRIFT-1712
> Project: Thrift
> Issue Type: New Feature
> Components: C++ - Compiler
> Affects Versions: 0.8
> Reporter: Martin Vogt
> Assignee: Ben Craig
> Priority: Minor
> Labels: base, c++, class
> Attachments: 000_line_first_140628v1.patch,
> 010_base_struct_gen_140629v1.patch, 011_base_struct_rest_140619v2.patch
>
>
> The generated c++ classes for struct's do not have a common base class.
> The patch adds two options to the compiler:
> - line_first : first line before all includes
> - base_struct : custom base class for structs
> For example:
> {code:title=MyService.thrift}
> struct MyStruct {
> 1:i32 val;
> }
> service MyService {
> void doSomething();
> }
> {code}
> thrift --gen cpp:line_first='#include <path/TBase.h>',base_struct=':public
> TBase' ./MyService.thrift
> {code:title=MyService_types.h}
> #ifndef MyService_TYPES_H
> #define MyService_TYPES_H
> #include <path/TBase.h>
> #include <thrift/Thrift.h>
> [....]
> class MyStruct:public TBase {
> [...]
> {code}
> The default, without any option:
> thrift --gen cpp ./MyService.thrift
> {code:title=MyService_types.h}
> #ifndef MyService_TYPES_H
> #define MyService_TYPES_H
> /* first line (modifier:off) */
> #include <thrift/Thrift.h>
> [....]
> class MyStruct /* base_struct (modifier:off) */ {
> [...
> {code}
> The idea is to have a base class for typecasting, which can be done with:
> {code}
> void processSignal(const TBase& tBase) {
> if (typeid(tBase).name() == typeid(MyStruct).name())
> printf("MyStruct found!\n")
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
