Timeline for Generate a deck of cards
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 12, 2018 at 4:39 | comment | added | ceilingcat |
Suggest char*[] instead of char*[54]
|
|
| Jun 11, 2018 at 18:41 | history | edited | LambdaBeta | CC BY-SA 4.0 |
-4 bytes
|
| Jun 11, 2018 at 17:59 | comment | added | Adalynn |
You can remove the space after S(X).Also, add a comma after its definition, then use remove each comma after its call.
|
|
| Jun 11, 2018 at 16:50 | comment | added | LambdaBeta | I agree that macro functions are definitely borderline (which c is, despite having no argument list). The relevant meta post states that "The default should be "programs or functions" This includes function-like constructs, including J's verbs and GolfScript's and CJam's blocks. I would argue that C macros are as function-like as J's verbs or GolfScript's blocks (though not CJam's blocks, as they can be assigned to variables and manipulated, the analogue of function pointers) | |
| Jun 11, 2018 at 16:37 | comment | added | Jakob | Oops. You're right about initializers being expressions. I agree with Jonathan though that consensus is that a C submission must be a function or full program. | |
| Jun 11, 2018 at 16:34 | comment | added | Jonathan Frech | I get your deep copy argument that macros are more function-esk than variables, though I do not think that is enough for them to be on par with functions regarding the I/O consensus. | |
| Jun 11, 2018 at 16:12 | comment | added | LambdaBeta | Here is my reasoning why the macros are more functional than a variable declaration: Try it online! | |
| Jun 11, 2018 at 16:07 | history | edited | LambdaBeta | CC BY-SA 4.0 |
More complete example.
|
| Jun 11, 2018 at 15:55 | comment | added | LambdaBeta |
No, you don't need a declaration. In a for loop you could have c[53] as identical to "J" without any variable being declared. That is exactly why I argue it is different. (the only issue being typing, but we abuse that all the time with our int functions taking pointers) Changing the line in the link to printf("%s ", (char*[54])c[i]) works fine. You could argue the need for +11 bytes to add the (char*[54]) in front of the array in c though.
|
|
| Jun 11, 2018 at 15:52 | comment | added | Jakob |
Nope, you need a declaration in order to use an initializer. And this is the main reason this approach isn't valid. Not only is the expansion of c not (used in) a function, but it doesn't produce a value. It's just syntax tied to a declaration.
|
|
| Jun 11, 2018 at 15:45 | comment | added | LambdaBeta |
The issue there is that z is in a variable and is the value of that variable. Many languages use 'inline blocks' as a valid submission format (e.g. J's unnamed verbs) this is similar in that it can be inlined directly. Note that I would consider the equal length second line of char*c[]={...}; invalid as it does not do what a C function normally would (return a new value on the stack). If you need a function then a second line of char*[54]f(){return {...};} would work I think.
|
|
| Jun 11, 2018 at 15:41 | comment | added | Jonathan Frech |
I do not think that is a fair comparision as you first change the supposed function, then only change the supposed function's return value. z=0;/**/c=z;c++;x=z; results in x==0, thus z acts like a function.
|
|
| Jun 11, 2018 at 15:36 | comment | added | LambdaBeta |
no, but I would consider #define z 0 valid. The reasoning is that: c=0; c++; x=c; results in x == 1 so c doesn't act much like a function. Meanwhile #define z 0 c=z; c++; x=z; does result in x == 0 so z acts like a function.
|
|
| Jun 11, 2018 at 15:34 | comment | added | Jonathan Frech |
If there was a challenge to output the integer zero, would you consider the C code c=0; a valid submission, viewing c as a function?
|
|
| Jun 11, 2018 at 15:21 | comment | added | LambdaBeta |
Except c is not an array, it would be an in-place literal. Each 'invokation' of c in the source will create a new copy of the array in the resulting executable (barring optimizations). Thus, the code char *a[] = c; char *b[] = c; create two deep copies of c. This behaviour is what you'd expect of a function as well.
|
|
| Jun 11, 2018 at 15:19 | comment | added | Jonathan Frech |
I would argue that c is not a "[...] weird 'function' [...]" but rather an array declaration stored in a macro. Such a form of output is to my knowledge not permitted by default.
|
|
| Jun 11, 2018 at 14:37 | history | answered | LambdaBeta | CC BY-SA 4.0 |