[
https://issues.apache.org/jira/browse/AVRO-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Peter Marlow updated AVRO-3705:
--------------------------------------
Description:
avrogencpp uses either std or boost in the generated code. It does this
depending on how it was built, using #if __cplusplus >= 201703L. If the
compiler supports std::any then it used, otherwise boost is used. The
assumption is that if the compiler used to build avrogencpp supports C\+\+{+}17
by default then emitted code can use C\+\+17 otherwise the emitted code should
use boost. This assumption turns out to have a weakness - if a project uses a
compiler where C{+}+17 is given as an option because it is not the default then
the code avrogencpp generates will use boost instead of std.
This problem could be solved if avrogencpp supported a command line option to
use c+\+{+}17. The option could be used by those environments where avrogencpp
was built with a version of gcc that does not support c{+}{+}17 by default but
the desire is to use C{+}+17.
This is a serious need because there is a significant difference between
boost::any and std::any. The standard any has a small buffer optimisation but
boost does not. This means that code generated by avrogencpp that uses
boost::any will use heap memory for every case where the generated code uses
the any type. This could be avoided if the c++17 option was available.
was:
avrogencpp uses either std or boost in the generated code. It does this
depending on how it was built, using #if __cplusplus >= 201703L. If the
compiler supports std::any then it used, otherwise boost is used. The
assumption is that if the compiler used to build avrogencpp supports C++17 by
default then emitted code can use C\+\+17 otherwise the emitted code should use
boost. This assumption turns out to have a weakness - if a project uses a
compiler where C++17 is given as an option because it is not the default then
the code avrogencpp generates will use boost instead of std.
This problem could be solved if avrogencpp supported a command line option to
use c++17. The option could be used by those environments where avrogencpp was
built with a version of gcc that does not support c++17 by default but the
desire is to use C++17.
This is a serious need because there is a significant difference between
boost::any and std::any. The standard any has a small buffer optimisation but
boost does not. This means that code generated by avrogencpp that uses
boost::any will use heap memory for every case where the generated code uses
the any type. This could be avoided if the c++17 option was available.
> avrogencpp needs an option to generate code using std instead of boost
> ----------------------------------------------------------------------
>
> Key: AVRO-3705
> URL: https://issues.apache.org/jira/browse/AVRO-3705
> Project: Apache Avro
> Issue Type: Improvement
> Components: c++
> Affects Versions: 1.11.0
> Environment: RHEL8. The gcc installed from the Red Hat repo is
> version 8.5.0 which has an option to use c++17 since that dialect is not the
> default. The avro-cpp package in the Red Hat repo must have been built with
> that since it emits code that uses boost.
> Reporter: Andrew Peter Marlow
> Priority: Minor
>
> avrogencpp uses either std or boost in the generated code. It does this
> depending on how it was built, using #if __cplusplus >= 201703L. If the
> compiler supports std::any then it used, otherwise boost is used. The
> assumption is that if the compiler used to build avrogencpp supports
> C\+\+{+}17 by default then emitted code can use C\+\+17 otherwise the
> emitted code should use boost. This assumption turns out to have a weakness -
> if a project uses a compiler where C{+}+17 is given as an option because it
> is not the default then the code avrogencpp generates will use boost instead
> of std.
> This problem could be solved if avrogencpp supported a command line option to
> use c+\+{+}17. The option could be used by those environments where
> avrogencpp was built with a version of gcc that does not support c{+}{+}17 by
> default but the desire is to use C{+}+17.
> This is a serious need because there is a significant difference between
> boost::any and std::any. The standard any has a small buffer optimisation but
> boost does not. This means that code generated by avrogencpp that uses
> boost::any will use heap memory for every case where the generated code uses
> the any type. This could be avoided if the c++17 option was available.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
