|
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.
|
![]() |
|
![]()
|
# ? Jun 6, 2024 23:51 |
|
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 |
![]() |
|
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.
|
![]() |
|
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?
|
![]() |
|
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.
|
![]() |
|
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.
|
![]() |
|
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.
|
![]() |
|
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
|
![]() |
|
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.
|
![]() |
|
ultrafilter posted:
Just use token pasting. code:
|
![]() |
|
Presto posted:Just use token pasting. Not enough, because now you need to manually know what the static const ints are called! code:
|
![]() |
|
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. ![]()
|
![]() |
|
I don't think anyone has used x macros yet
|
![]() |
|
Because X macros are great!
|
![]() |
|
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 !!!! ![]()
|
![]() |
|
"don't use variadic functions in embedded systems" seems like a pretty reasonable restriction.
|
![]() |
|
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?!
|
![]() |
|
Cast float32s to int32s before using as a parameter to a variadic function boom done.
|
![]() |
|
printf considered harmful
|
![]() |
|
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 ![]()
|
![]() |
|
qsvui posted:printf considered harmful yep
|
![]() |
|
We have printf but it's a custom implementation that doesn't understand %f and friends.
|
![]() |
|
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.
|
![]() |
|
qsvui posted:printf considered harmful I'll take printf formatting over iostream any day.
|
![]() |
|
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 |
![]() |
|
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.
|
![]() |
|
C has essentially typesafe printf if you compile with -Wformat -Wformat-nonliteral -Werror, like you should
|
![]() |
|
omeg posted:I'll take printf formatting over iostream any day. Talk about damning with faint praise.
|
![]() |
|
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
|
![]() |
|
omeg posted:I'll take printf formatting over iostream any day. Use fmt unless you're some kind of barbarian
|
![]() |
|
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.
|
![]() |
|
Plorkyeran posted:Thankfully it is no longer 1995 and those are not your only two options any more. yeah, now there's boost::format!
|
![]() |
|
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.
|
![]() |
|
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.
|
![]() |
|
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.)
|
![]() |
|
Just use std::format
|
![]() |
|
Just serialize into XML.
|
![]() |
|
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. ![]()
|
![]() |
|
Jesus gently caress stop creating duplicated code you fucks! Has anybody heard of a function before?
|
![]() |
|
![]()
|
# ? Jun 6, 2024 23:51 |
|
Yes, I've heard they're slower than writing code inline
|
![]() |