Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

The /prog/matic programmer

Name: Anonymous 2012-09-27 15:16

ANyways, so... I was reading The Pragmatic Programmer [1] and it occurred to me that we should probably boil these principles down for the novices amongst us. ITT things you want to carve into your colleagues' faces.

* KEEP IT FUCKING SIMPLE, MOTHERFUCKER!
* You're code is not ``clever'', it is autistic.
* Code is /not/ poetry or art. Go away! Fuck your OCD.
* This shit has been solved a thousand times over.
* You do not need to design with the latest and greatest in gang-of-four approved OOP design patterns, using infinitely scalable NoSQL solutions in hip new languages that compile down to JavaScript (srsly WTF?!), just to create a CRUD application.
* Not everyone gets off on code, some of us just want to make a living doing the least amount of effort that is required to deliver a consistent quality for an extended period of time.

I swear by god if I see one more AbstractControllerFactoryInterface

[1] http://pragprog.com/the-pragmatic-programmer, easily found online.

Name: >>80 2013-05-13 12:43

Of course, assuming the average x86 desktop and an ANSI compiler.

Name: Anonymous 2013-05-13 12:43

it looks like your real problem is files with individual lines stretching beyond 4GiB, or 16EiB
Then it's a retarded problem to begin with, reading a file that size one byte at a time is going to take ｆ　ｏ　ｒ　ｅ　ｖ　ｅ　ｒ.

Name: Anonymous 2013-05-13 13:31

>>82
Let it never be said that I didn't think this problem was completely retarded to begin with. Especially the smarm of `a decimal integer,' and then not even bothering to say that it must be the correct integer. What, am I going to be a smartass and display the line number in hex, then be considered inferior to the guy who just puts `17' for each line? Because that's how the problem works as written.

Name: Anonymous 2013-05-13 13:51

>>83
And does it have to be an ASCII decimal integer?

Name: Anonymous 2013-05-13 14:03

>>80
No, with your program, the final line (number 4294967296 -- you're counting from 1, remember?) would make i overflow and be printed as 0.

Name: Anonymous 2013-05-13 14:16

>>85

That's a trivial fix though - he can just use long instead of int and change that %u to %lu.

Name: Anonymous 2013-05-13 14:19

>>64
Come the fuck on, just what in the fuck do you want?

Name: Anonymous 2013-05-13 14:23

>>87
Maybe if you read the problem, preferably the entire problem, and then think about the problem space, after having read the problem, the problem space will allow you to think (preferably twice) about the answer which is, after all, in the space of the space of answers answering the problem space, which you should think of having read, hmm?  Also, please see the BIG HINTS at >>88 and >>thinkabouttheproblemspace!

Name: Anonymous 2013-05-13 14:31

Is Cudder-様 telling us to prepend the line numbers to a file that we can't even read, write, touch or think about?

Name: Anonymous 2013-05-13 15:03

Well, this is interesting. Not sure where the newline went, something weird from using null I guess. But it didn't blow up.

$ dd bs=1024 count=4194305 if=/dev/zero of=test
4194305+0 records in
4194305+0 records out
4294968320 bytes transferred in 104.261202 secs (41194310 bytes/sec)
$ gecho -e "\nline2\nline3" >>test
$ perl -pe 's/^/$. /' test
1 2 line2
3 line3

Name: Anonymous 2013-05-13 15:54

>>85,86
Read the statement again: "You may assume files have no more than 2^32-1 lines".
The maximum line would have number 2³² - 1 = UINT_MAX, and that IS NOT FSCKING ZERO.

Name: Anonymous 2013-05-13 16:26

OP is a fag

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2013-05-14 7:55

I think you'll all just make me facepalm more if I let you continue, so I'll explain it all now.

>>67 was the closest "why".
and it looks like your real problem is files with individual lines stretching beyond 4GiB, or 16EiB, or whatever, which would mean that your catch is `you better not store each line in an array as you read it in.'
Not quite. It'll die as soon as you have a line bigger than available memory. which may be several MB. Everything else you say isn't the main issue here. The main issue with the first few solutions is YOU ARE USING O(N) MEMORY WHEN YOU SHOULD ONLY BE USING O(1). That's why I said it doesn't matter whether you buffer or not. You can read in 64K at atime to buffer, no problem. But the moment you think of reading an "entire line" into memory at a time, you've FAILED.

>>70
>>34 is not correct because of getchar's return type. And it uses recursion and reinvents printf%u unnecessarily. Nothing else.

>>80
This is a pass, maybe overly complicated but if this was written on the first try it's a pass.

>>73
being meguca is suffering

Name: Anonymous 2013-05-14 8:44

Cudder please grace us with your O(1) memory usage C solution.

Name: Anonymous 2013-05-14 8:57

>>93
YHBTL

Name: tdavis 2013-05-14 9:22

>>93
really punish

Name: Anonymous 2013-05-14 9:28

>>93
if you thought of needing an array of some sort, you're not getting the job.
Based on your initial statement, you should be the one without the job. Attempting to process files with lines of the sort of length you're describing without using an array to handle the data in reasonably sized chunks is ludicrous.

Name: Anonymous 2013-05-14 9:31

>>93
which may be several MB
What is swapping?

Name: Anonymous 2013-05-14 10:36

>>100
nice dubs gro

Name: Anonymous 2013-05-14 10:55

>>99
Thanks, you too.

Name: DALMATIANS 2013-05-14 11:03

DALMATIANS

Name: Anonymous 2013-05-14 11:38

>>101
nice dogs bru

Name: Anonymous 2013-05-14 12:47

woof woof bark auuuuuu LeChuck arf arf arf

Name: Anonymous 2013-05-14 16:27

>>82-84
Yes, I have noticed that, but assumed the obvious.

Not forever, but RUBY AS FUCK I agree. So, taste this:

#include <stdio.h>

int main()
{
    char buf[4096];
    int line = 1;
    while(!feof(stdin)) {
        size_t i = 0;
        size_t j = 0;
        size_t n = fread(buf, 1, sizeof(buf), stdin);
        while (i < n) {
            if (j < n) fprintf(stdout, "%u ", line++);
            do {
                j++;
            } while ((j < n) && (buf[j-1] != '\n'));
            fwrite(&buf[i], 1, j-i, stdout);
            i = j;
        }
    }
    return 0;
}

:3

Name: >>104 2013-05-14 16:30

There is a bug, but that's okay! ^_^

Name: Anonymous 2013-05-14 21:04

>>104
http://pubs.opengroup.org/onlinepubs/009696899/functions/memchr.html

Name: Anonymous 2013-05-14 21:54

>>1
You say ``fuck'' too much.

Name: Anonymous 2013-05-14 23:24

>>96
heheh, golden calf

Name: Anonymous 2013-05-14 23:34

le moses game

Name: Anonymous 2013-05-15 0:00

rule 110 get.

Name: 111 2013-05-15 0:13

Rollin for trips. If I gets, OP has to kill himself.

Name: Anonymous 2013-05-15 7:37

>>111
Fuck off, spammer.

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2013-05-15 7:37

>>94
Something like this.

>>97
stdio includes buffering.

>>98
A "safety vent" to prevent hard crashes. You should never be running a system at that load level, because it'll be unacceptably slow. Some of the systems I work on don't even have secondary storage.

>>104
getchar and putchar will do buffering for you automatically, and they're inlined because they're macros in any good C library, so you're introducing additional overhead by buffering twice. MSVCRT's default buffer is 4K, glibc is also 4K.

>>106
This *might* be faster but you should then turn OFF stdio buffering. Either way I'm not interested in absolute speed with this question, and using 1000x the memory for <1000x speed increase is inefficient (see also: 10KB --- yes, ten thousand bytes --- implementations of memcpy() that achieve maybe a few % speedup in careful benchmarks over rep movsd and probably much less on Nehalem and Sandy Bridge).

Name: Anonymous 2013-05-15 7:47

>>113
stdio includes buffering.
And using it means violating the criteria given for this problem, resulting in horribly inefficient execution.

Name: Anonymous 2013-05-15 15:37

Don't you need O(n) memory for the case when you only have an array of '\n'.

Name: Anonymous 2013-05-15 16:27

>>115
No.  Why would you? '\n' is just a character.  It causes no more memory to be required than if it were 'a'.

Name: Anonymous 2013-05-15 17:13

>>116
Overwriting characters with the line numbers while updating the file.

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2013-05-16 2:21

>>114
No it doesn't.

>>117
In case you haven't noticed, the problem was about writing a filter, not an in-place algorithm.

Name: Anonymous 2013-05-16 7:45

>>118
So a buffer isn't an array?

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2013-05-16 7:47

>>119
It's a fixed-size one.
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -