[jira] [Commented] (AVRO-1541) Specific.hh is over-specialized for standard C++ containers

["Thiruvalluvan M. G. (JIRA)" <ji...@apache.org>]

    [ 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)