|
I war-rent that the crabby ones have a side-walk[^].
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
|
I’m siding with the people who think address would be the shingle most a-door-able thing for a house
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
Thats difficult to answer. A house has both address and a male-box.
I'll get my coat...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Of course! Have you not heard of a "house dress?" My wife has several.
Get me coffee and no one gets hurt!
|
|
|
|
|
Which house, the one in the hood?
|
|
|
|
|
For a format that should be a standard there are basically no easy, portable classes that parse that format to obtain a time_t. The only ones I saw around are very incomplete. The only library that does that is Boost, which is not an option.
No content, just ranting.
Bonus rant: GNU C library sucks. No __time64_t to force the use of 64 bit, no sscanf_s which should be standard... damn ungulates.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
|
I wonder how many development groups already use C++20.
|
|
|
|
|
Eh??
Half of the overloads are C++11.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I'd never heard of this, so I just clicked on the link, which showed 4 function templates with the notation "since C++20".
|
|
|
|
|
You are right, I misread the the 11 stuff further down that page.
But cppreference is a friend, and this method is C++11
std::get_time - cppreference.com[^]
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I find it amusing that supposedly the printf-family of functions' format strings are bad and streaming operators should be used yet the std:: time format functions seem to use format strings.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick York wrote: I find it amusing that supposedly the printf-family of functions' format strings are bad and streaming operators should be used In fact, while I like the idea behind stream classes. I often find the C format strings more useful.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I agree. The primary argument I have read against them is there is no type checking and that is no longer true. VC++ gives warnings on types that don't match the format specifier. Plus, there's thing we refer to as testing. It can catch all of those errors. In short, I don't buy that argument at all. I have yet to see a compelling argument that sways me away from using printf and I have read them for at least twenty years.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
It requires the format string, which makes it useless. The format is standard, I don't have to parse it and figure out which variation of the format is used. If I wished to do so I would have used my old friend sscanf and an ad hoc function.
Why should I write it on my own for a format that is an ISO standard, anyway?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
%T equivalent to "%H:%M:%S" (the ISO 8601 time format)
%F equivalent to "%Y-%m-%d" (the ISO 8601 date format)
Format more clearly stated under strftime but also applies to chrono::parse
strftime - cppreference.com[^]
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
ISO8601 strings also have the time zone, and what irks me is that it's a standard, why should anyone need to specify the format when it is, in fact, standard?
Besides, this
Returns an object manip of unspecified type such that, given a std::basic_istream<CharT, Traits> object is, the expression is >> manip calls from_stream (unqualified, to enable argument-dependent lookup) as follows:
1) from_stream(is, fmt.c_str(), tp)
2) from_stream(is, fmt.c_str(), tp, std::addressof(abbrev))
3) from_stream(is, fmt.c_str(), tp,
static_cast<std::basic_string<CharT, Traits, Alloc>*>(nullptr), &offset)
4) from_stream(is, fmt.c_str(), tp, std::addressof(abbrev), &offset).
The expression is >> manip is an lvalue of type std::basic_istream<CharT, Traits> with the value is.
These overloads only participate in overload resolution if the corresponding from_stream expression is well-formed.
makes no sense.
What there should exist?
time_t std::something::parseISO8601(std::string date);
Easy. Or the same with tm structure. Not a semiobscure infrastructure to build my own date format and parser, considering that it is an ISO standard.
So much talking about adding gazillions of functionalities to C++ (because it already has a simple syntax) to ncrease code reusability and then this.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
time_t is 64-bit when built for/on 64-bit Linux.
printf("sizeof(time_t): %d", sizeof(time_t));
|
|
|
|
|
Which makes cross platform development a bit finicky as you're not sure which time_t it will use. On Windows you can force the use of _time64_t even on 32 bit (as long as youm have at least WinXP on the target IIRC) and you're sure of the behavior.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Hope this link helps. __time64_t has been available for quite some time in the GCC world.
|
|
|
|
|
Bonus rant: GNU C library sucks. No __time64_t to force the use of 64 bit, no sscanf_s which should be standard... damn ungulates. So, your software is quite optimistic about the pandemic.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Pandemic will kill humans, my software will run on the machines that will take our place.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I shop and buy something on Amazon (in particular) and if I look to buy it again it's always more expensive.
OK -prices go up - but I've seen this literally "overnight" and the item I check is from a link from the invoice so it's the same source.
Is this another version of using my browsing/purchasing information on their sight to make some extra money?
Anyway, am I just rather unlucky in what I purchase or is this all-too-common?
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I have chalked most of the price hikes I see on Amazon to COVID.
A particular brand of salsa that I like and have bought in the past at $4 a jar are now being sold at almost $9 a jar. Same company. Same salsa. Same jar.
WTF is that?
Edit/correction: seems the prices are starting to come down since I last looked a few months ago. $5-6 now per jar, give or take. Still too expensive in my opinion to what it used to be.
Arriba Hot Salsa[^]
modified 17-Mar-21 10:50am.
|
|
|
|