[
https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16403957#comment-16403957
]
ASF GitHub Bot commented on THRIFT-4476:
----------------------------------------
Github user ozymaxx commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1496#discussion_r175284886
--- Diff: compiler/cpp/src/thrift/generate/t_generator.h ---
@@ -268,6 +271,30 @@ class t_generator {
return out.str();
}
+ const std::string emit_double_as_string(const double value) {
+ std::stringstream double_output_stream;
+ // sets the maximum precision:
http://en.cppreference.com/w/cpp/io/manip/setprecision
+ // sets the output format to fixed:
http://en.cppreference.com/w/cpp/io/manip/fixed (not in scientific notation)
+ double_output_stream <<
std::setprecision(std::numeric_limits<double>::digits10 + 1);
+
+ #ifdef _MSC_VER
+ // strtod is broken in MSVC compilers older than 2015, so
std::fixed fails to format a double literal.
+ // more details:
https://blogs.msdn.microsoft.com/vcblog/2014/06/18/
+ //
c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1/
+ // and
+ //
http://www.exploringbinary.com/visual-c-plus-plus-strtod-still-broken/
+ #if _MSC_VER >= MSC_2015_VER
+ double_output_stream << std::fixed;
+ #endif
+ #else
+ double_output_stream << std::fixed;
--- End diff --
No, in both cases it should use `std::fixed`, that outputs the fixed
floating point representation of the number. But if the MSVC compiler is older
than 2015, that function is broken, and should not be called. In short, we want
the compiler to generate the doubles in the fixed floating point representation
if possible. On the Erlang side, if the compiler is older than 2015, we want
the compiler to use `std::scientific` since there can be cases where the
mantissa is being output as integer, which is illegal. `std::scientific` always
outputs the floating points numbers with a floating point mantissa. But if it
is 2015 or later, `std::fixed` works correctly and can be used to get rid of
the exponent representation.
> Typecasting problem on list items
> ---------------------------------
>
> Key: THRIFT-4476
> URL: https://issues.apache.org/jira/browse/THRIFT-4476
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
> Affects Versions: 0.11.0
> Reporter: Ozan Can Altiok
> Priority: Major
>
> I was trying to add the following into a thrift interface file.
> {{const list<double> timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> With the definition given above the {{.thrift}} file compiled properly.
> However, I noticed that in Python, the items in {{timeCoefficients}} are
> considered to be integer although the list has been defined to include items
> of {{double}} type. Then I modified the definition as given below to make
> sure all the items are of type {{double}}.
> {{const list<double> timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0,
> 1000.0]}}
> After the change, I ran into the following error during compilation.
> {{[ERROR] .../TimeCoefficients.java:[402,48] error: no suitable method found
> for add(int)}}
> {{[ERROR] method Collection.add(Double) is not applicable}}
> {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> {{[ERROR] method List.add(Double) is not applicable}}
> {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> Next, I changed the line as follows and the compilation became successful.
> {{const list<double> timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1,
> 1000.1]}}
> When I reviewed the generated Java source files, I discovered that
> {{const list<double> timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> compiles to
> {{public static final java.util.List<java.lang.Double> timeCoefficients = new
> java.util.ArrayList<java.lang.Double>();}}
> {{static {}}
> {{ timeCoefficients.add((double)24);}}
> {{ timeCoefficients.add((double)60);}}
> {{ timeCoefficients.add((double)60);}}
> {{ timeCoefficients.add((double)1000);}}
> {{ timeCoefficients.add((double)1000);}}
> {{ timeCoefficients.add((double)1000);}}
> {{}}}
> whilst
> {{const list<double> timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0,
> 1000.0]}}
> compiles to
> {{public static final java.util.List<java.lang.Double> timeCoefficients = new
> java.util.ArrayList<java.lang.Double>();}}
> {{static {}}
> {{ timeCoefficients.add(24);}}
> {{ timeCoefficients.add(60);}}
> {{ timeCoefficients.add(60);}}
> {{ timeCoefficients.add(1000);}}
> {{ timeCoefficients.add(1000);}}
> {{ timeCoefficients.add(1000);}}
> {{}}}
> which leads to an error.
> When I modified this line as follows
> {{const list<double> timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1,
> 1000.1]}}
> this line compiled to
> {{public static final java.util.List<java.lang.Double> timeCoefficients = new
> java.util.ArrayList<java.lang.Double>();}}
> {{static {}}
> {{ timeCoefficients.add(24.1);}}
> {{ timeCoefficients.add(60.1);}}
> {{ timeCoefficients.add(60.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{}}}
> My guess is that, even if I put {{.0}} at the end of each numeric constant,
> on the Java side, Thrift compiler considers them to be {{double}} and does no
> typecasts. However, the {{.0}} s are getting lost somewhere and the items
> become integers in the generated Java code. Thus, when it comes to populating
> the array, Java cannot succeed. {{Double}} s cannot be unboxed to integer and
> Java thinks {{int}} and {{Double}} are not related.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
