Formatting Integers Using toml::value_flags

[LebJe]

Environment

toml++ version and/or commit hash:
1c3957ca206fb3915c123933b4a9b59ef6cf296a

Compiler:

clang++ --version
clang version 12.0.0
Target: arm64-apple-darwin20.5.0
Thread model: posix
InstalledDir: /Users/USER/homebrew/opt/llvm/bin

C++ standard mode:
C++ 17

Target arch:
AArch64 (ARM64)

Library configuration overrides:
None

Relevant compilation flags:
None

Describe the bug

I would like to format integers in my TOML table as hexadecimal, octal, or binary, but it seems that toml::value_flags only formats integers when they are sent to a stream.

Steps to reproduce (or a small repro code sample)

#include <iostream>

// toml++ single header
#include "toml.hpp"

int main(void) {
	auto v = toml::value { 0x123abc };
	v = v.flags(toml::value_flags::format_as_hexadecimal);

	auto t = toml::table {{ { "hex", v } }};

	// Prints 0x123ABC
	std::cout << v << std::endl;

	// Prints hex = 1194684
	std::cout << toml::default_formatter { t, toml::format_flags::allow_value_format_flags } << std::endl;
}

Output:

0x123ABC
hex = 1194684

Additional information

Is it possible to insert formatted integers into a toml::table or toml::array?

[marzer]

Ah, so you want insertion to also copy value flags when inserting by copying an from existing toml::value<>, right?

Is it possible to insert formatted integers into a toml::table or toml::array?

Not presently, unless you do it in two steps, e.g.:

arr.push_back(0x123abc);
arr.back().as<int64_t>()->flags(format_flags::format_as_hexadecimal);

Which is admittedly quite clunky, though easily fixed with a helper function.

---

As an aside/FYI:

// this:

std::cout << toml::default_formatter { t, toml::format_flags::allow_value_format_flags } << std::endl;

// is the same as this:

std::cout << t << std::endl;

[marzer]

Another point of clarification. When you say this:

but it seems that toml::value_flags only formats integers when they are sent to a stream.

What do you mean? The idea of 'formatting' TOML data in toml++ only has meaning when it's printed to a stream. Is there some other type of formatting you're expecting the library to do?

[LebJe]

@marzer Thank you for the solution. My code now looks like this:

#include <iostream>
#include "toml.hpp"

int main(void) {
	auto v = toml::value { 0x123abc };

	auto t = toml::table {{ { "hex", v } }};

	t.get("hex")->as_integer()->flags(toml::value_flags::format_as_hexadecimal);

	std::cout << t << std::endl;
}

and produces this output:

hex = 0x123ABC

---

Another point of clarification. When you say this:

but it seems that toml::value_flags only formats integers when they are sent to a stream.

What do you mean?

I meant that when I was trying to insert formatted integers into a toml::table I tested sending a toml::value to std::cout to make sure toml::value_flags::format_as_hexadecimal was being stored in v:

auto v = toml::value { 0x123abc };
v = v.flags(toml::value_flags::format_as_hexadecimal);

std::cout << v << std::endl;

[marzer]

@LebJe Ah, cool. Glad you were able to sort it out.

[marzer]

@LebJe FYI I've made improvements in this area on the v3 branch, such that value flags are now copied properly on insertion, and can also be overridden at insertion too:

toml::array arr;

// copying value flags
auto v = toml::value{ 10 };
v.flags(toml::value_flags::format_as_hexadecimal);
arr.push_back(v);

// setting/overriding them on array insertion
arr.push_back(10, toml::value_flags::format_as_hexadecimal);

std::cout << arr << std::endl;

would print

[ 0xA, 0xA ]

The full list of changes in the v3 branch can be found here.

[LebJe]

@marzer

Environment

toml++ version and/or commit hash:
7eb2ffcc09f8e9890dc0b77ff8ab00fc53b1f2b8

Compiler:

clang++ --version
Homebrew clang version 15.0.7
Target: arm64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Users/lebje/homebrew/opt/llvm/bin

C++ standard mode:
C++ 17

Target arch:
AArch64 (ARM64)

Library configuration overrides:
None

Relevant compilation flags:
None

I'm not sure if something in the library has changed, or if I'm doing something wrong, but it seems that there are problems with inserting formatted integers into arrays and tables:

• Inserting an integer into an array (using push_back) causes the integer to lose its value_flags.
  • Overriding the flags parameter of push_back properly inserts the integer.
• Inserting an integer into a table (using insert) causes the integer to lose its value_flags.
  • Overriding the flags parameter of insert properly inserts the integer.
  • If the table is inserted into another table, the integer loses its value_flags, even when the flags parameter of insert is overridden.

The code below demonstrates all the above issues:

#include "toml.hpp"
#include <iostream>

int main(void) {
	auto table = toml::table();
	auto innerTable = toml::table();
	auto array = toml::array();
	
	auto value = toml::value(0x123);
	value.flags(toml::value_flags::format_as_hexadecimal);
	
	array.push_back(value);
	array.push_back(value, toml::value_flags::format_as_hexadecimal);
	
	innerTable.insert("preserve_source_value_flags", value);
	innerTable.insert("format_as_hexadecimal", value, toml::value_flags::format_as_hexadecimal);
	innerTable.insert("array", array);
	
	std::cout << "# Inner table: \n" << innerTable << "\n\n";

	table.insert("preserve_source_value_flags", value);
	table.insert("format_as_hexadecimal", value, toml::value_flags::format_as_hexadecimal);
	table.insert("array", array);
	
	table.insert("innerTable", innerTable, toml::preserve_source_value_flags);

	std::cout << "# Outer table: \n" << table << "\n";
}

Result:

# Inner table: 
array = [ 291, 0x123 ]
format_as_hexadecimal = 0x123
preserve_source_value_flags = 291

# Outer table: 
array = [ 291, 0x123 ]
format_as_hexadecimal = 0x123
preserve_source_value_flags = 291

[innerTable]
array = [ 291, 0x123 ]
format_as_hexadecimal = 291
preserve_source_value_flags = 291

Please let me know if I should create another issue, or continue in this issue.

[marzer]

I'm not sure if something in the library has changed

Nope, not intentionally at least. Looks like a regression. Thanks for letting me know, I'll look into this some time this week.

[marzer]

@LebJe Sorry it took me so long to get back to this; I've implemented a fix in 2414d90, mind testing it when you get a chance?

Scratch that. Just found an issue with my fix.

EDIT: OK, fix is in 82c3b90

[LebJe]

It works perfectly! Thank you!