|
That seems like a good solution; no variadics in the actual language, only in a not-sucky metaprogramming layer (where the metaprogramming's run time is the overall program's compile time)
|
# ? Jun 29, 2020 00:52 |
|
|
# ? May 21, 2024 02:09 |
|
The Rust/C++ approach is really flexible but absolutely horrific for code size and compile time.
|
# ? Jun 29, 2020 03:29 |
|
https://gist.github.com/chrisdone/672efcd784528b7d0b7e17ad9c115292 Dependently typed printf is pretty cool
|
# ? Jun 29, 2020 03:40 |
RPATDO_LAMD posted:At compile time the variadic macro in println!("The cat is {} years old", 7) is transformed by And then you have the problem when you want to translate your software. If the strings are broken up at insertion points then translations that require different sentence structure might require recompiling the entire program, instead of just changing some strings data.
|
|
# ? Jun 29, 2020 10:25 |
|
Ola posted:If C was made today, I am convinced you could make a type safe, non-variadic "print to console" function that was every bit as a fast as printf. It was a fair mistake made at the time, there is no need to repeat it. Not in C. In C++ you can make one that is actually significantly faster right now, by abusing compile-time format string processing. Ola posted:Which begs the question why do you want to make something that seems like you can, with terrible consequences if you get it wrong, instead of making it easy to use with clearly defined rules that says what you can or can't? The most likely answer is academic circlejerk, with "sins of the fathers" a close runner up. Even if you write C today, you don't have to acknowledge or emulate it in any way, you can write whatever you want as type safe as you should. I am going to take it from the back. The limit on tuple's type list length is implementation defined. The standard recommends some baseline numbers to support, I think the applicable one here is either [temp.inst] or [temp.param], both of which are 1024. And the answer to why have variadic functions, the problem here is that people keep conflating C's it-was-a-good-idea-50-years-ago runtime variadics, and newer solutions using their lang's support for variadic type packs, e.g. C++ code:
|
# ? Jun 29, 2020 11:12 |
|
nielsm posted:And then you have the problem when you want to translate your software. If the strings are broken up at insertion points then translations that require different sentence structure might require recompiling the entire program, instead of just changing some strings data. Yeah, not everything needs precompiled formatters. OTOH, I don't think anyone ever translates their log messages.
|
# ? Jun 29, 2020 11:18 |
|
I managed to write a routine to check for lines in a file with duplicate identifiers that was quadratic in the number of lines. Good thing I took the time to add a unit test that tries it on real data. 40 seconds in debug to check over a file with just 7,000 lines. Swapped it out for a Dictionary-based approach and it takes 70ms. Good work me from 3 days ago or something
|
# ? Jul 3, 2020 18:38 |
|
It would be taking it too far to call this a Coding Horror, it's more like Coding Idiosyncracies And Their Interesting But Perhaps Not Ideal Effects I can kind of see the point of writing Git commits in imperative form, and I will stick to it if told. But isn't that idea based on some git master (perhaps an angry Finnish one) merging in the single commit in the same terminal environment it was made, performing the imperative action by doing so? But I've never seen that actually happen. It's more like this is a pull request in a web interface with one or a million commits, many of which where pushed just to save game before boarding a plane or whatever, most of the commit messages are just "wip" and "woops" but the PR text actually contains a well written summary and a link to the project management ticket. And once it's approved by someone else in a code review, the person who wrote it does the merging. Still, fair play if I work with you and you want it like that. Then I'll write it like that. Also, I can definitely see the usefulness of generating patch notes from carefully written commits. However, I'm definitely not having patch notes on the imperative form. In doesn't make any sense. Are the patch notes promising me things they will do in the next patch? Or is it some sort of open source awareness stunt, trying to get me to contribute by giving me a list of stuff to fix it myself? tl;dr write git commit -m "fixed bug gently caress you"
|
# ? Jul 4, 2020 19:55 |
|
You can write whatever you want in your local commits, as long as you clean it up and squash before you put up your CR.
|
# ? Jul 4, 2020 20:01 |
|
Adhemar posted:You can write whatever you want in your local commits, as long as you clean it up and squash before you put up your CR. But "what you want" and "clean it up" depends on some particular policy. Maybe 500 "wip" commits is ok in many companies. The particular policy I'm getting at is the dogma of imperative form.
|
# ? Jul 4, 2020 20:05 |
|
Ola posted:But "what you want" and "clean it up" depends on some particular policy. Maybe 500 "wip" commits is ok in many companies. The particular policy I'm getting at is the dogma of imperative form. “What you want” is literally whatever you want because nobody else ever has to see it (your local commits). The cleaned version does indeed vary wildly in different companies. I’ve never heard of this imperative form thing, that seems overly pedantic.
|
# ? Jul 4, 2020 20:19 |
|
idk how you can be against variadic templates in C++. Everybody was doing horrible hard to read bullshit to pretend to have varargs anyway, first-class support just made all of that less awful. If I never have to see a function copy+pasted 17 times to cope with all amounts of arguments it might be called with ever again, I'll die happy. Meanwhile try scrolling through the docs for tuples in rust, https://doc.rust-lang.org/std/primitive.tuple.html, or this bullshit that is partially ifdef'd to hide its shame from autogenerated docs: http://hackage.haskell.org/package/base-4.1.0.0/docs/src/Data-Tuple.html
|
# ? Jul 4, 2020 20:20 |
|
Adhemar posted:I’ve never heard of this imperative form thing, that seems overly pedantic. Ah, well there we go, that's the misunderstanding. Some are super strict on this, many have heard about it and just accept it as the done thing. And as the screenshot illustrates, the Notepad++ team seems to do it and then generate patch notes from it. edit, example: https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53 quote:Short (72 chars or less) summary Wrap it to 72 characters, strictly imperative form...? Sounds suspiciously like something a particularly feisty Finnish penguin would come up with.
|
# ? Jul 4, 2020 20:21 |
|
Vanadium posted:idk how you can be against variadic templates in C++. Everybody was doing horrible hard to read bullshit to pretend to have varargs anyway, first-class support just made all of that less awful. If I never have to see a function copy+pasted 17 times to cope with all amounts of arguments it might be called with ever again, I'll die happy. This is probably aimed at me, but I guess I haven't scrolled as many copy pasted things as you therefore I do not have the same opinion. The generated docs and definitions are useless, but do you even need them once you learn that a tuple is some types in paranthesis with comma between and sadly the native one has a hard limit at 17 or whatever? It's not like you go diving in there looking for the subtle particularities which kick in when you go from 14 to 15 types.
|
# ? Jul 4, 2020 20:29 |
|
Edit: ^^^ not aimed at you in particular, I'm just surprised at the consensus itt. Yeah, it's not like the docs are particularly the problem, they just demonstrate how awkward it gets if you try to write anything flexible enough to support variable amounts of values or whatever. From the people that brought you arrays that can only be equal or unequal to other arrays up to length 32: code:
Vanadium fucked around with this message at 20:32 on Jul 4, 2020 |
# ? Jul 4, 2020 20:29 |
|
Funnily enough, Linus is not a big proponent of 72 char limit on code, but things like GitHub and GitLab UI start breaking if the first line of your commit msg is overly long. ---e---- In regards to variadic, I am much more mad about having to copy paste code for multiple template args instead of being able to define a variadic type pack, than I am about low limit on its size... I think the only place where I wrote code using variadic type pack with more than 10 types was a compile-time test for that template Xarn fucked around with this message at 20:38 on Jul 4, 2020 |
# ? Jul 4, 2020 20:35 |
|
Copy pasting code is the easiest work I can do. The common variant:code:
code:
code:
Am I naive? What case does variadic behaviour solve in the current C++ world with a worthwhile tradeoff, given that he code is maintained by people who are not all C++ wizards?
|
# ? Jul 4, 2020 21:39 |
|
I find your lack of imagination... disturbing. I am going to use an example from a library I maintain, specifically the part that provides generic Hamcrest-style matchers for assertions. After recent changes to take full advantage of variadic templates, the usage looks something like this C++ code:
C++ code:
So far so good, the type even has a base class that could in theory be used to hold it in a single-type container... except that loses access to match, because you obviously cannot have templated virtual member functions. So, if you are to store multiple matchers like this (e.g. when you are constructing a generic MatchAll matcher), and use them to do matching, you have to keep around their actual types. That is where variadic template packs come in. The following is the implementation of MatchAll C++ code:
C++ code:
Now, could I just stamp out tons and tons and tons of overloads to handle all this? Yes. But the tradeoffs for that are worse compilation times and worse maintenance experience later on -- imagine deciding to improve describe's output, and then having to account for subtle differences between the 30 different overloads Are these tradeoffs potentially worth it? Maybe. Is it worth it because someone is afraid of variadic types? Definitely not. And as to maintenance by others... the whole point of libraries and abstractions is that the hard parts can be written be people familiar with the domain, while the users do not need to understand that complexity.
|
# ? Jul 4, 2020 22:51 |
|
The only "objective" argument for writing commit messages in the imperative tense is that it's typically the shortest form so you can fit more words in the subject line. It's something that doesn't matter very much, but there's also no reason not to just follow what the tool recommends.
|
# ? Jul 4, 2020 22:52 |
|
Other things variadics are used for are things like generic factory functions (make_unique, make_optional, (j)thread), and doing terrible things to your compiler for profit (precompiling regexes, format strings).
|
# ? Jul 4, 2020 22:53 |
|
Plorkyeran posted:The only "objective" argument for writing commit messages in the imperative tense is that it's typically the shortest form so you can fit more words in the subject line. It's something that doesn't matter very much, but there's also no reason not to just follow what the tool recommends. Yeah, I tend to write in 3rd person ("Fixes bug caused by unexpected interaction between foos and bars"), but when I run out of characters for summary and have to shorten it, I usually end up at imperative tense to save those precious characters.
|
# ? Jul 4, 2020 22:55 |
|
What's it called when a c++ function has an argument with a default value? I like and often use that kind of variadicity. Obviously not the same as what everyone else is talking about, though
|
# ? Jul 4, 2020 23:11 |
|
Xarn posted:MatchAll! Thank you, very interesting example! If it's easy to use and works well, obviously no problems. But the topic did come up as variadic being harder to handle than non-variadic. And the case you illustrate doesn't have to be variadic to solve the usefulness of having an arbitrary number of matchers: A single matcher can be a list of one matcher. The && or || or other operators concatenate lists of matchers according to appropriate rules, then return lists of matchers. Obviously these get evaluated before the function call. The function called which deals with matching takes two arguments, something to be matched and a list of matchers. No need for arbitrary amounts of arguments, no need for variadics.
|
# ? Jul 4, 2020 23:46 |
|
QuarkJets posted:What's it called when a c++ function has an argument with a default value? I like and often use that kind of variadicity. Obviously not the same as what everyone else is talking about, though I think that under the hood it's essentially the same as overloading.
|
# ? Jul 4, 2020 23:50 |
|
Xarn posted:And this is what the free && operator looks like: Is that some new syntax? It looks like you are declaring a function called &&() as opposed to operator&&().
|
# ? Jul 4, 2020 23:56 |
|
Ola posted:Am I naive? What case does variadic behaviour solve in the current C++ world with a worthwhile tradeoff, given that he code is maintained by people who are not all C++ wizards? Are you arguing against variadic functions in general, or C++'s specific implementation? In general, they can be a useful way to pass a list of arguments determined at compile time, for something like printf or a logging function. Why copy-paste (and run the risk of errors buried in your pile of almost-but-not-quite identical logic) when you don't have to? C++'s implementation is ugly because there's no way to express "some type, I don't care what it is" without templates, and that's a common case for variadic functions. Java, C#, and most other modern OO languages handle variadic functions in a clean, type-safe way by just giving you an array of params, that can be of the base object type or anything else you want.
|
# ? Jul 5, 2020 00:06 |
|
Plorkyeran posted:The only "objective" argument for writing commit messages in the imperative tense is that it's typically the shortest form so you can fit more words in the subject line. It's something that doesn't matter very much, but there's also no reason not to just follow what the tool recommends. This and other character limit arguments begs the question why there are character limits at all. What was the original limitation Linus based it on? When I write commits now in VS Code, it warns me when I get near and when I cross it. But when I keep writing it shuts up. I push, all my characters are intact on Github. In VS I think it doesn't even warn me. What does the character limit do, who or what is it for? There is obviously nothing bandwidth wise limiting it in any aspect, as you can send bagillions of bytes of code along with your limited commit message. Is it just the emperor penguin deciding that 72 bytes should be enough for anyone? *googles* https://www.midori-global.com/blog/2018/04/02/git-50-72-rule Yes, it is the emperor penguin. quote:What is the 50/72 rule? Now that is a coding horror. It seems more like tyrannical behavior rather than promoting good processes, trying to quench upstarts who can't quite stick to the "make one change" dogma. If you babble, can't quite put it to me in 72 characters, denied. Any Git implementation I've used seems to agree because there's no actual character limit, just a GUI warning. There is obviously no good reason to say another organization outside the Linux kernel team should limit themselves to any number of characters. What if the link to my project management tool is always 73 characters long? And there is obviously no universal rule that says ideas are always sufficiently explained in 72 characters or less.
|
# ? Jul 5, 2020 00:09 |
|
I think you missed the “arbitrary number of 72 character-wide lines” part. No one’s saying you’re limited to exactly 72 characters after a 50 character subject line. It’s still a stupid loving rule.
|
# ? Jul 5, 2020 00:18 |
|
Why 72? I thought 80 was the width of those dumb terminals from the 1970s.
|
# ? Jul 5, 2020 00:26 |
|
Space Gopher posted:Are you arguing against variadic functions in general, or C++'s specific implementation? I'm arguing against the idea of an arbitrary number of function arguments being better than a finite number of arguments. The bolded bit is not a problem. A list of something is one argument. Although in Bash, it seems like you give an "arbitrary list", but it's an arbitrary input which turns into a single list of ok inputs or a crash. It's an arbitrary amount of arguments I don't like, and the discussion got started by people having had trouble with variadic implementations and maintenance. It does seem like there is no modern need for variadics, other than to support old structures where it was more like variadics weren't explicitly banned rather than actively supported. Something I alluded to earlier was the academic circlejerk, that is always a factor unfortunately. The theoretical scene might have grand ideas about how amazing variadics are and push for their support in a language, without being interested in the fact that it might not be very useful to anyone actually programming something.
|
# ? Jul 5, 2020 00:30 |
|
Space Gopher posted:Are you arguing against variadic functions in general, or C++'s specific implementation? Accepting an array of base-object pointers and attempting to cast them to the appropriate type at runtime sounds like the exact opposite of type-safe. The only advantage of that over C-style printf is that you get an actual exception when it fails at runtime instead of garbage data or a crash.
|
# ? Jul 5, 2020 00:35 |
|
zergstain posted:Why 72? I thought 80 was the width of those dumb terminals from the 1970s. it's worse than you think
|
# ? Jul 5, 2020 00:38 |
|
csammis posted:I think you missed the “arbitrary number of 72 character-wide lines” part. Yeah, I definitely missed that part, because I wasn't rubbing my fingers and sniffing the finer grains of the stupid bullshit. "Ideal values"
|
# ? Jul 5, 2020 00:40 |
|
The only problem I have with variadic templates in C++ is that it introduces a separate foreach notation instead of using the one they've already established.
|
# ? Jul 5, 2020 00:41 |
|
Incredible computer scientific foresight to accommodate the Linux kernel community's idea of an ideal commit message length value.
|
# ? Jul 5, 2020 00:45 |
|
zergstain posted:Why 72? I thought 80 was the width of those dumb terminals from the 1970s. Probably a combination of git log indenting (but only by... 4 spaces?) and allowing for some amount of "> " when quoting commit messages in emails.
|
# ? Jul 5, 2020 01:43 |
Ola posted:Incredible computer scientific foresight to accommodate the Linux kernel community's idea of an ideal commit message length value. Wasn't git created for Linux kernel development? It kind of makes sense from that perspective.
|
|
# ? Jul 5, 2020 03:23 |
|
The fart-huffing bit is declaring that the "ideal" limit is shorter than about half of the commit messages that your project already uses.
|
# ? Jul 5, 2020 04:34 |
|
Jabor posted:The fart-huffing bit is declaring that the "ideal" limit is shorter than about half of the commit messages that your project already uses. make a tool that does this, a snazzy website, and sell this poo poo like crazy as a consultant
|
# ? Jul 5, 2020 04:35 |
|
|
# ? May 21, 2024 02:09 |
|
Ola posted:This and other character limit arguments begs the question why there are character limits at all. What was the original limitation Linus based it on? When I write commits now in VS Code, it warns me when I get near and when I cross it. But when I keep writing it shuts up. I push, all my characters are intact on Github. In VS I think it doesn't even warn me. What does the character limit do, who or what is it for? There is obviously nothing bandwidth wise limiting it in any aspect, as you can send bagillions of bytes of code along with your limited commit message. Is it just the emperor penguin deciding that 72 bytes should be enough for anyone? I think the suggested limit of 50 characters for the subject line is overly short (especially when you're doing things like putting ticket numbers in the subject), but if you're going way over it then you've probably failed to actually write a subject line and should put most of that in the body. I don't really see a reason to give a gently caress about what the line character limit for the body is. I just write some text then hit the word wrap button in my text editor.
|
# ? Jul 5, 2020 05:46 |