[
https://issues.apache.org/jira/browse/AVRO-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727994#comment-16727994
]
Thiruvalluvan M. G. commented on AVRO-1541:
-------------------------------------------
Good observation.
{{Specifc.hh}} kind of fixes C++ types for various Avro types. Apart from
obvious mappings for {{bool}}, {{int}}, {{long}} etc, it fixes {{std::string}}
for Avro string, \{{std::vector<uint8_t>}} for Avro bytes and
{{boost::array<uint8_t, >}} for Avro fixed. For composite types - Avro array
and map - it uses {{std::vector<T>}} and {{std::map<std::string, T>}}. The user
has no control over the choice of these C++ types when generating code using
{{avrogencpp}} tool. It will be an interesting project to generalize this to
allow the user to specify a compatible C++ while generating the code.
Now {{codec_traits}} exists to enable easy compile-time support for the
generated code and since the C++ types corresponding to Avro types is fixed,
the specializations for {{codec_traits}} are sufficient. But as
[~wgs_smiddleditch] points out, these specializations are too narrow and if
widened, they can be used for other purposes even if we do not allow the user
to choose C++ types during code generation.
The above observation is true for {{Generic.hh}} as well, except that for Avro
record and other types, it does not have specific generated classes but rather
uses {{GenericRecord}} and so on. But given the nature of use of
{{Generic.hh}}, customizability will not be of great use and hence no further
work is needed.
> Specific.hh is over-specialized for standard C++ containers
> -----------------------------------------------------------
>
> Key: AVRO-1541
> URL: https://issues.apache.org/jira/browse/AVRO-1541
> Project: Apache Avro
> Issue Type: Bug
> Components: c++
> Affects Versions: 1.7.6
> Reporter: Sean Middleditch
> Priority: Trivial
>
> The encoders in Specific.hh for the C++ stdlib types like string, vector,
> etc. are over-specialized and take only specific variations of these
> templated templates. The specializations of codec_traits should be partial
> specializations to support std::string, std::vector, std::map, and so on
> using user-specific allocators and (for std:set and std::map) a user-specific
> comparator, as Avro has absolutely no reason to care about these details.
> These partial specializations will not require any API incompatible breaks.
> They'd look something like:
> template <typename T, typename Allocator>
> template <>
> struct codec_traits<std::vector<T, Allocator> > {
> void encode(Encoder& e, const std::vector<T, Allocator>& s) {
> // ...
> }
> void encode(Encoder& d, std::vector<T, Allocator>& s) {
> // ...
> }
> };
> std::string could be the trickier one since it should probably be a partial
> specialization over the supported variants of basic_string, though partial
> specialization of std::string, std::u16string, std::u32string, and
> std::wstring (which can all have custom allocators).
> Don't forget that std::set and std::map can have both a custom allocator and
> a custom comparator.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
