search

mrosenbladt / yaml-cpp

Automatically exported from code.google.com/p/yaml-cpp
MIT License
0 stars 0 forks source link

uint8_t two digits conversion #251

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

  uint nine = 9;
  uint ten = 10;
  Node node;
  node.push_back(nine);
  node.push_back(ten);

  for (auto v : node)
  {
    try
      {
        std::cout << v.as<string>() << " " << v.as<uint8_t>() << "\n";
      }
   catch (...)
      {
        std::cout << v.as<string>()  << " failed\n";
      }
  }

What is the expected output? What do you see instead?

- expected:
9 9
10 10

- see:
9 9
10 failed

What version of the product are you using? On what operating system?
0.5.1

Please provide any additional information below.
Problem starts with two digits integers. snippet above uses 'uint' but other 
integer type raise the same issue.

Original issue reported on code.google.com by mdcb...@gmail.com on 17 Jun 2014 at 9:37

GoogleCodeExporter commented 9 years ago 
I guess I expected the exception to raise for values outside the char range 
[0-255].

Original comment by mdcb...@gmail.com on 17 Jun 2014 at 9:43

GoogleCodeExporter commented 9 years ago 
This looks like it's the fault of std::stringstream. Since uint8_t == unsigned 
char, it appears to try to read "10" by characters. So

std::stringstream ss("10");
uint8_t c;
ss >> c;

Leaves "0" left in the stream's buffer. At this point, yaml-cpp checks if it's 
read the whole input (it hasn't) and so it reports a conversion error.

I'm not sure what to do with this. Any thoughts?

Original comment by jbe...@gmail.com on 19 Jun 2014 at 1:22

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
newbie comment, sorry if I'm missing something, but why is yaml-cpp treating 
char/uchar and family as characters rather than integral. a choice had to be 
made but does it reflect the most common usage?

I can't think of 'character' in yaml file:

a_char: a      # in fact, string "a"
a_char: "\x61" # unwieldly, a string anyway

my line of work, but it's quite common to have (u)int8_t for numerical values
so I would rather have:

Dump(Node((uint8_t) 0x10)) // 16 rather than "\x10"

and

Node((int) 10).as<uint8_t>() // == 10 rather than exception

Original comment by mdcb...@gmail.com on 19 Jun 2014 at 7:22

GoogleCodeExporter commented 9 years ago 
possibly more illustrative:

Node((uint8_t) 48).as<int>()  // 48 rather than 0
Node((uint8_t) 0).as<int>()   // 0 rather than exception

Original comment by mdcb...@gmail.com on 19 Jun 2014 at 7:56

GoogleCodeExporter commented 9 years ago 
You may be right, but it seems really weird for

foo: 5

to give

node["foo"].as<char>() == 0x05

and even weirder for

foo: t

node["foo"].as<char>()

to throw an exception.

You're right, a choice has to be made, and you'll get some weird behavior both 
ways, but this seems... particularly weird.

Original comment by jbe...@gmail.com on 21 Jun 2014 at 6:03

GoogleCodeExporter commented 9 years ago

Original comment by jbe...@gmail.com on 24 Jan 2015 at 9:21