[
https://issues.apache.org/jira/browse/THRIFT-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14907322#comment-14907322
]
Vitali Lovich commented on THRIFT-2473:
---------------------------------------
[~jking3] is also right that the __set_foo should set the isset which is
something Java does that C++ doesn't & would need to be fixed if we don't get
rid of isset.
Would generating two classes make code cleaner? 1 for read & 1 for
program-generated structs? In other words Foo wouldn't have any isset generated
while FooInput (or however you want to name it) would (& would also ensure that
the _set_<name> methods set the isset flag).
In Java this would work great. In C++ there's the potential for slicing but
likely anyone checking for isset in the first place is expecting FooInput
anyway, no?
> _isset entries shouldn't be generated for non-optional fields
> -------------------------------------------------------------
>
> Key: THRIFT-2473
> URL: https://issues.apache.org/jira/browse/THRIFT-2473
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
> Reporter: Vitali Lovich
>
> There's quite a bit of memory overhead (4 bytes per field) that's wasted on
> every single type. The __isset field is unused by the thrift type for fields
> not annotated optional.
> Additionally, it causes confusion in program code since people never know
> whether or not the __isset struct can be checked for a particular field or
> not (e.g. for non-optional fields it would never get set normally unless you
> deserialized it).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
