|
mystes posted:Randomize the date format on startup. phew at least we got one posser talking some sense
|
#
?
Jul 3, 2020 22:16
|
|
|
|
| # ? Jun 6, 2024 06:08 |
|
|
Carthag Tuek posted:dates, times, & strings should only be initializable with full metadata (calendar, timezone, encoding, etc). otherwise you just invite badness  i'd allow an exception for reading the system clock / current GMT but even that shouldn't be displayable without metadata, you should just be able to subtract it for timing purposes
|
|
#
?
Jul 4, 2020 00:02
|
|
|
animist posted:
if you’re timing things then you probably don’t want time of day anyway, and the high precision monotonic clocks you want to be using deliberately don’t have a defined start time to prevent people mixing things up.
|
|
#
?
Jul 4, 2020 00:47
|
|
|
carry on then posted:let me guess, this doesn't support any other calendaring systems because programmers are racists Howard Hinnant (the author of the proposal) showed both the Chinese New Year calendar and lunar calendar as reasons for his design, and showed conversions between Gregorian and Julian calendars for astronomy. This changed also standardized using tz databases. oh and this code doesn’t work by default unless you put a using namespace in your code and that should give you a red flag to begin with unless you’re doing poo poo like ADL
|
|
#
?
Jul 4, 2020 09:30
|
|
|
Slurps Mad Rips posted:oh and this code doesn’t work by default unless you put a using namespace in your code and that should give you a red flag to begin with unless you’re doing poo poo like ADL this is the same for all of the timer literals, I never use them because of it
|
|
#
?
Jul 5, 2020 12:43
|
|
|
Sweeper posted:this is the same for all of the timer literals, I never use them because of it Or any of those literals really, I'm still curious as to what's the rationale for the string_view string literal.
|
|
#
?
Jul 5, 2020 14:37
|
|
|
Sapozhnik posted:folks, ive been looking at c++ lately and lemme tell ya Well, from now on you can use SQF for all your programming needs. Money quote: quote:The SQF Language is fairly simple in how it is built. In fact: there are barely any actual language structures at all.
|
|
#
?
Jul 5, 2020 22:33
|
|
|
Falcorum posted:Or any of those literals really, I'm still curious as to what's the rationale for the string_view string literal. We can know the string length of a literal at compile time, so "asd"sv will calculate the length at compile time, while std::string_view x = "asd" may call strlen (it actually calls traits_type::length) at runtime, and when you're using a string literal there's not really a point in wasting a call to strlen. It's basically a micro-optimization 
|
|
#
?
Jul 5, 2020 22:48
|
|
|
when do you want to construct an instance of string_view?
|
|
#
?
Jul 5, 2020 23:27
|
|
|
I want my string_views constructed at compile time and stored in the read-only data segment
|
|
#
?
Jul 6, 2020 00:08
|
|
|
Slurps Mad Rips posted:We can know the string length of a literal at compile time, so "asd"sv will calculate the length at compile time, while std::string_view x = "asd" may call strlen (it actually calls traits_type::length) at runtime, and when you're using a string literal there's not really a point in wasting a call to strlen. It's basically a micro-optimization i continue to be amazed that legendarily performance-focused c++ is essentially the only programming language on the planet where constructing a value of the standard string type from a string literal requires allocating memory and copying the string
|
|
#
?
Jul 6, 2020 03:44
|
|
|
rjmccall posted:i continue to be amazed that legendarily performance-focused c++ is essentially the only programming language on the planet where constructing a value of the standard string type from a string literal requires allocating memory and copying the string c++ trusts the programmer (not to use any of the built-in APIs)
|
|
#
?
Jul 6, 2020 05:36
|
|
|
rjmccall posted:i continue to be amazed that legendarily performance-focused c++ is essentially the only programming language on the planet where constructing a value of the standard string type from a string literal requires allocating memory and copying the string The cost of mutable and contiguous strings And also of conflating the type of string literals with runtime string types.
|
|
#
?
Jul 6, 2020 07:09
|
|
|
aka the cost of backward compatibility with C, but without it C++ would probably never have taken off
|
|
#
?
Jul 6, 2020 08:45
|
|
|
Slurps Mad Rips posted:We can know the string length of a literal at compile time, so "asd"sv will calculate the length at compile time, while std::string_view x = "asd" may call strlen (it actually calls traits_type::length) at runtime, and when you're using a string literal there's not really a point in wasting a call to strlen. It's basically a micro-optimization or just make the string view constexpr?, seems like that would be even easier and make your point clearer vs. the magical sv
|
|
#
?
Jul 6, 2020 11:54
|
|
|
you wouldn’t need to change the default type for literals, just allow types to opt in to a special rule when they’re being constructed by converting a literal expression you could support mutation etc. by doing copy-on-write for those literal strings even if you didn’t do that for anything else the committee just can’t actually get it together to do anything about it because it seems excessively targeted or something
|
|
#
?
Jul 6, 2020 16:47
|
|
|
incredible how much of this is stuff that rust gets right
|
|
#
?
Jul 6, 2020 17:36
|
|
|
you can either be popular or right
|
|
#
?
Jul 6, 2020 17:37
|
|
|
the right way to do dates and times is the way that postgres does it. except that a timestamptz should actually store the original tz and it doesn't, that is annoying. everything else though, perfect
|
|
#
?
Jul 6, 2020 18:42
|
|
|
carry on then posted:you can either be popular or slower than c++ to compile fixed
|
|
#
?
Jul 6, 2020 19:09
|
|
|
Bloody posted:incredible how much of this is stuff that rust gets right that's what i'm saying, literally every language except c++ gets this right, because they are designed by people with a non-hosed-up relationship to the language they work on
|
|
#
?
Jul 6, 2020 20:02
|
|
|
what would be a bigger waste of my time long term. learning c++ real good or rust
|
|
#
?
Jul 6, 2020 22:37
|
|
|
depends on what you consider wasted time. do you want to learn something, or do you want to stack paper? because you can learn rust, but there are not a ton of rust jobs. on the other hand, plenty of work in c++, but you are not going to learn c++ real good. no mere mortal is capable of that. the best you can hope for is to learn a particular dialect of c++ real good, and which dialect you must learn generally depends on the type of work you want to do, and the people you are doing it with
|
|
#
?
Jul 6, 2020 23:06
|
|
|
do both and find out!
|
|
#
?
Jul 6, 2020 23:15
|
|
|
Bloody posted:incredible how much of this is stuff that rust gets right rust gets this even more wrong than C++, passing a string literal into anything that takes an owning String forces you to explicitly convert it from &str to String, so you have noise like map.insert("foo".to_string(), "bar".to_string()) *everywhere*
|
|
#
?
Jul 7, 2020 00:21
|
|
|
b0lt posted:rust gets this even more wrong than C++, passing a string literal into anything that takes an owning String forces you to explicitly convert it from &str to String, so you have noise like map.insert("foo".to_string(), "bar".to_string()) *everywhere*
|
|
#
?
Jul 7, 2020 00:58
|
|
|
i thought rust's owning String always puts it on the heap and "string literal".to_string() definitely allocates
|
|
#
?
Jul 7, 2020 02:13
|
|
|
Lime posted:i thought rust's owning String always puts it on the heap and "string literal".to_string() definitely allocates
|
|
#
?
Jul 7, 2020 02:28
|
|
|
b0lt posted:rust gets this even more wrong than C++, passing a string literal into anything that takes an owning String forces you to explicitly convert it from &str to String, so you have noise like map.insert("foo".to_string(), "bar".to_string()) *everywhere* its not that bad. the compiler tells you when you need to perform the correct incantations
|
|
#
?
Jul 7, 2020 02:45
|
|
|
b0lt posted:rust gets this even more wrong than C++, passing a string literal into anything that takes an owning String forces you to explicitly convert it from &str to String, so you have noise like map.insert("foo".to_string(), "bar".to_string()) *everywhere* yes, and this is a good thing
|
|
#
?
Jul 7, 2020 06:31
|
|
|
You can write your function so it accepts anything that can be turned into a string using a trait, no?
|
|
#
?
Jul 7, 2020 07:02
|
|
|
Sweeper posted:or just make the string view constexpr?, seems like that would be even easier and make your point clearer vs. the magical sv constexpr means that it can run at compile time but it doesn’t guarantee that it will. There are some cases where it simply can’t, such as parameters to a non-constexpr function. consteval, added in C++20 is a “compile time only” form, and constexpr now forms the bridge. also to be fair we added operator “”sv so we have parity with the std::string form. honestly the suffix stuff is rarely used overall, (except for maybe complex floats?), but then again a lot of them are like that. it might change once my paper for allowing 69i64 makes it in. it’s just easier to write 69i64 than the “proper” way of INT64_C(69). I’m making C++ like rust, one terrifying operator overload at a time. also once upon a time we were going to permit literal types like string view in template parameters but NOT permit char const* literals. hence the “”sv operator. this ended up not panning our and we just ended up allowing char const* literals in template parameters. but now we can’t remove the dumb stuff because “wHaT aBoUt mY AbI?!”
|
|
#
?
Jul 7, 2020 07:06
|
|
|
taqueso posted:You can write your function so it accepts anything that can be turned into a string using a trait, no? Yes but that sucks to write and read a lot more than just saying `string` like a normal language.
|
|
#
?
Jul 7, 2020 07:21
|
|
|
c++ may simply be too beautiful for this dirty, tarnished world
|
|
#
?
Jul 7, 2020 08:47
|
|
|
it’s not
|
|
#
?
Jul 7, 2020 09:44
|
|
|
fart simpson posted:its not that bad. the compiler tells you when you need to perform the correct incantations you shouldn't need to perform any incantation to pass a string literal to a function as a read only string c++ gets it wrong: "c++ bad" rust gets it wrong: "rust good"
|
|
#
?
Jul 7, 2020 10:05
|
|
|
c++ can't get it wrong all of the time because it does everything every possible way one of them must be right right
|
|
#
?
Jul 7, 2020 10:33
|
|
|
c++ has a print-out of a scheme implementation in its attic
|
|
#
?
Jul 7, 2020 10:39
|
|
|
Zlodo posted:c++ gets it wrong: "c++ bad" this but unironically
|
|
#
?
Jul 7, 2020 10:46
|
|
|
|
| # ? Jun 6, 2024 06:08 |
|
|
there being such a thing as a "string-like" reminds me why i prefer to just not do modern low-level programming, or the really dumb kind of high-level programming which would have a string-like.
|
|
#
?
Jul 7, 2020 10:52
|
|
