thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (THRIFT-4476) Typecasting problem on list items
Date Sun, 18 Mar 2018 10:59:00 GMT

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

Mime
View raw message