I'm trying to print a specific integer value of a Bottle by using cout (the Bottle contains only integer values), but it seems that this is a wrong way to do it. The command I used in a for loop is (the b Bottle is defined outside the loop):
std::cout << b.get(i) << std::endl;
The corresponding error is:
I'd like to see an example regarding the reading of a Bottle value.
You would have to get at the underlying type of the Value, if you know that it is indeed an int32_t (in other words b.get(i).isInt32() is true) then
std::cout << b.get(i).asInt32() << std::endl;
For the purposes of writing, without having to check the underlying type, you might also consider simply stringifying the Value
std::cout << b.get(i).toString() << std::endl;
Related
I'm trying to write code more clearly and follow protocol or precedence with variable names. My question is if there is a decided upon variable name for a yes/no question.
For example in c++ it would look something like:
cout << "Yes or no";
cin >> YesOrNoVariable;
Creating a yaml string with leading zeros is not escaped with quotes in yaml-cpp. So writing the string to a texfile is not a valid yaml-string.leading_zeros: 00005 is 5 according to the specification yaml 1.2 (Try yourself: http://www.yamllint.com/)
YAML::Node node;
node["leading_zeros"] = "00005";
std::cout << YAML::Dump(node)<<std::endl;
// output: leading_zeros: 00005
// instead of:leading_zeros: "00005"
How to bring yaml-cpp to escape a string with leading zeros? So that is would not be interpreted as integer from other yaml parser?
Escaping manually does not seem to be the correct answer.
node["leading_zeros"] = "\"00005\"";
Update:
The digit value is stored in a YAML::Node! I am pretty sure it is a bug.
After some time spent on analyzing code I went to this hacky solution: https://github.com/nikich340/yaml-cpp/commit/468e0832b39c8320faa7c925708b76f6a3b1b840
It will save double quotes (or you can change emitte manip to single quotes) around all scalars which were strings with quotes originally.
Use the YAML::Emitter directly:
YAML::Emitter out;
out << YAML::BeginMap;
out << YAML::Key << "leading_zeroes" << YAML::Value;
out << YAML::Value << YAML::DoubleQuoted << "00005";
out << YAML::EndMap;
Does
if(strncmp(buf, buf2, 7) == 0)
do the same thing as
if(memcmp(buf, buf2, 7) == 0)
buf and buf2 are char* arrays or similar.
I was going to append this to another question but then decided perhaps it was better to post it separately. Presumably the answer is either a trivial "yes" or if not then what is the difference?
(I found these functions from online documentation, but wasn't sure about strncmp because the documentation was slightly unclear.)
Like strcmp(), strncmp() is for comparing strings, therefore it stops comparing when it finds a string terminator in at least one argument. Any differences past that point have no effect on the result. strncmp() differs in that it will also stop comparing after the specified number of bytes if it does not encounter a terminator before then.
memcmp(), on the other hand, is for comparing blocks of random memory. It compares up to the specified number of bytes from each block until it finds a difference, regardless of the values of the bytes. That is, it does not stop at string terminators.
In C and C++ the end of a string is indicated by a byte with value 0.
The function memcmp does not care about the end of a strig but will in any case compare exactly the number of bytes specified.
In contrast to that, the function strncmp will stop at a byte with value 0 even though the passed number of bytes to compare is not yet reached.
The main difference between strncmp() and memcmp() is that the first is sensible to (stops at) '\0' where the latest is not. If the first 7 bytes of memory from buf and buf2 do not contain a '\0' in it, then the behaviour is the same.
Consider the following example:
#include <stdio.h>
#include <string.h>
int main(void) {
char buf[] = "123\0 12";
char buf2[] = "123\0 34";
printf("strncmp(): %d\n", strncmp(buf, buf2, 7));
printf("memcmp(): %d\n", memcmp(buf, buf2, 7));
return 0;
}
It will output:
strncmp(): 0
memcmp(): -2
Because strncmp() will stop at buf[3], where it'll find a '\0', where memcmp() will continue until all 7 bytes are compared.
In PostScript if you have
[4 5 6]
you have the following tokens:
mark integer integer integer mark
The stack goes like this:
| mark |
| mark | integer |
| mark | integer | integer |
| mark | integer | integer | integer |
| array |
Now my question:
Is the ]-mark operator a literal object or an executable object?
Am I correct that the [-mark is a literal object (just data) and that the ]-mark is an executable object (because you always need to create an array when you see this ]-mark operator) ?
PostScript Language Reference Manual section 3.3.2 gives me:
The [ and ] operators, when executed, produce a literal array object with the en-closed objects as elements. Likewise, << and >> (LanguageLevel 2) produce a
literal dictionary object.
That is not clear for me if both [ ] operators are executable or only the ] operator.
Summary.
All of these special tokens, [, ], <<, >>, come out of the scanner as executable names. [ and << are defined to yield a marktype object (so they are not operators per se, but they are executable names defined in systemdict where all the operators live). ] and >> are defined as procedures or operators which are executed just like any other procedure or operator. These use the counttomark operator to find the opening bracket. But all of these tokens are treated specially by the scanner, which recognizes them without surrounding whitespace since they are part of its delimiter set.
Details.
It all depends on when you look at it. Let's trace through what the interpreter does with these tokens. I'm going to illustrate this with a string, but it works just the same with a file.
So if you have an input string
([4 5 6]) cvx exec
cvx makes a literal object executable. The program stream is a file object also labeled executable. exec pushes an object on the Execution Stack, where it is encountered by the interpreter on the next iteration of the inner interpreter processing loop. When executing the program stream, the executable file object is topmost on the Execution Stack.
The interpreter uses token to call the scanner. The scanner skips initial whitespace, then reads all non-whitespace characters up to the next delimiter, then attempts to interpret the string as a number, and failing that it becomes an executable name. The brackets are part of the set of delimiters, and so are termed 'self-delimiting'. So the scanner reads the one bracket character, stops reading because it's a delimiter, discovers it cannot be a number, so it yields an executable name.
Top of Exec Stack | Operand Stack
(4 5 6]) [ |
Next, the interpreter loop executes anything executable (unless it's an array). Executing a token means loading it from the dictionary, and then executing the definition if it's executable. [ is defined as a -mark- object, same as the name mark is defined. It's not technically an operator or a procedure, it's just a definition. Automatic loading happens because the name comes out of the scanner with the executable flag set.
(4 5 6]) | -mark-
The scanner then yields 4, 5, and 6 which are numbers and get pushed straight to the operand stack. 6 is delimited by the ] which is pushed back on the stream.
(]) | -mark- 4 5 6
The interpreter doesn't execute the numbers since they are not executable, but it would be just the same if it did. The action for executing a number is simply to push it on the stack.
Then, finally the scanner encounters the right bracket ]. And that's where the magic happens. Self-delimited, it doesn't need to be followed by any whitespace. The scanner yields the executable name ] and the interpreter executes it by loading and it finds ...
{ counttomark array astore exch pop }
Or maybe an actual operator that does this. But, yeah. counttomark yields the number of elements. array creates an array of that size. astore fills an array with elements from the stack. And exch pop to discard that pesky mark once and for all.
For dictionaries, << is exactly the same as [. It drops a mark. Then you line up some key-value pairs, and >> is procedure that does something to effect of ...
{ counttomark dup dict begin 2 idiv { def } repeat pop currentdict end }
Make a dictionary. Define all the pairs. Pop the mark. Yield the dictionary. This version of the procedure tries to create a fast dictionary by making it double-sized. Move the 2 idiv to before dup to make a small dictionary.
So, to get philosophical, counttomark is the operator you're using. And it requires a special object-type that isn't used for anything else, the marktype object, -mark-. The rest is just syntactical sugar to let you access this stack-counting ability to create linear data-structures.
Appendix
Here's a procedure that models the interpreter loop reading from currentfile.
{currentfile token not {exit} if dup type /arraytype ne {exec} if }loop
exec is responsible for loading (and further executing) any executable names. You can see from this that token really is the name of the scanner; and that procedures (arrays) directly encountered by the interpreter loop are not executed (type /arraytype ne {exec} if).
Using token on strings lets you do really cool stuff, however. For example, you can dynamically construct procedure bodies with substituted names. This is very much like a lisp macro.
/makeadder { % n . { n add }
1 dict begin
/n exch def
({//n add}) token % () {n add} true
pop exch pop % {n add}
end
} def
token reads the entire procedure from the string, substituting the immediately-evaluated name //n with its currently defined value. Notice here that the scanner reads an executable array all at once, effectively executing [ ... ] cvx internally before returning (In certain interpreters, like my own xpost, this allows you to bypass the stack-size limits to build an array, because the array is built in separate memory. But Level 2 garbage collection makes this largely irrelevant).
There is also the bind operator which modifies a procedure by replacing operator names with the operator objects themselves. These tricks help you to factor-out name lookups in speed-critical procedures (like inner loops).
Both [ and ] are executable tokens. [ produces a mark object, ] creates an array of objects to the last mark
Using yaml-cpp, version 0.2.5 ...
I would like to emit a blank line between entries in a list (for readability purposes).
Is this possible?
I have tried experimentation with the Verbatim, and Null manipulators, but have not had success.
As of revision 420, this is possible:
YAML::Emitter emitter;
emitter << YAML::BeginSeq;
emitter << "a" << YAML::Newline << "b" << "c";
emitter << YAML::EndSeq;
produces
---
- a
- b
- c
I decided to go with YAML::Newline instead of YAML::Newline(n) since I found
I usually just wanted a single newline.
I kept accidentally typing YAML::Newline, which implicitly cast the function to a bool (specifically, true), so I figured other people would probably make the same mistake.
If you just want to patch your copy (and not sync with the trunk), use revisions 418-420. (Note: it's slightly trickier than the patch in the link you posted, since you have to be careful about a newline after an implicit key. See the comment on the (now closed) Issue 77 for more details.)