|
Volte posted:In this particular case I don't see why it's better than just Hammerite posted:I'm glad I'm not the only one who cares about this ... Yeah, I get that. The point was code:
is not what I would consider one of those.
|
# ? Mar 19, 2020 15:04 |
|
|
# ? Jun 5, 2024 19:46 |
|
NihilCredo posted:Yes, that's a compile-time check though, not a runtime check. After going back and rereading your post, I think I understand what you are talking about, but I also think that your definition is useless To me, and to a lot of other people, weak vs strong typing is not about whether types are checked at runtime, but rather about how explicit you have to be when bypassing the type system (and how sane are the built-in implicit conversions). As an example, "12345" * 2 resulting in 24690, would be considered weak typing by most people, even if the runtime performs 1000 checks to ensure that the lhs is either a number or a string and nothing else. Similarly, atoi("12345") * 2 resulting in 24690 is considered strong typing, even though C has absolutely insane set of implicit conversions and no runtime checks. Xarn fucked around with this message at 15:10 on Mar 19, 2020 |
# ? Mar 19, 2020 15:08 |
|
Jabor posted:It's something that HCI folks have been ragging on forever, but I'm not aware of it being done for you in a commonly-used framework or anything. Well then I wish the people in charge of the Windows start menu at Microsoft were as attentive as you. Volmarias posted:... Yeah, I get that. The point was No? I think it amounts to more or less the same thing. It's basically creating a searchable tag. The fact that it has an argument is a red herring, it could instead be a macro that expands to nothing and is used alongside the integer literal. Volte has expressed the idea better than I am doing I mean I'm not saying I would do either of these things, just that I can see a rationale for why someone might do it.
|
# ? Mar 19, 2020 15:12 |
|
Hammerite posted:No? I think it amounts to more or less the same thing. It's basically creating a searchable tag. The fact that it has an argument is a red herring, it could instead be a macro that expands to nothing and is used alongside the integer literal. Volte has expressed the idea better than I am doing Volte pointed out, correctly, that a macro named BUFFER_LENGTH(n) has value. It communicates what the number is without any extra overhead. This is good. Imagine if, looking through some Radium Code, you came across AWFUL_SIZE(n). You see code like code:
And code:
What do those magic numbers mean? What are they relevant for? There's no context, you've just changed #DEFINE AWFUL_SIZE_8 8 into a macro function that communicates just as much information. If you're doing it to be searchable, what are you even searching for?
|
# ? Mar 19, 2020 15:19 |
|
Hammerite posted:That's a good start, but it has the problem that it could frustrate a user who has faster than normal reaction times and did actually intend to click on the thing - and sees their click have no effect. It's also possible that a user who is well-used to a particular workflow within your UI would begin to anticipate when something is going to appear and achieve clicks on that thing at faster than normal reaction time. That user would also be frustrated. Really, there has to be a period where no action is achieved. You can either do the present system where users are frustrated, or you could look back in time and guess what users were trying to click on, which would be even more frustrating, or you can lock them out. You can accompany the lockout with some visual indication, such as appearing at a lower contrast than normal. The user frustration stems from "I clicked and the thing I expected to happen didn't happen" If you telegraph what's happening, I'm sure they won't mind having to wait a tenth of a second for their element to become active.
|
# ? Mar 19, 2020 15:19 |
|
Volmarias posted:Volte pointed out, correctly, that a macro named BUFFER_LENGTH(n) has value. It communicates what the number is without any extra overhead. This is good. It seems to me that your AWFUL_SIZE example is fundamentally different because it doesn't communicate what it is for beyond that it's a "size", whereas TEAM_PREFIX_NAME_LENGTH is substantially more meaningful. It's a "team prefix name length"... whatever that is. It was my presumption that a "team prefix name length" is something meaningful in the problem domain that the codebase in question addresses.
|
# ? Mar 19, 2020 15:28 |
|
TEAM_PREFIX_NAME_LENGTH is used exclusively for declaring the length of character arrays. I have the option of killing it and just using hardcoded numbers, so this particular horror has reached the end of its life.
|
# ? Mar 19, 2020 15:42 |
|
pokeyman posted:
i like this because it's a subtle error when someone puts in TEAM_PREFIX_NAME_LENGTH(3) and something blows up on unaligned access the repeated thing is silly but when used consistently does have the effect of limiting acceptable lengths still.. make it an enum
|
# ? Mar 19, 2020 17:48 |
|
I seem to recall a UI with search suggestions where the suggestion under the element wouldn't change as long as your cursor was over it. I thought it was Chrome, but I can't reproduce it. Maybe they changed it. The main issue with that approach is that it doesn't work on touchscreens.
|
# ? Mar 19, 2020 19:31 |
|
ultrafilter posted:
Just use token pasting. code:
|
# ? Mar 19, 2020 21:18 |
|
Presto posted:Just use token pasting. Not enough, because now you need to manually know what the static const ints are called! code:
|
# ? Mar 19, 2020 22:22 |
|
You are trying to make a joke, but you aren't even within the same order of magnitude of terribleness as the macros I have in prod.
|
# ? Mar 19, 2020 23:45 |
|
I don't think anyone has used x macros yet
|
# ? Mar 20, 2020 00:31 |
|
Because X macros are great!
|
# ? Mar 20, 2020 02:51 |
|
I came across an inefficiency in C lately: in variadic functions a float is always widened to a double. On a desktop this is a nothingburger but on a microcontroller with only float32 hardware it turns a native single cycle operation into a multi-step process involving two conversions, stack alignments, etc. This isn't optimal !!!!
|
# ? Mar 20, 2020 18:41 |
|
"don't use variadic functions in embedded systems" seems like a pretty reasonable restriction.
|
# ? Mar 20, 2020 18:49 |
|
ultrafilter posted:"don't use variadic functions in embedded systems" seems like a pretty reasonable restriction. yeah, but what if you could? "...i just said you shouldn't." yeah, yeah, sure! but...think about it....what if you could?!
|
# ? Mar 20, 2020 18:51 |
|
Cast float32s to int32s before using as a parameter to a variadic function boom done.
|
# ? Mar 20, 2020 18:54 |
|
printf considered harmful
|
# ? Mar 20, 2020 19:03 |
|
Another solution: require that floats to be passed by pointer, assume this is always done and just dereference it. What could possibly go wrong? In the spirit of C, I've done nothing wrong and you're just holding the footgun wrong
|
# ? Mar 20, 2020 19:04 |
|
qsvui posted:printf considered harmful yep
|
# ? Mar 20, 2020 19:26 |
|
We have printf but it's a custom implementation that doesn't understand %f and friends.
|
# ? Mar 20, 2020 19:45 |
|
C's weird quirk around everything turning into doubles is yet another example of poo poo That Is Wrong With C, and which has nothing to do with having to support low-level programming. It just sucks. Another example is the declaration syntax. The worst is the implicit conversions.
|
# ? Mar 20, 2020 21:04 |
|
qsvui posted:printf considered harmful I'll take printf formatting over iostream any day.
|
# ? Mar 20, 2020 21:42 |
|
Spatial posted:I came across an inefficiency in C lately: in variadic functions a float is always widened to a double. On a desktop this is a nothingburger but on a microcontroller with only float32 hardware it turns a native single cycle operation into a multi-step process involving two conversions, stack alignments, etc. I hate the implementation of variadic functions in C. It's so clunky - there's no mechanism for type safety of variadic function args in C, and many places ban them because of potential security vulnerabilities (e.g. format string vulnerabilities in printf, resolving this was one of the motivating factors behind the design of iostream in C++.) Even disregarding the security bullshit, there's all these parlor tricks it's doing with macros and the va_list poo poo that make me really hesitant to ever touch variadics in C if I can possibly help it. Bruegels Fuckbooks fucked around with this message at 21:47 on Mar 20, 2020 |
# ? Mar 20, 2020 21:45 |
|
Someone in the Haskell community did eventually come up with a type-safe printf, but it took the better part of a decade, and I'm not sure you could do what they did in any other language.
|
# ? Mar 20, 2020 22:20 |
|
C has essentially typesafe printf if you compile with -Wformat -Wformat-nonliteral -Werror, like you should
|
# ? Mar 20, 2020 22:31 |
|
omeg posted:I'll take printf formatting over iostream any day. Talk about damning with faint praise.
|
# ? Mar 20, 2020 23:07 |
|
Athas posted:C's weird quirk around everything turning into doubles is yet another example of poo poo That Is Wrong With C, and which has nothing to do with having to support low-level programming. It just sucks. Another example is the declaration syntax. The worst is the implicit conversions. Integer promotion rules
|
# ? Mar 20, 2020 23:09 |
|
omeg posted:I'll take printf formatting over iostream any day. Use fmt unless you're some kind of barbarian
|
# ? Mar 21, 2020 03:29 |
|
omeg posted:I'll take printf formatting over iostream any day. Thankfully it is no longer 1995 and those are not your only two options any more.
|
# ? Mar 21, 2020 22:32 |
|
Plorkyeran posted:Thankfully it is no longer 1995 and those are not your only two options any more. yeah, now there's boost::format!
|
# ? Mar 22, 2020 07:08 |
|
Xarn posted:Without a cast, you cannot downcast at all though. It's possible to static_cast or reinterpret_cast a pointer at compile time with no runtime checks at all. You have to explicitly opt in to runtime typechecking by deciding to use dynamic_cast, and it's "slower" so people are likely to skip it out of premature optimisation.
|
# ? Mar 22, 2020 19:12 |
|
ultrafilter posted:Someone in the Haskell community did eventually come up with a type-safe printf, but it took the better part of a decade, and I'm not sure you could do what they did in any other language. F# (and apparently OCaml as well) has one, but it relies on special-casing within the compiler, which might count as cheating.
|
# ? Mar 23, 2020 05:20 |
|
raminasi posted:F# (and apparently OCaml as well) has one, but it relies on special-casing within the compiler, which might count as cheating. Rust has one! Rust's println! macro basically just calls rust's version of ToString on every argument and then shoves all those into the format string, which AFAIK is a pretty much foolproof way to do printf entirely type-safely in any lang. (Actually it calls 'fmt', which doesn't return a string but instead writes text to a "formatter" object, I guess like a C++ stream kinda thing? Presumably this helps to avoid creating a million unnecessary strings at runtime. And then there are a bunch of different functions that have to be defined on the type for it to work with the other printf specifiers like printing in binary or hexadecimal.)
|
# ? Mar 23, 2020 11:31 |
|
Just use std::format
|
# ? Mar 23, 2020 12:49 |
|
Just serialize into XML.
|
# ? Mar 23, 2020 13:15 |
|
Absurd Alhazred posted:Just serialize into XML. Just dump in it hex. Kids these days, never had to read a core dump to figure out why their program doesn’t work.
|
# ? Mar 23, 2020 17:34 |
|
Jesus gently caress stop creating duplicated code you fucks! Has anybody heard of a function before?
|
# ? Mar 26, 2020 19:08 |
|
|
# ? Jun 5, 2024 19:46 |
|
Yes, I've heard they're slower than writing code inline
|
# ? Mar 26, 2020 19:47 |