[Return] [Catalog]

1 guest@cc 2018-07-30T04:20:15 [ImgOps] [iqdb]
File: angry-witch-rotten-apple-long-… (JPEG, 186.38 KB, 957x1300)
So, I finally decided to properly try to learn C.

>main(){printf("suck my cock, dude\n");}

As you are all no doubt (painfully) aware, the above is a valid C program. Compilers will whine at you, even hiss and scream, but in the end, they'll do what they're told and put it together. As short and non-compliant as it is however, several points of redundancy still come out to me.

main: Not useful here, as we're just using one (proper) function, anyway.
(): These brackets do nothing. That is their explicit purpose.
"": We should be able to omit these, and have the compiler recognise the area between those brackets as a plain old string. Since I'm inexperienced, I don't know whether that's on the C language itself, or stdio, though.
;: As far as I can understand, the purpose of the semicolon is to separate functions from eachother. printf is the last (not to mention, ONLY) function in this area, so I can't see what it adds.

In short, I think this should be a valid C program:
>printf(suck my cock, dude\n)


To go about doing this, I propose that we create a new language, which is to be called "Corner-Cutting C", so we can shave off as many of those nasty little bytes as possible. Who's with me?
»
2 guest@cc 2018-07-30T06:02:03
sounds like you want perl
»
3 guest@cc 2018-07-30T15:09:24
>>2 I think I like this language.
»
4 guest@cc 2018-07-30T20:58:54
You can put non-strings inside printf though. So it would try to interpret 'suck' as a variable. Good luck trying to think of ways out of that pickle.
The only potential shortcut I see is for 1 line function calls to replace the parens with a space
>printf "suck my cock dude\n"

I don't think a few bytes in source code is worth it anyway. The final binary is going to be the same and that's what really matters.

The real benefit would be not having to press shift all the time to type annoying brackets and parenthesis. I'd also prefer if every language allowed single quotes instead of double.
»
5 guest@cc 2018-08-06T20:30:45
>>1
That's a weird way of doing it, OP.
Here's what you should really do:
//File: main.cpp
#include <iostream>
using namespace std;
int main() {
cout << "suck my cock, dude" << endl;
return 0;
}[/code]
I use C++ but I didn't use any C++ specific stuff.
>(): These brackets do nothing. That is their explicit purpose.

Oh wow. You have a LOT to learn if you think they do nothing. It's for function arguments. For C/C++ specifically, you could write a program that can take arguments directly from the command line, and they are passed to the main function.
>"": We should be able to omit these

Do you know the difference between a string and a variable?
[code]cout << cock << endl
will attempt to cout the value of the variable cock, not the string.
>In short, I think this should be a valid C program:

No, no, no. You are learning the wrong language if that's what you want to do.
Learn Python. Perl is old and too terse. Python is concise, unlike verbose languages like Java. It's very readable and easy to use. Of course, the automatic memory management, pseudocode-like syntax, forced indentations, and dynamic typing might set you up for some bad practices when you eventually learn other languages later. But I guess it's ok for beginners.
»
6 guest@cc 2018-08-07T00:07:51
>>(): These brackets do nothing. That is their explicit purpose.
>Oh wow. You have a LOT to learn if you think they do nothing. It's for function arguments. For C/C++ specifically, you could write a program that can take arguments directly from the command line, and they are passed to the main function.

What's the point in specifying an area for arguments, when there's no arguments? A compiler should be able to handle this (not a C compiler admittedly, but that's the whole point here).
>>"": We should be able to omit these

>Do you know the difference between a string and a variable?

It might not be sane, but I think it's reasonable for the compiler to assume it's not a variable, when no variables have been declared.

Also that iostream library you're using there looks funny. I don't like it.
»
7 guest@cc 2018-08-07T05:43:52
>>6
No offense, but I think you should move on and learn other language concepts instead of obsessing over syntax for hello world boilerplate. Maybe C isn't the right language for you. I think Python sounds more up your alley.

Here is a hello world program in Python:
print("suck my cock, dude")[/code]
That's the entire program. Compare that to the C++ example I posted above.

OR... just learn to accept that there are going to be design choices of a programming language that you dislike, but have to put up with anyway.

And it's not just about C. Empty parentheses for functions with no arguments is pretty normal. Same thing in Java and shell scripts too. If, for nothing else, it shows that something is a function call rather than a variable. [code]someExample[/code] could be an integer, whereas [code]someExample()
is immediately recognizable as a function call. Also, it always gives you the option of editing your code and adding functions later.

Just wondering, is this your first programming language? Because if so, I think C is not the best choice. It's good to know eventually, but starting out with C can be rough.
»
8 guest@cc 2018-08-07T05:45:29
Adding arguments later, I meant.
»
9 guest@cc 2018-08-07T16:50:25
well, judging by the thread name it doesnt seem like he actually has a problem with the way C is necesarially, hes just being perverse. obviously these things are necessary elsewhere, and what sense does it make to make what means what decided by some complicated mess of assumptions and inferences in something more robust than shell language? fun(arg, arg) is a function with two args, fun(arg) is a function with one, fun() is a function with none. programs start running at main(), theres no 'except when...' or 'unless...' in there.
I mean, isnt that right OP?
You dont actually think this is a good idea, do you OP?
>>7
>starting out with C can be rough.

Strong disagree here. C is easy to learn and actually mostly makes sense. Yes, im aware of the thorny edge cases and ambiguities, but we're talking about learning your first language aren't we, not mastering anything. So neglecting shit like that, C is far far easier to learn because its not loaded with fucking metaphysical abstractions, its features are basically simple and make sense. Nor does it have a bunch of confusing corner cutting bullshit thats supposed to make things more "natural" and "intuitive" for people who /already have a grasp on some programming/, but for beginners just confuse you. I couldnt wrap my head around "for x in y" style for loops until I learned C for loops and used them a few times.
You cant crank shit out in C as a beginner but thats a stupid complaint. Cranking worthless shit you did not need out(as you'll do as a beginner) is only valuable as a learning exercise, and in that way its not any more valuable than just doing code exercises that dont give you some dumb little thing you didnt need and did worse than someone else who did it already at the end anyway.
If you're thinking of making simple little convenience things, doing that in C(or in python. or absolutely any real progamming language, for that matter) is stupid. You have all the pieces you need for things like that right there in your /bin, ready to be combined at the shell prompt. If you feel like you need something more than that for that sort of thing you are almost certainly overcomplicating it. My password manager is 3 lines of shell. Its one-third echo. Its shorter than my prompt.
»
10 guest@cc 2018-08-08T02:00:36
>>9
For the most part, I just wanted to hear people tell me why I'm wrong. To appreciate the value of standards, you should investigate each one individually, and the best way of doing that is stretch the language itself, to figure out at which exact points the program fails to compile. Older programming languages were extra-ordinarily basic, so I wanted to figure out why they were getting more complex with time.
For the record, I still don't get the point of the practice of putting semicolons at points where they shouldn't be necessary, but the purpose of the other things are basically self-evident.

Well, I am the kind of kid who got pissed at his primary school teachers for marking me down for being "grammatically incorrect" in the same way old narrative writers and poets were, but pulling dumb hacks like these with compilers, which, unlike people, are exactly literal, is just going to fuck with cross-compatability. You don't want to need to install one exact version of a compiler to make a program for you when it doesn't work on any others.
»
11 guest@cc 2018-08-08T14:12:03
>>10
> I still don't get the point of the practice of putting semicolons at points where they shouldn't be necessary

>As far as I can understand, the purpose of the semicolon is to separate functions from eachother.

No, the purpose of semicolons is to separate statements from each other.
int
a
=
4;printf("%d"
,a )

; }

for example.
calling a function is a statement, so you put an ; at the end. C ignores whitespace. One styles their whitespace however they'd like, and marks the ends of their statements with ;.
»
12 guest@cc 2018-08-08T17:34:05
Here's what I learned in college: instead of hyper-analyzing and questioning every little detail of something, which will dramatically slow down the process of learning what you want/need to learn, just go with it and move on to the next concepts. If you want to get good with C and C++, you can't still spend time being hung up on introductory stuff.

It's good to think critically, but you're really overthinking this. Just wait until you get to pointers, data structures, and algorithms. Basic syntax really doesn't matter in the grand scheme of things. Languages are more than syntax.
»
13 guest@cc 2018-08-08T17:43:57
>>12
>just wait until you get to pointers, data structures

Those should be basic beginner shit on the same level as syntax and if they werent your classes were shit and aimed at shit people.
»
14 guest@cc 2018-08-08T18:54:53
>>13
do I have to point out the fact that the OP made a thread over-analyzing a hello world program?
»
15 guest@cc 2018-08-08T19:04:50
>>14
fair enough, 'just wait til you' made it sound like it was supposedly advanced reading to me.
»
16 guest@cc 2018-08-09T01:48:00
>>11
Sorry, right, it gets more than just functions. But still, what's the point in having one after the printf function? There's nothing to separate that last statement from, that's what I was meaning to get at.
»
17 guest@cc 2018-08-09T03:12:51
lol
»
18 guest@cc 2018-08-09T09:17:33
>>16
Because its a statement, so its ended by ;. Thats the rule. Whats the point in adding code to do this? So this hello world can have one fewer byte?
»
19 guest@cc 2018-08-09T16:27:51
Terseness is not the best measure of how good or bad a language is.
»
20 guest@cc 2018-11-30T04:12:34
touch o the tism
»
21 guest@cc 2019-01-24T16:27:18
I had some time to think about what I said, and I have to apologise. THIS is what I think should be a valid C-CC program:
>printf "suck my cock, dude

>"


Feel free to offer feedback.
»
22 guest@cc 2019-08-25T18:17:25
Dude its just like math. U have functions these are defined by having a type and a name f.e.
>int fnaddint(//any sort of arguments and options){

>//stuff u want the function to do

>return 0; //so all other programs know whether it was successful or there was an error

>}

And the u use them for example
>int output = fnaddint(summand1, summand2);

Then there are headers that define specific functions.
>#include stdio.h //defines the printf function.

Basic Rules. Ease of Use. No fucking around. Simple and clever. Flexible in its own way.
All other interpretation shit is redundant. If you don't like the way its handled. There are other languages more suitable for you.
»
23 guest@cc 2019-08-28T02:17:04 [ImgOps] [iqdb]
File: Madokas 177 (EE).gif (GIF, 61.71 KB, 300x300)
the iostream poster in this thread needs to die
it's not even c, its c++
and they're adding c style string formating to c++20 anyway with FMT
go to hell
»
24 guest@cc 2020-05-06T11:07:59
>The final binary is going to be the same and that's what really matters.
Nevertheless, the programme actually matters. A programme is a description of a process. It is the primary source about the process it describes.
Presently, many pragmïnformaticals' edifactaries are poor. It is reasonable that vainary (i.e. it's self) or tertiary (e.g. wikis) sources are poor; it's vainary source is only to do itself, it's tertiary sources are too distant. (It's antiprimary source is (only partly) accessible to only it's authors.) Wellest, often, are (sadly, often manuscribed, thus more letting organic errata) secondary sources. It's unreasonable, yet popular, that primary sources are poor.
Alarming? Don't manuscribe, let exact processes esscribe, secondaries. Literate programming, he says, is to {\sl for a person} write it, markt suffact for distal derivion of the therein described, ready for a person, understanding it, to use it.

>The real benefit would be not having to press shift all the time

That can only be a problem if you're tired. If you are {\sl tired}, you shouldn't be at the terminal. Rest. Only while refreshed, awake, et cetera can one reliably produce reliable programmes.
guest@cc 2020-05-06T21:55:03
escribe*

[Return] [Catalog]
Delete Post:
OptionsPassword
Name
Comment
File