C++

Forum

 
Chrono date literals

seeplus (6591)
Since C++20 there has been the d and y literals defined in <chrono> - but no m.

This seems to be able to be added by (for VS - based upon the code for d and y):

1
2
3
4
5
6
7
 
inline namespace literals {
	inline namespace chrono_literals {
		_EXPORT_STD _NODISCARD constexpr _CHRONO month operator"" m(unsigned long long _Month) noexcept {
			return _CHRONO month { static_cast<unsigned int>(_Month) };
		}
	}
}


Now this compiles ok:

1
2
3
4
5
6
7
 
int main() {
	using namespace std::chrono_literals;

	std::chrono::year_month_day ymd(2023y/3m/13d);

	std::cout << ymd << '\n';
}


where without m defined you have to do:

1
2
3
4
5
6
7
 
int main() {
	using namespace std::chrono_literals;

	std::chrono::year_month_day ymd(2023y/3/13d);

	std::cout << ymd << '\n';
}


which to me seems inconsistent.

Is there any reason why y and d are provided but not m?? Is there any reason why m can't be provided as above?
Peter87 (11234)
Because it could be mistaken for minute? Or millennium?
mbozzi (3932)
HowardHinnant wrote:
>> The library provides the literal suffixes _y and _d. Is there a reason why
>> there's no _m?

> Yes. I gave it some thought and decided against it. 3_m looks too much like "3
> meters". Especially if this library gets standardized, then 3_m becomes 3m.
> And that would forbid the C++ std::lib from ever developing a units library
> with meters in it.

https://github.com/HowardHinnant/date/issues/148

So the answer is that "it could be mistaken for meters". Good thinking.
Last edited on
seeplus (6591)
OK. There's min for minute and ms for milliseconds - so why not say mo (or mon ...) for months for consistency?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
inline namespace literals {
	inline namespace chrono_literals {
		_EXPORT_STD _NODISCARD constexpr _CHRONO month operator"" mo(unsigned long long _Month) noexcept {
			return _CHRONO month { static_cast<unsigned int>(_Month) };
		}
	}
}


int main() {
	using namespace std::chrono_literals;

	std::chrono::year_month_day ymd(2023y / 3mo / 13d);

	std::cout << ymd << '\n';
}



Last edited on
jonnin (11437)
I get forward thinking & future planning, but c++ has no business standardizing distance/volume/area/etc type units now or going forward. it might be nice to have the conversion constants to multiply, but its way, way out of scope at the language level. Time is important in general purpose programming; its a special case.

that said, I do suppose meters per min is valid, if strange.
Topic archived. No new replies allowed.