When dealing with list input in C, as in this question, is it acceptable to add extra argument to indicate the length of the list?
It does give advantages because other language needs functions like len(M), but I cannot figure out a simple way to represent such a list in C.
I estimate 15% of my Python golfs with list input could be shortened by taking in its length, if that were allowed. Hundreds of golfs in mainstream languages could be improved by mechanically replacing "len(l)" or similar with an input parameter.
These submissions strongly suggest that golfers wouldn't guess this to be allowed without knowing the rule specifically. This is a hidden rule of the worst kind -- broadly useful, unexpected, and likely to make golfs more boring on average.
I'm sympathetic to the problems languages like C have with cumbersome input processing, especially as they already have many disadvantages. Golfing languages can be designed around such issues, but C is stuck with them.
But, I want to avoid the trend of giving all languages an easy extra workaround because one language really wants it. The result is a laundry list of liberties with input that go beyond taking it conveniently and naturally for the language, to doing parts of the golfing task in the input format, justified by citing obscure meta threads about other languages.
I'd rather say that this is a property of C that golfers need to deal with, or that a C-specific rule be made. Either one would be better than changing the rules for all languages.
main function does so!
\$\endgroup\$
Jul 9, 2017 at 15:09
This is an interesting indication of the way PPCG has changed since the early days. I remember when a lot of questions included the length as a separate input and people commented with requests to make it optional because their high-level languages didn't need it.
In most high-level languages an array is effectively a struct with a pointer and a length. I don't see that there's any point to creating a standard struct template. However, it does seem perfectly reasonable to interpret "array" in a question as meaning "pointer and length, as encapsulated in your language". In the case of C the simplest "encapsulation"* is as two variables.
* Yes, I get the point that it's not really encapsulation if you can split them up, hence the scare quotes. But such pedanticism is not the point here.
In non-golf C, taking the length of an array as a parameter alongside a pointer to the array is standard. Just look at the multitudes of functions in the standard library that do exactly that. So, a precedent exists for the language.
In general, it is impossible to determine the length of an array in C without special assumptions. sizeof only works if the array was statically allocated (no malloc), and the reference hasn't decayed to a pointer (like it does when you pass it as a function parameter). There is no hack that is 100% effective.
This means that C (and other languages like it) have a severe disadvantage when it comes to variable-length input. The only surefire way to do variable-length input in C is to read from STDIN into a buffer until EOF (and if there isn't a maximum number of elements, be prepared to have to realloc that buffer). Because of the severe restriction on input formats, solutions in C are forced to use a cumbersome input format, something which the community has decided is undesirable. C solutions are essentially solving a different challenge.
So yes, let's allow solutions to take the length of variable-length input as an additional input parameter. The only challenge this change could possibly trivialize is "Find the length of a list", and that challenge would already be trivialized by the preponderance of languages with built-in list length functionality. This change will do very little harm, and much more good.
let's allow solutions to take the length of variable-length input as an additional input parameter --> Just to clarify, you are expanding this to all languages, right? So I can take an extra input l in JavaScript arrow functions that is assumed to equal a.length?
\$\endgroup\$
Not if the specifications do not explicitly allow it. There cannot be a clear line of what is allowed as extra input - sure, a list length seems reasonable, but this is really the user executing part of your algorithm. E.g., if the length of an array is allowed, why not a boolean array indicating which elements are prime? Saves a lot of effort implementing isprime if your algorithm needs it!
You are free to implement workarounds for features your language does not natively have - often, that's the part of the fun! Perhaps your language may not have a sizeof function, but why not scan the input until encountering a null byte, and calculate the length on the go?
If your language does not, in any imaginable way, perform the desired operation, you can always ask if your extra input is allowed by commenting on the OP - but do not be surprised to get a sound no - sometimes, your language is just not up for the task.
The Default Input/Output methods question is made to answer these sorts of questions. I have created an answer to that question*, for representing an array as a pointer and length. link.
I think the best way to settle this question is voting on that answer.
*As I commented above, an old answer proposed this, but was deleted, so I chose to propose my own version.
Expanding on my comment slightly:
Every language has its shortcomings and every language will come up against challenges that expose those shortcomings. If your chosen language can't achieve something natively then your options are to:
Implement a workaround. A well written "hack" to get your language to do something it was never intended to do will always impress, even it it comes at heavy byte cost. This can lead to higher upvotes and, on occasion, bounties.
Accept that your chosen language can't accomplish the task at hand and use a different language instead.
If we were to allow C to take list length as a separate argument then that sets a precedent and, once it's set, where do we draw the line?
