» | 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. |
|
» | 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. |
|
» | 9 guest@cc 2018-08-07T16:50:25well, 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. |
|
» | 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. |
|