Emitter: produce string with trailing '.0' for floating point value with only integral part

[romainreignier]

For example the number 1.0 will be converted to "1.0" instead of "1".
This allows to keep the correct type information when parsing back the YAML.

This is an attempt to Fix #226 #412 #1016

[romainreignier]

I don't know if it worth adding it, but this test fail on master and pass with this patch:

void testRoundTripDouble(double value) {
    Emitter out;
    out << value;
    Node node = Load(out.c_str());
	int64_t intValue;
	EXPECT_FALSE(YAML::convert<int64_t>::decode(node, intValue));
	double doubleValue;
	EXPECT_TRUE(YAML::convert<double>::decode(node, doubleValue));
    EXPECT_EQ(doubleValue, value);
}

TEST(RoundTripTest, Double) {
    testRoundTripDouble(0.0);
    testRoundTripDouble(3.14159);
}

[SGSSGene]

Hey,
I am uncertain of this PR. I do not think this fixes a bug, but adds a functionality that many would like to have.

Reading the yaml spec I understand that it has 3 types: sequence, collection and scalar.
Exporting a float without dot (e.g 0.0) is valid. So interfering the type is not a float from the missing of a dot is not valid.

The correct fix, would probably be add a explicit '!!float' tag to indicate the type, but yaml-cpp does not support this.

I have done some similar fix for some other library which uses yaml-cpp: fujitatomoya/ros2_persist_parameter_server#13 (comment)

[SGSSGene]

So, what we maybe actually need, is someway of configuring the Emitter to add a ".0" or not. (There might also be other things we want to configure?)

[romainreignier]

Thanks @SGSSGene for pointing out fujitatomoya/ros2_persist_parameter_server#13 (comment).
My issue is also related to a ROS 2 project and how parameter type is deduced by the YAML string in ROS 2.

Having a mean to configure the Emitter would be nice.
I don't think of any other thing to configure right now.

[jbeder]

FYI there are lots of emitter flags.

[SGSSGene]

I am working on this now.

Just notice, other parsers also have trouble with other representations, like 5e10 being converted to a string even though it is a valid floating point representation.

[SGSSGene]

@romainreignier please take a look at PR #1407 and give me feedback if that is a valid solution for you.